[jira] [Commented] (PROTON-1167) Qpid-proton: SIGSEGV crash when a queue becomes full
[
https://issues.apache.org/jira/browse/PROTON-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15218131#comment-15218131
]
Gordon Sim commented on PROTON-1167:
I wasn't able to reproduce this, either on latest svn/git for qpid/proton, or
on qpid-cpp 0.34 against proton 0.12 (this requires a minor patch to qpid-cpp
in order to compile it). Did you build qpid-cpp 0.34 yourself against 0.12? How
reproducible is it for you?
> Qpid-proton: SIGSEGV crash when a queue becomes full
>
>
> Key: PROTON-1167
> URL: https://issues.apache.org/jira/browse/PROTON-1167
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
> Environment: CentOS7 (latest)
> qpid-proton-c-0.12.0-1.el7.x86_64
>Reporter: Graham Leggett
>
> When qpid is asked to create a default queue as follows:
> {code}
> qpid-config add queue foo
> {code}
> And if an attempt is made to fill this queue to overflow with 1MB messages
> until we run out of space, qpid crashes as follows:
> {code}
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002
> decoded 65536 bytes from 65536
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002
> decoded 1016 bytes from 1016
> 2016-03-29 22:18:59 [Broker] debug received delivery:
> \xE4\x03\x00\x00\x00\x00\x00\x00
> 2016-03-29 22:18:59 [Broker] debug Message received: 1049552 bytes
> 2016-03-29 22:18:59 [System] debug Exception constructed: Maximum depth
> exceeded on foo: current=[count: 125, size: 103905496], max=[size: 104857600]
> (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/Queue.cpp:1633)
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002
> encoded 249 bytes from 65536
> 2016-03-29 22:18:59 [Network] debug qpid.127.0.0.1:5672-127.0.0.1:43002
> decoded 51 bytes from 51
> 2016-03-29 22:18:59 [Broker] debug received delivery:
> \xE4\x03\x00\x00\x00\x00\x00\x00
> 2016-03-29 22:18:59 [Broker] debug Message received: 0 bytes
> 2016-03-29 22:18:59 [Broker] debug clean(): 125 messages remain; head is now 0
> 2016-03-29 22:18:59 [Broker] debug Message 0x69b2e0 published, state is 1
> (head is now 0)
> 2016-03-29 22:18:59 [Broker] debug Message 126 enqueued on foo
> Program received signal SIGSEGV, Segmentation fault.
> pni_process_tpwork_receiver (settle=, delivery=0x698550,
> transport=0x7fffec01c710)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2147
> 2147if ((int16_t) ssn->state.local_channel >= 0 &&
> !delivery->remote.settled && delivery->state.init) {
> Missing separate debuginfos, use: debuginfo-install
> boost-program-options-1.53.0-25.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64
> krb5-libs-1.13.2-10.el7.x86_64 libaio-0.3.109-13.el7.x86_64
> libcom_err-1.42.9-7.el7.x86_64 libdb4-cxx-4.8.30-13.el7.x86_64
> libselinux-2.2.2-6.el7.x86_64 libuuid-2.23.2-26.el7.x86_64
> nss-softokn-freebl-3.16.2.3-13.el7_1.x86_64 pcre-8.32-15.el7.x86_64
> xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64
> (gdb) bt
> #0 pni_process_tpwork_receiver (settle=,
> delivery=0x698550, transport=0x7fffec01c710)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2147
> #1 pni_process_tpwork (transport=transport@entry=0x7fffec01c710,
> endpoint=)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2181
> #2 0x73a898c1 in pni_process_tpwork (endpoint=,
> transport=0x7fffec01c710)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2164
> #3 pni_phase (phase=, transport=0x7fffec01c710)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2381
> #4 pni_process (transport=) at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2399
> #5 pn_output_write_amqp (transport=, layer=,
> bytes=0x7fffec00bf80 "", available=16384)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2550
> #6 0x73a8aacc in transport_produce
> (transport=transport@entry=0x7fffec01c710)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2603
> #7 pn_transport_pending (transport=transport@entry=0x7fffec01c710)
> at
> /usr/src/debug/qpid-proton-0.12.0/proton-c/src/transport/transport.c:2882
> #8 0x73a8acd7 in pn_transport_output (transport=0x7fffec01c710,
> bytes=0x7fffec02f280 "", size=65536)
> at
> /usr/src/debug/qpid-p
[jira] [Commented] (PROTON-1135) [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
[
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15217804#comment-15217804
]
Gordon Sim commented on PROTON-1135:
My 2 cents: servers SHOULD handle the pipelined case (in the case of qpidd, I
consider it a bug in the io handling rather than a concious choice, and I would
guess the same is true of others). That said I do also think that proton is
doing the wrong thing with sasl on the client and should wait for the server to
offer mechanisms before choosing them. It MUST do this when a specific
mechanism isn't chosen anyway (at least when integrated with cyrus), and even
where it is I think it would provide clearer error information. Less of a
concern (to me anyway) is pipelining the open before receiving a successful
outcome.
> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN
> frames by default when connecting out to other peers using the ANONYMOUS
> mech, as shown in the following trace -
> {code}
> [0x7f41f80079c0]: -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f41f80079c0]: -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A",
> max-frame-size=65536, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]: <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]: <- AMQP
> [0x7f41f80079c0]:0 <- @open(16)
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767,
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux",
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see
> diagram below) but in any case various components have shown difficulty with
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =
> AMQP%d3.1.0.0 ->
> <- AMQP%d3.1.0.0
> :
> :
>
> :
> :
> AMQP%d0.1.0.0 ->
> (over SASL secured connection)
> <- AMQP%d0.1.0.0
> open ->
> <- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS
> logins, to aid compatibility with other components that don't expect/handle
> such behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] merge the proton mailing list into the users/dev lists
+1
[jira] [Created] (PROTON-1162) connection capabilities are not sent correctly by default
Gordon Sim created PROTON-1162:
--
Summary: connection capabilities are not sent correctly by default
Key: PROTON-1162
URL: https://issues.apache.org/jira/browse/PROTON-1162
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.12.0
Reporter: Gordon Sim
Priority: Minor
The offered- or desired- capabilities on a connection, they are sent out
incorrectly unless they are explicitly added as symbol or Array containing
symbols.
E.g. instead of
{noformat}
conn.offered_capabilities=["foo", "bar"]
{noformat}
you must use:
{noformat}
conn.offered_capabilities=Array(UNDESCRIBED, Data.SYMBOL, symbol("foo"),
symbol("bar"))
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Activemq timeout
On 05/03/16 09:38, Håvard M. Ottestad wrote: Hi, I’m having trouble with Activemq timing out when I subscribe to a queue over amqp. The timeout is on the Activemq side, and Qpid Proton doesn’t notice and keeps blocking on recv. I’ve tried to add various query params to the subscribe string, but whatever I try it still times out. Does anyone have any experience with Activemq, Qpid Proton and Amqp timing out? What versions of each are you using? What is the error or message on timeout? Can you get a protocol trace (e.g. run your proton application with env var PN_TRACE_FRM=1)?
Re: SASL
On 29/02/16 14:56, Gordon Sim wrote: On 28/02/16 15:59, Kai wrote: I was trying to find some examples or documentation regarding how to use SASL in Proton but did not find anything so far. Can you point me into the right direction? In particular I am interested in determining the identity of a client that has been authenticated as part of a TLS handshake (if that's possible) ... In the c api, pn_ssl_get_remote_subject() gets you the subject field of the certificate. In python that is exposed as a remote_subject property on the ssl object associated with the transport. I'm not sure if/how the java api's offer the behaviour, anyone else able to comment on that? One thing to add/point out here is that proton can be used in different ways. One use is simply as a protocol engine, with bytes pumped in and out by an external io component. In that usage model, you would use java's built in support for SSL (as part of the io).
Re: SASL
On 28/02/16 15:59, Kai wrote: I was trying to find some examples or documentation regarding how to use SASL in Proton but did not find anything so far. Can you point me into the right direction? In particular I am interested in determining the identity of a client that has been authenticated as part of a TLS handshake (if that's possible) ... In the c api, pn_ssl_get_remote_subject() gets you the subject field of the certificate. In python that is exposed as a remote_subject property on the ssl object associated with the transport. I'm not sure if/how the java api's offer the behaviour, anyone else able to comment on that?
Re: How does one setup a topic using qpid-config tyo satisfy QPID JMS requirements?
On 22/02/16 17:55, Robbie Gemmell wrote: The topic config in the jndi.properties file is just an example, only the queue is used by the code for the examples. But to answer the question, one model of a topic in qpidd would be to create an exchange of that name, of either topic or fanout type. i.e. qpid-config add exchange fanout my-jms-topic
Re: Need Help! qpid-cofig: No module named qpid.messaging
On 22/02/16 15:40, Flores, Paul A. wrote: Help! All the I can find when I Google on this messaging I am getting is dated 2010. It references a QMF extras folder that does not exist. Surely there has to be some updated guidance to this issue? This is "blocking" my current sprint progress! How did you install qpid-config, from packages (e.g. rpms) or from source? Or are you running from a build directory? You need the python client installed, I.e. qpid-python from: http://www.apache.org/dyn/closer.lua/qpid/0.32 (qpid-route also requires qpid-qmf I believe, but not the other tools).
[jira] [Resolved] (PROTON-1120) Memory leak using proton.utils
[
https://issues.apache.org/jira/browse/PROTON-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1120.
Resolution: Fixed
> Memory leak using proton.utils
> --
>
> Key: PROTON-1120
> URL: https://issues.apache.org/jira/browse/PROTON-1120
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Environment: python-qpid-proton-0.10-2.fc23.x86_64
> And 0.9-13
>Reporter: Jeff Ortel
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
> Attachments: memory-leak.py
>
>
> I have observed a fairly substantial memory leak using the blocking classes
> in proton.utils. Mainly with sending messages.
> Observations:
> {code}
> growth = 52 MB for 10,000 messages sent
> growth = 104 MB for 20,000 messages sent
> leak = 52 MB per 10,000 sends or ~5 kB / send
> {code}
> The attached reproducer, can be used to collect and display statistics.
> There is likely a better method for measuring the memory growth but this was
> easy. Perhaps there is something incorrect/missing with the way I'm using
> proton or measuring the memory growth/leak?
> {code}
>
> 1 messages
>
> total kB 242088 162567552 - sending
> total kB 293980 68224 59520 - sent
> total kB 293980 68228 59524 - receiving
> total kB 294236 68340 59632 - received
> SizeGrowth Context
> __||__
> 242088 kB +242088 kB sending
> 293980 kB + 51892 kB sent
> 293980 kB + 0 kB receiving
> 294236 kB + 256 kB received
>
> 2 messages
>
> total kB 294236 68348 59640 - sending
> total kB 397820 171896 163232 - sent
> total kB 397820 171900 163236 - receiving
> total kB 398020 172060 163396 - received
> SizeGrowth Context
> __||__
> 294236 kB +294236 kB sending
> 397820 kB +103584 kB sent
> 397820 kB + 0 kB receiving
> 398020 kB + 200 kB received
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1120) Memory leak using proton.utils
[
https://issues.apache.org/jira/browse/PROTON-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-1120:
---
Fix Version/s: 0.12.0
> Memory leak using proton.utils
> --
>
> Key: PROTON-1120
> URL: https://issues.apache.org/jira/browse/PROTON-1120
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Environment: python-qpid-proton-0.10-2.fc23.x86_64
> And 0.9-13
>Reporter: Jeff Ortel
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
> Attachments: memory-leak.py
>
>
> I have observed a fairly substantial memory leak using the blocking classes
> in proton.utils. Mainly with sending messages.
> Observations:
> {code}
> growth = 52 MB for 10,000 messages sent
> growth = 104 MB for 20,000 messages sent
> leak = 52 MB per 10,000 sends or ~5 kB / send
> {code}
> The attached reproducer, can be used to collect and display statistics.
> There is likely a better method for measuring the memory growth but this was
> easy. Perhaps there is something incorrect/missing with the way I'm using
> proton or measuring the memory growth/leak?
> {code}
>
> 1 messages
>
> total kB 242088 162567552 - sending
> total kB 293980 68224 59520 - sent
> total kB 293980 68228 59524 - receiving
> total kB 294236 68340 59632 - received
> SizeGrowth Context
> __||__
> 242088 kB +242088 kB sending
> 293980 kB + 51892 kB sent
> 293980 kB + 0 kB receiving
> 294236 kB + 256 kB received
>
> 2 messages
>
> total kB 294236 68348 59640 - sending
> total kB 397820 171896 163232 - sent
> total kB 397820 171900 163236 - receiving
> total kB 398020 172060 163396 - received
> SizeGrowth Context
> __||__
> 294236 kB +294236 kB sending
> 397820 kB +103584 kB sent
> 397820 kB + 0 kB receiving
> 398020 kB + 200 kB received
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-1120) Memory leak using proton.utils
[
https://issues.apache.org/jira/browse/PROTON-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-1120:
--
Assignee: Gordon Sim
> Memory leak using proton.utils
> --
>
> Key: PROTON-1120
> URL: https://issues.apache.org/jira/browse/PROTON-1120
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Environment: python-qpid-proton-0.10-2.fc23.x86_64
> And 0.9-13
>Reporter: Jeff Ortel
>Assignee: Gordon Sim
> Attachments: memory-leak.py
>
>
> I have observed a fairly substantial memory leak using the blocking classes
> in proton.utils. Mainly with sending messages.
> Observations:
> {code}
> growth = 52 MB for 10,000 messages sent
> growth = 104 MB for 20,000 messages sent
> leak = 52 MB per 10,000 sends or ~5 kB / send
> {code}
> The attached reproducer, can be used to collect and display statistics.
> There is likely a better method for measuring the memory growth but this was
> easy. Perhaps there is something incorrect/missing with the way I'm using
> proton or measuring the memory growth/leak?
> {code}
>
> 1 messages
>
> total kB 242088 162567552 - sending
> total kB 293980 68224 59520 - sent
> total kB 293980 68228 59524 - receiving
> total kB 294236 68340 59632 - received
> SizeGrowth Context
> __||__
> 242088 kB +242088 kB sending
> 293980 kB + 51892 kB sent
> 293980 kB + 0 kB receiving
> 294236 kB + 256 kB received
>
> 2 messages
>
> total kB 294236 68348 59640 - sending
> total kB 397820 171896 163232 - sent
> total kB 397820 171900 163236 - receiving
> total kB 398020 172060 163396 - received
> SizeGrowth Context
> __||__
> 294236 kB +294236 kB sending
> 397820 kB +103584 kB sent
> 397820 kB + 0 kB receiving
> 398020 kB + 200 kB received
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-876) python examples installed under share are not executable
[ https://issues.apache.org/jira/browse/PROTON-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-876: -- Fix Version/s: (was: 0.12.0) > python examples installed under share are not executable > > > Key: PROTON-876 > URL: https://issues.apache.org/jira/browse/PROTON-876 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.9.1 > Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1111) Fix warnings during make doc
[ https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119620#comment-15119620 ] Gordon Sim commented on PROTON-: I think I queried whether it needed to be that way for python 3 (as opposed to simply 'import _compat', the answer to which was yes. However Justin's change is different so may well be fine (I'm not fully up to date on python 3 imports) > Fix warnings during make doc > > > Key: PROTON- > URL: https://issues.apache.org/jira/browse/PROTON- > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, python-binding >Affects Versions: 0.13.0 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: 0.13.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1044. Resolution: Fixed Fix Version/s: 0.12.0 > Create/Delete of BlockingConnection leaks file descriptors > -- > > Key: PROTON-1044 > URL: https://issues.apache.org/jira/browse/PROTON-1044 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: Fedora 22 >Reporter: Jeff Ortel > Fix For: 0.12.0 > > Attachments: jortel.py > > > Each time a BlockingConnection is created, it creates a Container. The > Container() opens (2) file descriptors which are never closed. The result is > that (2) file descriptors are leaked for each time BlockingConnection() is > called even if properly closed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106485#comment-15106485 ] Gordon Sim commented on PROTON-1044: Thanks for confirming Jeff! > Create/Delete of BlockingConnection leaks file descriptors > -- > > Key: PROTON-1044 > URL: https://issues.apache.org/jira/browse/PROTON-1044 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: Fedora 22 >Reporter: Jeff Ortel > Attachments: jortel.py > > > Each time a BlockingConnection is created, it creates a Container. The > Container() opens (2) file descriptors which are never closed. The result is > that (2) file descriptors are leaked for each time BlockingConnection() is > called even if properly closed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1090) BlockingConnection client spins at 100% cpu on reconnect
[ https://issues.apache.org/jira/browse/PROTON-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088068#comment-15088068 ] Gordon Sim commented on PROTON-1090: fix proposed here: https://reviews.apache.org/r/42033/ > BlockingConnection client spins at 100% cpu on reconnect > > > Key: PROTON-1090 > URL: https://issues.apache.org/jira/browse/PROTON-1090 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9.1, 0.12.0 >Reporter: Ken Giusti >Priority: Blocker > Fix For: 0.12.0 > > Attachments: cputest.py > > > Attached is a simple python client that connects to a server and waits > forever for a message to be received, reconnecting on connection failure. > When the server is restarted (in my case I'm using qdrouterd), the client > reconnects then pins the cpu at 100%. It appears as if the > BlockingConnection.wait() method in util.py is the source of the busy loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-732) assertion in transport_consume when authentication fails: Assertion `n == (-1)' failed
[ https://issues.apache.org/jira/browse/PROTON-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-732. - Resolution: Fixed > assertion in transport_consume when authentication fails: Assertion `n == > (-1)' failed > -- > > Key: PROTON-732 > URL: https://issues.apache.org/jira/browse/PROTON-732 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim > > Running the messenger recv example against the java broker (both from latest > trunk at time of raising this issue), if the broker expects authentication > and you don't specify a username and password then the resulting sequence > causes an assertion in the proton-c library. > $ PN_TRACE_FRM=1 ./examples/messenger/c/recv amqp://localhost > [0xc6eb00]: -> SASL > [0xc6eb00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""] > [0xc6eb00]: <- SASL > [0xc6eb00]:0 <- @sasl-mechanisms(64) > [sasl-server-mechanisms=@PN_SYMBOL[:AMQPLAIN, :PLAIN, :"CRAM-MD5"]] > [0xc6eb00]:0 <- @sasl-outcome(68) [code=1] > recv: /home/gordon/projects/proton/proton-c/src/transport/transport.c:1070: > transport_consume: Assertion `n == (-1)' failed. > Aborted (core dumped) > Core was generated by `./examples/messenger/c/recv amqp://localhost'. > Program terminated with signal 6, Aborted. > #0 0x003d54635935 in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: debuginfo-install glibc-2.15-59.fc17.x86_64 > keyutils-libs-1.5.5-2.fc17.x86_64 krb5-libs-1.10.2-12.fc17.x86_64 > libcom_err-1.42.3-3.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 > libuuid-2.21.2-4.fc17.x86_64 openssl-1.0.0k-1.fc17.x86_64 > zlib-1.2.5-7.fc17.x86_64 > (gdb) bt > #0 0x003d54635935 in raise () from /lib64/libc.so.6 > #1 0x003d546370e8 in abort () from /lib64/libc.so.6 > #2 0x003d5462e6a2 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x003d5462e752 in __assert_fail () from /lib64/libc.so.6 > #4 0x7f796eed5823 in transport_consume > (transport=transport@entry=0xc6eb00) at > /home/gordon/projects/proton/proton-c/src/transport/transport.c:1070 > #5 0x7f796eed6e07 in pn_transport_process > (transport=transport@entry=0xc6eb00, size=) at > /home/gordon/projects/proton/proton-c/src/transport/transport.c:2117 > #6 0x7f796eedeb88 in pni_connection_readable (sel=0xc6ea00) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:242 > #7 0x7f796eede310 in pn_messenger_process > (messenger=messenger@entry=0xc6a980) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:1354 > #8 0x7f796eede440 in pn_messenger_tsync (timeout=, > predicate=0x7f796eedab00 , messenger=0xc6a980) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:1423 > #9 pn_messenger_tsync (messenger=0xc6a980, predicate=0x7f796eedab00 > , timeout=) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:1411 > #10 0x7f796eedeca6 in pn_messenger_recv > (messenger=messenger@entry=0xc6a980, n=n@entry=1024) at > /home/gordon/projects/proton/proton-c/src/messenger/messenger.c:2181 > #11 0x00401255 in main (argc=, argv=) > at /home/gordon/projects/proton/examples/messenger/c/recv.c:131 > (gdb) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1049) Reactor needs an alternative to using the URL to pass user authentication information.
[ https://issues.apache.org/jira/browse/PROTON-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1049. Resolution: Fixed > Reactor needs an alternative to using the URL to pass user authentication > information. > -- > > Key: PROTON-1049 > URL: https://issues.apache.org/jira/browse/PROTON-1049 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Gordon Sim >Priority: Blocker > Fix For: 0.12.0 > > > When creating a connection using the Container class, the only way to specify > the username/password credentials is via the URL. This may cause the > credentials to be leaked via the "ps" command if the URL is passed via a > command line argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1080) have container attribute on any relevant event
[ https://issues.apache.org/jira/browse/PROTON-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1080. Resolution: Fixed > have container attribute on any relevant event > -- > > Key: PROTON-1080 > URL: https://issues.apache.org/jira/browse/PROTON-1080 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 > Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.12.0 > > > At present event.container is an alias for event.reactor only for the > on_start() event (and obviously only when a Container instance is actually > being used). It would be nicer to make that alias available on all events. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1049) Reactor needs an alternative to using the URL to pass user authentication information.
[ https://issues.apache.org/jira/browse/PROTON-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-1049: -- Assignee: Gordon Sim > Reactor needs an alternative to using the URL to pass user authentication > information. > -- > > Key: PROTON-1049 > URL: https://issues.apache.org/jira/browse/PROTON-1049 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ken Giusti >Assignee: Gordon Sim >Priority: Blocker > Fix For: 0.12.0 > > > When creating a connection using the Container class, the only way to specify > the username/password credentials is via the URL. This may cause the > credentials to be leaked via the "ps" command if the URL is passed via a > command line argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1080) have container attribute on any relevant event
Gordon Sim created PROTON-1080: -- Summary: have container attribute on any relevant event Key: PROTON-1080 URL: https://issues.apache.org/jira/browse/PROTON-1080 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.11 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.12.0 At present event.container is an alias for event.reactor only for the on_start() event (and obviously only when a Container instance is actually being used). It would be nicer to make that alias available on all events. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-1071) EventInjector hangs on Windows
[ https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046607#comment-15046607 ] Gordon Sim edited comment on PROTON-1071 at 12/8/15 10:02 AM: -- There is no concept in Windows of a general select/poll that works on generic file descriptors/handles. You have a separate synchronous wait model for each file type. On top of that, you have a fancy proactor model (IO completion ports, IOCP) for asynchronous IO on a few file types: sockets and named pipes, but not console IO and anonymous pipes. The IOCP model is the preferred scalable IO mechanism for one or many threads. If using pn_selectable_set_fd(handle_xx) with IOCP, it cannot work for any handle_xx that is not IOCP aware. Well not without adding an extra thread that synchronously checks it (something that may have to be done for console IO). PROTON-668 was an attempt to find a useful subset of Posix and Windows capabilities (and other platforms, if identified) for performant IO (mostly looking at the dispatch router model). Threading consequences were one consideration, but so was mere achievability. The network (socket) IO plus pipe (interrupt mainly) IO were the prime candidates. Hence an "fd" in pn_selectable_set_fd is actually a pn_socket_t, not an int. An external socket may be used in this case, but also a pn_pipe object. In Posix, the pn_pipe is not an OS socket. In Windows, it currently is but may become something else, perhaps even an internal construct in future. Another difference to note, a Posix fd can move between different collections fds for poll/select. A Windows handle can be registered exactly once with a collection. It can never be moved to another selector. It is associated with a single IOCP port until it is closed. was (Author: cliffjansen): There is no concept in Windows of a general select/poll that works on generic file descriptors/handles. You have a separate synchronous wait model for each file type. On top of that, you have a fancy proactor model (IO completion ports, IOCP) for asynchronous IO on a few file types: sockets and named pipes, but not console IO and anonymous pipes. The IOCP model is the preferred scalable IO mechanism for one or many threads. If using pn_selectable_set_fd(handle_xx) with IOCP, it cannot work for any handle_xx that is not IOCP aware. Well not without adding an extra thread that synchronously checks it (something that may have to be done for console IO). PROTON-688 was an attempt to find a useful subset of Posix and Windows capabilities (and other platforms, if identified) for performant IO (mostly looking at the dispatch router model). Threading consequences were one consideration, but so was mere achievability. The network (socket) IO plus pipe (interrupt mainly) IO were the prime candidates. Hence an "fd" in pn_selectable_set_fd is actually a pn_socket_t, not an int. An external socket may be used in this case, but also a pn_pipe object. In Posix, the pn_pipe is not an OS socket. In Windows, it currently is but may become something else, perhaps even an internal construct in future. Another difference to note, a Posix fd can move between different collections fds for poll/select. A Windows handle can be registered exactly once with a collection. It can never be moved to another selector. It is associated with a single IOCP port until it is closed. > EventInjector hangs on Windows > -- > > Key: PROTON-1071 > URL: https://issues.apache.org/jira/browse/PROTON-1071 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.11 > Environment: Windows >Reporter: Ken Giusti >Assignee: Cliff Jansen > Fix For: 0.12.0 > > > I added a new reactor test that exercises the python-proton ApplicationEvent > and EventInjector classes: > proton_tests.reactor.ApplicationEventTest.test_application_events > See tests/python/proton_tests/reactor.py > This test passes on linux, but hangs when run on Windows. > Poking around a bit, I suspect the problem may be in the Windows selector > code. Description: > The EventInjector/ApplicationEvent classes provide a way to trigger events > from threads external to the reactor main loop. See > proton-c/bindings/python/proton/reactor.py. A pipe is used to wake up the > reactor when a new event is sent to the reactor (see reactor.py in the python > bindings). The EventInjector's trigger method puts the event on a queue and > writes to a pipe to wake up the reactor. The on_selectable_readable callback > in the EventInjector is called on the reactor thread
[jira] [Commented] (PROTON-1071) EventInjector hangs on Windows
[ https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046671#comment-15046671 ] Gordon Sim commented on PROTON-1071: In examples/python/reactor/cat.py a selectable is configured to use a normal file that is opened for reading. This is preceded by the comment: '# We can configure a selectable with any file descriptor we want.' I don't doubt that you are correct in all your points about the windows implementation, but I don't agree that EventInjector violates any clearly defined model or that it works on posix only by fortuitous accident. It seems to me that the design as originally conceived did not take windows into account. If the implication is that the reactor - proton's event loop - can only be used with proton objects and operations, that to me seems like a serious limitation. All that said, focusing solely on the functionality provided at present by EventInjector in python, what would be your suggestion for a solution that works on both windows and posix?. Preserving the API in python would be highly desirable but not mandatory. > EventInjector hangs on Windows > -- > > Key: PROTON-1071 > URL: https://issues.apache.org/jira/browse/PROTON-1071 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.11 > Environment: Windows >Reporter: Ken Giusti >Assignee: Cliff Jansen > Fix For: 0.12.0 > > > I added a new reactor test that exercises the python-proton ApplicationEvent > and EventInjector classes: > proton_tests.reactor.ApplicationEventTest.test_application_events > See tests/python/proton_tests/reactor.py > This test passes on linux, but hangs when run on Windows. > Poking around a bit, I suspect the problem may be in the Windows selector > code. Description: > The EventInjector/ApplicationEvent classes provide a way to trigger events > from threads external to the reactor main loop. See > proton-c/bindings/python/proton/reactor.py. A pipe is used to wake up the > reactor when a new event is sent to the reactor (see reactor.py in the python > bindings). The EventInjector's trigger method puts the event on a queue and > writes to a pipe to wake up the reactor. The on_selectable_readable callback > in the EventInjector is called on the reactor thread to get the event off the > queue and clear the pipe. > On windows it appears as if the EventInjector selectable is made "readable" > even though nothing has been written to the pipe. This causes the os.read() > call in the on_selectable_readable() callback to hang. > Best I can tell the windows selector code doesn't work properly with a pipe. > The pn_selector_next() function is returning a read event on the pipe's read > descriptor even though the pipe is empty. But I'm not familiar with the > window's selector implementation, so this is a best guess. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-1071) EventInjector hangs on Windows
[ https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045851#comment-15045851 ] Gordon Sim edited comment on PROTON-1071 at 12/8/15 10:03 AM: -- This JIRA cuts across a number of Proton IO and threading issues. EventInjector as coded violates Proton's io model: the pipe needs to come from pn_pipe() and the reading and writing via pn_read() and pn_write(), all on the reactor's pn_io_t object. It works by fortuitous accident on Posix. Coding EventInjector to work this way for Posix is presumably simple. For Windows, it further requires tackling deferred thread safety, at least for pipes and the associated pn_io_t->selector (but that may pull in everything). As noted in PROTON-640, there is no thread safety in Proton io on Windows other than a weak guarantee that two separate threads may independently work on separate pn_io_t objects. PROTON-668 attempted to document the stronger but still limited thread-safety available in the Posix implementation of Proton io. This is the model of concurrency used by Qpid Dispatch Router and perhaps the model that the Windows implementation should strive to. There is an opposing point of view that pushing thread safety into Proton is counterproductive: applications know what threading/io model works best for their workload. Hence the rising interest in connection_engine. EventInjector seems like a pretty important use case for coordinating threads. Alternatively, a more limited (or dedicated) api extension, perhaps pn_reactor_inject() which does platform-specific thread-safe coordination of something to be collected and the pn_io_t->selector might be more clear in its intention (as opposed to knowing that pn_write/read/select work a certain way together). The Windows io.c and related code could be made to work at the same level of thread safety as Posix, but with obvious locking overhead. If the assumption is that an application needing high performance IO will just use the connection_engine and manage the IO itself, perhaps there is no need to care about the locking penalty. See also PROTON-889 regarding general thread safety outages in Proton on all platforms for pn_io_error() and pn_io_wouldblock(). was (Author: cliffjansen): This JIRA cuts across a number of Proton IO and threading issues. EventInjector as coded violates Proton's io model: the pipe needs to come from pn_pipe() and the reading and writing via pn_read() and pn_write(), all on the reactor's pn_io_t object. It works by fortuitous accident on Posix. Coding EventInjector to work this way for Posix is presumably simple. For Windows, it further requires tackling deferred thread safety, at least for pipes and the associated pn_io_t->selector (but that may pull in everything). As noted in PROTON-640, there is no thread safety in Proton io on Windows other than a weak guarantee that two separate threads may independently work on separate pn_io_t objects. PROTON-688 attempted to document the stronger but still limited thread-safety available in the Posix implementation of Proton io. This is the model of concurrency used by Qpid Dispatch Router and perhaps the model that the Windows implementation should strive to. There is an opposing point of view that pushing thread safety into Proton is counterproductive: applications know what threading/io model works best for their workload. Hence the rising interest in connection_engine. EventInjector seems like a pretty important use case for coordinating threads. Alternatively, a more limited (or dedicated) api extension, perhaps pn_reactor_inject() which does platform-specific thread-safe coordination of something to be collected and the pn_io_t->selector might be more clear in its intention (as opposed to knowing that pn_write/read/select work a certain way together). The Windows io.c and related code could be made to work at the same level of thread safety as Posix, but with obvious locking overhead. If the assumption is that an application needing high performance IO will just use the connection_engine and manage the IO itself, perhaps there is no need to care about the locking penalty. See also PROTON-889 regarding general thread safety outages in Proton on all platforms for pn_io_error() and pn_io_wouldblock(). > EventInjector hangs on Windows > -- > > Key: PROTON-1071 > URL: https://issues.apache.org/jira/browse/PROTON-1071 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.11 > Environment: Windows >Reporter: Ken Giusti >Assignee: Cliff Jansen > Fix For: 0.12.0 > > >
[jira] [Commented] (PROTON-1071) EventInjector hangs on Windows
[
https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045930#comment-15045930
]
Gordon Sim commented on PROTON-1071:
{quote}
EventInjector as coded violates Proton's io model: the pipe needs to come from
pn_pipe() and the reading and writing via pn_read() and pn_write(), all on the
reactor's pn_io_t object. It works by fortuitous accident on Posix.
{quote}
I'm not sure I agree. What is your justification for this? The purpose of
pn_selectable_set_fd surely is to associate any file descriptor with the
pn_selectable. Having to use proton io operations defeats what I understood to
be a key purpose of the integration of selectables with the reactor, namely
providing a way to integrate other things into protons reactor event loop.
> EventInjector hangs on Windows
> --
>
> Key: PROTON-1071
> URL: https://issues.apache.org/jira/browse/PROTON-1071
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.11
> Environment: Windows
>Reporter: Ken Giusti
>Assignee: Cliff Jansen
> Fix For: 0.12.0
>
>
> I added a new reactor test that exercises the python-proton ApplicationEvent
> and EventInjector classes:
> proton_tests.reactor.ApplicationEventTest.test_application_events
> See tests/python/proton_tests/reactor.py
> This test passes on linux, but hangs when run on Windows.
> Poking around a bit, I suspect the problem may be in the Windows selector
> code. Description:
> The EventInjector/ApplicationEvent classes provide a way to trigger events
> from threads external to the reactor main loop. See
> proton-c/bindings/python/proton/reactor.py. A pipe is used to wake up the
> reactor when a new event is sent to the reactor (see reactor.py in the python
> bindings). The EventInjector's trigger method puts the event on a queue and
> writes to a pipe to wake up the reactor. The on_selectable_readable callback
> in the EventInjector is called on the reactor thread to get the event off the
> queue and clear the pipe.
> On windows it appears as if the EventInjector selectable is made "readable"
> even though nothing has been written to the pipe. This causes the os.read()
> call in the on_selectable_readable() callback to hang.
> Best I can tell the windows selector code doesn't work properly with a pipe.
> The pn_selector_next() function is returning a read event on the pipe's read
> descriptor even though the pipe is empty. But I'm not familiar with the
> window's selector implementation, so this is a best guess.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1055) Username sent twice during SASL AUTH
[
https://issues.apache.org/jira/browse/PROTON-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015544#comment-15015544
]
Gordon Sim commented on PROTON-1055:
This is not wrong. From https://tools.ietf.org/html/rfc4616
{quote}
The
client presents the authorization identity (identity to act as),
followed by a NUL (U+) character, followed by the authentication
identity (identity whose password will be used), followed by a NUL
(U+) character, followed by the clear-text password. As with
other SASL mechanisms, the client does not provide an authorization
identity when it wishes the server to derive an identity from the
credentials and use that as the authorization identity.
{quote}
What is the server you are connecting to? Is it possible the error lies on that
side?
> Username sent twice during SASL AUTH
>
>
> Key: PROTON-1055
> URL: https://issues.apache.org/jira/browse/PROTON-1055
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.10
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename: trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC
> 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>Reporter: Simon Lundstrom
>Priority: Blocker
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice
> during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]: -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]: <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]: -> AMQP
> [0x250d3b0]:0 -> @open(16)
> [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="TEST-queue", durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="TEST-queue", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> [0x250d3b0]: <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="",
> max-frame-size=4294967295, channel-max=32767, idle-time-out=15000,
> offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="ActiveMQ", :"topic-prefix"="topic://",
> :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
> incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
> next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0,
> link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]: -> SASL
> [0x18aa060]: <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]: -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs.
> Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]: -> SASL
> [0xa5d0
[jira] [Closed] (PROTON-1051) utils.ConnectionClosed.__init__() references non-existing 'url' attribute
[ https://issues.apache.org/jira/browse/PROTON-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-1051. -- Resolution: Duplicate > utils.ConnectionClosed.__init__() references non-existing 'url' attribute > - > > Key: PROTON-1051 > URL: https://issues.apache.org/jira/browse/PROTON-1051 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: Observed: python-qpid-proton-0.9-2.el7.x86_64 > Looks like it also exists in: python-qpid-proton-0.9-7.el7.x86_64 >Reporter: Jeff Ortel > > utils.ConnectionClosed.__init__() raises exception: > AttributeError: 'ConnectionClosed' object has no attribute 'url' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1005) Factor anonymous-relay handling out of the examples
[ https://issues.apache.org/jira/browse/PROTON-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1005. Resolution: Fixed > Factor anonymous-relay handling out of the examples > --- > > Key: PROTON-1005 > URL: https://issues.apache.org/jira/browse/PROTON-1005 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Justin Ross > Assignee: Gordon Sim > > We'd prefer to handle it internally so the user need not confront it. > http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/proton_server.py.html > http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/server.py.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1000.
Resolution: Fixed
Fix Version/s: (was: 0.11)
0.12.0
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.12.0
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998364#comment-14998364 ] Gordon Sim commented on PROTON-1044: Note the above snippet doesn't leak whether or not there is anything listening on the specified port. > Create/Delete of BlockingConnection leaks file descriptors > -- > > Key: PROTON-1044 > URL: https://issues.apache.org/jira/browse/PROTON-1044 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: Fedora 22 >Reporter: Jeff Ortel > Attachments: jortel.py > > > Each time a BlockingConnection is created, it creates a Container. The > Container() opens (2) file descriptors which are never closed. The result is > that (2) file descriptors are leaked for each time BlockingConnection() is > called even if properly closed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors
[
https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998362#comment-14998362
]
Gordon Sim commented on PROTON-1044:
In the attached reproducer, if you call container.stop() before trying to
delete it, there is no leak of file descriptors. Once created the reactor must
be stopped in order to clean everything up.
Trying out the following variation on the attached reproducer, I also see no
growth in the number of consumed file descriptors:
{noformat}
import os
import gc
from time import sleep
from proton.utils import BlockingConnection
print os.getpid()
for i in range(1000):
print 'pass #{n}'.format(n=i)
con = None
try:
con = BlockingConnection('localhost')
except Exception as e:
print e
finally:
if con:
con.close()
del con
gc.collect()
sleep(1)
{noformat}
Note however that this is based on the latest code upstream, including the most
recent fix to PROTON-1000 which may be relevant.
> Create/Delete of BlockingConnection leaks file descriptors
> --
>
> Key: PROTON-1044
> URL: https://issues.apache.org/jira/browse/PROTON-1044
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
> Environment: Fedora 22
>Reporter: Jeff Ortel
> Attachments: jortel.py
>
>
> Each time a BlockingConnection is created, it creates a Container. The
> Container() opens (2) file descriptors which are never closed. The result is
> that (2) file descriptors are leaked for each time BlockingConnection() is
> called even if properly closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1042) Can't distinguish between null target and null address on a target
[ https://issues.apache.org/jira/browse/PROTON-1042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1042. Resolution: Fixed Assignee: Gordon Sim Fix Version/s: 0.12.0 > Can't distinguish between null target and null address on a target > -- > > Key: PROTON-1042 > URL: https://issues.apache.org/jira/browse/PROTON-1042 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.12.0 > > > In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the > source for pn_do_attach() in transport.c, it appears that 'target' is used to > hold the target address and if that is not specified (and the target is not > a coordinator, it is left as unspecified). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1042) Can't distinguish between null target and null address on a target
Gordon Sim created PROTON-1042: -- Summary: Can't distinguish between null target and null address on a target Key: PROTON-1042 URL: https://issues.apache.org/jira/browse/PROTON-1042 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.11 Reporter: Gordon Sim In both cases pn_terminus_get_type() returns PN_UNSPECIFIED. Looking at the source for pn_do_attach() in transport.c, it appears that 'target' is used to hold the target address and if that is not specified (and the target is not a coordinator, it is left as unspecified). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-1005) Factor anonymous-relay handling out of the examples
[ https://issues.apache.org/jira/browse/PROTON-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-1005: -- Assignee: Gordon Sim > Factor anonymous-relay handling out of the examples > --- > > Key: PROTON-1005 > URL: https://issues.apache.org/jira/browse/PROTON-1005 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Justin Ross > Assignee: Gordon Sim > > We'd prefer to handle it internally so the user need not confront it. > http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/proton_server.py.html > http://qpid.apache.org/releases/qpid-proton-0.10/proton/python/examples/server.py.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1040) BlockingConnection fails to send heartbeats if timeout is None and no local idle time is specified
[ https://issues.apache.org/jira/browse/PROTON-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1040. Resolution: Fixed > BlockingConnection fails to send heartbeats if timeout is None and no local > idle time is specified > -- > > Key: PROTON-1040 > URL: https://issues.apache.org/jira/browse/PROTON-1040 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1040) BlockingConnection fails to send heartbeats if timeout is None and no local idle time is specified
[ https://issues.apache.org/jira/browse/PROTON-1040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-1040: --- Priority: Minor (was: Major) Summary: BlockingConnection fails to send heartbeats if timeout is None and no local idle time is specified (was: BlockingConnection fails to send heartbeats if timeout is None and no local idel time is specified) > BlockingConnection fails to send heartbeats if timeout is None and no local > idle time is specified > -- > > Key: PROTON-1040 > URL: https://issues.apache.org/jira/browse/PROTON-1040 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1040) BlockingConnection fails to send heartbeats if timeout is None and no local idel time is specified
Gordon Sim created PROTON-1040: -- Summary: BlockingConnection fails to send heartbeats if timeout is None and no local idel time is specified Key: PROTON-1040 URL: https://issues.apache.org/jira/browse/PROTON-1040 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.11 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.12.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1038) message-format on received transfer is never checked (nor made available for application to check)
Gordon Sim created PROTON-1038: -- Summary: message-format on received transfer is never checked (nor made available for application to check) Key: PROTON-1038 URL: https://issues.apache.org/jira/browse/PROTON-1038 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.11 Reporter: Gordon Sim Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1003. Resolution: Fixed This JIRA was raised for the specific issue of the error handler at the ssl transport layer, which is now resolved. PROTON-1000 covers the general leak, for which there is apparently still some fix needed. Hence resolving this and re-opening PROTON-1000. > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 > Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.11 > > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-1000:
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-876) python examples installed under share are not executable
[ https://issues.apache.org/jira/browse/PROTON-876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-876: -- Fix Version/s: (was: 0.11) 0.12.0 > python examples installed under share are not executable > > > Key: PROTON-876 > URL: https://issues.apache.org/jira/browse/PROTON-876 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.9.1 > Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > Fix For: 0.12.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1030) Reactor never freed if handler/global_handler set
[
https://issues.apache.org/jira/browse/PROTON-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1030.
Resolution: Fixed
Since no one else seems to have an interest in this, I'll consider it resolved
by my fix.
> Reactor never freed if handler/global_handler set
> -
>
> Key: PROTON-1030
> URL: https://issues.apache.org/jira/browse/PROTON-1030
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Gordon Sim
> Fix For: 0.11
>
>
> E.g.
> {noformat}
> from proton.reactor import Reactor
> class Print(object):
> def on_unhandled(self, name, event):
> print("%s %s" % (name, event))
> while True:
> reactor = Reactor()
> reactor.handler = Print()
> reactor.start()
> reactor.stop()
> {noformat}
> Will grow in memory and eventually crash. On debugging the reactor is never
> finalised.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1030) Reactor never freed if handler/global_handler set
[
https://issues.apache.org/jira/browse/PROTON-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-1030:
---
Description:
E.g.
{noformat}
from proton.reactor import Reactor
class Print(object):
def on_unhandled(self, name, event):
print("%s %s" % (name, event))
while True:
reactor = Reactor()
reactor.handler = Print()
reactor.start()
reactor.stop()
{noformat}
Will grow in memory and eventually crash. On debugging the reactor is never
finalised.
was:
E.g.
{noformat}
from proton.reactor import Container, Reactor
class Print(object):
def on_unhandled(self, name, event):
print("%s %s" % (name, event))
while True:
container = Reactor()
container.handler = Print()
container.start()
container.stop()
{noformat}
Will grow in memory and eventually crash. On debugging the reactor is never
finalised.
> Reactor never freed if handler/global_handler set
> -
>
> Key: PROTON-1030
> URL: https://issues.apache.org/jira/browse/PROTON-1030
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Affects Versions: 0.10
>Reporter: Gordon Sim
> Fix For: 0.11
>
>
> E.g.
> {noformat}
> from proton.reactor import Reactor
> class Print(object):
> def on_unhandled(self, name, event):
> print("%s %s" % (name, event))
> while True:
> reactor = Reactor()
> reactor.handler = Print()
> reactor.start()
> reactor.stop()
> {noformat}
> Will grow in memory and eventually crash. On debugging the reactor is never
> finalised.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1030) Reactor never freed if handler/global_handler set
[
https://issues.apache.org/jira/browse/PROTON-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14967752#comment-14967752
]
Gordon Sim commented on PROTON-1030:
I've committed a fix for this in the python binding. It feels like this should
really be handled more cleanly in the c code, but the reference counting there
is still something of a mystery to me.
> Reactor never freed if handler/global_handler set
> -
>
> Key: PROTON-1030
> URL: https://issues.apache.org/jira/browse/PROTON-1030
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Gordon Sim
> Fix For: 0.11
>
>
> E.g.
> {noformat}
> from proton.reactor import Reactor
> class Print(object):
> def on_unhandled(self, name, event):
> print("%s %s" % (name, event))
> while True:
> reactor = Reactor()
> reactor.handler = Print()
> reactor.start()
> reactor.stop()
> {noformat}
> Will grow in memory and eventually crash. On debugging the reactor is never
> finalised.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1028) BlockingConnection leaks due to cyclical reference
[
https://issues.apache.org/jira/browse/PROTON-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1028.
Resolution: Fixed
> BlockingConnection leaks due to cyclical reference
> --
>
> Key: PROTON-1028
> URL: https://issues.apache.org/jira/browse/PROTON-1028
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> E.g. (whether or not a server is listening):
> {noformat}
> while True:
> sleep(0.1)
> try:
> conn = BlockingConnection("amqp://localhost")
> except ConnectionException, e:
> print e
> {noformat}
> This keeps increasing memory until eventually it core dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1030) Reactor never freed if handler/global_handler set
Gordon Sim created PROTON-1030:
--
Summary: Reactor never freed if handler/global_handler set
Key: PROTON-1030
URL: https://issues.apache.org/jira/browse/PROTON-1030
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.10
Reporter: Gordon Sim
Fix For: 0.11
E.g.
{noformat}
from proton.reactor import Container, Reactor
class Print(object):
def on_unhandled(self, name, event):
print("%s %s" % (name, event))
while True:
container = Reactor()
container.handler = Print()
container.start()
container.stop()
{noformat}
Will grow in memory and eventually crash. On debugging the reactor is never
finalised.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-1028) BlockingConnection leaks due to cyclical reference
[
https://issues.apache.org/jira/browse/PROTON-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-1028:
---
Description:
E.g. (whether or not a server is listening):
{noformat}
while True:
sleep(0.1)
try:
conn = BlockingConnection("amqp://localhost")
except ConnectionException, e:
print e
{noformat}
This keeps increasing memory until eventually it core dumps.
was:
E.g. assuming there is nothing listening on port 12345, run the following:
{noformat}
while True:
sleep(0.1)
try:
conn = BlockingConnection("amqp://localhost:12345", heartbeat=2)
except ConnectionException, e:
print e
{noformat}
Summary: BlockingConnection leaks due to cyclical reference (was:
connect failue when creating BlockingConnection result in memory leak)
> BlockingConnection leaks due to cyclical reference
> --
>
> Key: PROTON-1028
> URL: https://issues.apache.org/jira/browse/PROTON-1028
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Affects Versions: 0.10
> Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> E.g. (whether or not a server is listening):
> {noformat}
> while True:
> sleep(0.1)
> try:
> conn = BlockingConnection("amqp://localhost")
> except ConnectionException, e:
> print e
> {noformat}
> This keeps increasing memory until eventually it core dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1028) connect failue when creating BlockingConnection result in memory leak
Gordon Sim created PROTON-1028:
--
Summary: connect failue when creating BlockingConnection result in
memory leak
Key: PROTON-1028
URL: https://issues.apache.org/jira/browse/PROTON-1028
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.10
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.11
E.g. assuming there is nothing listening on port 12345, run the following:
{noformat}
while True:
sleep(0.1)
try:
conn = BlockingConnection("amqp://localhost:12345", heartbeat=2)
except ConnectionException, e:
print e
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1025) CLOSE_WAIT leak following reproducer for PROTON-1023 / PROTON-1024
[
https://issues.apache.org/jira/browse/PROTON-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966806#comment-14966806
]
Gordon Sim commented on PROTON-1025:
The example above 'leaks' BlockingConnection instances. I.e. if rec2 is created
successfully, the while loop will proceed and the BlockingConnection instance
will not have been closed when a new instance is assigned to the conn variable.
Perhaps the BlockingConnection could close itself when it becomes unreferenced,
but at present the expectation is that it should be explicitly closed.
> CLOSE_WAIT leak following reproducer for PROTON-1023 / PROTON-1024
> --
>
> Key: PROTON-1025
> URL: https://issues.apache.org/jira/browse/PROTON-1025
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Pavel Moravec
>Priority: Minor
>
> Following reproducer for PROTON-1023 or PROTON-1024 (attached at the botton),
> client leaves some sockets in CLOSE_WAIT state forever.
> I tested the reproducer before & after those two fixes and it is present in
> both. I.e. this bug is not a regression caused by PROTON-1023 or PROTON-1024.
> Reproducer:
> (assuming localhost runs qdrouterd that is restarted every 5 seconds in a
> loop):
> {code}
> #!/usr/bin/python
> from time import sleep
> from uuid import uuid4
> from proton import ConnectionException
> from proton.utils import BlockingConnection
> import traceback
> import random
> while True:
> sleep(random.uniform(0.3,3))
> try:
> conn = BlockingConnection("proton+amqp://localhost:5672",
> ssl_domain=None, heartbeat=2)
> rec = conn.create_receiver("another_address", name=str(uuid4()),
> dynamic=False, options=None)
> print "sleeping.."
> sleep(random.uniform(0.3,3))
> rec2 = conn.create_receiver("some_address", name=str(uuid4()),
> dynamic=False, options=None)
> except ConnectionException:
> try:
> if conn:
> conn.close()
> except Exception, e:
> print e
> print(traceback.format_exc())
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1024) Disconnect during close not handled correctly in BlockingConnection
[ https://issues.apache.org/jira/browse/PROTON-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1024. Resolution: Fixed > Disconnect during close not handled correctly in BlockingConnection > --- > > Key: PROTON-1024 > URL: https://issues.apache.org/jira/browse/PROTON-1024 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.11 > > > If the connection is lost (or aborted) after issuing the close, but before > the peer responds, the BlockingConnection gets stuck in an endless loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1024) Disconnect during close not handled correctly in BlockingConnection
Gordon Sim created PROTON-1024: -- Summary: Disconnect during close not handled correctly in BlockingConnection Key: PROTON-1024 URL: https://issues.apache.org/jira/browse/PROTON-1024 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.11 If the connection is lost (or aborted) after issuing the close, but before the peer responds, the BlockingConnection gets stuck in an endless loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1023) Incorrect handling of failed attach for BlockingConnection
[
https://issues.apache.org/jira/browse/PROTON-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1023.
Resolution: Fixed
> Incorrect handling of failed attach for BlockingConnection
> --
>
> Key: PROTON-1023
> URL: https://issues.apache.org/jira/browse/PROTON-1023
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Where the attach response and subsequent detach are separated a bit, the
> BlockingConnection attempts to wait a little for the detach to get the actual
> error condition. However the code for this uses the wrong method name,
> meaning the exception thrown would be incorrect ('AttributeError:
> _waitForClose not in _attrs', rather than a LinkDetached as expected). In
> addition, if the detach is not received a Timeout is raised rather than a
> LinkException with the local link being closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-1023) Incorrect handling of failed attach for BlockingConnection
Gordon Sim created PROTON-1023:
--
Summary: Incorrect handling of failed attach for BlockingConnection
Key: PROTON-1023
URL: https://issues.apache.org/jira/browse/PROTON-1023
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.10
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.11
Where the attach response and subsequent detach are separated a bit, the
BlockingConnection attempts to wait a little for the detach to get the actual
error condition. However the code for this uses the wrong method name, meaning
the exception thrown would be incorrect ('AttributeError: _waitForClose not in
_attrs', rather than a LinkDetached as expected). In addition, if the detach is
not received a Timeout is raised rather than a LinkException with the local
link being closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1008) Using a blank mech_list disables authentication
[ https://issues.apache.org/jira/browse/PROTON-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1008. Resolution: Fixed > Using a blank mech_list disables authentication > --- > > Key: PROTON-1008 > URL: https://issues.apache.org/jira/browse/PROTON-1008 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.11 > > > This bug was introduced in commit > > https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6 > If the client leaves allowed_mechs as None, the SASL protocol is not even > executed. I claim that allowed_mechs is used to restrict the set of > acceptable mechanisms. If it is None, then all available mechanisms may be > used. > This bug causes a failure in the Qpid Dispatch test suite > (system_tests_qdstat). The failure is when the server requires > authentication and will accept EXTERNAL and the client has a valid > client-certificate but doesn't use the sasl protocol because qdstat doesn't > (and can't) set the allowed_mechs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-924) links are not uniquely named by messenger
[ https://issues.apache.org/jira/browse/PROTON-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-924. - Resolution: Duplicate > links are not uniquely named by messenger > - > > Key: PROTON-924 > URL: https://issues.apache.org/jira/browse/PROTON-924 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 > Reporter: Gordon Sim > > If sending messages to different nodes in the same container, messenger will > establish multiple links but will use the same name - sender-xxx - for each > of them which violates the spec section 2.6.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1008) Using a blank mech_list disables authentication
[ https://issues.apache.org/jira/browse/PROTON-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935975#comment-14935975 ] Gordon Sim commented on PROTON-1008: Proposal above available in patch form here: https://reviews.apache.org/r/38863/ > Using a blank mech_list disables authentication > --- > > Key: PROTON-1008 > URL: https://issues.apache.org/jira/browse/PROTON-1008 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.11 > > > This bug was introduced in commit > > https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6 > If the client leaves allowed_mechs as None, the SASL protocol is not even > executed. I claim that allowed_mechs is used to restrict the set of > acceptable mechanisms. If it is None, then all available mechanisms may be > used. > This bug causes a failure in the Qpid Dispatch test suite > (system_tests_qdstat). The failure is when the server requires > authentication and will accept EXTERNAL and the client has a valid > client-certificate but doesn't use the sasl protocol because qdstat doesn't > (and can't) set the allowed_mechs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1006) Sending pre-settled messages over the python blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1006. Resolution: Fixed I agree that the call should not block indefinitely, and have modified the code to prevent that. *However* the send() call for a sender in send-settled mode will return immediately, even before the message is ever written to the socket, so this pattern only works if you do further processing on the connection. > Sending pre-settled messages over the python blocking api waits indefinetly > --- > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 >Reporter: Ganesh Murthy >Assignee: Gordon Sim > Fix For: 0.10.1 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-1006) Sending pre-settled messages over the python blocking api waits indefinetly
[ https://issues.apache.org/jira/browse/PROTON-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-1006: --- Fix Version/s: (was: 0.10.1) 0.11 > Sending pre-settled messages over the python blocking api waits indefinetly > --- > > Key: PROTON-1006 > URL: https://issues.apache.org/jira/browse/PROTON-1006 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 >Reporter: Ganesh Murthy >Assignee: Gordon Sim > Fix For: 0.11 > > Attachments: helloworld_blocking_presettled.py > > > Sending a pre-settled message (snd_settle_mode = Link.SND_SETTLED) over a > blocking connection (using a blocking sender) blocks indefinetly. > Steps to reproduce - > 1. Modify the helloworld_blocking.py (located in examples/python folder) to > add an AtMostOnce() call before creating the sender (or use the attached file > helloworld_blocking_presettled.py) > 2. Start broker.py (located in examples/python folder) > 3. Run helloworld_blocking_presettled.py > You will see that the send is blocking indefinetly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1004) Inconsistency in container.create_sender
[
https://issues.apache.org/jira/browse/PROTON-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935271#comment-14935271
]
Gordon Sim commented on PROTON-1004:
Proposal:
Perhaps the behaviour can be made less confusing by adding a couple of
explicitly named arguments to the create_sender/create_receiver calls,
specifically: url - through which a url is passed, and connection - through
which a connection to use is passed.
The following would then be valid:
{noformat}
conn = event.container.connect(amqp://myhost:/xyz, heartbeat=8)
event.container.create_sender(url=amqp://myhost:/xyz, connection=conn)
{noformat}
and would establish a link to the node xyz, using the connection first
established. The same could be done by:
{noformat}
conn = event.container.connect(amqp://myhost:/xyz, heartbeat=8)
event.container.create_sender(target=xyz, connection=conn)
{noformat}
As before you could skip the explicit connect step if desired:
{noformat}
event.container.create_sender(url=amqp://myhost:/xyz)
{noformat}
In which case a new connection would be established based on the details
specified in the url.
This would not change any current use cases, but introducing the explicit names
would I think make things clearer and could be emphasised in the docs. The
first positional (un-named) arg would be treated as it is now, either as a
connection or as a url, depending on type.
Thoughts?
> Inconsistency in container.create_sender
>
>
> Key: PROTON-1004
> URL: https://issues.apache.org/jira/browse/PROTON-1004
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Ted Ross
>Assignee: Gordon Sim
>
> For URL = "localhost:5672/examples"
> Using the API in two different ways:
> {noformat}
> def on_start(self, event):
> event.container.create_sender(URL)
> {noformat}
> Yields an attach with the following target:
> [address="examples", durable=0, timeout=0, dynamic=false]
> But this variation yields something different:
> {noformat}
> def on_start(self, event):
> conn = event.container.connect(URL, heartbeat=8)
> event.container.create_sender(conn, URL)
> {noformat}
> yields:
> [address="localhost:5672/examples", durable=0, timeout=0, dynamic=false]
> The attach targets should be consistent across these examples. I believe the
> first example is the correct one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1008) Using a blank mech_list disables authentication
[
https://issues.apache.org/jira/browse/PROTON-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935246#comment-14935246
]
Gordon Sim commented on PROTON-1008:
{quote}Is it ever sensible to not use SASL?{quote}
The protocol is certainly designed to allow it to be optional. If you are using
SSL then the SASL layer doesn't really add anything. However the main reason
for the change was to get back to the behaviour pre 0.10, that I inadvertently
broke by exposing the allowed mechanisms option.
{quote}As it stands, I don't know how to turn SASL on.{quote}
Agreed, and this is I think the actual issue. We need a way to easily control
whether sasl is used or not.
{quote}There may be existing mechanisms available (EXTERNAL, GSSAPI), but I
don't have a username to supply and I don't necessarily know which mechanisms
to put in the allowed_mechs list.{quote}
Agreed again, and for this reason I think the allowed_mechs property is not the
ideal way of turning sasl on. (And so I think the change mentioned in the bug
description is actually correct).
Proposal:
What if we add a new container level option (perhaps also with per-connection
override) for controlling whether or not sasl is to be used. We can set that to
True by default (though that would be a slight change in behaviour from pre
0.10, the 0.10 release actually has sasl forced on always, so this is an
improvement.
> Using a blank mech_list disables authentication
> ---
>
> Key: PROTON-1008
> URL: https://issues.apache.org/jira/browse/PROTON-1008
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.11
> Reporter: Ted Ross
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> This bug was introduced in commit
>
> https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6
> If the client leaves allowed_mechs as None, the SASL protocol is not even
> executed. I claim that allowed_mechs is used to restrict the set of
> acceptable mechanisms. If it is None, then all available mechanisms may be
> used.
> This bug causes a failure in the Qpid Dispatch test suite
> (system_tests_qdstat). The failure is when the server requires
> authentication and will accept EXTERNAL and the client has a valid
> client-certificate but doesn't use the sasl protocol because qdstat doesn't
> (and can't) set the allowed_mechs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1008) Using a blank mech_list disables authentication
[ https://issues.apache.org/jira/browse/PROTON-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935164#comment-14935164 ] Gordon Sim commented on PROTON-1008: The commit referenced above was made to revert to pre 0.10 behaviour, where a SASL layer was not used unless a username was specified (even if that was 'anonymous'). All it does is avoids making a call to pn_sasl_allowed_mechs if no mechanisms have been specified. I believe that is actually sensible behaviour. There does need to be a way to avoid using SASL, though whether it needs to be off unless requested as it was prior to the 0.10 release is certainly debatable. > Using a blank mech_list disables authentication > --- > > Key: PROTON-1008 > URL: https://issues.apache.org/jira/browse/PROTON-1008 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 > Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.11 > > > This bug was introduced in commit > > https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6 > If the client leaves allowed_mechs as None, the SASL protocol is not even > executed. I claim that allowed_mechs is used to restrict the set of > acceptable mechanisms. If it is None, then all available mechanisms may be > used. > This bug causes a failure in the Qpid Dispatch test suite > (system_tests_qdstat). The failure is when the server requires > authentication and will accept EXTERNAL and the client has a valid > client-certificate but doesn't use the sasl protocol because qdstat doesn't > (and can't) set the allowed_mechs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1004) Inconsistency in container.create_sender
[
https://issues.apache.org/jira/browse/PROTON-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14935155#comment-14935155
]
Gordon Sim commented on PROTON-1004:
There are two quite different modes of use for the
create_sender/create_receiver methods, as documented in pydoc. In one you give
a connection object and the actual target/source address. In the other you give
a url from which a connection is created and the actual target/source is
inferred. So the behaviour is as intended. If in the first form you treated the
target as a url to be parse, it would make it more awkward to attach to a
target in the url syntax (e.g. with activemq, topics might be identified as
topic://my-topic).
Whether having the two modes is worth the confusion is I think subject to
debate. I'm also open to ways of making it nicer overall. However I don't think
simply trying to parse the exact target when using that mode is the correct
approach.
> Inconsistency in container.create_sender
>
>
> Key: PROTON-1004
> URL: https://issues.apache.org/jira/browse/PROTON-1004
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
> Reporter: Ted Ross
>Assignee: Gordon Sim
>
> For URL = "localhost:5672/examples"
> Using the API in two different ways:
> {noformat}
> def on_start(self, event):
> event.container.create_sender(URL)
> {noformat}
> Yields an attach with the following target:
> [address="examples", durable=0, timeout=0, dynamic=false]
> But this variation yields something different:
> {noformat}
> def on_start(self, event):
> conn = event.container.connect(URL, heartbeat=8)
> event.container.create_sender(conn, URL)
> {noformat}
> yields:
> [address="localhost:5672/examples", durable=0, timeout=0, dynamic=false]
> The attach targets should be consistent across these examples. I believe the
> first example is the correct one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-1004) Inconsistency in container.create_sender
[
https://issues.apache.org/jira/browse/PROTON-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-1004:
--
Assignee: Gordon Sim
> Inconsistency in container.create_sender
>
>
> Key: PROTON-1004
> URL: https://issues.apache.org/jira/browse/PROTON-1004
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.10
>Reporter: Ted Ross
>Assignee: Gordon Sim
>
> For URL = "localhost:5672/examples"
> Using the API in two different ways:
> {noformat}
> def on_start(self, event):
> event.container.create_sender(URL)
> {noformat}
> Yields an attach with the following target:
> [address="examples", durable=0, timeout=0, dynamic=false]
> But this variation yields something different:
> {noformat}
> def on_start(self, event):
> conn = event.container.connect(URL, heartbeat=8)
> event.container.create_sender(conn, URL)
> {noformat}
> yields:
> [address="localhost:5672/examples", durable=0, timeout=0, dynamic=false]
> The attach targets should be consistent across these examples. I believe the
> first example is the correct one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-1008) Using a blank mech_list disables authentication
[ https://issues.apache.org/jira/browse/PROTON-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-1008: -- Assignee: Gordon Sim > Using a blank mech_list disables authentication > --- > > Key: PROTON-1008 > URL: https://issues.apache.org/jira/browse/PROTON-1008 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.11 >Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.11 > > > This bug was introduced in commit > > https://github.com/apache/qpid-proton/commit/14956b07edc3de93f67179c753bbedcd9eba51a6 > If the client leaves allowed_mechs as None, the SASL protocol is not even > executed. I claim that allowed_mechs is used to restrict the set of > acceptable mechanisms. If it is None, then all available mechanisms may be > used. > This bug causes a failure in the Qpid Dispatch test suite > (system_tests_qdstat). The failure is when the server requires > authentication and will accept EXTERNAL and the client has a valid > client-certificate but doesn't use the sasl protocol because qdstat doesn't > (and can't) set the allowed_mechs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1010) BlockingConnection leaks sockets after close() is called
[ https://issues.apache.org/jira/browse/PROTON-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-1010. Resolution: Fixed Assignee: Gordon Sim > BlockingConnection leaks sockets after close() is called > > > Key: PROTON-1010 > URL: https://issues.apache.org/jira/browse/PROTON-1010 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Ken Giusti >Assignee: Gordon Sim > Fix For: 0.11 > > Attachments: pavel.py > > > Using the attached reproducer and connecting to a qpid-dispatch router, there > are many connections that are left half-closed indefinitely. The reproducer > fails to close it's socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1000.
Resolution: Fixed
Though the previous fix does not fix the ssl issue, I have raised a separate
JIRA for that as it is quite a distinct issue and more general than the
blocking connection or even the python binding. See PROTON-1003, for which a
patch that fixes the ssl based reproducer here has been proposed,
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-1003) ssl transport layer does not define an error handler
[ https://issues.apache.org/jira/browse/PROTON-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14905147#comment-14905147 ] Gordon Sim commented on PROTON-1003: Suggested fix: https://reviews.apache.org/r/38688/ > ssl transport layer does not define an error handler > > > Key: PROTON-1003 > URL: https://issues.apache.org/jira/browse/PROTON-1003 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.10 >Reporter: Gordon Sim >Assignee: Ken Giusti > > When the local process times out an ssl based connection due to lack of > heartbeats from its peer, the underlying socket is never closed. The cause of > this appears to be that the ssl transport layer doesn't define an error > handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-1003) ssl transport layer does not define an error handler
Gordon Sim created PROTON-1003: -- Summary: ssl transport layer does not define an error handler Key: PROTON-1003 URL: https://issues.apache.org/jira/browse/PROTON-1003 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Ken Giusti When the local process times out an ssl based connection due to lack of heartbeats from its peer, the underlying socket is never closed. The cause of this appears to be that the ssl transport layer doesn't define an error handler, which is what is used to notify it of the locally initiated timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-1000:
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-1000.
Resolution: Fixed
Fix Version/s: 0.11
The problem was that when encountering a disconnection, the BlockingConnection
caused an exception to be thrown during processing the event, meaning the event
queue didn't get drained and the event stuck on it kept the reference to the
connection alive preventing the socket being closed.
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
> Fix For: 0.11
>
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-1000) Connection leak on heartbeat-timeouted connections
[
https://issues.apache.org/jira/browse/PROTON-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-1000:
--
Assignee: Gordon Sim
> Connection leak on heartbeat-timeouted connections
> --
>
> Key: PROTON-1000
> URL: https://issues.apache.org/jira/browse/PROTON-1000
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Pavel Moravec
>Assignee: Gordon Sim
>
> Using gofer/katello-agent that uses BlockingConnection from Proton Reactor
> with heartbeats set up, if some connection timeouts due to the heartbeats,
> Proton does not close the TCP connection. That causes TCP connection leak,
> despite gofer properly called BlockingConnection.close() and forgot any
> reference to that class instance.
> Checking tcpdump, Proton simply ignores the timeouted connections - it does
> not respond anyhow to the communication partner whatever it sends (in some
> scenarios it sends some AMQP performative that Proton was assumed to respond,
> in other scenario the communication peer dropped the TCP connection by
> sending FIN+ACK packet but Proton didn't send FIN packet back - the only
> stuff seen in tcpdump is ACKing on TCP layer made by OS, not by Proton). And
> Proton ignores an attempt of Proton reactor to close the
> connection/container, raising:
> Sep 21 15:02:35 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 15:02:35 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 15:02:35 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> for SSL connections, and raising:
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 259, in
> on_transport_tail_closed
> Sep 21 14:56:28 my-capsule goferd: self.on_transport_closed(event)
> Sep 21 14:56:28 my-capsule goferd: File
> "/usr/lib64/python2.7/site-packages/proton/utils.py", line 263, in
> on_transport_closed
> Sep 21 14:56:28 my-capsule goferd: raise ConnectionException("Connection %s
> disconnected" % self.url);
> Sep 21 14:56:28 my-capsule goferd: ConnectionException: Connection
> amqps://satellite.example.com:5647 disconnected
> (some difference between SSL and nonSSL could come from the fact that in my
> case the server part - qdrouterd / Qpid Dispatch Router - sends FIN+ACK
> packet for nonSSL connection, while it does not send anything for SSL
> connection and continue for sending empty AMQP frames due to heartbeats
> enabled forever)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Error detection/handling
On 09/17/2015 08:37 AM, Tomáš Šoltys wrote: Here is an output from the broker when trace+ is enabled on protocol level. Thanks! This looks like the same root cause as https://issues.apache.org/jira/browse/QPID-6660, which is now fixed on trunk (but didn't make it into the 0.34 release) Scenario: send 1 message with incorrect subject and afterwards send 3 messages with correct subject. 3 messages will get delivered to the queue. I've confirmed that on trunk, the messages after the one barred by acl do *not* get enqueued.
Re: Error detection/handling
On 09/16/2015 02:02 PM, Tomáš Šoltys wrote: Thanks Gordon, I have already noticed that I am getting PN_LINK_REMOTE_CLOSE event type. But I am not able to get any error. pn_error_text(pn_link_error(pn_event_link(pEvent))) returns NULL. Try pn_link_remote_condition & pn_condition_get_description instead of pn_link_error and pn_error_text. Other thing that I do not understand is, that after sending erroneous message I am still able to send messages (this time with correct subject) to broker without any problem and messages are delivered. I thought that event type PN_LINK_REMOTE_CLOSE indicated that link was on remote side closed. That does indeed sound odd. Do you have a protocol trace to hand?
Re: Error detection/handling
On 09/16/2015 01:36 PM, Tomáš Šoltys wrote: I'm using reactor API and the broker is c++ broker from qpid 0.34 In that case the broker closes the link with an error condition. So on the client you should be able to be notified of the error by handling the appropriate event. If you are using MessagingHandler you can do that by implementing on_link_closing() or on_link_error(). Otherwise you can implement on_link_remote_close().
Re: Error detection/handling
On 09/16/2015 01:04 PM, Tomáš Šoltys wrote: Hi, I have a client that sends a messages to broker. It can happen that message contains incorrect subject which will trigger ACL deny on the broker. But on the client side everything seems to be OK. How do I detect such errors? What API are you using? (And what broker, as the other important question is how the broker is indicating the issue to the client).
Re: Sending server
On 09/09/2015 07:09 AM, Tomáš Šoltys wrote: Thanks a lot Gordon! And is there a suggested/proper way how to do it using reactor API? That example does use the reactor. If you mean an example that doesn't use any of the utilities and helper classes on top of that, then you could look at the python example under examples/python/reactor.send.py perhaps (as far as I know there is nothing equivalent to that yet in c or c++).
Re: Sending server
On 09/08/2015 02:24 PM, Tomáš Šoltys wrote: I would like to create a sender that sends messages on demand. What would be the best approach? Create a loop in PN_LINK_FLOW? Or is there a better way? Is this example any use: https://git1-us-west.apache.org/repos/asf?p=qpid-proton.git;a=blob;f=examples/cpp/direct_send.cpp;h=02bc3725db9809cac92ae04a91068932f636b59e;hb=HEAD It allows receivers to connect and when they do it will send a certain number of messages to them. Obviously the details of the logic could be adapted, but it may be a useful place to start experimenting?
proton-j tests failing on master?
The proton-j tests appear to be failing on master for me, even for a completely clean build with all the stuff that proton-j generates in the source tree removed as well: Leaked an instance of 'sun.nio.ch.ServerSocketChannelImpl[/127.0.0.1:36861]' from: java.lang.Exception at org.apache.qpid.proton.reactor.impl.LeakTestReactor$TestIO.serverSocketChannel(LeakTestReactor.java:64) at org.apache.qpid.proton.reactor.impl.AcceptorImpl.(AcceptorImpl.java:89) at org.apache.qpid.proton.reactor.impl.ReactorImpl.acceptor(ReactorImpl.java:429) at org.apache.qpid.proton.reactor.ReactorTest.connect(ReactorTest.java:235) Tests run: 49, Failures: 11, Errors: 22, Skipped: 0, Time elapsed: 0.198 sec <<< FAILURE! connect[0](org.apache.qpid.proton.reactor.ReactorTest) Time elapsed: 0.008 sec <<< ERROR! java.lang.NoSuchMethodError: org.apache.qpid.proton.engine.impl.CollectorImpl.put(Lorg/apache/qpid/proton/engine/Event$Type;Ljava/lang/Object;)Lorg/apache/qpid/proton/engine/impl/EventImpl; at org.apache.qpid.proton.engine.impl.ConnectionImpl.put(ConnectionImpl.java:644) at org.apache.qpid.proton.engine.impl.ConnectionImpl.collect(ConnectionImpl.java:626) at org.apache.qpid.proton.reactor.impl.ReactorImpl.connection(ReactorImpl.java:416) at org.apache.qpid.proton.reactor.ReactorTest.connect(ReactorTest.java:258) barfOnLink[1](org.apache.qpid.proton.reactor.ReactorTest) Time elapsed: 0.008 sec <<< FAILURE! junit.framework.AssertionFailedError: Resources leaked at org.apache.qpid.proton.reactor.impl.LeakTestReactor$TestIO.assertNoLeaks(LeakTestReactor.java:101) at org.apache.qpid.proton.reactor.impl.LeakTestReactor.assertNoLeaks(LeakTestReactor.java:115) at org.apache.qpid.proton.reactor.ReactorTest.checkForLeaks(ReactorTest.java:96) at org.apache.qpid.proton.reactor.ReactorTest.after(ReactorTest.java:102) plus many, many more similar to these. Anyone else seeing this?
[jira] [Resolved] (PROTON-977) handler appears to get ignored
[ https://issues.apache.org/jira/browse/PROTON-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-977. --- Resolution: Fixed > handler appears to get ignored > -- > > Key: PROTON-977 > URL: https://issues.apache.org/jira/browse/PROTON-977 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.10 > Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.11 > > > If a handler defines methods such that it is evaluated to false in a boolean > context, then tests inside the Container and/or MessagingHandler whose aim is > to test whether a handler is set, will fail even though there is a handler. > E.g. if the handler has a __len__() method that returns 0 when > Container.create_receiver is called, the handler will not be set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-977) handler appears to get ignored
Gordon Sim created PROTON-977: - Summary: handler appears to get ignored Key: PROTON-977 URL: https://issues.apache.org/jira/browse/PROTON-977 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.11 If a handler defines methods such that it is evaluated to false in a boolean context, then tests inside the Container and/or MessagingHandler whose aim is to test whether a handler is set, will fail even though there is a handler. E.g. if the handler has a __len__() method that returns 0 when Container.create_receiver is called, the handler will not be set. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: 0.10 beta2 now available
On 08/05/2015 03:31 PM, Ken Giusti wrote:
if I simply remove the PLAIN sasl mechs (client specifies no mechs in this
case), DIGEST-MD5 is selected:
$ ./send.py -a amqp://192.168.122.209:5672 --target amq.topic --username admin
--password qpid
KAG outcome = 1
KAG condition = None
Connection failed: Condition('amqp:unauthorized-access', 'Authentication
failed')
connection_failed, error=Condition('amqp:unauthorized-access', 'Authentication
failed') (ignored)
Send failed due to connection failure!
broker log:
$ 2015-08-05 10:27:07 [Security] info SASL: Mechanism list: DIGEST-MD5 CRAM-MD5
PLAIN
2015-08-05 10:27:07 [Security] info SASL: Starting authentication with
mechanism: DIGEST-MD5
2015-08-05 10:27:07 [Security] info
qpid.192.168.122.209:5672-192.168.122.1:38081 Challenge issued
2015-08-05 10:27:07 [Security] info
qpid.192.168.122.209:5672-192.168.122.1:38081 Failed to authenticate
2015-08-05 10:27:07 [Security] info
qpid.192.168.122.209:5672-192.168.122.1:38081 Connection closed prior to
authentication completing
Well, that's a head scratcher.
Thoughts?
You need to specify 'amqp' as the sasl service name using the newly
added --sasl-service-name option to qpidd (this defaults to 'qpidd').
Re: 0.10 beta2 now available
On 08/04/2015 05:30 PM, Robbie Gemmell wrote: On 3 August 2015 at 18:40, Robbie Gemmell wrote: Hi folks, I have put up a 0.10 beta2 cut from the new 0.10.x branch. I'll be looking to cut RC1 in the next couple of days and immediately proceed to vote on it, so please give the beta a kick of the tyres and report back your findings. You can find the files here: https://dist.apache.org/repos/dist/dev/qpid/proton/0.10-beta2/ Java binaries are also available in a temporary staging repo at: https://repository.apache.org/content/repositories/orgapacheqpid-1039 Robbie I gave things a kick of the tyres as follows: # Verified checksums ok. # Checked LICENCE and NOTICE present and look ok. # Ran the build and tests via Maven. # Ran the build/tests/install via CMake. # Built qpid-cpp 0.34 against the above install. # Ran the JMS client build+tests from master against the staging repo. # Ran the JMS client HelloWorld example against the earlier built 0.34 cpp broker. # Ran the ActiveMQ build + amqp tests from master using the staging repo. Looks good to me also; I ran the tests and also those of qpid-cpp against it.
[jira] [Resolved] (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 ] Gordon Sim resolved PROTON-950. --- Resolution: Fixed The issues I was having with the reactive API were a combination of user error and PROTON-974. This issue was indeed fixed. > 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, 0.11 > > > 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] [Created] (PROTON-974) single symbol for mechanisms in sasl-mechanisms not recognised
Gordon Sim created PROTON-974:
-
Summary: single symbol for mechanisms in sasl-mechanisms not
recognised
Key: PROTON-974
URL: https://issues.apache.org/jira/browse/PROTON-974
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.10
Reporter: Gordon Sim
Assignee: Andrew Stitcher
E.g. if a broker sends a sasl-mechanisms frame with a single symbol as the
value of the mechanisms field, then it appears that the cyrus-sasl support in
proton-c doesn't recognise that offered mechanism(?)
{noformat}
[0x2605d80]: -> SASL
[0x2605d80]: <- SASL
[0x2605d80]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
[0x2605d80]:sasl error: SASL(-4): no mechanism available: No worthy mechs found
[0x2605d80]:ERROR amqp:unauthorized-access Authentication failed
[0x2605d80]: -> EOS
ERROR:root:amqp:unauthorized-access: Authentication failed
{noformat}
>From the spec, section 1.4:
{quote}
The multiple attribute of a field description controls whether multiple element
values are permitted in the representation. A single element of the type
specified in the field description is always permitted. Multiple values are
represented by the use of an array where the type of the elements in the array
is the type defined in the field definition.
{quote}
--
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-tabpanel&focusedCommentId=14653847#comment-14653847 ] Gordon Sim commented on PROTON-950: --- The transport condition at th point of error merely states 'Authentication failed'. That is certainly better than nothing, but it doesn't explain that the reason was that there was no mutually acceptable mechanism as opposed to PLAIN proceeding but the credentials being invalid. > 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, 0.11 > > > 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] [Reopened] (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 ] Gordon Sim reopened PROTON-950: --- I can't get the new flag to work with the reactor, so I don't think this can be closed yet. > 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, 0.11 > > > 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-tabpanel&focusedCommentId=14653533#comment-14653533 ] Gordon Sim commented on PROTON-950: --- I think my preferred option would also be to allow PLAIN regardless of whether SSL is in use by default, but to clearly log a warning every time PLAIN is used over an unencrypted transport (along with a brief message as to how to prevent this). That way people become very aware of the problem and how to avoid it, but it doesn't cause hard to debug issues when first trying to get an example running. > 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-tabpanel&focusedCommentId=14653521#comment-14653521 ] Gordon Sim commented on PROTON-950: --- I think errors like this should be visible by default without needing to set some obscure environment variable. > 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-tabpanel&focusedCommentId=14653389#comment-14653389 ] Gordon Sim commented on PROTON-950: --- Even modifying the code to set that property as soon as the transport is created doesn't 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)
[jira] [Resolved] (PROTON-972) Support the heartbeat option in BlockingConnection
[ https://issues.apache.org/jira/browse/PROTON-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-972. --- Resolution: Fixed Fix Version/s: 0.11 > Support the heartbeat option in BlockingConnection > -- > > Key: PROTON-972 > URL: https://issues.apache.org/jira/browse/PROTON-972 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.9 > Environment: All >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.11 > > > Add support for the 'heartbeat' option in BlockingConnection. -- 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-tabpanel&focusedCommentId=14652436#comment-14652436 ] Gordon Sim commented on PROTON-950: --- I've not debugged. The behaviour changed since about a week ago though. > 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-tabpanel&focusedCommentId=14652425#comment-14652425 ] Gordon Sim commented on PROTON-950: --- That means that unless cyrus is available it would no longer be possible to authenticate as a given user unless SSL was used (since there would be no other mechanisms). > 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-tabpanel&focusedCommentId=14652420#comment-14652420 ] Gordon Sim commented on PROTON-950: --- There is no special logic added for PN_TRANSPORT_ERROR events, but PN_TRANSPORT_CLOSED and PN_TRANSPORT_TAIL_CLOSED are handled. Previously this would result in the connection attempt failing and either reconnecting or exiting depending on settings (along with the error logged of course). > 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-tabpanel&focusedCommentId=14652414#comment-14652414 ] Gordon Sim commented on PROTON-950: --- Yes, that does show up the error. > 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-tabpanel&focusedCommentId=14652409#comment-14652409 ] Gordon Sim commented on PROTON-950: --- No, I didn't make any changes. I had just assumed from a comment above that the messenger code had been changed. > 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-tabpanel&focusedCommentId=14652406#comment-14652406 ] Gordon Sim commented on PROTON-950: --- What is the intended behaviour when cyrus is not available on the platform in question? Would PLAIN be allowed over a non-SSL connection in that case? To me that seems non-intuitive from the client's perspective. > 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-tabpanel&focusedCommentId=14652394#comment-14652394 ] Gordon Sim commented on PROTON-950: --- Run eg. simple_send against direct_recv, or even just the messenger examples against a broker that only supports PLAIN. > 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-tabpanel&focusedCommentId=14652361#comment-14652361
]
Gordon Sim edited comment on PROTON-950 at 8/3/15 7:52 PM:
---
I can't seem to get the messenger examples to connect over non-ssl using PLAIN
either...
{noformat}
$ PN_TRACE_FRM=1 ./examples/c/messenger/send -a
amqp://guest:guest@localhost/amq.fanout
[0x162a700]: -> SASL
[0x162a700]: <- SASL
[0x162a700]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:PLAIN]
[0x162a700]: -> EOS
{noformat}
was (Author: gsim):
I can't seem to get the messenger examples to connect over non-ssl using PLAIN
either...
{noformat}
]$ PN_TRACE_FRM=1 ./examples/c/messenger/send -a
amqp://guest:guest@localhost/amq.fanout
[0x162a700]: -> SASL
[0x162a700]: <- SASL
[0x162a700]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:PLAIN]
[0x162a700]: -> EOS
{noformat}
> 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] [Assigned] (PROTON-972) Support the heartbeat option in BlockingConnection
[ https://issues.apache.org/jira/browse/PROTON-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-972: - Assignee: Gordon Sim > Support the heartbeat option in BlockingConnection > -- > > Key: PROTON-972 > URL: https://issues.apache.org/jira/browse/PROTON-972 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.9 > Environment: All >Reporter: Jeff Ortel >Assignee: Gordon Sim > > Add support for the 'heartbeat' option in BlockingConnection. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
