We had certain latency at loading the classes at run time for an outgoing call which uses axis internally. Options like explict class loading was tried out and finally the solution was to move the custom jar files (currently existing in <PACKAGE_HOME>/code/jars)including axis to <PACKAGE_HOME>/code/jars/static (which worked without latency).
Will this create a problem if multiple threads access the same class and tend to share the instance variable values between instances ?
Do the IS services interact with the library such that a new object is created for each IS service thread? Or do multiple IS threads access the same object instance?
How would the IS services “tend to share the instance variable values between instances?” Instance variables by definition aren’t shared between object instances. If multiple threads access the same object instance, there might be concurrency issues, depending on the specifics of what the methods called do to the state of the object being manipulated and if the methods use synchronization techniques.
I am surprised by the way the folder name “static” resolved the issue and curious to know what caused the behavioural change of the class/loading and instantiation as well. The “static” keyword took my thought into a perspective of sharing static instance variables between objects(least possible scenario). I am pretty much sure that something in webMethods is tied to this. Wanted to identify it before we actually implement this solution. Also i see that some of methods inside the jar file has synhronize block in it. Even not sure about the impact on those methods as well.
Let’s back up a sec and review the problem. What exactly was the latency you observed and how did you determine that it was associated with class loading?
The “static” folder has no bearing on the behavior of the classes nor their instantiations.
From the IS Administrator’s Guide (page 251 for v6.5):
"Place the jar files in this location when you want to make tehm available to other packages in the Integration Server and also to packages in other Integration Server systems.
When you place jar files in the static subdirectory, then at startup the Integration Server automatically loads these files to the server classpath. Also, the jar files are available to other packages even when the immediate package is disabled."
Thus, moving the .jar caused the jar to get put on the server classpath (which can be viewed on the About page in Administrator). IS itself doesn’t do anything with the classes within the .jar file. It’s purely a JVM thing and the JVM will load the classes as needed when referenced by your IS Java code.