| Author |
Message
|
| rromito |
 Posted: Wed Oct 31, 2012 10:22 am Post subject: Reloading /var/mqsi/common/wsrr/log4j.properties |
 |
|
Newbie
Joined: 31 Oct 2012
Posts: 5
|
We use log4j in our java compute nodes in our WMB 7 flows. We’ve placed a log4j.properties file under /var/mqsi/common/wsrr to enable a ConsoleAppender, which causes the logging output to go to the stdout file under the execution group directory.
This solution works great, except that we need to bounce the broker whenever we want to change the logging level in the log4j.properties file.
Is there a way to make the broker re-read the /var/mqsi/common/wsrr/log4j.properties file when the file changes?
Thanks. |
|
| Back to top |
|
 |
| rromito |
| Posted: Wed Oct 31, 2012 10:39 am Post subject: /var/mqsi/common/wsrr/log4j.properties |
|
|
Newbie
Joined: 31 Oct 2012
Posts: 5
|
It looks like we only need to restart the execution group in order to reload the log4j.properties config. This is better than bouncing the entire broker, but it would still be nice if we didn't have to restart anything.
Any suggestions? |
|
| Back to top |
|
|
| bsiggers |
| Posted: Wed Oct 31, 2012 10:48 am Post subject: |
|
|
Acolyte
Joined: 09 Dec 2010
Posts: 53
Location: Vancouver, BC
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 31, 2012 10:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Do you mean the log4j from the IAM3 support pac, or a log4j solution you've constructed yourself?
I'd wonder about doing a reload of the execution group rather than a restart if I answered Java questions.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rromito |
| Posted: Wed Oct 31, 2012 11:16 am Post subject: |
|
|
Newbie
Joined: 31 Oct 2012
Posts: 5
|
Thanks for the quick responses.
This is neither a custom log4j configuration nor the IAM3 support pac.
We're taking advantage of the built in WMB log4j configuration loader. If you put a log4j.properties file in /var/mqsi/common/wsrr, WMB will automatically configure log4j in each execution group using that log4j.properties file.
We like this approach because it's less code for us to maintain and the technique is provided to us by WMB. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 31, 2012 11:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rromito wrote: |
| We're taking advantage of the built in WMB log4j configuration loader. If you put a log4j.properties file in /var/mqsi/common/wsrr, WMB will automatically configure log4j in each execution group using that log4j.properties file. |
Got a link for that in the WMBv7 InfoCenter?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rromito |
| Posted: Wed Oct 31, 2012 12:04 pm Post subject: |
|
|
Newbie
Joined: 31 Oct 2012
Posts: 5
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 31, 2012 12:54 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This forum is not the IBM supplied documentation, despite the quality of the advice and the most worthy occupations of many who post here.
If you look at the threads you posted, they're talking about the WMB classloader feature, which is not what you described:
| rromito wrote: |
| built in WMB log4j configuration loader |
WMB does not have any built in functions to load or configure log4j. You can load the log4j jar in the same way you can load anything with that, but it's still a custom configuration not an IBM supplied function. On that basis you may do with it as you will, and IBM will support the class loading function.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 31, 2012 2:01 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So this is what you've done. - Deployed code that uses log4j into a JCN in a message flow
- put the properties file for log4j in a folder that is loaded by a "higher" classloader
.
In this case, the "higher" classloader is *too* high. The wsrr directory happens to be in the load path of the Broker classloader. Not the shared classloader, not the EGshared classloader. The *broker* classloader. Putting anything in there is the same as putting it into /classes. You're slightly safer in this case because you're putting a properties file in there rather than putting an executable class file in there - but you still run the risk of interfereing with any broker internal stuff that happens to want to use log4j.
Please DO NOT put anything into the wsrr directory other than those files that are required to be put in there when configuring connections to wsrr.
Put the properties file in shared-classes, or in the shared-classes part of a JavaClassloader configurable service. That is still a higher level classloader than your JCN code runs in, so it will still get loaded at EG startup.
You've not mentioned, but it sounds like you are also not deploying any particular version of log4j in a jar file to the runtime, but using the base java logging capabilities included in the Java runtime that ships with broker. If you *are* deploying that, then you should look at putting it into the node classloader portion of a JavaClassloader configurable service rather than in the shared classes portion. Then the shared classes portion is still a higher level classloader.
But none of that gets you any closer to having the file be reloaded when it's changed - you still need to reload the EG.
If you want to reload the properties when it's changed, you need to alter your code to specify a specific file and use the configureandwatch option mentioned. And then you don't have to worry about putting the properties file anywhere where any classloader will pick it up - you put it in a known location and instruct log4j where it is. |
|
| Back to top |
|
|
| rromito |
| Posted: Thu Nov 01, 2012 5:01 am Post subject: |
|
|
Newbie
Joined: 31 Oct 2012
Posts: 5
|
Thanks for the feedback.
mqjeff, I moved the log4j.properties file from wsrr to shared-classes and everything still works.
Yes, I didn't include that we've deployed log4j-1.2.16.jar into shared-classes.
We have an alternate solution where we manually configure log4j in each execution group. We were hoping to find a solution that worked without adding something to every execution group.
We haven't delved into the class loader services yet. It sounds like we need to learn more about them. |
|
| Back to top |
|
|
| nanotech |
| Posted: Thu Mar 28, 2013 6:30 pm Post subject: |
|
|
Novice
Joined: 29 May 2009
Posts: 15
|
Hi All,
We are also using log4j for logging in JCNs and have put the log4j.properties in wsrr directory, but after reading the discussion it seems that we should move the file to "shared-classes" directory.
Having said that, we are facing a rather strange issue lately, we have 6 execution groups with different bars deployed and each bar has its own copy of log4j.jar and other dependent jars....We are noticing that when the log file rolls over to next day some of the execution groups keep writing to the previous days log file, while other execution groups write to current day's file.
Has anyone else faced a similar issue ?
Also, Is there a way to create bar file (we are using mqsicreatebar from ant ) without referring the log4j.jar as dependency from toolkit. As I think creating multiple bar files with the copy of log4j.jar in each bar is a bad design. We were thinking of putting log4j.jar and other dependent jars in "shared-classes" directory, which I believe would work just fine , but if I remove reference of log4j.jar from my project (in toolkit ) then it complains in all JCNs because it is using log4j for logging.
Environment: WMB 7.0.0.4 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 28, 2013 8:25 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you need to do something like in java.logging which you should have used as a preference, or may be appache commons?
java.logging allows you to change logging level, create handlers etc at runtime. All you would need to achieve this is to have a flow that takes a message with the corresponding commands and execute those in java, in the currently running jvm....
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Mar 29, 2013 4:25 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 29, 2013 4:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nanotech wrote: |
We are noticing that when the log file rolls over to next day some of the execution groups keep writing to the previous days log file, while other execution groups write to current day's file.
Has anyone else faced a similar issue ? |
Yes we have. Given the lack of criticality in our log4j files & our plan to create a new "logger" using java.logging we've not cared that much.
Prevailing thinking is that the JVM in EG is holding open a file handle somewhere & preventing the file from rolling over, as we see it in EGs where the application is using log4j to produce high volumes of output in violation of best practice.
Another reason I don't get excited about fixing it. Ignore my best practice advice, pay the price.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| nanotech |
| Posted: Fri Mar 29, 2013 7:13 am Post subject: |
|
|
Novice
Joined: 29 May 2009
Posts: 15
|
@lancelotlinc : Thanks for the links.
@Vitor and @fjb_saper: Do you think if we move over to java.util.logging , this will fix the issue. Currently we are using sl4j wrapper with log4j |
|
| Back to top |
|
|
|
|
