Bug 480619

Summary: Remove need for explicit session sync() before Connection close()
Product: Red Hat Enterprise MRG Reporter: Alan Conway <aconway>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED WONTFIX QA Contact: Frantisek Reznicek <freznice>
Severity: medium Docs Contact:
Priority: medium    
Version: betaCC: esammons, mgoulish
Target Milestone: 1.3   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-24 09:25:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alan Conway 2009-01-19 13:54:33 UTC
Gordon Sim wrote:
> Alan Conway wrote:
>> Gordon Sim wrote:
>>> Sajid.Azami 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 14:22:14 UTC
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 14:11:05 UTC
*** Bug 453650 has been marked as a duplicate of this bug. ***

Comment 4 Gordon Sim 2010-05-24 09:25:58 UTC
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).