after some testing i was able to produce a test case. With this test, i make some sequential subscriptions and unsubscriptions, and ask for a receipt after each one, then send some messages and try to receive them back.
By running this script some times (most of the times 5 times is enough to reproduce the bug), it stops completing because it gets hung waiting for a receipt that never arrives. If you stop the script and restart it again 3 or 4 times, it's very likely that it will stop every and each time. Now you can try to stop the broker, and it won't stop. In log file there will be a bunch of: The connection to '/x.x.x.x:x' is taking a long time to shutdown one every 5 seconds. It seems to me that here there are 2 different bugs, the first one that lets the broker hung when a receipt is requested. The other one doesn't let the broker stop correctly after the first bug has happened. Attached there are the test.pl script, it was tested with ActiveMQ 5.1 and with 5.2 (the version downloaded from http://people.apache.org/~gtully/staging-repos/activemq-5.2.0/org/apache/activemq/apache-activemq/5.2.0/) and it happens in both the versions. Yari Marchetti ha scritto: > Bruce Snyder ha scritto: > >> On Wed, Sep 10, 2008 at 10:10 AM, Yari Marchetti >> <[EMAIL PROTECTED]> wrote: >> >>> Hi, >>> today i was testing a client application with ActiveMQ broker >>> using STOMP transport, and after some tests i saw 27 different >>> consumers connected to that queue by looking at the web console. >>> This is impossible because the broker is on my machine and i was >>> the only one accessing it. >>> >>> By looking at netstat i saw 27 CLOSED_WAIT different connections >>> to the stomp transport port, and the clients were all gone by long. >>> So i tried to stop the broker and got an unending list of >>> >>> The connection to '/x.x.x.x:x' is taking a long time to shutdown >>> >>> repetead by 5 seconds, and the broker never stopping so that i had >>> to kill it. >>> >>> The tests were somewhat unusual, with a lot of abruptly interruptions, >>> but i think this isn't the normal behavior for the broker, isn't it? >>> >> Please describe the behavior of your cilents more (and post code if >> possible). Were you connecting and disconnecting over and over on the >> STOMP transport in your tests? >> >> Bruce >> > i could post the code but it wouldn't help because those test > were only a debugging session of my (perl) STOMP client. > What i did were a lot of message sending (10000+), massive > queues subscriptions and unsubscriptions (5000+), with and > without receipt request. Many times the program was interrupted > before it could close the socket. > > I also find out, that under some circumstances the broker stopped > answering my client: i was sending subscriptions (with receipt > request) for a queue with a lot of messages in and i didn't get > anything back, neither the receipt nor any message. > > Using jconsole i was able to see around 15 consumers for those > queue (and my client should have been the only one since every > other instance were closed before) and around 5000 unconsumed > messages. I tried to send a stop command to 14 of those > consumers connection, but the commands seem to not complete > correctly. When i tried to purge the queue by jconsole, my client (that > was still subscribed to the queue) received some messages. > > I think this is all informations i can provide about the behavior i > observed > and what i did. Anyway is it normal for the broker to not shutdown for an > undefined time waiting for a socket to close? shouldn't the broker give up > after a max amount of time and close anyway? > > Yari > >
test.pl
Description: Perl program
