lroloson wrote:
I turned on the additional logging as suggested - and ran some additional
tests today, using the 0.5 broker on Linux & the 0.5 listener on Windows
(which I modified to reconnect). When I tested again today the messages were
all delivered, however they were out of order. I have attached a snip from
the log, it appears the broker detected the disconnect. I have not tried the
broker built from the trunk yet.
.... log .....
....
2009-aug-04 12:45:09 trace SENT [127.0.0.1:36531]: Frame[BEbe; channel=2;
{SessionCompletedBody: commands={ [0,13] }; }]
2009-aug-04 12:45:10 trace RECV [127.0.0.1:36531]: Frame[Bbe; channel=2;
{MessageTransferBody: destination=amq.direct; accept-mode=1; acquire-mode=0;
}]
2009-aug-04 12:45:10 trace gu...@qpid.1d5ba47a-8968-443d-97b2-1f535908db76:
recv cmd 14: {MessageTransferBody: destination=amq.direct; accept-mode=1;
acquire-mode=0; }
2009-aug-04 12:45:10 trace RECV [127.0.0.1:36531]: Frame[be; channel=2;
header (33 bytes); properties={{MessageProperties: content-length=38;
}{DeliveryProperties: delivery-mode=2; routing-key=aet_key; }}]
2009-aug-04 12:45:10 trace gu...@qpid.1d5ba47a-8968-443d-97b2-1f535908db76:
recv cmd 14: header (33 bytes); properties={{MessageProperties:
content-length=38; }{DeliveryProperties: delivery-mode=2;
routing-key=aet_key; }}
2009-aug-04 12:45:10 trace RECV [127.0.0.1:36531]: Frame[Ebe; channel=2;
content (38 bytes) 15 Message : Tue...]
2009-aug-04 12:45:10 trace gu...@qpid.1d5ba47a-8968-443d-97b2-1f535908db76:
recv cmd 14: content (38 bytes) 15 Message : Tue...
2009-aug-04 12:45:10 debug Message 0x1c3cea40 enqueued on aet_q[0x1c370ca0]
2009-aug-04 12:45:10 debug gu...@qpid.1d5ba47a-8968-443d-97b2-1f535908db76:
receiver marked completed: 14 incomplete: { } unknown-completed: { [0,14] }
2009-aug-04 12:45:10 trace SENT [127.0.0.1:36531]: Frame[BEbe; channel=2;
{SessionCompletedBody: commands={ [0,14] }; }]
2009-aug-04 12:45:11 debug DISCONNECTED [127.0.0.1:36531]
2009-aug-04 12:45:11 debug gu...@qpid.1d5ba47a-8968-443d-97b2-1f535908db76:
detached on broker.
I believe the disconnection here is of the publisher(?), certainly the
session involved had just sent a message to the broker (content starting
'15 Message : Tue'...
Would it be possible to send the whole log, or better still attach it to
a Jira?
My speculative hypothesis earlier was that the new session and
subscription were created before the messages 'locked' by the previous
session were freed (which happens when the broker detects the loss of
the connection).
If you modify your listener to request an exclusive subscription (set
SubcriptionSettings::exclusive to true), that might help confirm the
above (as would the log I hope). This is not foolproof as messages are
requeued after the subscription for a failed connection is cancelled.
However that is a much smaller window. If on making this change you get
an error on subscribe, then we would at least know what the issue was.
2009-aug-04 12:47:46 debug RECV [192.168.230.229:49234] INIT(0-10)
2009-aug-04 12:47:46 debug min_ssf: 0, max_ssf: 256
2009-aug-04 12:47:46 info SASL: Mechanism list: LOGIN ANONYMOUS PLAIN
2009-aug-04 12:47:46 trace SENT 192.168.230.229:49234 INIT(0-10)
2009-aug-04 12:47:46 trace SENT [192.168.230.229:49234]: Frame[BEbe;
channel=0; {ConnectionStartBody:
server-properties={qpid.federation_tag:V2:36:str16(3b244fc7-dce1-404c-9c4c-586577edb814)};
mechanisms=str16{V2:5:str16(LOGIN), V2:9:str16(ANONYMOUS),
V2:5:str16(PLAIN)}; locales=str16{V2:5:str16(en_US)}; }]
2009-aug-04 12:47:46 trace RECV [192.168.230.229:49234]: Frame[BEbe;
channel=0; {ConnectionStartOkBody:
client-properties={qpid.client_pid:F4:int32(4080),qpid.client_ppid:F4:int32(0),qpid.client_process:V2:0:str16(),qpid.session_flow:F4:int32(1)};
mechanism=PLAIN; response=xxxxxx; locale=en_US; }]
....
....
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
