In my original setup, the sender is a 'TimerService'. A simple JMX bean that wakes up every so often and sends a JMS message to a particular queue. This allows my EJBs to perform tasks at particular intervals. I've written a modem pool that dials out to devices in the field, and polls them for alarms, which are then sent via SNMP traps to a central office.
>From what I can tell, tonight the resources are completely stable since I set everything up to use CLIENT_ACKNOWLEDGE. Within the JBoss server everything is completely happy. It's just when the external client sends JMS messages that some sockets seem to remain open, even though I'm closing everything including the JNDI context, in this case. Actually, I might have to scratch that. I send two JMS messages, I started with 17 open sockets, it went up to 24, and now I'm down to 16. That's a good sign. I'll keep an eye on it and report if I continue to see anything bad happening. I'm glad I didn't put a bug report in just yet. :) Thanks for your suggestions, I'll keep those in my arsenal in case I need them. -Neal On June 5, 2002 12:25 am, you wrote: > Hmmm. I'm not a JBoss developer exactly (I'm a "user"), so I probably > can't help you a great deal here. Though your problem worries me since we > are using JMS with JBoss as well. > > This is another wild guess, but maybe JBoss has some sort of a connection > pooling/caching/sharing mechanism built-in as a client-side optimization. > > Also, in your original setup (one request per minute) -- did the problem > occur with the same instance of the client application (i.e. the same > sender running over the span of two weeks), or was there a different sender > instance for each request? If the latter, then the JMS problem is > server-side and killing the client should make no difference... > > One quick way to test whether the leaks are garbage collector-related or > driven by deliberate (faulty?) JBoss logic is to allocate a really huge > data structure (e.g. 100 megabyte array) and then explicitly invoke > System.gc() in the client. This should force the garbage collector to run > and actually finalize/reclaim any dangling resources. If, after such a > call, the number of open sockets does not decrease then it's likely you've > discovered a JBoss "feature". > > Good luck, and keep us posted! > > (BTW, it's usually a good idea to close JNDI Contexts, unless you plan to > reuse the instance. Each context can be assumed to correspond to a session > with the JNDI provider (server) -- which can include open sockets, files, > or other resources. What happens when you don't close a Context that > you're going to discard, is that it is eventually reclaimed by the garbage > collector, and the associated resources are released at that point. But > such behavior is obviously non-deterministic and can lead to problems under > high loads... But from what you wrote so far it doesn't sound like that's > the problem you're having.) > > -----Original Message----- > From: Neal Sanche [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 04, 2002 6:45 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-user] JBoss 2.4.6 JMS Socket Leak > > > > Well, some more information that I found interesting this evening. I > thought > > I'd add it to this list as well. I have a pure Java client that has a > method > > very similar to that shown below. All it does is send a message to a topic > that a Message Driven Bean is listening on. The message driven bean sends > an > > SNMP trap to my Linux box. > > What's interesting is that if I fire a bunch of these messages in rapid > succession, the established connection count goes up as one would expect. > But > it never quite gets back down to the starting level. I'd expect it to if > everything is working properly. So I took the advice below and closed the > JNDI InitialContext (I didn't know I was supposed to close it after use, > I've > never done so in the past...), but there was still something lingering. As > soon as I closed the client, the levels went back down to normal. > > Now this worries me a little. How would I determine what objects are > accumulating? Should I get something like JProbe out to figure this out, or > is there an easier way? > > Thanks in advance. > > -Neal > > On June 4, 2002 07:22 pm, you wrote: > > Thanks for that, but... > > > > Well, the messages in this case are only happening once per minute, and > > yet > > > managed to cause all of the sockets on a machine to be occupied within > > the span of a couple of weeks. > > > > I think I stabilized things a little by using CLIENT_ACKNOWLEDGE mode for > > all of my messages and explicitly do acknowlegement in the receivers. > > Under > > > Windows 2000 and Linux that seems to allow sockets to be closed properly. > > I'm not sure if this is significant to the developers or not though. > > > > As long as I can run a JBoss server for a couple of weeks at a time, or > > longer without requiring a restart, I'm happy. ;) At one point I had a > > server on line for two months without a boot (to the head). > > > > -Neal > > > > On June 3, 2002 11:19 pm, you wrote: > > > This is just a wild guess (and maybe it really is a bug in JBoss...), > > but > > > > how about also closing the JNDI context? It could *theoretically* be > > > possible that the JNDI contexts accumulate too fast for the garbage > > > collector to keep up...? > > > > > > -----Original Message----- > > > From: Neal Sanche [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, June 03, 2002 6:50 PM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-user] JBoss 2.4.6 JMS Socket Leak > > > > > > > > > Hi All, > > > > > > I've been encountering socket leaks in JBoss 2.4.6 when running code > > > similar > > > > > > to the following to send JMS messages to topics on which Message Driven > > > Beans > > > are listening. > > > > > > public static void sendLogItem(int type, String message) { > > > TopicPublisher publisher = null; > > > TopicConnection connection = null; > > > TopicSession session = null; > > > try { > > > InitialContext jndiContext = new InitialContext(); > > > Topic topic = > > > (Topic)jndiContext.lookup("topic/logEventTopic"); > > > TopicConnectionFactory factory = > > > (TopicConnectionFactory)jndiContext.lookup("TopicConnectionFactory"); > > > connection = factory.createTopicConnection(); > > > session = connection.createTopicSession(false, > > > Session.AUTO_ACKNOWLEDGE); > > > publisher = session.createPublisher(topic); > > > LogData evt = new LogData(); > > > evt.setMessage(message); > > > evt.setType(type); > > > ObjectMessage msg = session.createObjectMessage(evt); > > > publisher.publish(msg); > > > } catch (Throwable ex) { > > > } finally { > > > if (publisher != null) { > > > try { > > > publisher.close(); > > > } catch (Throwable discard) {} > > > } > > > if (session != null) { > > > try { > > > session.close(); > > > } catch (Throwable discard) {} > > > } > > > if (connection != null) { > > > try { > > > connection.close(); > > > } catch (Throwable discard) {} > > > } > > > } > > > } > > > > > > As shown, I've tried to be careful to close anything that might need > > > closing, > > > but I'm probably missing something here, since after numerous calls to > > > this method, a number of unclosed sockets will accumulate until no more > > > sockets can be allocated by my program. What am I doing wrong here? > > > > > > Thanks in advance. > > > > > > -Neal > > > > > > _______________________________________________________________ > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > _______________________________________________ > > > JBoss-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > > > > > > > DISCLAIMER: The information in this message is confidential and may be > > > legally privileged. It is intended solely for the addressee. Access to > > > this message by anyone else is unauthorized. If you are not the > > intended > > > > recipient, any disclosure, copying, or distribution of the message, or > > > any action or omission taken by you in reliance on it, is prohibited > > > and may be unlawful. Please immediately contact the sender if you have > > > received this message in error. Thank you. > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > JBoss-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-user > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user > > > DISCLAIMER: The information in this message is confidential and may be > legally privileged. It is intended solely for the addressee. Access to > this message by anyone else is unauthorized. If you are not the intended > recipient, any disclosure, copying, or distribution of the message, or any > action or omission taken by you in reliance on it, is prohibited and may be > unlawful. Please immediately contact the sender if you have received this > message in error. Thank you. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
