Hi Robbie
Indeed we have some different cases on PROD.
1) Some messages processed by our app several times. Frequent use case.
2) Sometimes we got message with JMXDeliveryCount=2 with no log entries with
JMXDeliveryCount=1 on the same message before or after.
3) We processed message with
>Are these logs from such an experiment, as they seem valid from a
>protocol perspective (delivery with id 0 arrives, then is accepted)?
Yes these logs are from the experiment.
1) Start debug session of my java program. I send `Flow` frame with 1 credit
limit, then receive 'Transfer' then
One thing to be clear on is that the credit given by a Flow frame can
endure for a time until used. Credit granted must either be used by
sending a message, or removed by further Flows so that there is no
outstanding credit if no messages are desired. The clients consumers
'drain' the link credit
I have 3 observation:
1.) Azure Service Bus place lock on message when receive Flow frame with
non-zero link credit
The clock for the expiration of the lock on the message inside the
`queue/topic
On 29 May 2018 at 21:00, Gordon Sim wrote:
> On 29/05/18 20:24, Rob Godfrey wrote:
>>
>> On Tue, 29 May 2018 at 19:45, akabhishek1
>>
>> wrote:
>>
>>> HI Robbie,
>>>
>>> Thanks a lot for details. I am able to reproduce this issue with your
>>> finding, i am facing same idle timeOut issue for
On 30 May 2018 at 11:13, popalka wrote:
> I have 3 observation:
>
>
> 1.) Azure Service Bus place lock on message when receive Flow frame with
> non-zero link credit
>
>
> The clock for the expiration of
You can't, its deep in the internals of the client and not exposed for
outside use (nor will it be).
On 30 May 2018 at 12:45, akabhishek1 wrote:
> Hi Robbie and Team,
>
> I was doing to reseacrh to find out solution for MessageProducer Status.
>
> At this moment i am creating MessageProducer via
Hi Robbie,
Thanks a lot for all help and quick reply. I am going to handle in catch
block and re create producer for JMS IllegalStateException.
Have a nice day !! :)
Regards,
Abhishek Kumar
--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html
On 30/05/18 12:42, Robbie Gemmell wrote:
The client has an notification system for use in its tests, which can
be used to listen for such events as they occur. Using it would tie
application code to the client impl, entirely at odds with using the
vendor neutral JMS API, and the listener
+1.
My testing was:
1) Verified the md5/sha checksums on all distribution artefacts
2) Verified signatures on all the distribution artefacts
3) Ran apache RAT
4) Built/ran test profiles: mms/AMQP1.0, bdb/AMQP0-91, dby/AMQP0-10
from source bundle (using Qpid JMS Client 0.32.0)
5) Generally kicked
Thanks for your comments.
I'll try to collect more trace logs and will return with my findings.
2 problems here:
1) I cannot reliably reproduce this issue locally
2) Log rotation on PROD is too fast, so It's hard to get logs in moment of
issue is reproducing.
--
Sent from:
+1
- Run Murex test suite with Broker-J 7.0.4, Dispatch-Router 0.7.0 and Proton
0.16.0
-Original Message-
From: Keith W
Sent: mercredi 30 mai 2018 15:45
To: users@qpid.apache.org
Subject: Re: [VOTE] Release Apache Qpid Broker-J 7.0.4
+1.
My testing was:
1) Verified the md5/sha
12 matches
Mail list logo
