qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Kargapolov <dmitriy.kargapo...@gmail.com>
Subject Re: message accept confirmation
Date Thu, 19 Mar 2009 22:31:41 GMT
On Thu, Mar 19, 2009 at 5:42 PM, Dmitriy Kargapolov <
dmitriy.kargapolov@gmail.com> wrote:

> On Thu, Mar 19, 2009 at 4:00 PM, Gordon Sim <gsim@redhat.com> wrote:
>
>> Dmitriy Kargapolov wrote:
>>
>>> Hi,
>>> I'm playing with C++ Qpid broker M4 and .NET client (Win32).
>>> Test scenario looks this way:
>>> 1) open connection
>>> 2) create a session (timeout = 0 sec)
>>> 3) declare a queue (durable, exclusive)
>>> 4) subscribe to the queue
>>> 5) transfer test message to the exchange
>>> 6) wait until message arrives from the queue
>>> 7) accept the message
>>> 8) close session
>>> 9) close connection
>>>
>>> When I run this test, it works just fine. But the message left in the
>>> queue
>>> after test completed! Second pass returns 2 messages - new and old one,
>>> 3rd
>>> pass - 3 messages etc.
>>>
>>> I was able to "fix" this in various ways:
>>> 1) If I add short delay (100ms) between steps 7) and 8), accepted message
>>> successfully deleted from the queue.
>>> Obviously this way is ugly.
>>>
>>
>> I'm not very familiar with the .Net client but what I suspect you want to
>> do is sync with the server on or after step 7 to ensure that the server has
>> processed your accept before you exit.
>>
>> I believe session.sync() should do that, or alternatively setting
>> session.setAutoSync(true). As mentioned though, I'm no expert on the .Net
>> client but hopefully Arnaud or others will correct me if thats wrong.
>>
>
> Added sync():
>             session.sync();
>             session.close();
>             client.close();
>
> This didn't hepl actually.
> Still, if no delay provided before closing session, no 'Accepted' message
> received by broker (checked traces)...
> Looks like some race condition between client threads...
>

No explicit sync() is required.
What actually solved the problem - setting TCP_NODELAY option in
environment:

set qpid.tcpNoDelay=true

This could impact network exchange performance though, in that case the only
solution I see for the moment - pause before closing connection... May be
Devs have an opinion?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message