| Author |
Message
|
| er_pankajgupta84 |
 Posted: Tue Feb 28, 2012 9:28 am Post subject: JavaClassLoader Configurable Service for external jars |
 |
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
On WMB 7.0.3 -
Can we use JavaClassLoader Configurable Service to re-load external java classes dynamically?
We use JCN to load java classes (jar files stored ih shared-classes location) dynamically using reflection.
If any of these external classes change then we need to reload the EG.
I know we can re-load a class if we build custom class loader. I would like to know does message broker provide something for that - like hot Deployment without EG reload.
Any direction/sample is appreciated. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Feb 28, 2012 9:32 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
There is no such version as 7.0.3. What version are you on?
Using reflection from within a JCN is not recommended. You should package all your custom code in its own jar, and write Junits against that jar. From the jar, you should load your classes and implement hot-reload as needed.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Feb 28, 2012 9:40 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I am on Wmb version 7.
| Quote: |
| Using reflection from within a JCN is not recommended. You should package all your custom code in its own jar, and write Junits against that jar. From the jar, you should load your classes and implement hot-reload as needed. |
Class that load other classes using reflection is not a JCN. But it is called from JCN - compile time binding.
If I create a configurable service like -
Create a JavaClassLoader service:
mqsicreateconfigurableservice MB7BROKER -c JavaClassLoader
-o myJavaClassLoader
-n includedDeployedJars,sharedJarPath
-v "jcnapp1.jar","/var/app1/jars"
will it work without any reload/restart after any change to files present in "/var/app1/jars" location? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 28, 2012 9:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Using reflection from within a JCN is not recommended. |
| lancelotlinc wrote: |
| You should package all your custom code in its own jar, and write Junits against that jar. From the jar, you should load your classes and implement hot-reload as needed. |
That doesn't help during execution of message flows, unless I misunderstand what you're saying.
If you want to reload jar files based on something other than the startup of an EG, you need to deploy the JAR files as part of a bar file deployment. This puts them in the EGShared classloader, which is then loaded anew at each deployment.
I suppose in theory one could write code in a JCN that would iterate over Named Classloaders and cause the correct one to get reloaded, but that's fundamentally a dangerous prospect.
A slightly better idea is to deploy the flows that use the JavaClassLoader service into an EG that has not previously had copies of those flows. It should then load the jar files from the named location into the new EG process.
But, again, mqsireload should not be a terribly large impact on a broker environment, particularly during a deployment maintenance window. So there's little reason to do much else. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 28, 2012 9:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 28, 2012 9:57 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
| Using reflection from within a JCN is not recommended. |
| lancelotlinc wrote: |
| You should package all your custom code in its own jar, and write Junits against that jar. From the jar, you should load your classes and implement hot-reload as needed. |
That doesn't help during execution of message flows, unless I misunderstand what you're saying.
If you want to reload jar files based on something other than the startup of an EG, you need to deploy the JAR files as part of a bar file deployment. This puts them in the EGShared classloader, which is then loaded anew at each deployment.
I suppose in theory one could write code in a JCN that would iterate over Named Classloaders and cause the correct one to get reloaded, but that's fundamentally a dangerous prospect.
A slightly better idea is to deploy the flows that use the JavaClassLoader service into an EG that has not previously had copies of those flows. It should then load the jar files from the named location into the new EG process.
But, again, mqsireload should not be a terribly large impact on a broker environment, particularly during a deployment maintenance window. So there's little reason to do much else. |
He wants a hot reload capability of Java classes during runtime. This is a neat feature, but I think it wastes too much developer resources building tooling rather than actual function.
To clarify, I suggested he isolate his hot-reload in a custom Jar with Junits to prove it works as designed. Inside this Jar, he would have his own classloader defined and periodically invoke an inventory mechanism to detect the need to refresh the in-memory classes.
This prevents any disruption to Broker classloaders and provides the functionality he desired. Albeit, from his earlier posts, he is on z/OS, and probably at the "Bank" since, when I was there, this was a constant requirement. The technical leadership on that project is young yet, and more growth will eventually redirect the energies into more productive ventures.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Feb 28, 2012 10:20 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
I might not have explained correctly -
Here is the code snippet.
| Quote: |
Class cls = Class.forName("ClassA");
ClassParent parent = (ClassParent) cls.newInstance();
Where "ClassA" is recieved as part of input message and all such classes extends ClassParent. |
Such kind of coding is not suggested in JCN ?
There could be hundreds of classes like "ClassA" which are grouped in different-different JARs.
Now if any of these classes which extends ClassParent changes then I am looking for the options where we don't need broker restart or EG reload. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Feb 28, 2012 10:51 am Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
We are still in process to move from v6.1 to v7.
While referring to manuals i found 2 statements -
• Enhanced Java class-loading to resolve hot deployment issues for multiple flows.
• Individual Java Compute nodes can optionally specify CLASSPATH.
I wanted to check if any of it can help me optimizing the deployment process.
I am not interested in writing extra code for a custom class loader. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 28, 2012 12:12 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| er_pankajgupta84 wrote: |
I might not have explained correctly -
Here is the code snippet.
| Quote: |
Class cls = Class.forName("ClassA");
ClassParent parent = (ClassParent) cls.newInstance();
Where "ClassA" is recieved as part of input message and all such classes extends ClassParent. |
Such kind of coding is not suggested in JCN ? |
There's nothing nominally wrong with that, except that it indicates that you're not using Broker to do the heavy lifting. It indicates that you're using a java based object model to parse and serialize your message data, instead of using the built-in tools to do so.
So this is at least a bit like using a tractor to tow your automobile, when the automobile works just fine.
| er_pankajgupta84 wrote: |
There could be hundreds of classes like "ClassA" which are grouped in different-different JARs.
Now if any of these classes which extends ClassParent changes then I am looking for the options where we don't need broker restart or EG reload. |
Yes, again, if you want this, then you need to put those jars in the BAR.
You can then, for example, put the relevant changed Jar file into it's own BAR file and then deploy that to only change that Jar file.
But that will still cause *all* of the jar files in that EG to be reloaded, since that's what the EGShared classloader does.
But this is, again, in general a very poor design for a Broker message flow.
You should redesign your solution to stop being so dependent on Java classes to describe message contents, and use Message Models. These are automatically hot-reloadable, and are in theory part of the cost justification for using Broker in the first place. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Feb 28, 2012 12:58 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
@mqjeff - I agree that this is not the optimal use of broker.
I took this as an example to show why I need hot deployment.
Leaving the design consideration apart - I have 2 questions wrt v7.
| Quote: |
| If the JavaCompute node specifies a JavaClassLoader configurable service, the EGShared classloader loads all the classes defined by the includedDeployedJars property. Otherwise, the EGShared classloader loads all classes that are deployed to the execution group in the broker archive |
1. Suppose includedDeployedJars property is set to "shared-classes" location. Then when ever I deploy any Jar to EG it will reload all the jars present in "shared-classes" location & this doesn't need any broker restart or EG reload. Is it true?
2. If all my common/external JARs are present at a common location ("shared-classes") and I make some modification in them only. As I haven't made any modification to my JCN java files so I don't deploy anything to EG. In this case to have the change to come in effect I need to do EG reload and configurable service wouldn't be helpful here?
Thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 28, 2012 1:22 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| er_pankajgupta84 wrote: |
| Quote: |
| If the JavaCompute node specifies a JavaClassLoader configurable service, the EGShared classloader loads all the classes defined by the includedDeployedJars property. Otherwise, the EGShared classloader loads all classes that are deployed to the execution group in the broker archive |
1. Suppose includedDeployedJars property is set to "shared-classes" location. Then when ever I deploy any Jar to EG it will reload all the jars present in "shared-classes" location & this doesn't need any broker restart or EG reload. Is it true? |
No, I don't think so.
Among other things, I strongly suspect this will cause all the jar files to be loaded by both the EGShared classloader and the Shared classloader. Which means that either you'll get copies of all classes in both classloaders, or that you'll only ever get copies in the Shared classloader.
This is, in general, a really bad idea.
| er_pankajgupta84 wrote: |
2. If all my common/external JARs are present at a common location ("shared-classes") and I make some modification in them only. As I haven't made any modification to my JCN java files so I don't deploy anything to EG. In this case to have the change to come in effect I need to do EG reload and configurable service wouldn't be helpful here?
Thanks. |
JavaClassLoader configurable services are only ever loaded at EG startup, or the first time that a flow that uses them is deployed after EG startup.
If you want to be able to reload a JAR file without restarting the EG, then you have exactly two choices. - Put the jar file in a BAR file
- write your own classloader and configure a method to reload the JAR file
.
You're very unlikely to get any better information from this forum on this topic. This leaves you with the choice of either taking it for granted, or running your own experiments and then opening the PMRs that will be required after you try messing with this. |
|
| Back to top |
|
|
| er_pankajgupta84 |
| Posted: Tue Feb 28, 2012 1:42 pm Post subject: |
|
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
Thanks - jeff
To summaries:
1. Each java deployment on EG will kick EG class-loader so changed code will come in execution without any reload of EG.
2. JavaClassLoader configurable services are only ever loaded at EG startup, or the first time that a flow that uses them is deployed after EG startup. But not after the re-deployment of jars in EG.
3. If you want to make a change in the jar files stores at the common location an EG reload is required even with v7.
Question - What does this statement adds to wmb with v7 - "Enhanced Java class-loading to resolve hot deployment issues for multiple flows"?
The only advantage I can think of is - If you want to keep your common jars at some location on file system (not shared classes and not in class path) then thoses jars can be loaded thru configurable service.
Let me know if I am missing anything in understanding.
I have just started reading the wmb v7 documentation and need to wait to get runtime to conduct my own experiments. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 28, 2012 2:00 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A JavaClassloader configurable service allows you to designate one or more set of JavaCompute nodes to have their own classloader, rather than relying on the Shared classloader or the EGShared classloader.
This means that you can deploy different versions of classes to the same EG and have those different versions loaded and isolated to the specific set of flows or JavaCompute nodes that need them. |
|
| Back to top |
|
|
|
|
