[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=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-proton-0.12.0/proton-c/src/transport/transport.c:2630
> #9 0x73d046ee in qpid::broker::amqp::Connection::encode
> (this=0x7fffec007780, buffer=0x7fffec02f280 "", size=65536)
> at /usr/src/debug/qpid-cpp-0.34/src/qpid/broker/amqp/Connection.cpp:233
> #10 0x7749b3c4 in qpid::sys::AsynchIOHandler::idle
> (this=0x7fffec01ca30)
[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=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)
[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)
[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] [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-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] [Commented] (PROTON-1111) Fix warnings during make doc
[ https://issues.apache.org/jira/browse/PROTON-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [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=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] [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] [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=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] [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] [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] [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] [Commented] (PROTON-1071) EventInjector hangs on Windows
[ https://issues.apache.org/jira/browse/PROTON-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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 to get the event off the > queue and clear the pipe. > On windows it appears as if the EventInjector selectable is made "readable"
[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=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 > > > I added a new reactor test that exercises the python-proton ApplicationEvent > and EventInjector
[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=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=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
> [0xa5d060]: <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"the_username\x00the_username\x00the_password"]
> [0xa5d060]:0 <- @sasl-outcome(68) [code=1]
> ^CTraceback (most recent call last):
> File "./meow.py", line 12, in
> messenger.send()
> File "/usr/local/lib/python2.7/dist-packages/proton/__init__.py", line 568,
> in send
> self._check(pn_messenger_send(self._mng, n))
> KeyboardInterrupt
> Command exited with non-zero status 1
>
[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] [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=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-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] [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=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] [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] [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] [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] [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] [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] [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] [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] [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] [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] [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=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] [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=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] [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] [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-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] [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-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] [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] [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] [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] [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=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] [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=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] [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] [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=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=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] [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-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=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] [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] [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] [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=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] [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] [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)
[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] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14652352#comment-14652352 ] Gordon Sim commented on PROTON-950: --- I tried unsuccessfully to do this. It is awkward to get at the sasl object for a connection when using the reactor. In theory you can do so via the on_connection_bound method. However even doing so, and setting the new property to True, I was unable to connect using PLAIN over a non-ssl connection. Without making any changes, the behaviour also seems to have changed very recently. Previously when attempting to connect where only PLAIN was offered by the broker, an error would at least be logged to the effect that 'no worthy mechs' could be selected, and both sides would end up disconnected. Now there is no error at all and the reactive examples just hang. SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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] [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)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Comment Edited] (PROTON-950) SASL PLAIN over cleartext should be supported
[
https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=14644813#comment-14644813 ] Gordon Sim commented on PROTON-950: --- This can only be a change in behaviour for applications that are using the messenger library, as it is the only part of the Proton-c library that has the PLAIN mechanism built in before 0.10. - Idon't think that is correct. The python 'reactive' api also supported plain previously but now only does so on ssl connections. SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-950) SASL PLAIN over cleartext should be supported
[ https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644837#comment-14644837 ] Gordon Sim commented on PROTON-950: --- It set the chosen mechanism to be plain if a username and password were specified in the url (using the Sasl.plain() method). SASL PLAIN over cleartext should be supported - Key: PROTON-950 URL: https://issues.apache.org/jira/browse/PROTON-950 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Ted Ross Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if the connection is encrypted (using SSL). This is a surprising change of behavior from earlier versions of Proton and it's arguable that a security policy like that should be left to the application using the Proton library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-961) messenger doesn't handle multi-frame transfers
Gordon Sim created PROTON-961: - Summary: messenger doesn't handle multi-frame transfers Key: PROTON-961 URL: https://issues.apache.org/jira/browse/PROTON-961 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10, 0.11 Reporter: Gordon Sim See QPID-6651 for a reproducer. The pni_pump_in function in messenger,c doesn't check whether the current delivery is partial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-961) messenger doesn't handle multi-frame transfers
[
https://issues.apache.org/jira/browse/PROTON-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642741#comment-14642741
]
Gordon Sim commented on PROTON-961:
---
The pni_pump_in function in messenger.c proceeds to process incoming deliveries
even if they are partial. There *is* a check for pn_delivery_partial at the
start, but I'm not quite sure what it is trying to test there.
The following change seems to fix the problem with large incoming messages and
doesn't break any of the tests. Is it possible the original check was just
written incorrectly?
{noformat}
--- a/proton-c/src/messenger/messenger.c
+++ b/proton-c/src/messenger/messenger.c
@@ -987,7 +987,7 @@ static void pn_condition_report(const char *pfx,
pn_condition_t *condition)
int pni_pump_in(pn_messenger_t *messenger, const char *address, pn_link_t
*receiver)
{
pn_delivery_t *d = pn_link_current(receiver);
- if (!pn_delivery_readable(d) !pn_delivery_partial(d)) {
+ if (!pn_delivery_readable(d) || pn_delivery_partial(d)) {
return 0;
}
{noformat}
messenger doesn't handle multi-frame transfers
--
Key: PROTON-961
URL: https://issues.apache.org/jira/browse/PROTON-961
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.10, 0.11
Reporter: Gordon Sim
See QPID-6651 for a reproducer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-961) messenger doesn't handle multi-frame transfers
[ https://issues.apache.org/jira/browse/PROTON-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-961: -- Description: See QPID-6651 for a reproducer. The pni_pump_in function in messenger.c proceeds to process incoming deliveries even if they are partial. was: See QPID-6651 for a reproducer. The pni_pump_in function in messenger,c doesn't check whether the current delivery is partial. messenger doesn't handle multi-frame transfers -- Key: PROTON-961 URL: https://issues.apache.org/jira/browse/PROTON-961 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10, 0.11 Reporter: Gordon Sim See QPID-6651 for a reproducer. The pni_pump_in function in messenger.c proceeds to process incoming deliveries even if they are partial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-962) heartbeat/empty frame trace has spurious newline
Gordon Sim created PROTON-962: - Summary: heartbeat/empty frame trace has spurious newline Key: PROTON-962 URL: https://issues.apache.org/jira/browse/PROTON-962 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.11 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Trivial Fix For: 0.11 -- 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.10) 0.11 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.11 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-806) closing a blocking sender hangs if connection has been lost
[ https://issues.apache.org/jira/browse/PROTON-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-806. - Resolution: Cannot Reproduce Closing for now; can reopen if it shows up again. closing a blocking sender hangs if connection has been lost --- Key: PROTON-806 URL: https://issues.apache.org/jira/browse/PROTON-806 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-905) Long-lived connections leak sessions and links
[ https://issues.apache.org/jira/browse/PROTON-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reopened PROTON-905: --- The change made for this is causing crashes in tests from qpid-cpp that use proton. I have a further fix proposed: https://reviews.apache.org/r/36509/ Long-lived connections leak sessions and links -- Key: PROTON-905 URL: https://issues.apache.org/jira/browse/PROTON-905 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Ken Giusti Assignee: Ken Giusti Priority: Blocker Fix For: 0.10 Attachments: test-send.py I found this issue while debugging a crash dump of qpidd. Long lived connections do not free its sessions/link. This only applies when NOT using the event model. The version of qpidd I tested against (0.30) still uses the iterative model. Point to consider, I don't know why this is the case. Details: I have a test script that opens a single connection, then continually creates sessions/links over that connection, sending one message before closing and freeing the sessions/links. See attached. Over time the qpidd run time consumes all memory on the system and is killed by OOM. To be clear, I'm using drain to remove all sent messages - there is no message build up. On debugging this, I'm finding thousands of session objects on the connections free sessions weakref list. Every one of those sessions has a refcount of one. Once the connection is finalized, all session objects are freed. But until then, freed sessions continue to accumulate indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reopened PROTON-927: --- Assignee: (was: Gordon Sim) The new test was reported to have segfaulted on windows: https://ci.appveyor.com/project/ke4qqq/qpid-proton/build/0.10-SNAPSHOT-master.122 Reverting the change. absolute-expiry-time and creation-time are encoded as 0 if not set -- Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim Fix For: 0.10 They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-927: -- Fix Version/s: (was: 0.10) absolute-expiry-time and creation-time are encoded as 0 if not set -- Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-927. --- Resolution: Fixed absolute-expiry-time and creation-time are encoded as 0 if not set -- Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-907: - Assignee: Gordon Sim Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs This effectively deadlocks our application. So far, I’ve tried compiling qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send timeout to 1 (it was previously -1), turning off iptables entirely and disabling selinux and rebooting but no luck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-907: -- Fix Version/s: 0.10 Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Fix For: 0.10 Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs This effectively deadlocks our application. So far, I’ve tried compiling qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send timeout to 1 (it was previously -1), turning off iptables entirely and disabling selinux and rebooting but no luck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-907. --- Resolution: Fixed Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Assignee: Gordon Sim Priority: Critical Fix For: 0.10 Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs This effectively deadlocks our application. So far, I’ve tried compiling qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send timeout to 1 (it was previously -1), turning off iptables entirely and disabling selinux and rebooting but no luck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14610797#comment-14610797 ] Gordon Sim commented on PROTON-907: --- Perhaps a better fix posted for review: https://reviews.apache.org/r/36102/ Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Priority: Critical Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs This effectively deadlocks our application. So far, I’ve tried compiling qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send timeout to 1 (it was previously -1), turning off iptables entirely and disabling selinux and rebooting but no luck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
Gordon Sim created PROTON-927: - Summary: absolute-expiry-time and creation-time are encoded as 0 if not set Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-927) absolute-expiry-time and creation-time are encoded as 0 if not set
[ https://issues.apache.org/jira/browse/PROTON-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14609895#comment-14609895 ] Gordon Sim commented on PROTON-927: --- https://reviews.apache.org/r/36087/ absolute-expiry-time and creation-time are encoded as 0 if not set -- Key: PROTON-927 URL: https://issues.apache.org/jira/browse/PROTON-927 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 They should instead be encoded as null (since there is no default). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-907) Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send
[ https://issues.apache.org/jira/browse/PROTON-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-907: -- Attachment: PROTON-907-workaround.patch The issue appears to be that on the affected platforms, when unable to connect, the file descriptor is not marked as writeable. Though it hits the read error, messenger only closes the 'tail' of the transport as a result. The head is closed when an error is returned from send, but as the socket is not writeable, send is never called. I don't know what the real fix for this is, messenger is an area of the code I'm even less familiar with. Fwiw the attached patch works around the issue and passes all the existing tests. It works by explicitly closing the head of the transport if there is an error on reading from the socket and the connection has not been closed by the peer. Qpid Proton Point to Point Hang on CentOS 6 pn_messenger_send - Key: PROTON-907 URL: https://issues.apache.org/jira/browse/PROTON-907 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8, 0.9.1 Environment: CentOS 6 (both VM and native 64-bit) and RHEL 6 Reporter: Frank Quinn Priority: Critical Attachments: PROTON-907-workaround.patch See thread at http://qpid.2158936.n2.nabble.com/Strange-behaviour-for-pn-messenger-send-on-CentOS-6-td7625846.html. Key points: * pn_messenger_send will hang on CentOS 6 if the destination is not yet up * Works fine on Fedora 21 and 22 (by 'fine', i mean it will attempt to send, fail and move on) * Can be recreated by running the send.c application when recv.c is not yet running * Proton burns CPU as it hangs This effectively deadlocks our application. So far, I’ve tried compiling qpid proton c myself (both 0.8 and 0.9.1), setting pn_messenger_send timeout to 1 (it was previously -1), turning off iptables entirely and disabling selinux and rebooting but no luck. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-924) links are not uniquely named by messenger
Gordon Sim created PROTON-924: - Summary: 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] [Created] (PROTON-925) proton-c seems to treat unspecified channel-max as implying 0
Gordon Sim created PROTON-925:
-
Summary: proton-c seems to treat unspecified channel-max as
implying 0
Key: PROTON-925
URL: https://issues.apache.org/jira/browse/PROTON-925
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.10
Reporter: Gordon Sim
Assignee: michael goulish
Priority: Blocker
Fix For: 0.10
If max-channels is not specified in the open, it appears the latest proton-c
treats that as implying the maximum is 0 though the spec states the default is
65535.
This breaks compatibility with previous proton releases. E.g. the following is
the interaction between a sender using the latest 0.10 and a receiver using
proton 0.9.
{noformat}
[0x151c710]: - AMQP
[0x151c710]:0 - @open(16)
[container-id=65A6602D-5D24-4D39-9C6F-7403D98F5E15, hostname=localhost,
channel-max=32767]
[0x151c710]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:1 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:2 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x151c710]:0 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_a,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_a,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:1 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_b,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_b,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:2 - @attach(18) [name=sender-xxx, handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_c,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_c,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]: - AMQP
[0x151c710]:0 - @open(16) [container-id=abab56b0-c25e-427b-9f4f-d63da48d1973]
[0x151c710]:0 - @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:1 - @begin(17) [remote-channel=1, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:2 - @begin(17) [remote-channel=2, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x151c710]:0 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_a,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_a,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:1 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_b,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_b,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:2 - @attach(18) [name=sender-xxx, handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address=queue_c,
durable=0, timeout=0, dynamic=false], target=@target(41) [address=queue_c,
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
[0x151c710]:0 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:1 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:2 - @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=341, drain=false]
[0x151c710]:0 - @close(24) [error=@error(29)
[condition=:amqp:connection:framing-error, description=remote channel 1 is
above negotiated channel_max 0.]]
[0x151c710]: - EOS
[0x151c710]:0 - @close(24) []
[0x151c710]: - EOS
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-920) frames on invalid channel crash proton
Gordon Sim created PROTON-920: - Summary: frames on invalid channel crash proton Key: PROTON-920 URL: https://issues.apache.org/jira/browse/PROTON-920 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 The result of pni_channel_state() is not checked before it is used for many of the frames. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-920) frames on invalid channel crash proton
[ https://issues.apache.org/jira/browse/PROTON-920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-920. --- Resolution: Fixed frames on invalid channel crash proton -- Key: PROTON-920 URL: https://issues.apache.org/jira/browse/PROTON-920 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 The result of pni_channel_state() is not checked before it is used for many of the frames. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591738#comment-14591738 ] Gordon Sim commented on PROTON-915: --- So it sends the SASl header, then no SASL frames and no plain AMQP header before the open (and close) frames? That would indeed be a violation of the spec. (However sending a SASL headers, one or more SASL frames, then an AMQP header and then AMQP frames would be ok in my view). Incompatible protocol header handled incorrectly Key: PROTON-915 URL: https://issues.apache.org/jira/browse/PROTON-915 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9, 0.9.1 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Blocker Fix For: 0.10 Attachments: 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch The correct response is to send back a supported header[1] before closing the socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this commit: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 It means anything relying on proton-c for protocol header handling is not compliant with the spec. [1] section 2.2 of spec: If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14591514#comment-14591514 ] Gordon Sim commented on PROTON-915: --- The spec says: Any data appearing beyond the protocol header MUST match the version indicated by the protocol header also Note that if the server only supports a single protocol version, it is consistent with the above rules for the server to send its protocol header prior to receiving anything from the client and to subsequently close the socket if the client’s protocol header does not match the server’s. So I would argue that the current behaviour does not violate the spec. Incompatible protocol header handled incorrectly Key: PROTON-915 URL: https://issues.apache.org/jira/browse/PROTON-915 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9, 0.9.1 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Blocker Fix For: 0.10 Attachments: 0001-PROTON-915-Send-correct-AMQP-header-upon-protocol-mi.patch The correct response is to send back a supported header[1] before closing the socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this commit: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 It means anything relying on proton-c for protocol header handling is not compliant with the spec. [1] section 2.2 of spec: If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-915) Incompatible protocol header handled incorrectly
[ https://issues.apache.org/jira/browse/PROTON-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14590077#comment-14590077 ] Gordon Sim commented on PROTON-915: --- E.g. 1. start wireshark 2. run ./examples/c/messenger/recv 3. run qpid-send --address foo Observe wireshark trace which shows qpid-cpp sending the 0-10 header and proton not sending one back. If use the recv example from proton 0.8 (in a slightly different path, ./examples/messenger/c/recv) a protocol-header *is* sent. You can substitute any other tcp server using proton-c for managing protocol version headers in step 2, e.g. dispatch router, examples/python/broker.py etc) Incompatible protocol header handled incorrectly Key: PROTON-915 URL: https://issues.apache.org/jira/browse/PROTON-915 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9, 0.9.1 Reporter: Gordon Sim Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 The correct response is to send back a supported header[1] before closing the socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this commit: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 It means anything relying on proton-c for protocol header handling is not compliant with the spec. [1] section 2.2 of spec: If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-915) Incompatible protocol header handled incorrectly
Gordon Sim created PROTON-915: - Summary: Incompatible protocol header handled incorrectly Key: PROTON-915 URL: https://issues.apache.org/jira/browse/PROTON-915 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1, 0.9 Reporter: Gordon Sim Assignee: Andrew Stitcher Priority: Blocker Fix For: 0.10 The correct response is to send back a supported header[1] before closing the socket. This worked for 0.8 but is broker from 0.9 onwards, I believe by this commit: https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=1b2be03c748ef5a57cf181f8373b9b6e8f8cfd22 It means anything relying on proton-c for protocol header handling is not compliant with the spec. [1] section 2.2 of spec: If the requested protocol version is not supported, the server MUST send a protocol header with a supported protocol version and then close the socket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-913) Calling allow_unsecured_client() on SSLDomain.MODE_CLIENT causes client segfault
[ https://issues.apache.org/jira/browse/PROTON-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-913. --- Resolution: Fixed Fix Version/s: 0.10 Assignee: Gordon Sim Calling allow_unsecured_client() on SSLDomain.MODE_CLIENT causes client segfault Key: PROTON-913 URL: https://issues.apache.org/jira/browse/PROTON-913 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9.1 Environment: packages: qpid-proton-c-0.9-3 qpid-proton-c-devel-0.9-3 python-qpid-proton-0.9-3 Reporter: Petr Matousek Assignee: Gordon Sim Priority: Minor Fix For: 0.10 Attachments: ssl_client_allow_unsecured_client.py, stacktrace.txt Calling allow_unsecured_client() on SSLDomain.CLIENT_MODE object causes client segmentation fault. It is not intended to call this method on client instance, but obviously the client segfault should not appear. Please see the attached reproducer ssl_client_allow_unsecured_client.py for details. Attaching also client traces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-913) Calling allow_unsecured_client() on SSLDomain.MODE_CLIENT causes client segfault
[ https://issues.apache.org/jira/browse/PROTON-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-913: -- Component/s: proton-c Calling allow_unsecured_client() on SSLDomain.MODE_CLIENT causes client segfault Key: PROTON-913 URL: https://issues.apache.org/jira/browse/PROTON-913 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9.1 Environment: packages: qpid-proton-c-0.9-3 qpid-proton-c-devel-0.9-3 python-qpid-proton-0.9-3 Reporter: Petr Matousek Assignee: Gordon Sim Priority: Minor Fix For: 0.10 Attachments: ssl_client_allow_unsecured_client.py, stacktrace.txt Calling allow_unsecured_client() on SSLDomain.CLIENT_MODE object causes client segmentation fault. It is not intended to call this method on client instance, but obviously the client segfault should not appear. Please see the attached reproducer ssl_client_allow_unsecured_client.py for details. Attaching also client traces. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-906) Would be nice to make durable subscriptions simpler
[ https://issues.apache.org/jira/browse/PROTON-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-906. --- Resolution: Fixed Would be nice to make durable subscriptions simpler --- Key: PROTON-906 URL: https://issues.apache.org/jira/browse/PROTON-906 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.9.1 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.10 To get behaviour similar to that of the proton based JMS client's durable subscriptions, the durability and expiry-policy need to be set. Providing a simple option that shields the user from the detailed spec knowledge where desired would be a nice improvement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-903) UUID version should be in sixth octet
[ https://issues.apache.org/jira/browse/PROTON-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-903. --- Resolution: Fixed Fix Version/s: 0.10 UUID version should be in sixth octet - Key: PROTON-903 URL: https://issues.apache.org/jira/browse/PROTON-903 Project: Qpid Proton Issue Type: Improvement Reporter: Flavio Percoco Assignee: Gordon Sim Fix For: 0.10 Attachments: 0001-PROTON-903-Set-UUID-s-version-in-the-sixth-octet.patch Python's UUID fallback implementation sets the UUID version in the seventh octet instead of the sixth. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-903) UUID version should be in sixth octet
[ https://issues.apache.org/jira/browse/PROTON-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-903: - Assignee: Gordon Sim (was: Ken Giusti) UUID version should be in sixth octet - Key: PROTON-903 URL: https://issues.apache.org/jira/browse/PROTON-903 Project: Qpid Proton Issue Type: Improvement Reporter: Flavio Percoco Assignee: Gordon Sim Attachments: 0001-PROTON-903-Set-UUID-s-version-in-the-sixth-octet.patch Python's UUID fallback implementation sets the UUID version in the seventh octet instead of the sixth. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
