Bugs item #554502, was opened at 2002-05-10 09:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=554502&group_id=22866
Category: JBossMQ Group: v2.4 (stable) >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Todd Neumarker (tneumarker) Assigned to: Nobody/Anonymous (nobody) Summary: Message Selectors cause Memory Leak Initial Comment: When multiple clients subscribe to a topic, and each subscriber is making use of a message selector, published messages intended for the clients build up on the server. There exists a BasicQueue object for each JMSTopic subscriber, which keeps a "messages" TreeSet of SpyMessages. When a message is published from the server, a copy of each SpyMessage is given to each subscriber. When there is no Selector the message is popped off the queue. When the SpyMessage passes the Selector test, it is also popped off the queue. However, when the message fails the selector test, it is left on the "messages" object. Each time "receive ()" is called on the BasicQueue that represents the subscriber, the "messages" TreeSet is iterated over and each message is tested again against the selector. So eventually the Selector.test() method begins to hog the CPU, and the server runs out of memory and crashes, if you have a message subscriber open with a message selector. A simple change in the BasicQueue does not appear to solve the problem. It appears that the "receive()" method only gets called once when the client subscribes, but not again when the server publishes a message not intended for that client. So if all clients are receiving messages there is no memory leak, but if for some reason one client is opened with a message selector, and doesn't receive any messages for a long time, memory will be leaking until that client finally gets a valid message. I made a temporary fix in the JMSTopic class, by not giving a copy of each message to the subscriber, if it didn't pass the message selector. Since the list of subscribers is kept as keys to the tempQueue java.util.Map, I iterated key values, and only called a SpyMessage.myClone() on subscribers that passed the selector.test(). This is only a temporary fix, so my server won't crash. And I haven't looked into how it might effect durable subscriptions, but I am not using them yet anyway, and it stopped the leak, made things faster, because it didn't have to make a copy for subscribers that didn't need the message anyway. Below is a snippet from org.jboss.mq.server.BasicQueue: synchronized ( messages ) { Iterator i = messages.iterator(); while ( i.hasNext() ) { SpyMessage m = ( SpyMessage )i.next(); if ( selector.test( m ) ) { message = m; messages.remove( message ); break; } // When is the message being removed when the // test returns false? } } Thank Todd ---------------------------------------------------------------------- Comment By: Hiram Chirino (chirino) Date: 2002-05-10 09:41 Message: Logged In: YES user_id=175851 Yes. The fix for this was commited last night to Branch_2_4. It should be fixed in the next 2.4.x release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=554502&group_id=22866 _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development