[jira] [Assigned] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-907: - Assignee: Gordon Sim Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-907: -- Fix Version/s: 0.10 Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Fix For: 0.10 Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-911) Implement SASL security layer
[ https://issues.apache.org/jira/browse/PROTON-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612000#comment-14612000 ] ASF subversion and git services commented on PROTON-911: Commit c1a1df200dc1fe1e912930dac96f40f5c6ff3678 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c1a1df2 ] PROTON-911: Signed/unsigned confusion fix - Fixes a warning picked up by the clang compiler. Implement SASL security layer - Key: PROTON-911 URL: https://issues.apache.org/jira/browse/PROTON-911 Project: Qpid Proton Issue Type: Sub-task Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.10 Implement SASL encryption using the Cyrus SASL library. This would allow you to use AMQP over kerberos. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-887) Windows SSL implementation needs working version of pn_ssl_get_remote_subject()
[ https://issues.apache.org/jira/browse/PROTON-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-887. --- Resolution: Fixed Fix Version/s: 0.10 Windows SSL implementation needs working version of pn_ssl_get_remote_subject() --- Key: PROTON-887 URL: https://issues.apache.org/jira/browse/PROTON-887 Project: Qpid Proton Issue Type: Bug Reporter: Andrew Stitcher Assignee: Cliff Jansen Fix For: 0.10 Commit 894a463b introduced a new ssl API pn_ssl_get_remote_subject(). This has no Windows SChannel implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612069#comment-14612069 ] ASF subversion and git services commented on PROTON-907: Commit 5638c5a86c4802e587d111ea888d0d3d3a0045b0 in qpid-proton's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5638c5a ] PROTON-907: check error status of connections selectable, and close transport if set Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Fix For: 0.10 Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-907. --- Resolution: Fixed Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Fix For: 0.10 Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-887) Windows SSL implementation needs working version of pn_ssl_get_remote_subject()
[ https://issues.apache.org/jira/browse/PROTON-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen reassigned PROTON-887: --- Assignee: Cliff Jansen Windows SSL implementation needs working version of pn_ssl_get_remote_subject() --- Key: PROTON-887 URL: https://issues.apache.org/jira/browse/PROTON-887 Project: Qpid Proton Issue Type: Bug Reporter: Andrew Stitcher Assignee: Cliff Jansen Fix For: 0.10 Commit 894a463b introduced a new ssl API pn_ssl_get_remote_subject(). This has no Windows SChannel implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-930) add explicit AMQP 1.0 constants
michael goulish created PROTON-930: -- Summary: add explicit AMQP 1.0 constants Key: PROTON-930 URL: https://issues.apache.org/jira/browse/PROTON-930 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: michael goulish Assignee: michael goulish Priority: Minor Fix For: 0.10 Add an include file that has explicit defined constants for every numeric default value that is mandated by the AMQP 1.0 spec. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-925) proton-c seems to treat unspecified channel-max as implying 0
[
https://issues.apache.org/jira/browse/PROTON-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612572#comment-14612572
]
ASF subversion and git services commented on PROTON-925:
Commit fc38e86a6f5a1b265552708e674d3c8040c1985b in qpid-proton's branch
refs/heads/master from mgoulish
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=fc38e86 ]
PROTON-925: use scanner right for remote_channel_max and remote_max_frame
proton-c seems to treat unspecified channel-max as implying 0
-
Key: PROTON-925
URL: https://issues.apache.org/jira/browse/PROTON-925
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.10
Reporter: Gordon Sim
Assignee: michael goulish
Priority: Blocker
Fix For: 0.10
If max-channels is not specified in the open, it appears the latest proton-c
treats that as implying the maximum is 0 though the spec states the default
is 65535.
This breaks compatibility with previous proton releases. E.g. the following
is the interaction between a sender using the latest 0.10 and a receiver
using proton 0.9.
{noformat}
[0x151c710]: - AMQP
[0x151c710]:0 - @open(16)
[container-id=65A6602D-5D24-4D39-9C6F-7403D98F5E15, hostname=localhost,
channel-max=32767]
[0x151c710]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:1 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:2 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:0 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_a,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_a,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:1 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_b,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_b,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:2 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_c,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_c,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]: - AMQP
[0x151c710]:0 - @open(16)
[container-id=abab56b0-c25e-427b-9f4f-d63da48d1973]
[0x151c710]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:1 - @begin(17) [remote-channel=1, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:2 - @begin(17) [remote-channel=2, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:0 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_a,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_a,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:1 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_b,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_b,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:2 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_c,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_c,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:0 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:1 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:2 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=remote channel 1 is
above negotiated channel_max 0.]]
[0x151c710]: - EOS
[0x151c710]:0 - @close(24) []
[0x151c710]: - EOS
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-925) proton-c seems to treat unspecified channel-max as implying 0
[
https://issues.apache.org/jira/browse/PROTON-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
michael goulish resolved PROTON-925.
Resolution: Fixed
commit fc38e86a6f5a1b265552708e674d3c8040c1985b
proton-c seems to treat unspecified channel-max as implying 0
-
Key: PROTON-925
URL: https://issues.apache.org/jira/browse/PROTON-925
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.10
Reporter: Gordon Sim
Assignee: michael goulish
Priority: Blocker
Fix For: 0.10
If max-channels is not specified in the open, it appears the latest proton-c
treats that as implying the maximum is 0 though the spec states the default
is 65535.
This breaks compatibility with previous proton releases. E.g. the following
is the interaction between a sender using the latest 0.10 and a receiver
using proton 0.9.
{noformat}
[0x151c710]: - AMQP
[0x151c710]:0 - @open(16)
[container-id=65A6602D-5D24-4D39-9C6F-7403D98F5E15, hostname=localhost,
channel-max=32767]
[0x151c710]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:1 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:2 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:0 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_a,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_a,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:1 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_b,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_b,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:2 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_c,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_c,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]: - AMQP
[0x151c710]:0 - @open(16)
[container-id=abab56b0-c25e-427b-9f4f-d63da48d1973]
[0x151c710]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:1 - @begin(17) [remote-channel=1, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:2 - @begin(17) [remote-channel=2, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:0 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_a,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_a,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:1 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_b,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_b,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:2 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_c,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_c,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:0 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:1 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:2 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=remote channel 1 is
above negotiated channel_max 0.]]
[0x151c710]: - EOS
[0x151c710]:0 - @close(24) []
[0x151c710]: - EOS
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
