qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From HADI Ali <Ali.H...@murex.com>
Subject RE: [QPID JMS] receive with timeout and reconnect
Date Fri, 08 Mar 2019 14:02:06 GMT
Hello,

According to the documentation the jms.receiveLocalOnly URI option will make the receive calls
with a timeout will only check a consumers local message buffer. This option will solve the
receive with timeout issue only if we are prefetching messages.

In our case, our prefetch policy is set to zero. Can’t the receive with timeout behave the
same way the send timeout does? As a client of the JMS API, I would expect the receive with
timeout to exit in the worst case when the timeout expires no matter what is happening in
the background ( Reconnect option triggered ).

Regards,
Ali

-----Original Message-----
From: Robbie Gemmell <robbie.gemmell@gmail.com>
Sent: mardi 26 février 2019 17:27
To: users@qpid.apache.org
Subject: Re: [QPID JMS] receive with timeout and reconnect

I guess it is probably blocking on beginning an attempt to drain the link credit as way to
verify no messages before returning null.
Setting the jms.receiveLocalOnly URI option true would stop it draining the link and so I
guess let it return null instead of waiting for the failover process to complete.

I dont think I'd ever choose to throw from the consumer there, alternatively it could just
return null repeatedly since thats what it does otherwise when there arent messages it can
give.

Robbie

On Mon, 25 Feb 2019 at 10:16, VERMEULEN Olivier <Olivier.VERMEULEN@murex.com> wrote:
>
> Hello,
>
> We're using QPID JMS 0.39.0 with a set of reconnect options that makes the client retry
to connect for 2 hours in case of problem.
> When doing a synchronous receive call with a smaller timeout (like 60 seconds) we were
expecting to receive a TimeOutException after 60 seconds but we actually have to wait for
the whole reconnect to end, so 2 hours.
> Is that expected? We were expecting a behavior similar to the one we have with the sendTimeout
(defined at the level of the connection factory) where the send fails but the reconnect continues
behind the scene.
>
> Thanks,
> Olivier
>
> *******************************
> This e-mail contains information for the intended recipient only. It may contain proprietary
material or confidential information. If you are not the intended recipient you are not authorized
to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that
it is virus free and accepts no responsibility for any loss or damage arising from its use.
If you have received this e-mail in error please notify immediately the sender and delete
the original email received, any attachments and all copies from your system.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail:
users-help@qpid.apache.org

*******************************
This e-mail contains information for the intended recipient only. It may contain proprietary
material or confidential information. If you are not the intended recipient you are not authorized
to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that
it is virus free and accepts no responsibility for any loss or damage arising from its use.
If you have received this e-mail in error please notify immediately the sender and delete
the original email received, any attachments and all copies from your system.
Mime
View raw message