i
>
> -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
> the client to
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 also no final
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 the time i
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:04
> To: users@qpi
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 remote-only.
>
&g
@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 connection
ent: 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.receiveL
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
> Sent: mardi 26 février 2019 17:27
> To: users
,
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
11 matches
Mail list logo
