Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <10081908.1256584612741.JavaMail.jira@brutus>
Date: Mon, 26 Oct 2009 12:16:52 -0700 (PDT)
From: "Aaron Baff (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Created: (AMQ-2465) MessageConsumer.receive(timeout) with
 prefetchSize=0 results in hang when broker goes down
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

MessageConsumer.receive(timeout) with prefetchSize=3D0 results in hang when=
 broker goes down
---------------------------------------------------------------------------=
---------------

                 Key: AMQ-2465
                 URL: https://issues.apache.org/activemq/browse/AMQ-2465
             Project: ActiveMQ
          Issue Type: Bug
          Components: JMS client
    Affects Versions: 5.3.0
         Environment: WinXP, Netbeans 6.7, JDK 1.5
            Reporter: Aaron Baff


I'm doing some testing to verify that I detect and correctly handle when th=
e broker goes down while consuming. I came across some strange behavior whe=
re the consumers recieve(timeout) call would hang and not throw an exceptio=
n which prevented me from detecting any error, which means I couldn't back =
off and take appropriate actions. I traced down the call, and it seems that=
 when the prefetch size is set to 0, there is a separate code path which is=
 ActiveMQMessageConsumer:550 where it then calls the MessageDispatchChannel=
.dequeue(timeout) with a timeout of -1 which the comments indicate that wil=
l wait for the broker to push the message down the connection at which time=
 it will be received. However, since I am stopping the broker, it seems tha=
t the sendPullCommand() from ActiveMQMessageConsumer:513 is getting sent, b=
ut there is a race condition with the MessageDispatchChannel.dequeue(timeou=
t) and the code hitting the mutex.wait() in MessageDispatchChannel:75, whic=
h doesn't have a timeout and so the broker never notifies the client that t=
here is a message or that it should unblock and the consumers sit there stu=
ck.=20

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.