Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of robbie.gemmell@gmail.com
 designates 209.85.212.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <F23CBE5EE71A764689F945177804E5D00EBC2E@EXCHANGE2010.halcom.local>
References: <F23CBE5EE71A764689F945177804E5D00EBC2E@EXCHANGE2010.halcom.local>
Date: Sat, 6 Apr 2013 23:55:57 +0100
Message-ID: 
 <CAFitrpT5kWyyTZ898NPYnkkyLJMW-JaR_VhuPuG8_bFUjY-sKA@mail.gmail.com>
Subject: Re: Java JMS client eating InterruptedException
From: Robbie Gemmell <robbie.gemmell@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a8d765a4cbb04d9b91b16

--047d7b3a8d765a4cbb04d9b91b16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Ales,

It seems reasonable to raise a JIRA

Robbie


On 2 April 2013 16:55, Ale=C5=A1 Tr=C4=8Dek <Ales.Trcek@halcom.si> wrote:

> Hi all!
>
> I am implementing proper stopping (with ExecutorService.shutdownNow()) of
> a few worker threads I have, that are consuming messages from the queue a=
ll
> the time, and if there were no messages the threads wouldn't stop...
> Thread.currentThread().isInterrupted() is always false. So after a little
> bit of debugging I discovered that the problem lies in the fact that
> receive method on MessageConsumer eats up the InterruptedException, which
> clears isInterrupted flag.
> Relevant code from BasicMessageConsumer.java:
> public Message receive(long l) throws JMSException
> {
> ...
>     catch (InterruptedException e)
>     {
>         _logger.warn("Interrupted acquire: " + e);
>         if (isClosed())
>         {
>             return null;
>         }
>     }
> ...
>     catch (InterruptedException e)
>     {
>         _logger.warn("Interrupted: " + e);
>
>         return null;
>     }
> ...
> }
>
> Even though the JMS standard does not specify how to handle such interrup=
t
> (JMSException or returning null message), I'm sure the implementation
> shouldn't just ignore it (which is basically what happens). When catching
> InterruptedException, the interrupted flag should immediately be set back
> (Thread.currentThread().interrupt()), so in the calling code we can still
> detect such situation.
> Any other point of view on this subject, or should I file a bug? :)
>
> Btw: I got around this by not using timeout in receive() call, but I woul=
d
> be more comfortable if the Consumer would wait for messages for a while,
> instead of me looping like crazy in my code...
>
> P.S.: Sorry if this should go to qpid-dev.
>
>
> Regards,
> Ales
>

--047d7b3a8d765a4cbb04d9b91b16--