| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JavaClassloader Configurable Services |
« View previous topic :: View next topic » |
| Author |
Message
|
| lancelotlinc |
 Posted: Wed Apr 24, 2013 3:51 am Post subject: JavaClassloader Configurable Services |
 |
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Greetings !
WMB 8.0.0.2
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fbn26240_.htm
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fbk58220_.htm
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fak04960_.htm
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fan60170_.htm
| Quote: |
| |--CLASSLOADER--ClassLoaderConfigurableServiceName--------------| |
| Quote: |
| The clause in the JavaClassLoader section applies only to LANGUAGE JAVA routines. The CLASSLOADER clause is optional; if you do not specify this clause, the Java class is loaded by the EGShared classloader. |
| Quote: |
| You can include automatic in the list to also load the JAR file that contains the class required by a JavaCompute node. Including automatic results in a runtime error, if the configurable service was specified in an ESQL routine. |
There seems to be a catch-22 and perhaps someone from the IBM WMB team that deals with classloaders can offer some guidance or clarification.
I have an ESQL function defined globally in one of my message flow's main ESQL files. This message flow also has some JCNs which have .java files that host the class which is referenced by the ESQL function. All is good so far, I can call my Java class from ESQL no problem.
If I include a call to a third-party jar from the .java files, and want to use JavaClassloader configurable service, I run into some limitations.
For example, the .java file which hosts the ESQL-referenced function makes a call to a third-party jar which makes other calls to other third-party jars. The only way I could get this to work is to abandon using JavaClassloader configurable service and place all third party jars into the EGShared classloader path (/var/mqsi/shared-classes).
It would make sense to me to be able to specify multiple classloader configurable services along with the order in which the Broker runtime searches these classloader configurable services. At the present time, I do not see any way to specify an affinity in classloader configurable services for which locations are searched in what order.
If I try to use classloader configurable services, I get class not found errors.
By the way, I like the enhancement to the CREATE FUNCTION command that lets you specify what classloader to use. Great idea. Unfortunately, it does not work when that classloader configurable service references other jars not located in EGShared.
When can we expect some improvement here in this area?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Apr 24, 2013 4:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Presumably you will see improvement in this area after the RFE you opened is serviced, or the PMR you opened is marked as complete.
Regardless, I'm not sure that you're expecting the correct behavior.
It seems to me you want to designate - directoryA
- directoryB
- directoryC
and have a single classloader service load from all of them.
I would not expect that this would work. The only case I would expect this to work is if directoryB and directoryC are children of directoryA and you only told the classloader to load directoryA.
I think you'll find that base barebones java classloaders simply don't load more than one directory (and it's children). This has nothing to do with Broker, this is just simply the documented behavior of Java classloaders.
So if you are trying to use a single Java routine that uses thirdPartyInstallA, thirdPartyInstallB, and thirdPartyInstallC... I think you need to copy jar files from all three installs into directoryA.
I think you'll find that all three thirdParty applications expect that you will have to copy their jar files around in many cases. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Apr 24, 2013 4:18 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I don't mind having three separate classloaders, one for each directory you specified: A, B, C.
And I don't mind copying the jars to EGShared.
What I think a good RFE might suggest is, being able to specify multiple classloaders with each having an affinity parent-child relationship to the other and able to be called from ESQL.
Do you think this is worthwhile or do you think the complexity and cost to implement outweighs the convenience?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Apr 24, 2013 4:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
I don't mind having three separate classloaders, one for each directory you specified: A, B, C.
And I don't mind copying the jars to EGShared.
What I think a good RFE might suggest is, being able to specify multiple classloaders with each having an affinity parent-child relationship to the other and able to be called from ESQL.
Do you think this is worthwhile or do you think the complexity and cost to implement outweighs the convenience? |
Well, in the first place, this is something that you can actually write yourself in your java code... you can simply have your java routine do dynamic classloading.
In the second case, I'd say you should look at capabilities available in WAS as a model and see what options you get there.
And again that you should consider doing things like packaging all of these needed jar files in a single external directory for a given classloader.
My personal opinion is that altering the classloader configurable service to specify the name of a single parent or a single child classloader configurable service is not terribly complicated. But that doing so means that it makes configuration much much more complicated and much harder to troubleshoot. Because it becomes easy to instantly and relatively invisibly create classloader loops or cycles or trees.
Dave creates classloader service A, which points to Joe's classloader service B as a child. Bill creates a new classloader service C which has A as a child, and then alters B to have C as a child.
The value of the extra disk space needed to maintain multiple copies of jar files disappears beneath the cost of trying to troubleshoot this at 1 am after a new deploy, when the EG hangs at startup and starts consuming resources and CPU and apparently doing nothing. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
