egards,
> Ali
>
> -Original Message-
> From: Robbie Gemmell
> Sent: lundi 1 avril 2019 14:13
> To: users@qpid.apache.org
> Subject: Re: [QPID JMS] receive with timeout and reconnect
>
> I wouldn't consider it an internal error that you have expressly configured
e.org
Subject: Re: [QPID JMS] receive with timeout and reconnect
I wouldn't consider it an internal error that you have expressly configured the
client to sit reconnecting and it is currently doing so, such that there is
obviously no message available in the time it is doing that but als
avril 2019 14:13
To: users@qpid.apache.org
Subject: Re: [QPID JMS] receive with timeout and reconnect
I wouldn't consider it an internal error that you have expressly configured the
client to sit reconnecting and it is currently doing so, such that there is
obviously no message available in
JMS provider fails to receive the next
> message due to some internal error."
> Isn't it the case here, we actually failed to receive the next message, no?
>
> Thanks,
> Olivier
>
> -Original Message-----
> From: Robbie Gemmell
> Sent: mardi 12 mars 2019 15
l Message-----
> From: Robbie Gemmell
> Sent: lundi 11 mars 2019 15:51
> To: users@qpid.apache.org
> Subject: Re: [QPID JMS] receive with timeout and reconnect
>
> Correct, its not possible for local-only operation while disabling
> prefetching, as thats necessarily requiring
@qpid.apache.org
Subject: RE: [QPID JMS] receive with timeout and reconnect
In our C++ API we chose to return an exception if the server doesn’t respond
because the client needs to differentiate between receiving with no message
available and server not responding (or down) because he will react differently
@qpid.apache.org
Subject: Re: [QPID JMS] receive with timeout and reconnect
I wouldn't use an exception if the server was known to be down and the client
has been explicitly configured to keep reconnecting. If the reconnections are
ultimately exhausted, then an exception is appropriate.
If the conne
worst case when
> > the timeout expires no matter what is happening in the background (
> > Reconnect option triggered ).
> >
> > Regards,
> > Ali
> >
> > -Original Message-
> > From: Robbie Gemmell
> > Sent: mardi 26 février 201
gt; 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.rec
he 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
> Sent: mardi 26 février 2019 17:27
> To:
,
Ali
-Original Message-
From: Robbie Gemmell
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
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 comp
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
actual
13 matches
Mail list logo
