Bugs item #554502, was opened at 2002-05-10 14: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: Open
Resolution: None
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
----------------------------------------------------------------------
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
