Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1098606

Summary: Need to change Selector from singleton to singleton per process (QPID-5637)
Product: Red Hat Enterprise MRG Reporter: Mike Cressman <mcressma>
Component: python-qpidAssignee: Ken Giusti <kgiusti>
Status: CLOSED ERRATA QA Contact: Frantisek Reznicek <freznice>
Severity: high Docs Contact:
Priority: high    
Version: 2.3CC: esammons, freznice, iboverma, jross, lzhaldyb, mcressma
Target Milestone: 2.5.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-qpid-0.18-11 Doc Type: Bug Fix
Doc Text:
Previously, the Selector class instantiated a single global instance of itself. If an application using the selector call forked, the parent and child processes shared the Selector's open file descriptors, which ultimately led to the broker connections failing. The fix changes the behavior of the Selector from singleton, to singleton per process. When the forked child process attempts to use the Selector, the process creates its own set of file descriptors separate to the parent process. The new behavior corrects the originally reported issue.
 Story Points: ---
Clone Of:
: 1100442 (view as bug list) Environment:
Last Closed: 2014-06-30 10:26:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1100442    
Attachments:
Description Flags
Patch to make Selector pid-aware (one Selector per process) none

Description Mike Cressman 2014-05-16 16:12:04 UTC 
Created attachment 896463 [details]
Patch to make Selector pid-aware (one Selector per process)

Description of problem:
The file descriptors registered by the Selector object inside of qpid.messaging are stale after a fork. The Selector object uses a singleton pattern to provide a reference to the same Selector object no matter how many times you call it. This selector object already has registered file descriptors with the filesystem, which allow the selector to read/write data in an I/O efficient manner.  Changing the singleton to keep a Selector per process would allow
each process to use it's own Selector (and associated resources).


Version-Release number of selected component (if applicable):
python-qpid-0.18-9

How reproducible:
100%

Steps to Reproduce:
See https://issues.apache.org/jira/browse/QPID-5637

Actual results:
After a fork, both processes share a Selector, causing problems.

Expected results:
Each process has its own Selector (and resources)


Additional info:
Comment 4 Ken Giusti 2014-05-20 18:14:04 UTC 
Fixed on upstream trunk:
https://svn.apache.org/viewvc?view=revision&revision=r1596341
Comment 5 Ken Giusti 2014-05-20 20:14:42 UTC 
pushed to 0.18 branch:

http://git.app.eng.bos.redhat.com/git/rh-qpid.git/commit/?h=0.18-mrg-kgiusti-bz1098606&id=b36848b52b3817740d1ceb4ea6af93dd315e28ad
Comment 10 Frantisek Reznicek 2014-06-26 15:36:17 UTC 
The issue has been fixed, python client is now able to connect to broker from main and forked process on all RHEL5.9 i/x / 6.4 i/x / 7.0 x:

python-qpid-0.18-12.el5_10
python-qpid-qmf-0.18-24.el5_10
qpid-cpp-client-0.18-25.el5_10
qpid-cpp-client-devel-0.18-25.el5_10
qpid-cpp-client-devel-docs-0.18-25.el5_10
qpid-cpp-client-rdma-0.18-25.el5_10
qpid-cpp-client-ssl-0.18-25.el5_10
qpid-cpp-mrg-debuginfo-0.18-25.el5_10
qpid-cpp-server-0.18-25.el5_10
qpid-cpp-server-cluster-0.18-25.el5_10
qpid-cpp-server-devel-0.18-25.el5_10
qpid-cpp-server-ha-0.18-25.el5_10
qpid-cpp-server-rdma-0.18-25.el5_10
qpid-cpp-server-ssl-0.18-25.el5_10
qpid-cpp-server-store-0.18-25.el5_10
qpid-cpp-server-xml-0.18-25.el5_10
qpid-java-client-0.18-8.el5_9
qpid-java-common-0.18-8.el5_9
qpid-java-example-0.18-8.el5_9
qpid-jca-0.18-8.el5
qpid-jca-xarecovery-0.18-8.el5
qpid-jca-zip-0.18-8.el5
qpid-qmf-0.18-24.el5_10
qpid-qmf-debuginfo-0.18-24.el5_10
qpid-qmf-devel-0.18-24.el5_10
qpid-tests-0.18-2.el5
qpid-tools-0.18-10.el5_9
rh-qpid-cpp-tests-0.18-25.el5_10
ruby-qpid-qmf-0.18-24.el5_10

python-qpid-0.18-12.el6.noarch
python-qpid-qmf-0.18-24.el6.i686
qpid-cpp-client-0.18-25.el6.i686
qpid-cpp-client-devel-0.18-25.el6.i686
qpid-cpp-client-devel-docs-0.18-25.el6.noarch
qpid-cpp-client-rdma-0.18-25.el6.i686
qpid-cpp-client-ssl-0.18-25.el6.i686
qpid-cpp-debuginfo-0.18-25.el6.i686
qpid-cpp-server-0.18-25.el6.i686
qpid-cpp-server-cluster-0.18-25.el6.i686
qpid-cpp-server-devel-0.18-25.el6.i686
qpid-cpp-server-ha-0.18-25.el6.i686
qpid-cpp-server-rdma-0.18-25.el6.i686
qpid-cpp-server-ssl-0.18-25.el6.i686
qpid-cpp-server-store-0.18-25.el6.i686
qpid-cpp-server-xml-0.18-25.el6.i686
qpid-java-client-0.18-8.el6_4.noarch
qpid-java-common-0.18-8.el6_4.noarch
qpid-java-example-0.18-8.el6_4.noarch
qpid-jca-0.18-8.el6.noarch
qpid-jca-xarecovery-0.18-8.el6.noarch
qpid-jca-zip-0.18-8.el6.noarch
qpid-qmf-0.18-24.el6.i686
qpid-qmf-debuginfo-0.18-24.el6.i686
qpid-qmf-devel-0.18-24.el6.i686
qpid-tests-0.18-2.el6.noarch
qpid-tools-0.18-10.el6_4.noarch
rh-qpid-cpp-tests-0.18-25.el6.i686
ruby-qpid-qmf-0.18-24.el6.i686


python-qpid-0.18-12.el7.noarch
python-qpid-qmf-0.18-24.el7.x86_64
qpid-cpp-client-0.18-25.el7.x86_64
qpid-cpp-client-devel-0.18-25.el7.x86_64
qpid-cpp-client-devel-docs-0.18-25.el7.noarch
qpid-cpp-client-rdma-0.18-25.el7.x86_64
qpid-cpp-client-ssl-0.18-25.el7.x86_64
qpid-cpp-debuginfo-0.18-25.el7.x86_64
qpid-cpp-server-0.18-25.el7.x86_64
qpid-cpp-server-cluster-0.18-25.el7.x86_64
qpid-cpp-server-devel-0.18-25.el7.x86_64
qpid-cpp-server-ha-0.18-25.el7.x86_64
qpid-cpp-server-rdma-0.18-25.el7.x86_64
qpid-cpp-server-ssl-0.18-25.el7.x86_64
qpid-cpp-server-store-0.18-25.el7.x86_64
qpid-qmf-0.18-24.el7.x86_64
qpid-qmf-debuginfo-0.18-24.el7.x86_64
qpid-qmf-devel-0.18-24.el7.x86_64
qpid-tools-0.18-10.el7.noarch
rh-qpid-cpp-tests-0.18-25.el7.x86_64

I created special reduced reproducer for RHEL 5/6/7, see it attached in bug 1113675 comment 1.

Reproducer is passing well on RHEL6/7, but on RHEL5 there is another linked problem in different part (while sending from both main and fork process) of the client tracked as bug 1113675.


-> VERIFIED
Comment 12 errata-xmlrpc 2014-06-30 10:26:35 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-0803.html