did anyone have time to check this? do i have to
open a bug report?
Yari Marchetti ha scritto:
> 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
>>
>>
>
