You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Frank Quinn <fq...@gmail.com> on 2015/06/04 16:12:51 UTC
Strange behaviour for pn_messenger_send on CentOS 6
Hi Folks,
I hit a strange issue today when setting up a qpid proton development
environment on a fresh CentOS 6 VM. I first found the issue in our
application, but when I went a little deeper, I realized I could recreate
the issue with the qpid proton send and recv example applications. All you
need to do is run ‘send’ on its own and the pn_messenger_send call hangs
indefinitely. If you start ‘recv’ first, it works fine, but ‘send’ on its
own hangs every time.
This is contrary to its behaviour on my Fedora 21 laptop (latest yum
provisioned 0.8 version) where it always attempts once, logs a failure,
then exits (which is what I would expect).
This effectively deadlocks our application. So far, I’ve tried compiling
qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send
timeout to 1 (it was previously -1), turning off iptables entirely and
disabling selinux and rebooting but no luck. Is this something you folks
have seen before?
Cheers,
Frank
Proton-J engine and thread safety
Posted by "Kritikos, Alex" <Al...@softwareag.com>.
Hi all,
is the proton-j engine meant to be thread safe?
We have been experiencing some sporadic issues where under load, the engine sends callbacks to registered handlers with null as the event. We do not have a standalone repro case yet but just wondered what other people’s experience is as well as what are the recommendations around thread safety.
Thanks,
Alex Kritikos
Software AG
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it, is strictly prohibited. If you have received this communication in error please notify us by e-mail and then delete the e-mail and any copies of it.
Software AG (UK) Limited Registered in England & Wales 1310740 - http://www.softwareag.com/uk
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by Frank Quinn <fq...@gmail.com>.
Thanks - at least I know I'm not going mad! Just raised
https://issues.apache.org/jira/browse/PROTON-907 for tracking.
Cheers,
Frank
On Wed, Jun 10, 2015 at 2:52 PM, Darryl L. Pierce <dp...@redhat.com>
wrote:
> On Wed, Jun 10, 2015 at 02:17:23PM +0100, Frank Quinn wrote:
> > You can recreate this on a CentOS 6.6 box by installing
> qpid-proton-c-devel
> > using yum from EPEL, then compiling the example application that comes
> with
> > it in /usr/share/proton/examples/messenger/send.c.
> >
> > There is no broker with these example applications - it's point to point.
> >
> > There is a matching recv.c application there too. If you start recv
> first,
> > it works fine, but if you don't, the send application hangs which I
> believe
> > is new behaviour.
> >
> > Again, this does not happen on my Fedora laptop - only on CentOS 6.
>
> I'm able to recreate this on RHEL6 as well using the RPMs from EPEL. I
> see the connection aborted notice in the trace and then it fails to
> exit. It appears to be repeatedly calling pn_transport_closed(). The
> stack trace I see on EL6 is:
>
> (gdb) backtrace
> #0 pn_transport_closed (transport=0x804fa28)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/transport/transport.c:2802
> #1 0x00140ea8 in pni_connection_capacity (ctx=0x804f920)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:166
> #2 pni_connection_update (ctx=0x804f920) at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:196
> #3 pni_conn_modified (ctx=0x804f920) at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:225
> #4 0x00141071 in pn_messenger_process_transport (messenger=0x804cb40,
> event=0x805c520)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1201
> #5 0x00141134 in pn_messenger_process_events (messenger=0x804cb40)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1252
> #6 0x00141f83 in pni_connection_readable (sel=0x804f958)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:261
> #7 0x00143425 in pn_selectable_readable (selectable=0x804f958)
> at /home/mcpierce/Programming/Proton/proton-c/src/selectable.c:204
> #8 0x00141483 in pn_messenger_process (messenger=0x804cb40)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1310
> #9 0x001415c8 in pn_messenger_tsync (messenger=0x804cb40,
> predicate=0x13da40 <pn_messenger_sent>, timeout=-1)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1379
> #10 0x00141a97 in pn_messenger_sync (messenger=0x804cb40,
> predicate=0x13da40 <pn_messenger_sent>)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1410
> #11 0x00141c8c in pn_messenger_send (messenger=0x804cb40, n=-1)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:2119
> #12 0x08048e59 in main (argc=-72537468, argv=0xb7ffe000)
> at /home/mcpierce/Programming/Proton/examples/c/messenger/send.c:102
>
> The same backtrace on F22 is:
>
> (gdb) backtrace
> #0 pn_transport_closed (transport=transport@entry=0x60ac40)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/transport/transport.c:2801
> #1 0x00007ffff7bbf0a8 in pni_connection_capacity (sel=0x60aaf0)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:166
> #2 pni_connection_update (sel=0x60aaf0) at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:196
> #3 pni_conn_modified (ctx=0x60aa80) at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:225
> #4 0x00007ffff7bbf135 in pn_messenger_process_transport
> (messenger=messenger@entry=0x605970,
> event=event@entry=0x61a240) at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1201
> #5 0x00007ffff7bbf27b in pn_messenger_process_events
> (messenger=messenger@entry=0x605970)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1252
> #6 0x00007ffff7bbf6d9 in pni_connection_readable (sel=0x60aaf0)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:261
> #7 0x00007ffff7bbf7e8 in pn_messenger_process (messenger=messenger@entry
> =0x605970)
> at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1310
> #8 0x00007ffff7bbf94f in pn_messenger_tsync (messenger=0x605970,
> predicate=0x7ffff7bbc420 <pn_messenger_sent>,
> timeout=-1) at
> /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1379
> #9 0x0000000000401158 in main (argc=<optimized out>, argv=<optimized out>)
> at /home/mcpierce/Programming/Proton/examples/c/messenger/send.c:102
>
> There's definitely a difference in the runtime behavior of Fedora vs.
> RHEL in this case.
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Wed, Jun 10, 2015 at 02:17:23PM +0100, Frank Quinn wrote:
> You can recreate this on a CentOS 6.6 box by installing qpid-proton-c-devel
> using yum from EPEL, then compiling the example application that comes with
> it in /usr/share/proton/examples/messenger/send.c.
>
> There is no broker with these example applications - it's point to point.
>
> There is a matching recv.c application there too. If you start recv first,
> it works fine, but if you don't, the send application hangs which I believe
> is new behaviour.
>
> Again, this does not happen on my Fedora laptop - only on CentOS 6.
I'm able to recreate this on RHEL6 as well using the RPMs from EPEL. I
see the connection aborted notice in the trace and then it fails to
exit. It appears to be repeatedly calling pn_transport_closed(). The
stack trace I see on EL6 is:
(gdb) backtrace
#0 pn_transport_closed (transport=0x804fa28)
at /home/mcpierce/Programming/Proton/proton-c/src/transport/transport.c:2802
#1 0x00140ea8 in pni_connection_capacity (ctx=0x804f920)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:166
#2 pni_connection_update (ctx=0x804f920) at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:196
#3 pni_conn_modified (ctx=0x804f920) at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:225
#4 0x00141071 in pn_messenger_process_transport (messenger=0x804cb40, event=0x805c520)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1201
#5 0x00141134 in pn_messenger_process_events (messenger=0x804cb40)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1252
#6 0x00141f83 in pni_connection_readable (sel=0x804f958)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:261
#7 0x00143425 in pn_selectable_readable (selectable=0x804f958)
at /home/mcpierce/Programming/Proton/proton-c/src/selectable.c:204
#8 0x00141483 in pn_messenger_process (messenger=0x804cb40)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1310
#9 0x001415c8 in pn_messenger_tsync (messenger=0x804cb40, predicate=0x13da40 <pn_messenger_sent>, timeout=-1)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1379
#10 0x00141a97 in pn_messenger_sync (messenger=0x804cb40, predicate=0x13da40 <pn_messenger_sent>)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1410
#11 0x00141c8c in pn_messenger_send (messenger=0x804cb40, n=-1)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:2119
#12 0x08048e59 in main (argc=-72537468, argv=0xb7ffe000)
at /home/mcpierce/Programming/Proton/examples/c/messenger/send.c:102
The same backtrace on F22 is:
(gdb) backtrace
#0 pn_transport_closed (transport=transport@entry=0x60ac40)
at /home/mcpierce/Programming/Proton/proton-c/src/transport/transport.c:2801
#1 0x00007ffff7bbf0a8 in pni_connection_capacity (sel=0x60aaf0)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:166
#2 pni_connection_update (sel=0x60aaf0) at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:196
#3 pni_conn_modified (ctx=0x60aa80) at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:225
#4 0x00007ffff7bbf135 in pn_messenger_process_transport (messenger=messenger@entry=0x605970,
event=event@entry=0x61a240) at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1201
#5 0x00007ffff7bbf27b in pn_messenger_process_events (messenger=messenger@entry=0x605970)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1252
#6 0x00007ffff7bbf6d9 in pni_connection_readable (sel=0x60aaf0)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:261
#7 0x00007ffff7bbf7e8 in pn_messenger_process (messenger=messenger@entry=0x605970)
at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1310
#8 0x00007ffff7bbf94f in pn_messenger_tsync (messenger=0x605970, predicate=0x7ffff7bbc420 <pn_messenger_sent>,
timeout=-1) at /home/mcpierce/Programming/Proton/proton-c/src/messenger/messenger.c:1379
#9 0x0000000000401158 in main (argc=<optimized out>, argv=<optimized out>)
at /home/mcpierce/Programming/Proton/examples/c/messenger/send.c:102
There's definitely a difference in the runtime behavior of Fedora vs.
RHEL in this case.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by Frank Quinn <fq...@gmail.com>.
You can recreate this on a CentOS 6.6 box by installing qpid-proton-c-devel
using yum from EPEL, then compiling the example application that comes with
it in /usr/share/proton/examples/messenger/send.c.
There is no broker with these example applications - it's point to point.
There is a matching recv.c application there too. If you start recv first,
it works fine, but if you don't, the send application hangs which I believe
is new behaviour.
Again, this does not happen on my Fedora laptop - only on CentOS 6.
Cheers,
Frank
On Wed, Jun 10, 2015 at 1:34 PM, Darryl L. Pierce <dp...@redhat.com>
wrote:
> On Tue, Jun 09, 2015 at 10:41:51PM +0100, Frank Quinn wrote:
> > Just tried this and can recreate on a 64 bit laptop running CentOS 6.6
> > natively too. The send application never exits if a receiver is not yet
> > ready. Can anyone else see this or am I going mad?
>
> Are these bits you've built or did you install them from RPM (not sure
> if you said before, so please remind me)? And are you running a Qpid or
> other broker? I ask because it seems you're getting a connection (no
> "connection refused" error) but something else is causing the failure,
> the SASL header mismatch.
>
> How is your SASL configuration setup on the broker to which you're
> connecting?
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Tue, Jun 09, 2015 at 10:41:51PM +0100, Frank Quinn wrote:
> Just tried this and can recreate on a 64 bit laptop running CentOS 6.6
> natively too. The send application never exits if a receiver is not yet
> ready. Can anyone else see this or am I going mad?
Are these bits you've built or did you install them from RPM (not sure
if you said before, so please remind me)? And are you running a Qpid or
other broker? I ask because it seems you're getting a connection (no
"connection refused" error) but something else is causing the failure,
the SASL header mismatch.
How is your SASL configuration setup on the broker to which you're
connecting?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by Frank Quinn <fq...@gmail.com>.
Hi Folks,
Just tried this and can recreate on a 64 bit laptop running CentOS 6.6
natively too. The send application never exits if a receiver is not yet
ready. Can anyone else see this or am I going mad?
Cheers,
Frank
On Thu, Jun 4, 2015 at 3:51 PM, Frank Quinn <fq...@gmail.com> wrote:
> Thanks Darryl,
>
> Also note this is on a VMWare VM if that makes a difference (clock types
> available perhaps?) and it is pinning CPU at the time.
>
> After seeing that a recompile didn't fix the problem, I nuked the newly
> compiled libraries and reverted to the EPEL RPMs:
>
> Installed Packages
> Name : qpid-proton-c-devel
> Arch : x86_64
> Version : 0.8
> Release : 1.el6
> Size : 300 k
> Repo : installed
> From repo : epel
> Summary : Development libraries for writing messaging apps with Qpid
> Proton
> URL : http://qpid.apache.org/proton/
> License : ASL 2.0
> Description : Development libraries for writing messaging apps with Qpid
> Proton.
>
>
> The issue is with send not exiting, so after running the trace on send:
>
> [fquinn@omvmfq01 messenger]$ PN_TRACE_FRM=1 ./send
> [0x19ddf10]: -> SASL
> [0x19ddf10]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b""]
> recv: Connection refused
> [0x19ddf10]:0 -> @open(16) [container-id=""]
> [0x19ddf10]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error", description="SASL header
> mismatch: ''"]]
> [0x19ddf10]:ERROR amqp:connection:framing-error SASL header mismatch: ''
> [0x19ddf10]: <- EOS
> CONNECTION ERROR connection aborted (remote)
>
>
> Stack trace of hung application:
>
> (gdb) bt
> #0 clock_gettime (clock_id=0, tp=0x7fffac992580) at
> ../sysdeps/unix/clock_gettime.c:94
> #1 0x00007f5a1c00912e in pn_i_now () at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/platform.c:31
> #2 0x00007f5a1c0079bf in pn_selector_select (selector=0x19da280,
> timeout=-1) at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/posix/selector.c:161
> #3 0x00007f5a1c0052f9 in pn_messenger_tsync (messenger=0x19d9960,
> predicate=0x7f5a1c0020e0 <pn_messenger_sent>, timeout=<value optimized out>)
> at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1440
> #4 0x0000000000401335 in main ()
>
> Another stack trace from the same instance:
>
> (gdb) bt
> #0 0x00007f5a1b1e9e15 in clock_gettime (clock_id=0, tp=0x7fffac992560)
> at ../sysdeps/unix/clock_gettime.c:94
> #1 0x00007f5a1c00912e in pn_i_now () at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/platform.c:31
> #2 0x00007f5a1c004dce in pni_messenger_tick (messenger=0x19d9960) at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1330
> #3 pn_messenger_process (messenger=0x19d9960) at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1367
> #4 0x00007f5a1c0052b8 in pn_messenger_tsync (messenger=0x19d9960,
> predicate=0x7f5a1c0020e0 <pn_messenger_sent>, timeout=<value optimized
> out>)
> at
> /usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1423
> #5 0x0000000000401335 in main ()
>
>
> Cheers,
> Frank
>
> On Thu, Jun 4, 2015 at 3:38 PM, Darryl L. Pierce <dp...@redhat.com>
> wrote:
>
>> On Thu, Jun 04, 2015 at 03:12:51PM +0100, Frank Quinn wrote:
>> > I hit a strange issue today when setting up a qpid proton development
>> > environment on a fresh CentOS 6 VM. I first found the issue in our
>> > application, but when I went a little deeper, I realized I could
>> recreate
>> > the issue with the qpid proton send and recv example applications. All
>> you
>> > need to do is run ‘send’ on its own and the pn_messenger_send call hangs
>> > indefinitely. If you start ‘recv’ first, it works fine, but ‘send’ on
>> its
>> > own hangs every time.
>> >
>> > This is contrary to its behaviour on my Fedora 21 laptop (latest yum
>> > provisioned 0.8 version) where it always attempts once, logs a failure,
>> > then exits (which is what I would expect).
>> >
>> > This effectively deadlocks our application. So far, I’ve tried compiling
>> > qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send
>> > timeout to 1 (it was previously -1), turning off iptables entirely and
>> > disabling selinux and rebooting but no luck. Is this something you folks
>> > have seen before?
>>
>> Hrm, this isn't something I've heard reported before. Does it do the
>> same if you use the Python recv.py example as well?
>>
>> Also, can you do the following:
>>
>> $ PN_TRACE_FRM=1 ./recv [options]
>>
>> and share the output displayed?
>>
>> Also, is this solely with binaries you've built or are you installed
>> RPMs from EPEL for Proton?
>>
>> --
>> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
>> Delivering value year after year.
>> Red Hat ranks #1 in value among software vendors.
>> http://www.redhat.com/promo/vendor/
>>
>>
>
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by Frank Quinn <fq...@gmail.com>.
Thanks Darryl,
Also note this is on a VMWare VM if that makes a difference (clock types
available perhaps?) and it is pinning CPU at the time.
After seeing that a recompile didn't fix the problem, I nuked the newly
compiled libraries and reverted to the EPEL RPMs:
Installed Packages
Name : qpid-proton-c-devel
Arch : x86_64
Version : 0.8
Release : 1.el6
Size : 300 k
Repo : installed
>From repo : epel
Summary : Development libraries for writing messaging apps with Qpid
Proton
URL : http://qpid.apache.org/proton/
License : ASL 2.0
Description : Development libraries for writing messaging apps with Qpid
Proton.
The issue is with send not exiting, so after running the trace on send:
[fquinn@omvmfq01 messenger]$ PN_TRACE_FRM=1 ./send
[0x19ddf10]: -> SASL
[0x19ddf10]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
recv: Connection refused
[0x19ddf10]:0 -> @open(16) [container-id=""]
[0x19ddf10]:0 -> @close(24) [error=@error(29)
[condition=:"amqp:connection:framing-error", description="SASL header
mismatch: ''"]]
[0x19ddf10]:ERROR amqp:connection:framing-error SASL header mismatch: ''
[0x19ddf10]: <- EOS
CONNECTION ERROR connection aborted (remote)
Stack trace of hung application:
(gdb) bt
#0 clock_gettime (clock_id=0, tp=0x7fffac992580) at
../sysdeps/unix/clock_gettime.c:94
#1 0x00007f5a1c00912e in pn_i_now () at
/usr/src/debug/qpid-proton-0.8/proton-c/src/platform.c:31
#2 0x00007f5a1c0079bf in pn_selector_select (selector=0x19da280,
timeout=-1) at
/usr/src/debug/qpid-proton-0.8/proton-c/src/posix/selector.c:161
#3 0x00007f5a1c0052f9 in pn_messenger_tsync (messenger=0x19d9960,
predicate=0x7f5a1c0020e0 <pn_messenger_sent>, timeout=<value optimized out>)
at
/usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1440
#4 0x0000000000401335 in main ()
Another stack trace from the same instance:
(gdb) bt
#0 0x00007f5a1b1e9e15 in clock_gettime (clock_id=0, tp=0x7fffac992560)
at ../sysdeps/unix/clock_gettime.c:94
#1 0x00007f5a1c00912e in pn_i_now () at
/usr/src/debug/qpid-proton-0.8/proton-c/src/platform.c:31
#2 0x00007f5a1c004dce in pni_messenger_tick (messenger=0x19d9960) at
/usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1330
#3 pn_messenger_process (messenger=0x19d9960) at
/usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1367
#4 0x00007f5a1c0052b8 in pn_messenger_tsync (messenger=0x19d9960,
predicate=0x7f5a1c0020e0 <pn_messenger_sent>, timeout=<value optimized
out>)
at
/usr/src/debug/qpid-proton-0.8/proton-c/src/messenger/messenger.c:1423
#5 0x0000000000401335 in main ()
Cheers,
Frank
On Thu, Jun 4, 2015 at 3:38 PM, Darryl L. Pierce <dp...@redhat.com> wrote:
> On Thu, Jun 04, 2015 at 03:12:51PM +0100, Frank Quinn wrote:
> > I hit a strange issue today when setting up a qpid proton development
> > environment on a fresh CentOS 6 VM. I first found the issue in our
> > application, but when I went a little deeper, I realized I could recreate
> > the issue with the qpid proton send and recv example applications. All
> you
> > need to do is run ‘send’ on its own and the pn_messenger_send call hangs
> > indefinitely. If you start ‘recv’ first, it works fine, but ‘send’ on its
> > own hangs every time.
> >
> > This is contrary to its behaviour on my Fedora 21 laptop (latest yum
> > provisioned 0.8 version) where it always attempts once, logs a failure,
> > then exits (which is what I would expect).
> >
> > This effectively deadlocks our application. So far, I’ve tried compiling
> > qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send
> > timeout to 1 (it was previously -1), turning off iptables entirely and
> > disabling selinux and rebooting but no luck. Is this something you folks
> > have seen before?
>
> Hrm, this isn't something I've heard reported before. Does it do the
> same if you use the Python recv.py example as well?
>
> Also, can you do the following:
>
> $ PN_TRACE_FRM=1 ./recv [options]
>
> and share the output displayed?
>
> Also, is this solely with binaries you've built or are you installed
> RPMs from EPEL for Proton?
>
> --
> Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
> Delivering value year after year.
> Red Hat ranks #1 in value among software vendors.
> http://www.redhat.com/promo/vendor/
>
>
Re: Strange behaviour for pn_messenger_send on CentOS 6
Posted by "Darryl L. Pierce" <dp...@redhat.com>.
On Thu, Jun 04, 2015 at 03:12:51PM +0100, Frank Quinn wrote:
> I hit a strange issue today when setting up a qpid proton development
> environment on a fresh CentOS 6 VM. I first found the issue in our
> application, but when I went a little deeper, I realized I could recreate
> the issue with the qpid proton send and recv example applications. All you
> need to do is run ‘send’ on its own and the pn_messenger_send call hangs
> indefinitely. If you start ‘recv’ first, it works fine, but ‘send’ on its
> own hangs every time.
>
> This is contrary to its behaviour on my Fedora 21 laptop (latest yum
> provisioned 0.8 version) where it always attempts once, logs a failure,
> then exits (which is what I would expect).
>
> This effectively deadlocks our application. So far, I’ve tried compiling
> qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send
> timeout to 1 (it was previously -1), turning off iptables entirely and
> disabling selinux and rebooting but no luck. Is this something you folks
> have seen before?
Hrm, this isn't something I've heard reported before. Does it do the
same if you use the Python recv.py example as well?
Also, can you do the following:
$ PN_TRACE_FRM=1 ./recv [options]
and share the output displayed?
Also, is this solely with binaries you've built or are you installed
RPMs from EPEL for Proton?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/