dcsimg
[Swiftmq 3.2]CLIENT hang resolved! (The classloader did it)
0 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   Adam_Skogman
Posted On:   Wednesday, October 16, 2002 02:25 AM

While not really a question, I would like to share a problem I've had and its solution/workaround, and possibly get some feedback from others who have had the same problem. When using Swift 3.2 on Sun jdk 1.4.1 fcs on Windows 2000 I got really weird hangs in the client. Sometimes the JVM CRASHED(!), sometimes a threaddump said I had a deadlock and sometimes the threaddump said nothing. The server continued to run just fine. The same client also ran fine on sun jdk 1.3.1_05 and ibm 1.3.0. When I got deadlocks, the dump said one of the locks causing it was on my own Classloader, lets call it FooLoader. FooLoader is constructed by my boot class, pulling in all jars in a lib directory (including swiftmq.jar). FooLoader inherits   More>>

While not really a question, I would like to share a problem I've had and its solution/workaround, and possibly get some feedback from others who have had the same problem.

When using Swift 3.2 on Sun jdk 1.4.1 fcs on Windows 2000 I got really weird hangs in the client. Sometimes the JVM CRASHED(!), sometimes a threaddump said I had a deadlock and sometimes the threaddump said nothing. The server continued to run just fine. The same client also ran fine on sun jdk 1.3.1_05 and ibm 1.3.0.

When I got deadlocks, the dump said one of the locks causing it was on my own Classloader, lets call it FooLoader. FooLoader is constructed by my boot class, pulling in all jars in a lib directory (including swiftmq.jar). FooLoader inherits from URLClassLoader, but adds nothing.

So, having tried everything else, I decided to get rid of FooLoader, thereby loading the jms.jar and swiftmq.jar by means of a -cp on my commandline. And it ran perfectly. No hangs. So a big WARNING to all you people in custom classloader land!

Just for completeness, it should be said that FooLoader was made the thread context classloader for all threads, partly because JNDI (InitialContext actually) wouldn't work otherwise.

   <<Less
About | Sitemap | Contact