Description of problem: The python client uses a select() call to implement waiting, but does not handle any errors thrown from this. In the case where the application enables a signal handler, if the signal is sent while the application is waiting on qpid.messaging, say in a fetch(), that operation throws select.error Version-Release number of selected component (if applicable): qpid.0-26 How reproducible: 100% Steps to Reproduce: 1. modify e.g. drain to set a signal handler (see patch below for example) 2. run drain with timeout e.g. drain -t 120 amq.direct 3. send the drain process the relevant signal Actual results: the fetch() call throws an exception Expected results: No exception, signal should be handled and fetch() should behave as normal. Additional info: Example patch to modify drain as in 1. above: diff --git a/qpid/python/examples/api/drain b/qpid/python/examples/api/drain index 5e30153..7a40821 100755 --- a/qpid/python/examples/api/drain +++ b/qpid/python/examples/api/drain @@ -22,6 +22,12 @@ import optparse from qpid.messaging import * from qpid.util import URL from qpid.log import enable, DEBUG, WARN +import signal + +def blah(sig, frm): + print "got signal %s" % sig + +signal.signal(signal.SIGUSR1, blah) parser = optparse.OptionParser(usage="usage: %prog [options] ADDRESS ...", description="Drain messages from the supplied address.")
Fixed upstream: https://svn.apache.org/r1558503
I've tested this and the bug seems to be fixed. Python client is capable of handling a signal. However, when I send a signal to a client a number of times in a row, it still fails, but the traceback is different, though: Traceback (most recent call last): File "./drain", line 92, in ? msg = rcv.fetch(timeout=timeout) File "<string>", line 6, in fetch File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 1021, in fetch msg = self.session._get(self, timeout=timeout) File "<string>", line 6, in _get File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 654, in _get timeout): File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 571, in _ewait result = self.connection._ewait(lambda: self.error or predicate(), timeout) File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 213, in _ewait result = self._wait(lambda: self.error or predicate(), timeout) File "/usr/lib/python2.4/site-packages/qpid/messaging/endpoints.py", line 198, in _wait return self._waiter.wait(predicate, timeout=timeout) File "/usr/lib/python2.4/site-packages/qpid/concurrency.py", line 57, in wait self.condition.wait(3) File "/usr/lib/python2.4/site-packages/qpid/concurrency.py", line 96, in wait sw.wait(timeout) File "/usr/lib/python2.4/site-packages/qpid/compat.py", line 66, in wait raise e select.error: (22, 'Invalid argument') To reproduce on python-qpid-0.18-8, start a modified python client and in a different terminal, execute "count=0; res=0; while [ $res -eq 0 ]; do kill -s SIGUSR1 $(pidof python); res=$?; let count++; echo "iteration $count, result $res"; done"; this fails almost immediately. -> ASSIGNED
Additional fix upstream: https://svn.apache.org/r1560974
Tested on RHEL5.10 and RHEL6.5 (both i386 and x86_64). This issue has been fixed. Packages used for testing: RHEL5: python-qpid-0.18-9.el5_10 python-qpid-qmf-0.18-20.el5_10 qpid-cpp-client-0.18-20.el5_10 qpid-cpp-client-devel-0.18-20.el5_10 qpid-cpp-client-devel-docs-0.18-20.el5_10 qpid-cpp-client-rdma-0.18-20.el5_10 qpid-cpp-client-ssl-0.18-20.el5_10 qpid-cpp-server-0.18-20.el5_10 qpid-cpp-server-cluster-0.18-20.el5_10 qpid-cpp-server-devel-0.18-20.el5_10 qpid-cpp-server-ha-0.18-20.el5_10 qpid-cpp-server-rdma-0.18-20.el5_10 qpid-cpp-server-ssl-0.18-20.el5_10 qpid-cpp-server-store-0.18-20.el5_10 qpid-cpp-server-xml-0.18-20.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-20.el5_10 qpid-qmf-devel-0.18-20.el5_10 qpid-tests-0.18-2.el5 qpid-tools-0.18-10.el5_9 ruby-qpid-qmf-0.18-20.el5_10 RHEL6: python-qpid-0.18-9.el6 python-qpid-qmf-0.18-20.el6 qpid-cpp-client-0.18-20.el6 qpid-cpp-client-devel-0.18-20.el6 qpid-cpp-client-devel-docs-0.18-20.el6 qpid-cpp-client-rdma-0.18-20.el6 qpid-cpp-client-ssl-0.18-20.el6 qpid-cpp-server-0.18-20.el6 qpid-cpp-server-cluster-0.18-20.el6 qpid-cpp-server-devel-0.18-20.el6 qpid-cpp-server-ha-0.18-20.el6 qpid-cpp-server-rdma-0.18-20.el6 qpid-cpp-server-ssl-0.18-20.el6 qpid-cpp-server-store-0.18-20.el6 qpid-cpp-server-xml-0.18-20.el6 qpid-java-client-0.18-8.el6_4 qpid-java-common-0.18-8.el6_4 qpid-java-example-0.18-8.el6_4 qpid-jca-0.18-8.el6 qpid-jca-xarecovery-0.18-8.el6 qpid-jca-zip-0.18-8.el6 qpid-qmf-0.18-20.el6 qpid-qmf-devel-0.18-20.el6 qpid-tests-0.18-2.el6 qpid-tools-0.18-10.el6_4 ruby-qpid-qmf-0.18-20.el6 -> VERIFIED
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-0130.html