[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=14610797#comment-14610797 ] Gordon Sim commented on PROTON-907: --- Perhaps a better fix posted for review: https://reviews.apache.org/r/36102/ 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 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] [Created] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
Gordon Sim created PROTON-927: - Summary: absolute-expiry-time and creation-time are encoded as 0 if not set Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609895#comment-14609895 ] Gordon Sim commented on PROTON-927: --- https://reviews.apache.org/r/36087/ absolute-expiry-time and creation-time are encoded as 0 if not set -- Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-881: Graceful handling of runtime...
Github user prestona commented on the pull request: https://github.com/apache/qpid-proton/pull/37#issuecomment-117609566 This was merged by @rhs as cd42324 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: PROTON-881: Graceful handling of runtime...
Github user prestona closed the pull request at: https://github.com/apache/qpid-proton/pull/37 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609941#comment-14609941 ] ASF GitHub Bot commented on PROTON-881: --- Github user prestona commented on the pull request: https://github.com/apache/qpid-proton/pull/37#issuecomment-117609566 This was merged by @rhs as cd42324 Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-881: Make connect a non-blocking ...
GitHub user prestona opened a pull request: https://github.com/apache/qpid-proton/pull/40 PROTON-881: Make connect a non-blocking operation Previously connecting was a blocking operation which meant that if the server being connected to took a long time to accept the connection this blocked all other work in an instance of the Reactor. This commit makes connect a non-blocking operation, allowing the reactor to continue processing other work while the connection is established (or not). Unfortunately, I've not found a satisfactory way to test this behavior in the test suite - because Java never blocks during connect if it is using the loopback adapter. Instead, to test the non-blocking connect code path, I had to configure firewall rules to drop all packets sent to a particular port. You can merge this pull request into a Git repository by running: $ git pull https://github.com/prestona/qpid-proton reactor Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/40.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #40 commit 4f2bac8ba136866c55e136fd6a71588bca7c179d Author: Adrian Preston prest...@uk.ibm.com Date: 2015-06-26T22:58:21Z PROTON-881: Make connect a non-blocking operation Previously connecting was a blocking operation which meant that if the server being connected to took a long time to accept the connection this blocked all other work in an instance of the Reactor. This commit makes connect a non-blocking operation, allowing the reactor to continue processing other work while the connection is established (or not). Unfortunately, I've not found a satisfactory way to test this behavior in the test suite - because Java never blocks during connect if it is using the loopback adapter. Instead, to test the non-blocking connect code path, I had to configure firewall rules to drop all packets sent to a particular port. commit f06a1bb3f931531bee6891fa4036fdd2695039cc Author: Adrian Preston prest...@uk.ibm.com Date: 2015-06-27T19:48:37Z PROTON-881: Tidy up TODOs in proton-j reactor code About half the TODOs were me being overly paranoid. The rest generally required some tidy-up. One decision I made was to swallow IOExceptions thrown from closing something - because there was no other cleanup action that could be taken - and rethrowing as an unchecked exception seemed a little heavy-handed. commit 19d23dfbc8178e4dffc2173f00a4c9a526c33601 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-06-30T23:30:53Z PROTON-881: Tidy up and doc reactor interfaces Tidy up the Java interfaces for the proton-j reactor by removing a few unnecessary setters. Document the interfaces using Javadoc. commit a29254752a08285192aae878db9986f4af569d2c Author: Adrian Preston prest...@uk.ibm.com Date: 2015-07-01T00:22:55Z PROTON-881: Tidy up proton-j reactor examples Tidy up comments and more closely mirror the Python examples. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (PROTON-928) Cancellable tasks
Bozo Dragojevic created PROTON-928: -- Summary: Cancellable tasks Key: PROTON-928 URL: https://issues.apache.org/jira/browse/PROTON-928 Project: Qpid Proton Issue Type: Improvement Components: proton-c, proton-j, python-binding Reporter: Bozo Dragojevic Allow scheduled tasks to be cancelled. A cancelled task does not keep reactor from stoping running -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609943#comment-14609943 ] ASF GitHub Bot commented on PROTON-881: --- Github user prestona closed the pull request at: https://github.com/apache/qpid-proton/pull/37 Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609945#comment-14609945 ] ASF GitHub Bot commented on PROTON-881: --- GitHub user prestona opened a pull request: https://github.com/apache/qpid-proton/pull/40 PROTON-881: Make connect a non-blocking operation Previously connecting was a blocking operation which meant that if the server being connected to took a long time to accept the connection this blocked all other work in an instance of the Reactor. This commit makes connect a non-blocking operation, allowing the reactor to continue processing other work while the connection is established (or not). Unfortunately, I've not found a satisfactory way to test this behavior in the test suite - because Java never blocks during connect if it is using the loopback adapter. Instead, to test the non-blocking connect code path, I had to configure firewall rules to drop all packets sent to a particular port. You can merge this pull request into a Git repository by running: $ git pull https://github.com/prestona/qpid-proton reactor Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/40.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #40 commit 4f2bac8ba136866c55e136fd6a71588bca7c179d Author: Adrian Preston prest...@uk.ibm.com Date: 2015-06-26T22:58:21Z PROTON-881: Make connect a non-blocking operation Previously connecting was a blocking operation which meant that if the server being connected to took a long time to accept the connection this blocked all other work in an instance of the Reactor. This commit makes connect a non-blocking operation, allowing the reactor to continue processing other work while the connection is established (or not). Unfortunately, I've not found a satisfactory way to test this behavior in the test suite - because Java never blocks during connect if it is using the loopback adapter. Instead, to test the non-blocking connect code path, I had to configure firewall rules to drop all packets sent to a particular port. commit f06a1bb3f931531bee6891fa4036fdd2695039cc Author: Adrian Preston prest...@uk.ibm.com Date: 2015-06-27T19:48:37Z PROTON-881: Tidy up TODOs in proton-j reactor code About half the TODOs were me being overly paranoid. The rest generally required some tidy-up. One decision I made was to swallow IOExceptions thrown from closing something - because there was no other cleanup action that could be taken - and rethrowing as an unchecked exception seemed a little heavy-handed. commit 19d23dfbc8178e4dffc2173f00a4c9a526c33601 Author: Adrian Preston prest...@uk.ibm.com Date: 2015-06-30T23:30:53Z PROTON-881: Tidy up and doc reactor interfaces Tidy up the Java interfaces for the proton-j reactor by removing a few unnecessary setters. Document the interfaces using Javadoc. commit a29254752a08285192aae878db9986f4af569d2c Author: Adrian Preston prest...@uk.ibm.com Date: 2015-07-01T00:22:55Z PROTON-881: Tidy up proton-j reactor examples Tidy up comments and more closely mirror the Python examples. Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
AMQP 1.0 session outgoing-window usage / meaning
Hi all, Short intro: The way we use the outgoing-window feels wrong, and seems to violate at least one bit of the related [and unclear overall] description in the spec. The way we use it means we currently can't send messages to ServiceBus in many cases (likely anything-but-messenger). Full version: A user reported being unable to send messages to Service Bus (Azure or Windows variants) using the new JMS client. Investigating that lead me to the handling of session outgoing-window in proton (and incoming-window in ServiceBus). I'd like to discuss how proton uses this, what the spec actually says on how it should be used since its not clear to me these are currently in alignment, and possibly changing how we utilise it in proton. In Proton the outgoing-window is set based on the amount of outstanding outgoing bytes for the session (from buffered sends) and the frame size, which leads to many situations where the advertised value is 0, particularly in a client that creates sessions entirely independently from sending messages (such as a JMS client, or the Qpid Messaging C++ client). We then send transfer frames if a link has credit, regardless of the session outgoing window, only withholding them if the remote-incoming-window hits 0. This causes problems against ServiceBus because it seems to base its advertised incoming window on the clients [initial] advertised outgoing window. If it is 0, then it means we can never send any messages. The intent/definition of the outgoing-window seems a bit unclear as a whole in the spec to me, to the point you could almost remove it without issue given the [remote-]incoming-window seems to govern overall behaviour. However, it seems wrong to me that we often set the outgoing-window to 0. Doing this means we violate the outgoing window (local and at peer) whenever we send a message if the remote-incoming-window allowed it. If we tried not to violate it, we would have to flow the new session window before every send, which again seems odd. It feels to me like it would be better to define initial values for the windows, perhaps allowing that to be configurable in the same manner as e.g max frame size is. Those that want to impose some limit then could, and those that don't can leave/set it to the max values to achieve that effect. Thoughts? Robbie
[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=14610895#comment-14610895 ] ASF subversion and git services commented on PROTON-911: Commit 395b23f5fee57d55ed7395723f560eefe3747c07 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=395b23f ] PROTON-911: Implemented encryption/decryption functionality for Cyrus SASL 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 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)
RE: AMQP 1.0 session outgoing-window usage / meaning
FYI, I have forwarded this and important bits of the preceding discussion to our AMQP stack dev within the ServiceBus team. Both the Qpid JMS AMQP 1.0 legacy client and Proton-C have been working fine with Azure SB for years now. Proton-J, however, is not something we have explored previously, and obviously there is something different about its behavior compared to the other clients. The Qpid JMS client is our recommended JMS client for interop with ServiceBus, and we would like to keep up with the times and not have to direct customers to the legacy client, so we are very interested in figuring out the correct resolution to this issue. -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: Wednesday, July 1, 2015 7:48 AM To: us...@qpid.apache.org; proton@qpid.apache.org Subject: AMQP 1.0 session outgoing-window usage / meaning Hi all, Short intro: The way we use the outgoing-window feels wrong, and seems to violate at least one bit of the related [and unclear overall] description in the spec. The way we use it means we currently can't send messages to ServiceBus in many cases (likely anything-but-messenger). Full version: A user reported being unable to send messages to Service Bus (Azure or Windows variants) using the new JMS client. Investigating that lead me to the handling of session outgoing-window in proton (and incoming-window in ServiceBus). I'd like to discuss how proton uses this, what the spec actually says on how it should be used since its not clear to me these are currently in alignment, and possibly changing how we utilise it in proton. In Proton the outgoing-window is set based on the amount of outstanding outgoing bytes for the session (from buffered sends) and the frame size, which leads to many situations where the advertised value is 0, particularly in a client that creates sessions entirely independently from sending messages (such as a JMS client, or the Qpid Messaging C++ client). We then send transfer frames if a link has credit, regardless of the session outgoing window, only withholding them if the remote-incoming-window hits 0. This causes problems against ServiceBus because it seems to base its advertised incoming window on the clients [initial] advertised outgoing window. If it is 0, then it means we can never send any messages. The intent/definition of the outgoing-window seems a bit unclear as a whole in the spec to me, to the point you could almost remove it without issue given the [remote-]incoming-window seems to govern overall behaviour. However, it seems wrong to me that we often set the outgoing-window to 0. Doing this means we violate the outgoing window (local and at peer) whenever we send a message if the remote-incoming-window allowed it. If we tried not to violate it, we would have to flow the new session window before every send, which again seems odd. It feels to me like it would be better to define initial values for the windows, perhaps allowing that to be configurable in the same manner as e.g max frame size is. Those that want to impose some limit then could, and those that don't can leave/set it to the max values to achieve that effect. Thoughts? Robbie
[jira] [Created] (PROTON-929) [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete
Ken Giusti created PROTON-929: - Summary: [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete Key: PROTON-929 URL: https://issues.apache.org/jira/browse/PROTON-929 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.10 If both sides of the connection specify just the ANONYMOUS mech, then the connection open does not complete. The frame trace for the connection attempt: ./test-runner unit_tests.connection.APITest.test_sasl_callbacks unit_tests.connection.APITest.test_sasl_callbacks ...[0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x228c1e0]: - AMQP [0x228c1e0]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x2475800]:Authenticated user: anonymous with mechanism ANONYMOUS [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x2475800]:0 - @sasl-outcome(68) [code=0] [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-1, channel-max=32767] [0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x228c1e0]:0 - @sasl-outcome(68) [code=0] hangs waiting for connection to open The server's open frame is never processed by the client, though it has been received 'on the wire'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-911) Implement SASL security layer
[ https://issues.apache.org/jira/browse/PROTON-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-911. Resolution: Implemented Fix Version/s: 0.10 Except for bug fixing, this is now implemented and tested using the DIGEST-MD5 mechanism 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] [Resolved] (PROTON-929) [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete
[ https://issues.apache.org/jira/browse/PROTON-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-929. Resolution: Fixed [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete -- Key: PROTON-929 URL: https://issues.apache.org/jira/browse/PROTON-929 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.10 If both sides of the connection specify just the ANONYMOUS mech, then the connection open does not complete. The frame trace for the connection attempt: ./test-runner unit_tests.connection.APITest.test_sasl_callbacks unit_tests.connection.APITest.test_sasl_callbacks ...[0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x228c1e0]: - AMQP [0x228c1e0]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x2475800]:Authenticated user: anonymous with mechanism ANONYMOUS [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x2475800]:0 - @sasl-outcome(68) [code=0] [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-1, channel-max=32767] [0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x228c1e0]:0 - @sasl-outcome(68) [code=0] hangs waiting for connection to open The server's open frame is never processed by the client, though it has been received 'on the wire'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-929) [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete
[ https://issues.apache.org/jira/browse/PROTON-929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611019#comment-14611019 ] ASF subversion and git services commented on PROTON-929: Commit f99337f1abf95fb1a2002d93b111a25b8f8f98d1 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f99337f ] PROTON-929: Fix for ANONYMOUS cut through - Previously client wasn't reading anything after the SASL interchange [SASL] If both client and server specify ANONYMOUS mech connection setup does not complete -- Key: PROTON-929 URL: https://issues.apache.org/jira/browse/PROTON-929 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ken Giusti Assignee: Andrew Stitcher Fix For: 0.10 If both sides of the connection specify just the ANONYMOUS mech, then the connection open does not complete. The frame trace for the connection attempt: ./test-runner unit_tests.connection.APITest.test_sasl_callbacks unit_tests.connection.APITest.test_sasl_callbacks ...[0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x228c1e0]: - AMQP [0x228c1e0]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=banonymous@t530.localdomain] [0x2475800]:Authenticated user: anonymous with mechanism ANONYMOUS [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-2, channel-max=32767] [0x2475800]: - SASL [0x2475800]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x2475800]:0 - @sasl-outcome(68) [code=0] [0x2475800]: - AMQP [0x2475800]:0 - @open(16) [container-id=test-container-1, channel-max=32767] [0x228c1e0]: - SASL [0x228c1e0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x228c1e0]:0 - @sasl-outcome(68) [code=0] hangs waiting for connection to open The server's open frame is never processed by the client, though it has been received 'on the wire'. -- 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: -- Attachment: PROTON-907-workaround.patch The issue appears to be that on the affected platforms, when unable to connect, the file descriptor is not marked as writeable. Though it hits the read error, messenger only closes the 'tail' of the transport as a result. The head is closed when an error is returned from send, but as the socket is not writeable, send is never called. I don't know what the real fix for this is, messenger is an area of the code I'm even less familiar with. Fwiw the attached patch works around the issue and passes all the existing tests. It works by explicitly closing the head of the transport if there is an error on reading from the socket and the connection has not been closed by the peer. 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 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)
Re: AMQP 1.0 session outgoing-window usage / meaning
Thanks James. Some expansion which may be useful to add. When comparing the older JMS client, proton-c via the Messenger API, and the new JMS client using proton-j, its important to note that they aren't all doing the same thing even where their underlying implementations do seem to share the same behaviour in the cases of proton-c and proton-j. The older JMS client initializes its outgoing window to a fixed number in the session Begin frame and then doesnt seem to ever change it for subsequent Flow frames, and simply manages whether its session can later send transfer frames based on the current value of the remote incoming window. Proton-J and Proton-C similarly only base their session level decision to send transfers on the remote incoming window and not their own outgoing window (which as noted below means they violate their advertised outgoing window, which is often going to be 0). Proton-C and Proton-J both currently look to set the outgoing window at any given time to a calculated value based on either the number of buffered messages or the buffered bytes divided by frame size. If there are no buffered messages at the point the Begin and Flow frames are generated, then the outgoing-window will be set to 0. This appears to function the same for both proton-c and proton-j. A key point though is that I think much of the historic usage of proton-c against Service Bus has been via the Messenger API, which works somewhat differently than many others in that it looks to create a session and a sender and sends the messages in one pipelined sequence of transport output, which means that by the point the Begin frame actually gets generated there are indeed buffered messages to send which means the outgoing-window is initialised to a value greater than zero. Other APIs which create the session as a distinct step thus wont ever have buffered messages when the Begin frame gets created and so the outgoing-window is initialised to 0, which is the behaviour observed with the new JMS client using proton-j and also what I saw when trying proton-c via the Qpid Messaging C++ client (against qpidd). Robbie On 1 July 2015 at 20:54, James Birdsall jb...@microsoft.com wrote: FYI, I have forwarded this and important bits of the preceding discussion to our AMQP stack dev within the ServiceBus team. Both the Qpid JMS AMQP 1.0 legacy client and Proton-C have been working fine with Azure SB for years now. Proton-J, however, is not something we have explored previously, and obviously there is something different about its behavior compared to the other clients. The Qpid JMS client is our recommended JMS client for interop with ServiceBus, and we would like to keep up with the times and not have to direct customers to the legacy client, so we are very interested in figuring out the correct resolution to this issue. -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: Wednesday, July 1, 2015 7:48 AM To: us...@qpid.apache.org; proton@qpid.apache.org Subject: AMQP 1.0 session outgoing-window usage / meaning Hi all, Short intro: The way we use the outgoing-window feels wrong, and seems to violate at least one bit of the related [and unclear overall] description in the spec. The way we use it means we currently can't send messages to ServiceBus in many cases (likely anything-but-messenger). Full version: A user reported being unable to send messages to Service Bus (Azure or Windows variants) using the new JMS client. Investigating that lead me to the handling of session outgoing-window in proton (and incoming-window in ServiceBus). I'd like to discuss how proton uses this, what the spec actually says on how it should be used since its not clear to me these are currently in alignment, and possibly changing how we utilise it in proton. In Proton the outgoing-window is set based on the amount of outstanding outgoing bytes for the session (from buffered sends) and the frame size, which leads to many situations where the advertised value is 0, particularly in a client that creates sessions entirely independently from sending messages (such as a JMS client, or the Qpid Messaging C++ client). We then send transfer frames if a link has credit, regardless of the session outgoing window, only withholding them if the remote-incoming-window hits 0. This causes problems against ServiceBus because it seems to base its advertised incoming window on the clients [initial] advertised outgoing window. If it is 0, then it means we can never send any messages. The intent/definition of the outgoing-window seems a bit unclear as a whole in the spec to me, to the point you could almost remove it without issue given the [remote-]incoming-window seems to govern overall behaviour. However, it seems wrong to me that we often set the outgoing-window to 0. Doing this means we violate the outgoing window (local and at peer) whenever we send
[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=14609612#comment-14609612
]
ASF subversion and git services commented on PROTON-925:
Commit c78392f1901a9a4fa2a44005f78a085840b160b3 in qpid-proton's branch
refs/heads/master from mgoulish
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c78392f ]
PROTON-925: old line of code was initializing remote_channel_max to zero.
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)
