[jboss-user] [Messaging, JMS & JBossMQ] - Re: UIL2 ReadTask / WriteTask thread leak on 4.0.5 GA
Ok, so here is how I solved the problem. It is due effectively to the fact that a connection is not closed. I thought I knew all the points in the application that interacted with JMS, I checked and double checked them, still there was a place that did its own JMS sending without closing connections (and using the non XA /ConnectionFactory). What allowed me to realize where the problem was is that by enabling TRACE on org.jboss.mq, every time a message is sent you have a stacktrace of where that call is coming from. So in my case here PublisherToJmsTopic was the class I had completely forgotten about. | 2008-02-15 11:20:51,498 TRACE [JMS SessionPool Worker-1-org.jboss.mq.il.uil2.SocketManager] start called | java.lang.Exception: Start stack trace | at org.jboss.mq.il.uil2.SocketManager.start(SocketManager.java:112) | at org.jboss.mq.il.uil2.UILServerIL.createConnection(UILServerIL.java:523) | at org.jboss.mq.il.uil2.UILServerIL.getSocketMgr(UILServerIL.java:390) | at org.jboss.mq.il.uil2.UILServerIL.authenticate(UILServerIL.java:277) | at org.jboss.mq.Connection.authenticate(Connection.java:1067) | at org.jboss.mq.Connection.(Connection.java:252) | at org.jboss.mq.Connection.(Connection.java:323) | at org.jboss.mq.SpyConnection.(SpyConnection.java:116) | at org.jboss.mq.SpyConnectionFactory.internalCreateConnection(SpyConnectionFactory.java:137) | at org.jboss.mq.SpyConnectionFactory.createTopicConnection(SpyConnectionFactory.java:118) | at fr.bnf.entrychain.internalservice.impl.PublisherToJmsTopic.publishEvent(PublisherToJmsTopic.java:31) | at fr.bnf.entrychain.internalservice.impl.InternalOrchestrationServiceImpl.publishEvent(InternalOrchestrationServiceImpl.java:59) | at fr.bnf.entrychain.internalservice.impl.InternalOrchestrationServiceBean.publishEvent(InternalOrchestrationServiceBean.java:40) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | The JDBC pool in JBoss has a nice feature that closes unclosed connections showing the stracktrace of the point that opened the connection. Not that developers should use that as connection closing mechanism but it is helpful for debugging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129603#4129603 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129603 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Messaging, JMS & JBossMQ] - Re: UIL2 ReadTask / WriteTask thread leak on 4.0.5 GA
I was wrong, the ReadTask/WriteTask pairs still accumulate, my JConsole was not refreshing the thread list which lead me to think the problem was over. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129568#4129568 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129568 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Messaging, JMS & JBossMQ] - Re: UIL2 ReadTask / WriteTask thread leak on 4.0.5 GA
Ok, the problem was that the jBPM installation I used did not close connections after each and every JMS message send it did. In fact, jBPM JMS subsystem keeps one single Connection and Session for the whole life of the server application. The JMS specification says that : anonymous wrote : A JMS Connection is a client'Âs active connection to its JMS provider. It will | typically allocate provider resources outside the Java virtual machine. | | Connection objects support concurrent use. | and anonymous wrote : A JMS Session is a single-threaded context for producing and consuming | messages. Although it may allocate provider resources outside the Java virtual | machine, it is considered a lightweight JMS object. If I read between the lines correctly, this should mean that it is acceptable to keep a costly Connection for a long time while it is not really acceptable to keep a "lightweight" Session for a long time. If I close Sessions but not Connections, the thread blocking still persists. So I modified the code to close both and the thread blocking no longer appears. Is it normal that if a Connection is hold for a long time, a thread leak, eventually followed by OutOfMemory, occur ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129452#4129452 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129452 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [Messaging, JMS & JBossMQ] - Re: UIL2 ReadTask / WriteTask thread leak on 4.0.5 GA
Ok, I confirm it myself : ASPATCH300 didn't make it in the 4.0.5GA. But, if you look at the svn rep, you can see that it has been eventually merged : The history of SocketManager.java in 4.0.5: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/tags/JBoss_4_0_5_GA_CP11/messaging/src/main/org/jboss/mq/il/uil2/SocketManager.java?view=log the 4.0.5.GA_CP11 release contains the fix. So, people having the same problem, svn checkout that release and build it. Some further URLs concerning this issue: The backport JIRA issue: http://jira.jboss.org/jira/browse/ASPATCH-300?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel The diff showing what changed : http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/JBoss_4_0_3_SP1_CP/messaging/src/main/org/jboss/mq/il/uil2/SocketManager.java/?revision=66324&r1=66324&r2=66323 The patched file in 4.0.3SP1 : http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/branches/JBoss_4_0_3_SP1_CP/messaging/src/main/org/jboss/mq/il/uil2/SocketManager.java?revision=67114&view=markup View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4129038#4129038 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4129038 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
