Bug 480619 - Remove need for explicit session sync() before Connection close()
Remove need for explicit session sync() before Connection close()
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
All Linux
medium Severity medium
: 1.3
: ---
Assigned To: Gordon Sim
Frantisek Reznicek
: 453650 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-01-19 08:54 EST by Alan Conway
Modified: 2015-11-15 19:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-24 05:25:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Conway 2009-01-19 08:54:33 EST
Gordon Sim wrote:
> Alan Conway wrote:
>> Gordon Sim wrote:
>>> Sajid.Azami@tsx.com wrote:
>>>> Can you guys throw some light on these messages ... *Background:*  
>>>> Recently I've implemented a Connection Pool (per process) for my 
>>>> MrgServices - where each connection can be shared
>>>> by upto 10 sessions, I do close the session when I'm done, but the 
>>>> connection is only  closed when the last session
>>>> is close.  Is this because of my connection pool.
>>> I would suggest a sync() just before you close the session if you are 
>>> using any asynchronous communication. When a sync() and close on the 
>>> session you should not get any such messages.
>> Perhaps we should do a sync() of all sessions in connection close() so 
>> the user doesn't have to worry about this.
> Yes, I agree; I actually thinks there is something not 100% correct 
> about the session detach process at present, but a sync() in the close 
> is probably a quick workaround.

In addition to sync() we should set timeout to 0 to ensure clean close of the session.
Comment 1 Gordon Sim 2009-01-19 09:22:14 EST
As this can be easily worked around in the application I'm lowering the severity and re-targetting for after 1.1.1 due to time constraints.
Comment 2 Gordon Sim 2009-02-17 09:11:05 EST
*** Bug 453650 has been marked as a duplicate of this bug. ***
Comment 4 Gordon Sim 2010-05-24 05:25:58 EDT
The error that the email thread quoted above is based on refers to warnings in the logs for *incoming* frames that are ignored. This is a result of not cancelling subscriptions (or not waiting for the cancellation to be confirmed) before closing the connection.

An explicit sync() is recommended as it allows any exceptions to be handled (e.g. the in doubt transfer may be invalid of may breach a queue limit).

Note You need to log in before you can comment on or make changes to this bug.