Re: Empty frame
On 07/28/2015 08:17 AM, Tomáš Šoltys wrote: Hi, I am looking for a way hot to send a heartbeat. I have found something about sending an empty frame and pn_transport_set_idle_timeout() Is this somewhat related? Is there a way how to send/receive heartbeats? In AMQP 1.0, heartbeats are configured separately in each direction. That is, each of the connected processes indicates how frequently the remote peer should send some traffic in order to prevent the connection timing out due to being idle. So in proton, to indicate to the remote peer that they should send heartbeats, you do indeed set the idle timeout. Proton will advertise half that time to the peer such that they should then send heartbeats frequently enough to avoid the connection timing out when connected. The sending out of heartbeats by the local peer is controlled by the remote peer and whatever idle timeout it has advertised.
Empty frame
Hi, I am looking for a way hot to send a heartbeat. I have found something about sending an empty frame and pn_transport_set_idle_timeout() Is this somewhat related? Is there a way how to send/receive heartbeats? Thanks and regards, Tomas
Re: Empty frame
Hi Gordon, thanks for the answer. So to make it work it is enough to set idle timeout on both sides and proton will handle rest? Is heartbeat being sent by pn_transport_tick() ? If so in what event it should be sent? In PN_TRANSPORT ? Regards, Tomas 2015-07-28 11:01 GMT+02:00 Gordon Sim g...@redhat.com: On 07/28/2015 08:17 AM, Tomáš Šoltys wrote: Hi, I am looking for a way hot to send a heartbeat. I have found something about sending an empty frame and pn_transport_set_idle_timeout() Is this somewhat related? Is there a way how to send/receive heartbeats? In AMQP 1.0, heartbeats are configured separately in each direction. That is, each of the connected processes indicates how frequently the remote peer should send some traffic in order to prevent the connection timing out due to being idle. So in proton, to indicate to the remote peer that they should send heartbeats, you do indeed set the idle timeout. Proton will advertise half that time to the peer such that they should then send heartbeats frequently enough to avoid the connection timing out when connected. The sending out of heartbeats by the local peer is controlled by the remote peer and whatever idle timeout it has advertised. -- Tomáš Šoltys tomas.sol...@gmail.com http://www.range-software.com (+420) 776-843-663
Re: proton 0.10 blocker
On 07/20/2015 08:53 PM, Rafael Schloming wrote: I'm fine going ahead with Gordon's fix. I don't have a lot of time to dig into the refcounting issue personally right now, but I'd at least leave the bug open until we have made it through a bit more testing. I have an uneasy feeling it (or something closely related) may pop up again if we push harder on testing. You were right I'm afraid! I've seen further failures of a similar nature even with that fix now committed. They seem less frequent (previously I was seeing a core dump every run, now its more like 2 out of 10 or so). My inclination is to revert the original fix for PROTON-905 for now, until more detailed testing and investigation can be carried out. The fix prevents a build up of memory on long running connections where multiple sessions (and links) are opened then closed. As reported this only happens with older versions of the broker. In any case it does also have a workaround (albeit a very inconvenient one) of restarting the connection every so often, at which point the memory is freed. By contrast I don't understand enough about these crashes to suggest any workaround and the effects are more serious even for the latest broker.
[jira] [Commented] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644471#comment-14644471
]
Andrew Stitcher commented on PROTON-923:
This is the issue for raising the correct type of transport error on
authentication failure.
[SASL] PN_TRANSPORT_ERROR event not raised
--
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do
not share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on
the client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does
not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome:
1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from
the SASL failure itself, but rather from a framing error occuring on the
server (which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: proton 0.10 blocker
Awww crap. Let's revert the whole thing then. I always felt that 'fix' was more voodoo than science. IMHO I don't think the original bug should be a blocker for 0.10. IIRC it isn't a regression, and there's a 'work around' by using proton events. - Original Message - From: Gordon Sim g...@redhat.com To: d...@qpid.apache.org Cc: proton@qpid.apache.org Sent: Tuesday, July 28, 2015 10:09:07 AM Subject: Re: proton 0.10 blocker On 07/20/2015 08:53 PM, Rafael Schloming wrote: I'm fine going ahead with Gordon's fix. I don't have a lot of time to dig into the refcounting issue personally right now, but I'd at least leave the bug open until we have made it through a bit more testing. I have an uneasy feeling it (or something closely related) may pop up again if we push harder on testing. You were right I'm afraid! I've seen further failures of a similar nature even with that fix now committed. They seem less frequent (previously I was seeing a core dump every run, now its more like 2 out of 10 or so). My inclination is to revert the original fix for PROTON-905 for now, until more detailed testing and investigation can be carried out. The fix prevents a build up of memory on long running connections where multiple sessions (and links) are opened then closed. As reported this only happens with older versions of the broker. In any case it does also have a workaround (albeit a very inconvenient one) of restarting the connection every so often, at which point the memory is freed. By contrast I don't understand enough about these crashes to suggest any workaround and the effects are more serious even for the latest broker. -- -K
[jira] [Created] (PROTON-963) [SASL] Raise PN_TRANSPORT_ERROR events with correct condition for authentication failure
Andrew Stitcher created PROTON-963: -- Summary: [SASL] Raise PN_TRANSPORT_ERROR events with correct condition for authentication failure Key: PROTON-963 URL: https://issues.apache.org/jira/browse/PROTON-963 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-963) [SASL] Raise PN_TRANSPORT_ERROR events with correct condition for authentication failure
[ https://issues.apache.org/jira/browse/PROTON-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644491#comment-14644491 ] ASF subversion and git services commented on PROTON-963: Commit 0dea44515b152752f04d46aecc6243ebff101cef in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0dea445 ] PROTON-963: Raise Transport Error event with correct condition on authentication failure [SASL] Raise PN_TRANSPORT_ERROR events with correct condition for authentication failure Key: PROTON-963 URL: https://issues.apache.org/jira/browse/PROTON-963 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-923) [SASL] PN_TRANSPORT_ERROR event not raised
[
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti resolved PROTON-923.
---
Resolution: Fixed
Re-tested with 0.10 Beta1 and concur - the TRANSPORT_ERROR event is now
properly posted.
[SASL] PN_TRANSPORT_ERROR event not raised
--
Key: PROTON-923
URL: https://issues.apache.org/jira/browse/PROTON-923
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Reporter: Ken Giusti
Assignee: Andrew Stitcher
Priority: Blocker
Fix For: 0.10
I have a pyngus test that exercises the case where the client and server do
not share compatible mechanisms. The purpose of the test is to check pyngus
handling of this misconfiguration.
At a high level, the SASL configuration is:
server_props = {'x-server': True,
'x-sasl-mechs': 'PLAIN'}
client_props = {'x-server': False,
'x-sasl-mechs': 'ANONYMOUS'}
(these x- values are used to set the corresponding properties in proton's
connection and sasl objects)
When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on
the client side, although the outcome is set to indicate a failure occurred.
Below is the debug output from the test. C1 is the server connection, C2 is
the client. Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does
not:
$ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
unit_tests.connection.APITest.test_sasl_callbacks
...
start
2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
[0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in
mechanism inclusion list.
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: None)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl
outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome:
1)
2015-06-26 10:03:15,295 DEBUG Connection failed:
Condition('amqp:connection:framing-error', 'connection aborted')
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1
(sasl outcome: 1)
2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl
outcome: 1)
unit_tests.connection.APITest.test_sasl_callbacks
...
fail
I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from
the SASL failure itself, but rather from a framing error occuring on the
server (which in itself is suspect, but that's a matter for a different JIRA)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Empty frame
On 07/28/2015 10:57 AM, Tomáš Šoltys wrote: So to make it work it is enough to set idle timeout on both sides and proton will handle rest? If an idle timeout is set by the local application, then proton will raise an error if there is no incoming traffic for that time. If an idle timeout is specified by the remote peer, proton will emit empty frames into its output stream provided the pn_transport_tick() function is called frequently enough. Is heartbeat being sent by pn_transport_tick() ? If so in what event it should be sent? In PN_TRANSPORT ? Yes, the pn_transport_tick will trigger the writing of empty frames to the transport and this should result in a transport event as for any other write.
[jira] [Updated] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-950: --- Description: In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. (was: In the current 0.10 alpha, if SASL PLAIN is selected, SSL is forced. This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library.) SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-960) On error Proton can send an open and a close frame during the SASL negotiation (before sending the AMQP header)
[
https://issues.apache.org/jira/browse/PROTON-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-960.
Resolution: Fixed
Fix Version/s: 0.10
On error Proton can send an open and a close frame during the SASL
negotiation (before sending the AMQP header)
---
Key: PROTON-960
URL: https://issues.apache.org/jira/browse/PROTON-960
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.10
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
Fix For: 0.10
Here is a trace from one of the tests:
{noformat}
$ PN_TRACE_FRM=1 proton-test *Zombie*SASL
proton_tests.engine.IdleTimeoutEventTest.testTimeoutWithZombieServerAndSASL
...[0x1306350]: - SASL
[0x1306350]:0 - @open(16) [container-id=]
[0x1306350]:0 - @close(24) [error=@error(29)
[condition=:amqp:resource-limit-exceeded, description=local-idle-timeout
expired]]
[0x1306350]: - AMQP
[0x1306350]: - EOS
pass
Totals: 1 tests, 1 passed, 0 skipped, 0 ignored, 0 failed
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-959) On error Proton can send an open and a close frame before sending the AMQP header
[
https://issues.apache.org/jira/browse/PROTON-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-959.
Resolution: Fixed
Fix Version/s: 0.10
On error Proton can send an open and a close frame before sending the AMQP
header
-
Key: PROTON-959
URL: https://issues.apache.org/jira/browse/PROTON-959
Project: Qpid Proton
Issue Type: Bug
Affects Versions: 0.10
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
Fix For: 0.10
In the following trace of some transport tests you will see that many of the
tests have open/close frames before the AMQP header is sent.
Trace from some of the tests:
{noformat}
$ PN_TRACE_FRM=1 proton-test *ServerTransport*
proton_tests.transport.ServerTransportTest.testBigGarbage
...[0x1ef9b40]:0 - @open(16)
[container-id=]
[0x1ef9b40]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=Unknown protocol
detected: 'GARBAGE_XXX']]
[0x1ef9b40]: - AMQP
[0x1ef9b40]: - EOS
pass
proton_tests.transport.ServerTransportTest.testBindAfterOpen
[0x20d1460]: - AMQP
[0x20d1460]:0 - @open(16) [container-id=test-container,
hostname=test-hostname, channel-max=32767]
[0x20d1460]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
[0x1fa0350]: - AMQP
[0x1fa0350]:0 - @open(16) [container-id=test-container,
hostname=test-hostname, channel-max=32767]
[0x1fa0350]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=2147483647]
pass
proton_tests.transport.ServerTransportTest.testCloseHead
pass
proton_tests.transport.ServerTransportTest.testCloseTail
[0x1fa0350]:0 - @open(16)
[container-id=]
[0x1fa0350]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=No valid protocol
header found]]
[0x1fa0350]: - EOS
pass
proton_tests.transport.ServerTransportTest.testEOS
..[0x20b55d0]:0 - @open(16)
[container-id=]
[0x20b55d0]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=No valid protocol
header found]]
[0x20b55d0]: - EOS
[0x20b55d0]: - EOS
pass
proton_tests.transport.ServerTransportTest.testEOSAfterSASL
.[0x20b55d0]: - SASL
[0x20b55d0]:0 - @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=banonymous@pansy.local]
[0x20b55d0]: - AMQP
[0x1fa0350]: - SASL
[0x1fa0350]:0 - @sasl-init(65) [mechanism=:ANONYMOUS,
initial-response=banonymous@pansy.local]
[0x1fa0350]:Authenticated user: anonymous with mechanism ANONYMOUS
[0x1fa0350]: - AMQP
[0x1fa0350]: - EOS
[0x1fa0350]: - EOS
pass
proton_tests.transport.ServerTransportTest.testGarbage
..[0x20b55d0]:0 - @open(16)
[container-id=]
[0x20b55d0]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=Unknown protocol
detected: 'GARBAGE_']]
[0x20b55d0]: - AMQP
[0x20b55d0]: - EOS
pass
proton_tests.transport.ServerTransportTest.testHeader
...[0x1fa0350]: - AMQP
[0x1fa0350]:0 - @open(16) [container-id=]
[0x1fa0350]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=connection
aborted]]
[0x1fa0350]: - EOS
[0x1fa0350]: - AMQP
[0x20b55d0]: - AMQP
[0x20b55d0]:0 - @open(16) [container-id=]
[0x20b55d0]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=connection
aborted]]
[0x20b55d0]: - EOS
[0x1fa0350]: - EOS
pass
proton_tests.transport.ServerTransportTest.testPartial
..[0x20b55d0]:0 - @open(16)
[container-id=]
[0x20b55d0]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=End of input stream
before protocol detection: 'AMQ' (connection aborted)]]
[0x20b55d0]: - AMQP
[0x20b55d0]: - EOS
pass
proton_tests.transport.ServerTransportTest.testPeek
. pass
proton_tests.transport.ServerTransportTest.testProtocolNotSupported
.[0x20b55d0]:0 - @open(16) [container-id=]
[0x20b55d0]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=Incompatible AMQP
connection detected: 'AMQP\x01\x01\x0a\x00']]
[0x20b55d0]: - AMQP
[0x20b55d0]: - EOS
pass
proton_tests.transport.ServerTransportTest.testSmallGarbage
.[0x1fa0350]:0 - @open(16) [container-id=]
[0x1fa0350]:0 - @close(24)
[jira] [Resolved] (PROTON-963) [SASL] Raise PN_TRANSPORT_ERROR events with correct condition for authentication failure
[ https://issues.apache.org/jira/browse/PROTON-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-963. Resolution: Fixed [SASL] Raise PN_TRANSPORT_ERROR events with correct condition for authentication failure Key: PROTON-963 URL: https://issues.apache.org/jira/browse/PROTON-963 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644675#comment-14644675 ] Andrew Stitcher commented on PROTON-950: This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10. My proposed change is to add an API to the SASL object allow_insecure_mechs(bool) which defaults to false for the underlying Proton-c library as used directly via the engine or event APIs. If this property is set true then it will allow plain to be used unencrypted. For the messenger APIs I will default to insecure mechs by default for 0.10, but note that this will be changed in 0.11 to a more secure setting in the 0.10 release notes and the messenger documentation. SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644749#comment-14644749 ] ASF subversion and git services commented on PROTON-905: Commit 4c84dd7c3c708fd823116876cd65885a628f92ff in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4c84dd7 ] PROTON-905: Revert PROTON-905: fix to prevent crash with latest qpidd This reverts commit d9ce3cfd0916ae3719cb39a83a6174c5f88b10bb. The latest qpidd is crashing due to the PROTON-905 fix whilst running the HA tests. Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Rafael H. Schloming Priority: Critical Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644751#comment-14644751 ] ASF subversion and git services commented on PROTON-905: Commit 0fa93bcbc0b5cb2988254eadf1bbd8a7f62f87eb in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0fa93bc ] PROTON-905: Revert PROTON-905: fix leak of session/links when not using events This reverts commit 653f4e5fe2b9307dccced0a5a85028d1ca67c66a. This patch causes crashes in qpidd when running its HA tests. Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Rafael H. Schloming Priority: Critical Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644813#comment-14644813 ] Gordon Sim commented on PROTON-950: --- This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10. - Idon't think that is correct. The python 'reactive' api also supported plain previously but now only does so on ssl connections. SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644842#comment-14644842 ] Andrew Stitcher edited comment on PROTON-950 at 7/28/15 6:49 PM: - [I don't understand - the previous code didn't implement any mechanisms except ANONYMOUS, how did PLAIN work?] Oh - I see, that (removed) method set the SASL INIT frame directly to a PLAIN mechanism frame. was (Author: astitcher): [I don't understand - the previous code didn't implement any mechanisms except ANONYMOUS, how did PLAIN work?] Oh - I see that (removed) method set the SASL INIT frame directly to a PLAIN mechanism frame. SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644750#comment-14644750 ] ASF subversion and git services commented on PROTON-905: Commit 0fa93bcbc0b5cb2988254eadf1bbd8a7f62f87eb in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=0fa93bc ] PROTON-905: Revert PROTON-905: fix leak of session/links when not using events This reverts commit 653f4e5fe2b9307dccced0a5a85028d1ca67c66a. This patch causes crashes in qpidd when running its HA tests. Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Rafael H. Schloming Priority: Critical Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644748#comment-14644748 ] ASF subversion and git services commented on PROTON-905: Commit 4c84dd7c3c708fd823116876cd65885a628f92ff in qpid-proton's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4c84dd7 ] PROTON-905: Revert PROTON-905: fix to prevent crash with latest qpidd This reverts commit d9ce3cfd0916ae3719cb39a83a6174c5f88b10bb. The latest qpidd is crashing due to the PROTON-905 fix whilst running the HA tests. Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Rafael H. Schloming Priority: Critical Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644842#comment-14644842 ] Andrew Stitcher commented on PROTON-950: I don't understand - the previous code didn't implement any mechanisms except ANONYMOUS, how did PLAIN work? SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: proton 0.10 blocker
PROTON-905 reverted. - Original Message - From: Ken Giusti kgiu...@redhat.com To: proton@qpid.apache.org Cc: d...@qpid.apache.org Sent: Tuesday, July 28, 2015 10:49:20 AM Subject: Re: proton 0.10 blocker Awww crap. Let's revert the whole thing then. I always felt that 'fix' was more voodoo than science. IMHO I don't think the original bug should be a blocker for 0.10. IIRC it isn't a regression, and there's a 'work around' by using proton events. - Original Message - From: Gordon Sim g...@redhat.com To: d...@qpid.apache.org Cc: proton@qpid.apache.org Sent: Tuesday, July 28, 2015 10:09:07 AM Subject: Re: proton 0.10 blocker On 07/20/2015 08:53 PM, Rafael Schloming wrote: I'm fine going ahead with Gordon's fix. I don't have a lot of time to dig into the refcounting issue personally right now, but I'd at least leave the bug open until we have made it through a bit more testing. I have an uneasy feeling it (or something closely related) may pop up again if we push harder on testing. You were right I'm afraid! I've seen further failures of a similar nature even with that fix now committed. They seem less frequent (previously I was seeing a core dump every run, now its more like 2 out of 10 or so). My inclination is to revert the original fix for PROTON-905 for now, until more detailed testing and investigation can be carried out. The fix prevents a build up of memory on long running connections where multiple sessions (and links) are opened then closed. As reported this only happens with older versions of the broker. In any case it does also have a workaround (albeit a very inconvenient one) of restarting the connection every so often, at which point the memory is freed. By contrast I don't understand enough about these crashes to suggest any workaround and the effects are more serious even for the latest broker. -- -K - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org -- -K
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644837#comment-14644837 ] Gordon Sim commented on PROTON-950: --- It set the chosen mechanism to be plain if a username and password were specified in the url (using the Sasl.plain() method). SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644849#comment-14644849 ] Andrew Stitcher commented on PROTON-950: Given that the 0.10 version of the Python reactive API should work correctly with any other SASL mech just by setting the user and password to the API I'm not sure that the potential accidental security loss is worth it for an such a new API. You can still use the allow_insecure_mechs SASL property to allow PLAIN in this case. However if you feel this is widely used I can change it in the same way as I'm proposing for the messenger API. SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
