[jira] [Created] (PROTON-427) settle does not match accept/reject for ruby
Gordon Sim created PROTON-427: - Summary: settle does not match accept/reject for ruby Key: PROTON-427 URL: https://issues.apache.org/jira/browse/PROTON-427 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.5 Reporter: Gordon Sim In 0.4 the ruby versions of accept()/reject() and settle() all took a tracker and flags (and both were required) In 0.5 this was changed for accept/reject. Only one argument could be passed, the tracker, and it was optional. However settle remains the same as before which seems inconsistent. (Of course changing it now would break the API again between 0.5 and the next release). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (PROTON-425) [Messenger] messenger can only browse qpidd's queues
[
https://issues.apache.org/jira/browse/PROTON-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-425.
-
Resolution: Not A Problem
This is an issue with qpidd, not proton. As the messages are not explicitly
accepted, even though settled, they are never being dequeued.
See https://issues.apache.org/jira/browse/QPID-5170
> [Messenger] messenger can only browse qpidd's queues
>
>
> Key: PROTON-425
> URL: https://issues.apache.org/jira/browse/PROTON-425
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Ken Giusti
> Fix For: 0.6
>
>
> I have a simple queue on the qpidd broker, which holds one message:
> $ qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn msgOut
> bytes bytesIn bytesOut cons bind
>
> KENQ 1 1
> 0 65 650 0 1
> Attempting to consume from that queue using the messenger recv example:
> $ ./examples/messenger/py/recv.py amqp://127.0.0.1:5672/KENQ
> None (no subject) {u'spout-id': u'7fe1a726-b1bc-40e6-b91f-51cf34136f33:0'}
> None
> recv.py gets the message, but it is never removed from qpidd's queue:
> $ qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn msgOut
> bytes bytesIn bytesOut cons bind
>
> KENQ 1 1
> 0 65 650 0 1
> Seems like messenger can only browse qpidd's queues.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782741#comment-13782741 ] Gordon Sim commented on PROTON-342: --- As far as I can see it is still not possible to install both c headers/libs and bindings to a non-standard location and still rely on pkg-config for dependency configuration. I would concede that is not the common use case, but it is one that I would have expected to work. For my own needs I can just disable the bindings. If you close it mark it as wont fix (rather than not a bug or resolved) unless you can point describe a solution. "The dynamic languages are behaving as expected, as they will install to directories as specified by the dynamic languages themselves." So is there some other way to change where the bindings get installed, if I as a user don't want to use the standard location for the given language for whatever reason? > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Assignee: Darryl L. Pierce > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13782831#comment-13782831 ] Gordon Sim commented on PROTON-342: --- Also, if 'DESTDIR isn't meant to update the paths' in the pkg conf file, that should probably be noted in the README. > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Assignee: Darryl L. Pierce > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13783031#comment-13783031 ] Gordon Sim commented on PROTON-342: --- "The use of DESTDIR does not affect the contents of libqpid-proton.pc." is not as clear as it might be. I think something like "The paths in libqpid-proton.pc are not adjusted for DESTDIR, so if that is specified they will not be accurate." > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Assignee: Darryl L. Pierce > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PROTON-432) seg fault when handling error
Gordon Sim created PROTON-432:
-
Summary: seg fault when handling error
Key: PROTON-432
URL: https://issues.apache.org/jira/browse/PROTON-432
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
-> SASL
[0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00gordon\x00gordon"]
<- SASL
[0x18b8320:0] <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] <- @sasl-outcome(68) [code=0]
-> AMQP
[0x18b08d0:0] -> @open(16)
[container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
[0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
<- AMQP
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (PROTON-433) seg fault when handling error
Gordon Sim created PROTON-433:
-
Summary: seg fault when handling error
Key: PROTON-433
URL: https://issues.apache.org/jira/browse/PROTON-433
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
-> SASL
[0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00gordon\x00gordon"]
<- SASL
[0x18b8320:0] <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] <- @sasl-outcome(68) [code=0]
-> AMQP
[0x18b08d0:0] -> @open(16)
[container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
[0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
<- AMQP
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (PROTON-434) seg fault when handling error
Gordon Sim created PROTON-434:
-
Summary: seg fault when handling error
Key: PROTON-434
URL: https://issues.apache.org/jira/browse/PROTON-434
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
-> SASL
[0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00gordon\x00gordon"]
<- SASL
[0x18b8320:0] <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] <- @sasl-outcome(68) [code=0]
-> AMQP
[0x18b08d0:0] -> @open(16)
[container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
[0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
<- AMQP
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (PROTON-435) seg fault when handling error
Gordon Sim created PROTON-435:
-
Summary: seg fault when handling error
Key: PROTON-435
URL: https://issues.apache.org/jira/browse/PROTON-435
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.5
Reporter: Gordon Sim
Priority: Blocker
Fix For: 0.6
{noformat}
$ ./proton-c/examples/messenger/c/send -a
amqp://gordon:gordon@localhost/my-queue
Connected to localhost:5672
-> SASL
[0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
initial-response=b"\x00gordon\x00gordon"]
<- SASL
[0x18b8320:0] <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
[0x18b8320:0] <- @sasl-outcome(68) [code=0]
-> AMQP
[0x18b08d0:0] -> @open(16)
[container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
[0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=1]
[0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
<- AMQP
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
[0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
:platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
Segmentation fault (core dumped)
{noformat}
#0 0x7f799b10c0e0 in pn_data_rewind () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#1 0x7f799b11555f in pn_do_close () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#2 0x7f799b111554 in pn_dispatch_frame () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#3 0x7f799b1116e7 in pn_dispatcher_input () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#4 0x7f799b1169ee in pn_input_read_amqp () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#5 0x7f799b114855 in transport_consume () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#6 0x7f799b1185e2 in pn_transport_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#7 0x7f799b1204fb in pn_connector_process () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#8 0x7f799b11e420 in pn_messenger_tsync () from
/home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
#9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-433) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-433.
-
Resolution: Fixed
Created extra JIRAs in error.
> seg fault when handling error
> -
>
> Key: PROTON-433
> URL: https://issues.apache.org/jira/browse/PROTON-433
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Priority: Blocker
> Fix For: 0.6
>
>
> {noformat}
> $ ./proton-c/examples/messenger/c/send -a
> amqp://gordon:gordon@localhost/my-queue
> Connected to localhost:5672
> -> SASL
> [0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00gordon\x00gordon"]
> <- SASL
> [0x18b8320:0] <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
> [0x18b8320:0] <- @sasl-outcome(68) [code=0]
> -> AMQP
> [0x18b08d0:0] -> @open(16)
> [container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
> [0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
> durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
> durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> <- AMQP
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> Segmentation fault (core dumped)
> {noformat}
> #0 0x7f799b10c0e0 in pn_data_rewind () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #1 0x7f799b11555f in pn_do_close () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #2 0x7f799b111554 in pn_dispatch_frame () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #3 0x7f799b1116e7 in pn_dispatcher_input () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #4 0x7f799b1169ee in pn_input_read_amqp () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #5 0x7f799b114855 in transport_consume () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #6 0x7f799b1185e2 in pn_transport_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #7 0x7f799b1204fb in pn_connector_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #8 0x7f799b11e420 in pn_messenger_tsync () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Reopened] (PROTON-433) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-433:
---
> seg fault when handling error
> -
>
> Key: PROTON-433
> URL: https://issues.apache.org/jira/browse/PROTON-433
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Priority: Blocker
> Fix For: 0.6
>
>
> {noformat}
> $ ./proton-c/examples/messenger/c/send -a
> amqp://gordon:gordon@localhost/my-queue
> Connected to localhost:5672
> -> SASL
> [0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00gordon\x00gordon"]
> <- SASL
> [0x18b8320:0] <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
> [0x18b8320:0] <- @sasl-outcome(68) [code=0]
> -> AMQP
> [0x18b08d0:0] -> @open(16)
> [container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
> [0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
> durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
> durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> <- AMQP
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> Segmentation fault (core dumped)
> {noformat}
> #0 0x7f799b10c0e0 in pn_data_rewind () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #1 0x7f799b11555f in pn_do_close () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #2 0x7f799b111554 in pn_dispatch_frame () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #3 0x7f799b1116e7 in pn_dispatcher_input () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #4 0x7f799b1169ee in pn_input_read_amqp () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #5 0x7f799b114855 in transport_consume () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #6 0x7f799b1185e2 in pn_transport_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #7 0x7f799b1204fb in pn_connector_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #8 0x7f799b11e420 in pn_messenger_tsync () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-434) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-434.
-
Resolution: Duplicate
Created extra JIRAs in error.
> seg fault when handling error
> -
>
> Key: PROTON-434
> URL: https://issues.apache.org/jira/browse/PROTON-434
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Priority: Blocker
> Fix For: 0.6
>
>
> {noformat}
> $ ./proton-c/examples/messenger/c/send -a
> amqp://gordon:gordon@localhost/my-queue
> Connected to localhost:5672
> -> SASL
> [0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00gordon\x00gordon"]
> <- SASL
> [0x18b8320:0] <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
> [0x18b8320:0] <- @sasl-outcome(68) [code=0]
> -> AMQP
> [0x18b08d0:0] -> @open(16)
> [container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
> [0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
> durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
> durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> <- AMQP
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> Segmentation fault (core dumped)
> {noformat}
> #0 0x7f799b10c0e0 in pn_data_rewind () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #1 0x7f799b11555f in pn_do_close () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #2 0x7f799b111554 in pn_dispatch_frame () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #3 0x7f799b1116e7 in pn_dispatcher_input () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #4 0x7f799b1169ee in pn_input_read_amqp () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #5 0x7f799b114855 in transport_consume () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #6 0x7f799b1185e2 in pn_transport_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #7 0x7f799b1204fb in pn_connector_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #8 0x7f799b11e420 in pn_messenger_tsync () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-433) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-433.
-
Resolution: Duplicate
Created extra JIRAs in error.
> seg fault when handling error
> -
>
> Key: PROTON-433
> URL: https://issues.apache.org/jira/browse/PROTON-433
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Priority: Blocker
> Fix For: 0.6
>
>
> {noformat}
> $ ./proton-c/examples/messenger/c/send -a
> amqp://gordon:gordon@localhost/my-queue
> Connected to localhost:5672
> -> SASL
> [0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00gordon\x00gordon"]
> <- SASL
> [0x18b8320:0] <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
> [0x18b8320:0] <- @sasl-outcome(68) [code=0]
> -> AMQP
> [0x18b08d0:0] -> @open(16)
> [container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
> [0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
> durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
> durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> <- AMQP
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> Segmentation fault (core dumped)
> {noformat}
> #0 0x7f799b10c0e0 in pn_data_rewind () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #1 0x7f799b11555f in pn_do_close () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #2 0x7f799b111554 in pn_dispatch_frame () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #3 0x7f799b1116e7 in pn_dispatcher_input () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #4 0x7f799b1169ee in pn_input_read_amqp () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #5 0x7f799b114855 in transport_consume () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #6 0x7f799b1185e2 in pn_transport_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #7 0x7f799b1204fb in pn_connector_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #8 0x7f799b11e420 in pn_messenger_tsync () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (PROTON-435) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-435.
-
Resolution: Duplicate
Created extra JIRAs in error.
> seg fault when handling error
> -
>
> Key: PROTON-435
> URL: https://issues.apache.org/jira/browse/PROTON-435
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Priority: Blocker
> Fix For: 0.6
>
>
> {noformat}
> $ ./proton-c/examples/messenger/c/send -a
> amqp://gordon:gordon@localhost/my-queue
> Connected to localhost:5672
> -> SASL
> [0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00gordon\x00gordon"]
> <- SASL
> [0x18b8320:0] <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
> [0x18b8320:0] <- @sasl-outcome(68) [code=0]
> -> AMQP
> [0x18b08d0:0] -> @open(16)
> [container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
> [0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
> durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
> durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> <- AMQP
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> Segmentation fault (core dumped)
> {noformat}
> #0 0x7f799b10c0e0 in pn_data_rewind () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #1 0x7f799b11555f in pn_do_close () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #2 0x7f799b111554 in pn_dispatch_frame () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #3 0x7f799b1116e7 in pn_dispatcher_input () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #4 0x7f799b1169ee in pn_input_read_amqp () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #5 0x7f799b114855 in transport_consume () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #6 0x7f799b1185e2 in pn_transport_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #7 0x7f799b1204fb in pn_connector_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #8 0x7f799b11e420 in pn_messenger_tsync () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (PROTON-432) seg fault when handling error
[
https://issues.apache.org/jira/browse/PROTON-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-432:
-
Assignee: Rafael H. Schloming
The issue appears to be a over long error description, and no bounds checking
when assigning that to the condition's buffer. Possible fix posted here:
https://reviews.apache.org/r/14442/
> seg fault when handling error
> -
>
> Key: PROTON-432
> URL: https://issues.apache.org/jira/browse/PROTON-432
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Gordon Sim
>Assignee: Rafael H. Schloming
>Priority: Blocker
> Fix For: 0.6
>
>
> {noformat}
> $ ./proton-c/examples/messenger/c/send -a
> amqp://gordon:gordon@localhost/my-queue
> Connected to localhost:5672
> -> SASL
> [0x18b8320:0] -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00gordon\x00gordon"]
> <- SASL
> [0x18b8320:0] <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN, :AMQPLAIN]]
> [0x18b8320:0] <- @sasl-outcome(68) [code=0]
> -> AMQP
> [0x18b08d0:0] -> @open(16)
> [container-id="8133b412-5ca8-4359-be9f-e236b87d3528", hostname="localhost"]
> [0x18b08d0:0] -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=1]
> [0x18b08d0:0] -> @attach(18) [name="sender-xxx", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="my-queue",
> durable=0, timeout=0, dynamic=false], target=@target(41) [address="my-queue",
> durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> <- AMQP
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> [0x18b08d0:0] <- @open(16) [container-id="rabbit@GRS-T520",
> idle-time-out=60, properties={:copyright="Copyright (C) 2007-2013 VMware,
> Inc.", :information="Licensed under the MPL. See http://www.rabbitmq.com/";,
> :platform="Erlang/OTP", :product="RabbitMQ", :version="3.1.3"}]
> Segmentation fault (core dumped)
> {noformat}
> #0 0x7f799b10c0e0 in pn_data_rewind () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #1 0x7f799b11555f in pn_do_close () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #2 0x7f799b111554 in pn_dispatch_frame () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #3 0x7f799b1116e7 in pn_dispatcher_input () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #4 0x7f799b1169ee in pn_input_read_amqp () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #5 0x7f799b114855 in transport_consume () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #6 0x7f799b1185e2 in pn_transport_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #7 0x7f799b1204fb in pn_connector_process () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #8 0x7f799b11e420 in pn_messenger_tsync () from
> /home/gordon/projects/proton/build/proton-c/libqpid-proton.so.2
> #9 0x004010f3 in main ()
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd
[
https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802184#comment-13802184
]
Gordon Sim commented on PROTON-426:
---
Just for completeness, the 1.0 protocol does define a mechanism by which the
broker can be asked to create a queue (the 'dynamic' flag on source/target),
however in that case the queue is named by the broker and not the application.
This works well for 'temporary queues' e.g. as used in request-response
patterns. However I share the view that the more general solution of on-demand
creation is indeed better handled through broker configuration and have raised
https://issues.apache.org/jira/browse/QPID-5251 to add that to qpidd.
> [Messenger] messenger has no ability to dynamically create queues/topics on
> qpidd
> -
>
> Key: PROTON-426
> URL: https://issues.apache.org/jira/browse/PROTON-426
> Project: Qpid Proton
> Issue Type: New Feature
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Ken Giusti
> Fix For: 0.6
>
>
> The current QPID client addressing syntax provides a way to create and delete
> queue/topic resource on the qpidd broker "in band". For example:
> $ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options "{protocol:amqp1.0}"
> "TestQ;{create:always,node:{type:queue}}"
> $ qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn msgOut bytes
> bytesIn bytesOut cons bind
>
> <...>
> TestQ1 1
> 0 65 650 0 1
> This capability is not available when using the Messenger API.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (PROTON-483) detach with closed=false (or unspecified) not handled
Gordon Sim created PROTON-483:
-
Summary: detach with closed=false (or unspecified) not handled
Key: PROTON-483
URL: https://issues.apache.org/jira/browse/PROTON-483
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6
Reporter: Gordon Sim
If an application using proton-c receives a detach frame where the closed field
is not set to true, then the state of the link doesn't change and the
application is essentially unaware that anything has been received (and
consequently can't respond).
>From transport.c (line 882):
{noformat}
if (closed)
{
PN_SET_REMOTE(link->endpoint.state, PN_REMOTE_CLOSED);
} else {
// TODO: implement
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Reopened] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd
[
https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reopened PROTON-426:
---
> [Messenger] messenger has no ability to dynamically create queues/topics on
> qpidd
> -
>
> Key: PROTON-426
> URL: https://issues.apache.org/jira/browse/PROTON-426
> Project: Qpid Proton
> Issue Type: New Feature
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Ken Giusti
> Fix For: 0.6
>
>
> The current QPID client addressing syntax provides a way to create and delete
> queue/topic resource on the qpidd broker "in band". For example:
> $ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options "{protocol:amqp1.0}"
> "TestQ;{create:always,node:{type:queue}}"
> $ qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn msgOut bytes
> bytesIn bytesOut cons bind
>
> <...>
> TestQ1 1
> 0 65 650 0 1
> This capability is not available when using the Messenger API.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (PROTON-426) [Messenger] messenger has no ability to dynamically create queues/topics on qpidd
[
https://issues.apache.org/jira/browse/PROTON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim closed PROTON-426.
-
Resolution: Duplicate
> [Messenger] messenger has no ability to dynamically create queues/topics on
> qpidd
> -
>
> Key: PROTON-426
> URL: https://issues.apache.org/jira/browse/PROTON-426
> Project: Qpid Proton
> Issue Type: New Feature
> Components: proton-c
>Affects Versions: 0.5
>Reporter: Ken Giusti
> Fix For: 0.6
>
>
> The current QPID client addressing syntax provides a way to create and delete
> queue/topic resource on the qpidd broker "in band". For example:
> $ QPID_LOAD_MODULE=amqpc.so ./spout --connection-options "{protocol:amqp1.0}"
> "TestQ;{create:always,node:{type:queue}}"
> $ qpid-stat -q
> Queues
> queue dur autoDel excl msg msgIn msgOut bytes
> bytesIn bytesOut cons bind
>
> <...>
> TestQ1 1
> 0 65 650 0 1
> This capability is not available when using the Messenger API.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (PROTON-506) Queue names with '@' symbol cause incorrect hostname lookup
[
https://issues.apache.org/jira/browse/PROTON-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-506:
--
Fix Version/s: 0.7
> Queue names with '@' symbol cause incorrect hostname lookup
> ---
>
> Key: PROTON-506
> URL: https://issues.apache.org/jira/browse/PROTON-506
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.6
>Reporter: Brian Bouterse
>Assignee: Rafael H. Schloming
> Fix For: 0.7
>
>
> I have need to create a queue with the following name (no quotes):
> "cel...@dhcp129-138.rdu.redhat.com.celery.pidbox"
> I try to subscribe using the string
> 'amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox'
> I receive the following error:
> Unrecoverable error: MessengerException('[-2]: unable to connect to
> amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox:
> getaddrinfo(dhcp129-138.rdu.redhat.com.celery.pidbox, 5672): Name or service
> not known',)
> I expected the hostname to be 'localhost', but instead the hostname being
> used is 'dhcp129-138.rdu.redhat.com.celery.pidbox' which is not an actual
> hostname.
> Better interpretation of the string would resolve this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (PROTON-506) Queue names with '@' symbol cause incorrect hostname lookup
[
https://issues.apache.org/jira/browse/PROTON-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-506:
-
Assignee: Rafael H. Schloming
> Queue names with '@' symbol cause incorrect hostname lookup
> ---
>
> Key: PROTON-506
> URL: https://issues.apache.org/jira/browse/PROTON-506
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.6
>Reporter: Brian Bouterse
>Assignee: Rafael H. Schloming
> Fix For: 0.7
>
>
> I have need to create a queue with the following name (no quotes):
> "cel...@dhcp129-138.rdu.redhat.com.celery.pidbox"
> I try to subscribe using the string
> 'amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox'
> I receive the following error:
> Unrecoverable error: MessengerException('[-2]: unable to connect to
> amqp://localhost/cel...@dhcp129-138.rdu.redhat.com.celery.pidbox:
> getaddrinfo(dhcp129-138.rdu.redhat.com.celery.pidbox, 5672): Name or service
> not known',)
> I expected the hostname to be 'localhost', but instead the hostname being
> used is 'dhcp129-138.rdu.redhat.com.celery.pidbox' which is not an actual
> hostname.
> Better interpretation of the string would resolve this.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (PROTON-608) seg fault if attach is sent before open and begin
Gordon Sim created PROTON-608: - Summary: seg fault if attach is sent before open and begin Key: PROTON-608 URL: https://issues.apache.org/jira/browse/PROTON-608 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Gordon Sim Fix For: 0.8 While working with the proton-j engine, I inadvertently opened a link before opening the corresponding session and connection. This resulted in the attach being sent without the open or begin. Though clearly user error, it did show up an issue with the proton-c engine, where this sequence causes a segfault. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-608) seg fault if attach is sent before open and begin
[ https://issues.apache.org/jira/browse/PROTON-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030641#comment-14030641 ] Gordon Sim commented on PROTON-608: --- > 2014-06-11 17:12:11 [Protocol] trace [qpid.127.0.0.1:5672-127.0.0.1:42526]: > <- AMQP > 2014-06-11 17:12:11 [Protocol] trace [qpid.127.0.0.1:5672-127.0.0.1:42526]: > 65535 <- @attach(18) [name="amq.topic_1", handle=0, role=false, > snd-settle-mode=2, rcv-settle-mode=0, target=@target(41) > [address="amq.topic"], incomplete-unsettled=false, initial-delivery-count=0] > Segmentation fault (core dumped) > Core was generated by `./src/qpidd --auth no --load-module ./src/amqp.so > --log-enable info+ --log-enab'. > Program terminated with signal 11, Segmentation fault. > #0 0x7f4a9be383b4 in pn_find_link () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > Missing separate debuginfos, use: debuginfo-install > boost-program-options-1.48.0-14.fc17.x86_64 > cyrus-sasl-lib-2.1.23-31.fc17.x86_64 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 nspr-4.9.6-1.fc17.x86_64 > nss-3.14.3-2.fc17.x86_64 nss-softokn-freebl-3.14.3-1.fc17.x86_64 > nss-util-3.14.3-1.fc17.x86_64 openssl-1.0.0k-1.fc17.x86_64 > zlib-1.2.5-7.fc17.x86_64 > (gdb) bt > #0 0x7f4a9be383b4 in pn_find_link () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #1 0x7f4a9be385ce in pn_do_attach () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #2 0x7f4a9be32c34 in pn_dispatch_frame () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #3 0x7f4a9be32dc7 in pn_dispatcher_input () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #4 0x7f4a9be3a5ee in pn_input_read_amqp () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #5 0x7f4a9be39b65 in transport_consume () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #6 0x7f4a9be3aaf2 in pn_transport_process () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #7 0x7f4a9be3ac48 in pn_transport_input () from > /home/gordon/qpid-releases/proton/0.7/installation/lib64/libqpid-proton.so.2 > #8 0x7f4a9c103516 in qpid::broker::amqp::Connection::decode(char const*, > unsigned long) () from > seg fault if attach is sent before open and begin > - > > Key: PROTON-608 > URL: https://issues.apache.org/jira/browse/PROTON-608 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Gordon Sim > Fix For: 0.8 > > > While working with the proton-j engine, I inadvertently opened a link before > opening the corresponding session and connection. This resulted in the attach > being sent without the open or begin. Though clearly user error, it did show > up an issue with the proton-c engine, where this sequence causes a segfault. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-641) pn_connection_t leaked when links not closed
Gordon Sim created PROTON-641: - Summary: pn_connection_t leaked when links not closed Key: PROTON-641 URL: https://issues.apache.org/jira/browse/PROTON-641 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Fix For: 0.8 If the application doesn't call pn_link_close(), but calls on_session_close(), pn_connection_close(), then pn_transport_free() and pn_connection_free(), the pn_connection_t object appear to be leaked. Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-641) pn_connection_t leaked when links not closed
[ https://issues.apache.org/jira/browse/PROTON-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-641: -- Attachment: proton_leak.cpp Running attached test under valgrind gives: ==17718== ==17718== HEAP SUMMARY: ==17718== in use at exit: 29,660 bytes in 612 blocks ==17718== total heap usage: 819 allocs, 207 frees, 156,612 bytes allocated ==17718== ==17718== 14,830 (256 direct, 14,574 indirect) bytes in 1 blocks are definitely lost in loss record 611 of 612 ==17718==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==17718==by 0x4C24B5D: pn_new2 (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C24B37: pn_new (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C355A6: pn_connection (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x40139C: Client::Client() (proton_leak.cpp:35) ==17718==by 0x40128B: main (proton_leak.cpp:152) ==17718== ==17718== 14,830 (256 direct, 14,574 indirect) bytes in 1 blocks are definitely lost in loss record 612 of 612 ==17718==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==17718==by 0x4C24B5D: pn_new2 (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C24B37: pn_new (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x4C355A6: pn_connection (in /home/gordon/projects/proton/installation/lib64/libqpid-proton.so.2.0.0) ==17718==by 0x401546: Server::Server() (proton_leak.cpp:84) ==17718==by 0x401297: main (proton_leak.cpp:153) ==17718== ==17718== LEAK SUMMARY: ==17718==definitely lost: 512 bytes in 2 blocks ==17718==indirectly lost: 29,148 bytes in 610 blocks ==17718== possibly lost: 0 bytes in 0 blocks ==17718==still reachable: 0 bytes in 0 blocks ==17718== suppressed: 0 bytes in 0 blocks ==17718== ==17718== For counts of detected and suppressed errors, rerun with: -v ==17718== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2 from 2) > pn_connection_t leaked when links not closed > > > Key: PROTON-641 > URL: https://issues.apache.org/jira/browse/PROTON-641 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming > Fix For: 0.8 > > Attachments: proton_leak.cpp > > > If the application doesn't call pn_link_close(), but calls > on_session_close(), pn_connection_close(), then pn_transport_free() and > pn_connection_free(), the pn_connection_t object appear to be leaked. > Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-648) Memory leaks on aborted connections.
[
https://issues.apache.org/jira/browse/PROTON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098427#comment-14098427
]
Gordon Sim commented on PROTON-648:
---
See also https://issues.apache.org/jira/browse/PROTON-641 which is similar in
scope.
> Memory leaks on aborted connections.
>
>
> Key: PROTON-648
> URL: https://issues.apache.org/jira/browse/PROTON-648
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7, 0.8
>Reporter: Marcel Meulemans
> Attachments: leak.c
>
>
> When a connection is aborted, open sessions can not be ended and attached
> links can not be not detached properly. Because of this there are some
> references to connection/sessions/links that are not released properly:
> # The session state does not release references to links in the
> {{local_handles/remote_handles}} hash map. This causes a leak because the
> session references links and the links reference the session but the engine
> does have a reference to any of these objects anymore.
> # The transport does not release references to sessions in the
> {{local_channels/remote_channels}} hash map. This is not really a leak
> because the references are released in {{pn_transport_free}}, but i.m.o. they
> should be release when the connection is unbound from the transport, i.e.
> {{pn_unbind_transport()}}.
> The leak can be observed by using the attached test program with ActiveMQ.
> When ActiveMQ is shutdown with CTRL-C it just kills the connection causing a
> transport error (connection aborted) on the client side. When this happens
> the program leaks. See below for the program/valgrind output of the program
> with and without the patch.
> The patch can be found here:
> https://github.com/marcelmeulemans/qpid-proton/commit/e5300da7be015ea874248b6593040d1bd50ac0e3
> - The removed commented code in {{pn_session_finalize}} is the right idea in
> the wrong place; {{pn_session_finalize}} is never called because the
> references that this code releases still exist. The code has been moved to a
> new function {{pn_cleanup_session}} in the transport "class".
> - The {{pn_cleanup_session}} call from {{pn_remove_session}} is needed in the
> case the session is freed ({{pn_session_free}}) manually from application
> code.
> - The {{pn_cleanup_session}} call from {{pn_transport_unbind}} is needed in
> the case the session is automatically freed via the connection.
> - The changes in {{pn_session_close}} solve the real leak describe in *1*
> above.
> *Valgrind output without patch*:
> {noformat}
> ==5607== Memcheck, a memory error detector
> ==5607== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==5607== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==5607== Command: ./leak.symbols
> ==5607==
> Connected to 127.0.0.1:5672
> [0x6671b80]: -> SASL
> [0x6671b80]: <- SASL
> [0x6671b80]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x6671b80]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
> [0x6671b80]:0 <- @sasl-outcome(68) [code=0]
> [0x6671b80]: <- AMQP
> [0x6671b80]: -> AMQP
> [0x6671b80]:0 -> @open(16) [container-id="leak", hostname="leak"]
> [0x6671b80]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=0]
> [0x6671b80]:0 -> @attach(18) [name="leak", handle=0, role=true,
> snd-settle-mode=0, rcv-settle-mode=1, source=@source(40)
> [address="queue://leak", durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="queue://leak", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> [0x6671b80]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
> outgoing-window=0, handle=0, delivery-count=0, link-credit=8, drain=false]
> [0x6671b80]:0 <- @open(16) [container-id="", hostname="",
> max-frame-size=1048576]
> [0x6671b80]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
> incoming-window=0, outgoing-window=0, handle-max=1024]
> [0x6671b80]:0 <- @attach(18) [name="leak", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="queue://leak"], target=@target(41) [address="queue://leak"],
> incomplete-unsettled=false, initial-delivery-count=0]
> [0x6671b80]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error"]]
> [0x6671b80]:ERROR amqp:connection:framing-error connection aborted
> [0x6671b80]:ERROR[-2] connection aborted
> [0x6671b80]: <- EOS
> [0x6671b80]: -> EOS (-2) connection aborted
> Closed 127.0.0.1:5672
> close: Bad file descriptor
> ==5607==
> ==5607== HEAP SUMMARY:
> ==5607== in use at exit: 14,904 bytes in 306 blocks
> ==5607== total heap usage: 508 allocs, 202 frees, 1,151,697 bytes allocated
> ==5607==
> ==5607== 14,90
[jira] [Commented] (PROTON-648) Memory leaks on aborted connections.
[
https://issues.apache.org/jira/browse/PROTON-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098472#comment-14098472
]
Gordon Sim commented on PROTON-648:
---
Absolutely, thanks!
> Memory leaks on aborted connections.
>
>
> Key: PROTON-648
> URL: https://issues.apache.org/jira/browse/PROTON-648
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.7, 0.8
>Reporter: Marcel Meulemans
> Attachments: leak.c
>
>
> When a connection is aborted, open sessions can not be ended and attached
> links can not be not detached properly. Because of this there are some
> references to connection/sessions/links that are not released properly:
> # The session state does not release references to links in the
> {{local_handles/remote_handles}} hash map. This causes a leak because the
> session references links and the links reference the session but the engine
> does have a reference to any of these objects anymore.
> # The transport does not release references to sessions in the
> {{local_channels/remote_channels}} hash map. This is not really a leak
> because the references are released in {{pn_transport_free}}, but i.m.o. they
> should be release when the connection is unbound from the transport, i.e.
> {{pn_unbind_transport()}}.
> The leak can be observed by using the attached test program with ActiveMQ.
> When ActiveMQ is shutdown with CTRL-C it just kills the connection causing a
> transport error (connection aborted) on the client side. When this happens
> the program leaks. See below for the program/valgrind output of the program
> with and without the patch.
> The patch can be found here:
> https://github.com/marcelmeulemans/qpid-proton/commit/e5300da7be015ea874248b6593040d1bd50ac0e3
> - The removed commented code in {{pn_session_finalize}} is the right idea in
> the wrong place; {{pn_session_finalize}} is never called because the
> references that this code releases still exist. The code has been moved to a
> new function {{pn_cleanup_session}} in the transport "class".
> - The {{pn_cleanup_session}} call from {{pn_remove_session}} is needed in the
> case the session is freed ({{pn_session_free}}) manually from application
> code.
> - The {{pn_cleanup_session}} call from {{pn_transport_unbind}} is needed in
> the case the session is automatically freed via the connection.
> - The changes in {{pn_session_close}} solve the real leak describe in *1*
> above.
> *Valgrind output without patch*:
> {noformat}
> ==5607== Memcheck, a memory error detector
> ==5607== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==5607== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==5607== Command: ./leak.symbols
> ==5607==
> Connected to 127.0.0.1:5672
> [0x6671b80]: -> SASL
> [0x6671b80]: <- SASL
> [0x6671b80]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
> [0x6671b80]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
> [0x6671b80]:0 <- @sasl-outcome(68) [code=0]
> [0x6671b80]: <- AMQP
> [0x6671b80]: -> AMQP
> [0x6671b80]:0 -> @open(16) [container-id="leak", hostname="leak"]
> [0x6671b80]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
> outgoing-window=0]
> [0x6671b80]:0 -> @attach(18) [name="leak", handle=0, role=true,
> snd-settle-mode=0, rcv-settle-mode=1, source=@source(40)
> [address="queue://leak", durable=0, timeout=0, dynamic=false],
> target=@target(41) [address="queue://leak", durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> [0x6671b80]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0,
> outgoing-window=0, handle=0, delivery-count=0, link-credit=8, drain=false]
> [0x6671b80]:0 <- @open(16) [container-id="", hostname="",
> max-frame-size=1048576]
> [0x6671b80]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1,
> incoming-window=0, outgoing-window=0, handle-max=1024]
> [0x6671b80]:0 <- @attach(18) [name="leak", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="queue://leak"], target=@target(41) [address="queue://leak"],
> incomplete-unsettled=false, initial-delivery-count=0]
> [0x6671b80]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error"]]
> [0x6671b80]:ERROR amqp:connection:framing-error connection aborted
> [0x6671b80]:ERROR[-2] connection aborted
> [0x6671b80]: <- EOS
> [0x6671b80]: -> EOS (-2) connection aborted
> Closed 127.0.0.1:5672
> close: Bad file descriptor
> ==5607==
> ==5607== HEAP SUMMARY:
> ==5607== in use at exit: 14,904 bytes in 306 blocks
> ==5607== total heap usage: 508 allocs, 202 frees, 1,151,697 bytes allocated
> ==5607==
> ==5607== 14,904 (256 direct, 14,648 indirect) bytes in 1 blocks are
> definite
[jira] [Commented] (PROTON-641) pn_connection_t leaked when links not closed
[ https://issues.apache.org/jira/browse/PROTON-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098471#comment-14098471 ] Gordon Sim commented on PROTON-641: --- See also https://issues.apache.org/jira/browse/PROTON-648 which has a patch. > pn_connection_t leaked when links not closed > > > Key: PROTON-641 > URL: https://issues.apache.org/jira/browse/PROTON-641 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming > Fix For: 0.8 > > Attachments: proton_leak.cpp > > > If the application doesn't call pn_link_close(), but calls > on_session_close(), pn_connection_close(), then pn_transport_free() and > pn_connection_free(), the pn_connection_t object appear to be leaked. > Will attach reproducer. See also QPID-5951. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-656) pn_transport_close_{head, tail} no longer return an error code on framing error.
[
https://issues.apache.org/jira/browse/PROTON-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14119939#comment-14119939
]
Gordon Sim commented on PROTON-656:
---
sounds good to me
> pn_transport_close_{head, tail} no longer return an error code on framing
> error.
>
>
> Key: PROTON-656
> URL: https://issues.apache.org/jira/browse/PROTON-656
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
>Reporter: Ken Giusti
>Priority: Blocker
> Fix For: 0.8
>
>
> In the 0.7 release, the transport interfaces pn_transport_close_head() and
> pn_transport_close_tail() used to return an error should the close occur at
> an 'unexpected' point on the protocol (framing error, for example).
> The behavior no longer occurs on trunk. This results in an API change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-659) if protons internal buffer gets large, performance can suffer
Gordon Sim created PROTON-659: - Summary: if protons internal buffer gets large, performance can suffer Key: PROTON-659 URL: https://issues.apache.org/jira/browse/PROTON-659 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.7 Reporter: Gordon Sim Priority: Minor In doing some performance investigations using qpid::messaging over 1.0, in particular as message size got larger, I saw much lower throughput and lots of cpu used. From callgrind it looked like this was from shuffliing up the buffer in pn_dispatcher_output. Because of the threading in qpid::messaging, it was possible for the application to generate too much output using the top-half of the engine API before the IO was done for the bottom half. Fixing that in qpid:messaging improved performance. There may perhaps be something that proton could do to make users more aware of this (e.g. a log message if the buffer exceeds a certain size? or just documentation?) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-688) pn_transport_unbind() doesn't reset all relevant trasnport state
Gordon Sim created PROTON-688: - Summary: pn_transport_unbind() doesn't reset all relevant trasnport state Key: PROTON-688 URL: https://issues.apache.org/jira/browse/PROTON-688 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Gordon Sim Unbinding a transport on connection failure, then trying to rebind a new transport to the original connection option doesn't work as expected as not all relevant state is reset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-688) pn_transport_unbind() doesn't reset all relevant trasnport state
[ https://issues.apache.org/jira/browse/PROTON-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14139410#comment-14139410 ] Gordon Sim commented on PROTON-688: --- Patch proposed: https://reviews.apache.org/r/25790/ > pn_transport_unbind() doesn't reset all relevant trasnport state > > > Key: PROTON-688 > URL: https://issues.apache.org/jira/browse/PROTON-688 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.8 >Reporter: Gordon Sim > > Unbinding a transport on connection failure, then trying to rebind a new > transport to the original connection option doesn't work as expected as not > all relevant state is reset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-688) pn_transport_unbind() doesn't reset all relevant trasnport state
[ https://issues.apache.org/jira/browse/PROTON-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-688. --- Resolution: Fixed Fix Version/s: 0.8 > pn_transport_unbind() doesn't reset all relevant trasnport state > > > Key: PROTON-688 > URL: https://issues.apache.org/jira/browse/PROTON-688 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.8 >Reporter: Gordon Sim > Fix For: 0.8 > > > Unbinding a transport on connection failure, then trying to rebind a new > transport to the original connection option doesn't work as expected as not > all relevant state is reset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
Gordon Sim created PROTON-723: - Summary: Proton-c does not support attaching to the transaction coordinator Key: PROTON-723 URL: https://issues.apache.org/jira/browse/PROTON-723 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Reporter: Hiram Chirino Assignee: Rafael H. Schloming Got at: Caused by: java.lang.ClassCastException: org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to org.apache.qpid.proton.type.messaging.Target at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977) at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59) at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090) at org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) at org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120) ... 5 more and I think the frame being processed was the following (hex): 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 73 73 6e 40 40 43 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-723: -- Component/s: (was: proton-j) Description: Though there is a terminus type PN_COORDINATOR defined, setting that seems to have no effect and indeed the code in pn_process_link_setup always sets the source to the descriptor code for amqp:source:list. was: Got at: Caused by: java.lang.ClassCastException: org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to org.apache.qpid.proton.type.messaging.Target at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977) at org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59) at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090) at org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) at org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) at org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120) ... 5 more and I think the frame being processed was the following (hex): 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d 73 73 6e 40 40 43 Priority: Critical (was: Major) Affects Version/s: 0.8 > Proton-c does not support attaching to the transaction coordinator > -- > > Key: PROTON-723 > URL: https://issues.apache.org/jira/browse/PROTON-723 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming >Priority: Critical > Labels: api, transactions > > Though there is a terminus type PN_COORDINATOR defined, setting that seems to > have no effect and indeed the code in pn_process_link_setup always sets the > source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-62) Proton(-j) does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-62: - Component/s: (was: proton-c) This is still an issue for proton-c, so I have cloned a new JIRA for tracking that: PROTON-723 > Proton(-j) does not support attaching to the transaction coordinator > > > Key: PROTON-62 > URL: https://issues.apache.org/jira/browse/PROTON-62 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming > Labels: api, transactions > > Got at: > Caused by: java.lang.ClassCastException: > org.apache.qpid.proton.type.transaction.Coordinator cannot be cast to > org.apache.qpid.proton.type.messaging.Target > at > org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:977) > at > org.apache.qpid.proton.engine.impl.TransportImpl.handleAttach(TransportImpl.java:59) > at org.apache.qpid.proton.type.transport.Attach.invoke(Attach.java:389) > at > org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:1090) > at > org.apache.qpid.proton.engine.impl.FrameParser.input(FrameParser.java:409) > at > org.apache.qpid.proton.engine.impl.TransportImpl.input(TransportImpl.java:156) > at > org.apache.activemq.transport.amqp.AmqpProtocolConverter.onAMQPData(AmqpProtocolConverter.java:120) > ... 5 more > and I think the frame being processed was the following (hex): > 00 00 00 6a 02 00 00 01 00 53 12 c0 5d 0a a1 11 74 78 6e 43 > 6f 6e 74 72 6f 6c 6c 65 72 4c 69 6e 6b 43 42 50 00 50 00 00 > 53 28 c0 01 00 00 53 30 c0 35 01 e0 32 02 a3 17 61 6d 71 70 > 3a 6c 6f 63 61 6c 2d 74 72 61 6e 73 61 63 74 69 6f 6e 73 17 > 61 6d 71 70 3a 6d 75 6c 74 69 2d 74 78 6e 73 2d 70 65 72 2d > 73 73 6e 40 40 43 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-723: -- Attachment: quick_and_dirty.patch Quick and dirty fix to allow the attach made by the controller to the coordinator to be sent out correctly. (Doesn't address the issue of an incoming link to the coordinator on the coordinator processes side). > Proton-c does not support attaching to the transaction coordinator > -- > > Key: PROTON-723 > URL: https://issues.apache.org/jira/browse/PROTON-723 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming >Priority: Critical > Labels: api, transactions > Attachments: quick_and_dirty.patch > > > Though there is a terminus type PN_COORDINATOR defined, setting that seems to > have no effect and indeed the code in pn_process_link_setup always sets the > source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-667) add support for transactional state and enable outgoing transfer frames to specify a txn-id
[ https://issues.apache.org/jira/browse/PROTON-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-667: - Assignee: Rafael H. Schloming > add support for transactional state and enable outgoing transfer frames to > specify a txn-id > --- > > Key: PROTON-667 > URL: https://issues.apache.org/jira/browse/PROTON-667 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Rafael H. Schloming > > Similar to PROTON-666 for proton-j, proton-c needs to be able to apply > transactional state to outgoing transfer frames in order to allow publihsing > messages transactionally. Support needs to be added for transactional state > generally in order to allow this. Changes should include python binding > updates to allow testing these changes and those for PROTON-666. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-667) add support for transactional state and enable outgoing transfer frames to specify a txn-id
[ https://issues.apache.org/jira/browse/PROTON-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-667: -- Attachment: quick_and_dirty_again.patch Another quick and dirty fix in case it is of use to anyone. > add support for transactional state and enable outgoing transfer frames to > specify a txn-id > --- > > Key: PROTON-667 > URL: https://issues.apache.org/jira/browse/PROTON-667 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Rafael H. Schloming > Attachments: quick_and_dirty_again.patch > > > Similar to PROTON-666 for proton-j, proton-c needs to be able to apply > transactional state to outgoing transfer frames in order to allow publihsing > messages transactionally. Support needs to be added for transactional state > generally in order to allow this. Changes should include python binding > updates to allow testing these changes and those for PROTON-666. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-730) Can't read transactional state set on incoming transfer
Gordon Sim created PROTON-730: - Summary: Can't read transactional state set on incoming transfer Key: PROTON-730 URL: https://issues.apache.org/jira/browse/PROTON-730 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185228#comment-14185228 ] Gordon Sim commented on PROTON-730: --- This is the other side of PROTON-667 really, where that appears to mainly be focused on controlling outgoing transfers, this is about handling incoming transfers with transactional state set on them. > Can't read transactional state set on incoming transfer > --- > > Key: PROTON-730 > URL: https://issues.apache.org/jira/browse/PROTON-730 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-723: -- Attachment: PROTON-723_part2_quick_and_dirty.patch This patch is for the other side of the wire, allowing the coordinator process itself to detect an incoming link for transaction control requests. Again, just a quick and dirty fix that works for me in my testing so far. > Proton-c does not support attaching to the transaction coordinator > -- > > Key: PROTON-723 > URL: https://issues.apache.org/jira/browse/PROTON-723 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming >Priority: Critical > Labels: api, transactions > Attachments: PROTON-723_part2_quick_and_dirty.patch, > quick_and_dirty.patch > > > Though there is a terminus type PN_COORDINATOR defined, setting that seems to > have no effect and indeed the code in pn_process_link_setup always sets the > source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-730: -- Attachment: PROTON-730_quick_and_dirty.patch Quick and dirty fix. This follows the same approach already in place for dispositions, whereby the descriptor code is available via pn_delivery_remote_state(). However this approach does seem limited to cases (admittedly the most likely) where the descriptor is numeric. Assuming it is valid to send a symbolic descriptor for delivery states, proton-c wouldn't read them. > Can't read transactional state set on incoming transfer > --- > > Key: PROTON-730 > URL: https://issues.apache.org/jira/browse/PROTON-730 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming > Attachments: PROTON-730_quick_and_dirty.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-730: -- Priority: Critical (was: Major) > Can't read transactional state set on incoming transfer > --- > > Key: PROTON-730 > URL: https://issues.apache.org/jira/browse/PROTON-730 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Critical > Attachments: PROTON-730_quick_and_dirty.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-732) assertion in transport_consume when authentication fails: Assertion `n == (-1)' failed
Gordon Sim created PROTON-732: - Summary: 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] [Created] (PROTON-734) deliveries are not returned in order
Gordon Sim created PROTON-734: - Summary: deliveries are not returned in order Key: PROTON-734 URL: https://issues.apache.org/jira/browse/PROTON-734 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Critical If, on a single session, I send e.g. 3 messages on one link, followed by a message on another link, then on the receiving side I expect those to be returned in the order in which they are sent. Although proton-c on the receiving side receives them in the correct order as verified by turning on tracing, the order in which the respective deliveries are returned by pn_work_head()/pn_work_next() is not correct. I get the first message, followed by the last message (i.e. the fourth), then the second and third. If I modify the test to send a fifth message to a third link, then on the receiving side the 5th message is received 3rd. I.e. it appears that the work queue involves taking the first delivery off each link, rather than having a session level ordering(?) In the case where a transaction discharge message is sent *after* some transactional publications, this results in the discharge being processed before all the publications the transaction is supposed to cover. (The sender can of course wait for all the transactional publications to be accepted before it sends the commit, but on a single session this isn't necessary and as far as I can see not required by the spec.) In any case, preserving order is likely to be important in other cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-754) no way to set or get properties on a flow
Gordon Sim created PROTON-754: - Summary: no way to set or get properties on a flow Key: PROTON-754 URL: https://issues.apache.org/jira/browse/PROTON-754 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim The transaction section of the spec states that this properties map is used to specify a txn-id for transaction acquisition. Even if this is not supported, resources are supposed to detect that being set and detach with not-implemented. So at present it is not possible to be compliant with the spec when using proton-c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-773) No way to determine that link is detahced (but not closed)
Gordon Sim created PROTON-773: - Summary: No way to determine that link is detahced (but not closed) Key: PROTON-773 URL: https://issues.apache.org/jira/browse/PROTON-773 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim At least I can't see any obvious way. The endpoint state indicates when the link is closed, but the detached flag used internally to record that the link has been detached, is not exposed in anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-730: - Assignee: Gordon Sim (was: Rafael H. Schloming) > Can't read transactional state set on incoming transfer > --- > > Key: PROTON-730 > URL: https://issues.apache.org/jira/browse/PROTON-730 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Critical > Fix For: 0.9 > > Attachments: PROTON-730_quick_and_dirty.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-730) Can't read transactional state set on incoming transfer
[ https://issues.apache.org/jira/browse/PROTON-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-730. --- Resolution: Fixed Fix Version/s: 0.9 > Can't read transactional state set on incoming transfer > --- > > Key: PROTON-730 > URL: https://issues.apache.org/jira/browse/PROTON-730 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Critical > Fix For: 0.9 > > Attachments: PROTON-730_quick_and_dirty.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-667) add support for transactional state and enable outgoing transfer frames to specify a txn-id
[ https://issues.apache.org/jira/browse/PROTON-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-667. --- Resolution: Fixed Fix Version/s: 0.9 > add support for transactional state and enable outgoing transfer frames to > specify a txn-id > --- > > Key: PROTON-667 > URL: https://issues.apache.org/jira/browse/PROTON-667 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: quick_and_dirty_again.patch > > > Similar to PROTON-666 for proton-j, proton-c needs to be able to apply > transactional state to outgoing transfer frames in order to allow publihsing > messages transactionally. Support needs to be added for transactional state > generally in order to allow this. Changes should include python binding > updates to allow testing these changes and those for PROTON-666. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-667) add support for transactional state and enable outgoing transfer frames to specify a txn-id
[ https://issues.apache.org/jira/browse/PROTON-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-667: - Assignee: Gordon Sim (was: Rafael H. Schloming) > add support for transactional state and enable outgoing transfer frames to > specify a txn-id > --- > > Key: PROTON-667 > URL: https://issues.apache.org/jira/browse/PROTON-667 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Robbie Gemmell >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: quick_and_dirty_again.patch > > > Similar to PROTON-666 for proton-j, proton-c needs to be able to apply > transactional state to outgoing transfer frames in order to allow publihsing > messages transactionally. Support needs to be added for transactional state > generally in order to allow this. Changes should include python binding > updates to allow testing these changes and those for PROTON-666. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-806) closing a blocking sender hangs if connection has been lost
Gordon Sim created PROTON-806: - Summary: 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] [Assigned] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
[ https://issues.apache.org/jira/browse/PROTON-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-812: - Assignee: Gordon Sim > LinkException needs an attribute that indicates the reason for the exception. > - > > Key: PROTON-812 > URL: https://issues.apache.org/jira/browse/PROTON-812 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: 0.8 >Reporter: Jeff Ortel >Assignee: Gordon Sim > > LinkException needs an attribute that indicates the reason for the exception > so that the exception can be appropriately delt with. For example: A link > exception caused when a node does not exist would be delt with differently > than a link exception caused by an issue in the link chain involving dispatch > router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
[ https://issues.apache.org/jira/browse/PROTON-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-812. --- Resolution: Fixed Fix Version/s: 0.9 There is now a LinkDetached subclass of LinkException, which has the 'condition' the peer set on the detach as a property. > LinkException needs an attribute that indicates the reason for the exception. > - > > Key: PROTON-812 > URL: https://issues.apache.org/jira/browse/PROTON-812 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: 0.8 >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.9 > > > LinkException needs an attribute that indicates the reason for the exception > so that the exception can be appropriately delt with. For example: A link > exception caused when a node does not exist would be delt with differently > than a link exception caused by an issue in the link chain involving dispatch > router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-812) LinkException needs an attribute that indicates the reason for the exception.
[ https://issues.apache.org/jira/browse/PROTON-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301530#comment-14301530 ] Gordon Sim commented on PROTON-812: --- When a peer detaches a link, it can supply a condition that is a string code that provides some context or reason for the detach. The correct behaviour on receiving an attach is always to echo an attach back, but then to follow that immediately with a detach. So, in general, in order to distinguish between two cases of the peer detaching a link there would need to be distinct conditions associated with the two cases. This change allows you to determine the condition. There is one special case, where the node the link is to be attached to doesn't exist and is not going to be created, the appropriate response is to send back an attach with no source or target (depending on direction of link) at all. That is in effect a precursor to an immediate detach with not-found as the condition. I don't know how dispatch router will handle case 2 above. For case 1, against qpidd, you will get a LinkException on create_receiver or create_sender, due to the source.target respectively being null on the attach sent back by the broker. > LinkException needs an attribute that indicates the reason for the exception. > - > > Key: PROTON-812 > URL: https://issues.apache.org/jira/browse/PROTON-812 > Project: Qpid Proton > Issue Type: Improvement >Affects Versions: 0.8 >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.9 > > > LinkException needs an attribute that indicates the reason for the exception > so that the exception can be appropriately delt with. For example: A link > exception caused when a node does not exist would be delt with differently > than a link exception caused by an issue in the link chain involving dispatch > router. Having constants for the error codes would be desireable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-815) LinkException on BlockingConnection.create_receiver() leaves things in bad state.
[ https://issues.apache.org/jira/browse/PROTON-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-815: - Assignee: Gordon Sim > LinkException on BlockingConnection.create_receiver() leaves things in bad > state. > - > > Key: PROTON-815 > URL: https://issues.apache.org/jira/browse/PROTON-815 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.8 > Environment: F20 with proton built from master. qpidd is 0.26. >Reporter: Jeff Ortel >Assignee: Gordon Sim > Attachments: t.py > > > Calling BlockingConnection.create_receiver() with an address that does not > exist raises a LinkException. This is expected. However, all subsequent > calls to either create_sender() or create_receiver() cause the original > LinkException to be re-raised. > Attaching a script to re-create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-815) LinkException on BlockingConnection.create_receiver() leaves things in bad state.
[ https://issues.apache.org/jira/browse/PROTON-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-815. --- Resolution: Fixed Fix Version/s: 0.9 > LinkException on BlockingConnection.create_receiver() leaves things in bad > state. > - > > Key: PROTON-815 > URL: https://issues.apache.org/jira/browse/PROTON-815 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: F20 with proton built from master. qpidd is 0.26. >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: t.py > > > Calling BlockingConnection.create_receiver() with an address that does not > exist raises a LinkException. This is expected. However, all subsequent > calls to either create_sender() or create_receiver() cause the original > LinkException to be re-raised. > Attaching a script to re-create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-815) LinkException on BlockingConnection.create_receiver() leaves things in bad state.
[ https://issues.apache.org/jira/browse/PROTON-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-815: -- Affects Version/s: (was: 0.8) 0.9 > LinkException on BlockingConnection.create_receiver() leaves things in bad > state. > - > > Key: PROTON-815 > URL: https://issues.apache.org/jira/browse/PROTON-815 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: F20 with proton built from master. qpidd is 0.26. >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: t.py > > > Calling BlockingConnection.create_receiver() with an address that does not > exist raises a LinkException. This is expected. However, all subsequent > calls to either create_sender() or create_receiver() cause the original > LinkException to be re-raised. > Attaching a script to re-create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-816) Add access to dynamic-node-properties in termini
[ https://issues.apache.org/jira/browse/PROTON-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-816: - Assignee: Gordon Sim > Add access to dynamic-node-properties in termini > > > Key: PROTON-816 > URL: https://issues.apache.org/jira/browse/PROTON-816 > Project: Qpid Proton > Issue Type: New Feature > Components: python-binding >Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: PROTON-816.patch > > > The Python reactive API needs to provide access to the > dynamic-node-properties map in termini for senders and receivers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-816) Add access to dynamic-node-properties in termini
[ https://issues.apache.org/jira/browse/PROTON-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-816. --- Resolution: Fixed > Add access to dynamic-node-properties in termini > > > Key: PROTON-816 > URL: https://issues.apache.org/jira/browse/PROTON-816 > Project: Qpid Proton > Issue Type: New Feature > Components: python-binding >Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: PROTON-816.patch > > > The Python reactive API needs to provide access to the > dynamic-node-properties map in termini for senders and receivers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-817) BlockingConnection doesn't pass options down in create_sender or create_receiver
[ https://issues.apache.org/jira/browse/PROTON-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-817. --- Resolution: Fixed > BlockingConnection doesn't pass options down in create_sender or > create_receiver > > > Key: PROTON-817 > URL: https://issues.apache.org/jira/browse/PROTON-817 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Ted Ross >Assignee: Gordon Sim > Fix For: 0.9 > > Attachments: PROTON-817.patch > > > The options argument is not passed down from > BlockingConnection.create_receiver to Container.create_receiver. The same is > true for create_sender. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-819) BlockingLink.__init__() raise LinkDetached instead of LinkException
[ https://issues.apache.org/jira/browse/PROTON-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-819: - Assignee: Gordon Sim > BlockingLink.__init__() raise LinkDetached instead of LinkException > --- > > Key: PROTON-819 > URL: https://issues.apache.org/jira/browse/PROTON-819 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.9 > Environment: All >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.9 > > > Please change BlockingLink.__init__() to raise LinkDetached instead of > LinkException. The 'condition' needed to differentiate between dispatch > router - routing issues and cases where the node does not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-819) BlockingLink.__init__() raise LinkDetached instead of LinkException
[ https://issues.apache.org/jira/browse/PROTON-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-819. --- Resolution: Fixed Fix Version/s: 0.9 > BlockingLink.__init__() raise LinkDetached instead of LinkException > --- > > Key: PROTON-819 > URL: https://issues.apache.org/jira/browse/PROTON-819 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Affects Versions: 0.9 > Environment: All >Reporter: Jeff Ortel >Assignee: Gordon Sim > Fix For: 0.9 > > > Please change BlockingLink.__init__() to raise LinkDetached instead of > LinkException. The 'condition' needed to differentiate between dispatch > router - routing issues and cases where the node does not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-734) deliveries are not returned in order
[ https://issues.apache.org/jira/browse/PROTON-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim closed PROTON-734. - Resolution: Won't Fix The conclusion here was to use the event api instead of the old work queue api, which avoids the problem. > deliveries are not returned in order > > > Key: PROTON-734 > URL: https://issues.apache.org/jira/browse/PROTON-734 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Gordon Sim >Assignee: Rafael H. Schloming >Priority: Critical > > If, on a single session, I send e.g. 3 messages on one link, followed by a > message on another link, then on the receiving side I expect those to be > returned in the order in which they are sent. > Although proton-c on the receiving side receives them in the correct order as > verified by turning on tracing, the order in which the respective deliveries > are returned by pn_work_head()/pn_work_next() is not correct. I get the first > message, followed by the last message (i.e. the fourth), then the second and > third. > If I modify the test to send a fifth message to a third link, then on the > receiving side the 5th message is received 3rd. I.e. it appears that the work > queue involves taking the first delivery off each link, rather than having a > session level ordering(?) > In the case where a transaction discharge message is sent *after* some > transactional publications, this results in the discharge being processed > before all the publications the transaction is supposed to cover. (The sender > can of course wait for all the transactional publications to be accepted > before it sends the commit, but on a single session this isn't necessary and > as far as I can see not required by the spec.) In any case, preserving order > is likely to be important in other cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-831) proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5
[
https://issues.apache.org/jira/browse/PROTON-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim reassigned PROTON-831:
-
Assignee: Gordon Sim
> proton_tests.utils.SyncRequestResponseTest.test_request_response test fails
> on RHEL 5
> -
>
> Key: PROTON-831
> URL: https://issues.apache.org/jira/browse/PROTON-831
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.9
> Environment: RHEL 5
>Reporter: Irina Boverman
>Assignee: Gordon Sim
>Priority: Minor
> Attachments: PROTON-831.patch
>
>
> proton_tests.utils.SyncRequestResponseTest.test_request_response fail
> Error during test: Traceback (most recent call last):
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton-test",
> line 355, in run
> phase()
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py",
> line 92, in test_request_response
> test("foo") # Simple request/resposne
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py",
> line 82, in test
> response = client.call(Message(address=address, body=body))
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py",
> line 315, in call
> self.sender.send(request)
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py",
> line 76, in send
> delivery = self.link.send(msg)
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py",
> line 2845, in send
> return obj.send(self, tag=tag)
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py",
> line 1098, in send
> dlv = sender.delivery(tag or sender.delivery_tag())
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py",
> line 2858, in delivery_tag
> return next(self.tag_generator)
> NameError: global name 'next' is not defined
> Suggested fix (contributed by Ted Ross):
> Seems the "next" builtin function was introduced in Python 2.6. Perhaps
> this should be changed to:
> return self.tag_generator.next()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PROTON-831) proton_tests.utils.SyncRequestResponseTest.test_request_response test fails on RHEL 5
[
https://issues.apache.org/jira/browse/PROTON-831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-831.
---
Resolution: Fixed
Fix Version/s: 0.9
> proton_tests.utils.SyncRequestResponseTest.test_request_response test fails
> on RHEL 5
> -
>
> Key: PROTON-831
> URL: https://issues.apache.org/jira/browse/PROTON-831
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.9
> Environment: RHEL 5
>Reporter: Irina Boverman
>Assignee: Gordon Sim
>Priority: Minor
> Fix For: 0.9
>
> Attachments: PROTON-831.patch
>
>
> proton_tests.utils.SyncRequestResponseTest.test_request_response fail
> Error during test: Traceback (most recent call last):
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton-test",
> line 355, in run
> phase()
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py",
> line 92, in test_request_response
> test("foo") # Simple request/resposne
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/tests/python/proton_tests/utils.py",
> line 82, in test
> response = client.call(Message(address=address, body=body))
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py",
> line 315, in call
> self.sender.send(request)
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/utils.py",
> line 76, in send
> delivery = self.link.send(msg)
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py",
> line 2845, in send
> return obj.send(self, tag=tag)
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py",
> line 1098, in send
> dlv = sender.delivery(tag or sender.delivery_tag())
> File
> "/var/lib/jenkins/workspace/proton/label/rhel5-64/proton-c/bindings/python/proton/__init__.py",
> line 2858, in delivery_tag
> return next(self.tag_generator)
> NameError: global name 'next' is not defined
> Suggested fix (contributed by Ted Ross):
> Seems the "next" builtin function was introduced in Python 2.6. Perhaps
> this should be changed to:
> return self.tag_generator.next()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-841) C recv example does not return disposition state
[ https://issues.apache.org/jira/browse/PROTON-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14378178#comment-14378178 ] Gordon Sim commented on PROTON-841: --- You can set the incoming window for messenger and then accept (or reject) explicitly. FWIW what the qpid c++ broker does in the case described is treat the settlement as positive acknowledgement (i.e. as accept) if no explicit disposition is specified. > C recv example does not return disposition state > > > Key: PROTON-841 > URL: https://issues.apache.org/jira/browse/PROTON-841 > Project: Qpid Proton > Issue Type: Bug >Reporter: Matt Broadstone > > I apologize that I can't dig deeper into this for you, but I'm pressed for > time and figured it would still be meaningful feedback. I was recently > testing the rabbitmq amqp1.0 module against a number of amqp 1.0 clients, and > realized that when using the send/recv examples for the messenger api in > proton my recv client was disconnecting immediately after receiving a > message. > I submitted this > [issue](https://github.com/rabbitmq/rabbitmq-amqp1.0/issues/8) to rabbitmq's > github and we traced the issue down to the fact that proton was not sending > back a state in the settled disposition frame upon receipt of the message > from the "send" client. The spec is incredibly ambiguous about what to do in > this scenario for brokers, and specifies that state is an optional field, but > at the same time the broker has no idea whether the message has been > acknowledged or rejects, simply that it has been settled. > Not sure how you guys want to go about this in your project, rabbitmq > gracefully handles this problem by closing the channel at this point (rather > than crashing as it did previously). > Anyway, just letting you know! > Cheers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-846) error on disconnect or failure to connect
Gordon Sim created PROTON-846: - Summary: error on disconnect or failure to connect Key: PROTON-846 URL: https://issues.apache.org/jira/browse/PROTON-846 Project: Qpid Proton Issue Type: Bug Components: python-binding Reporter: Gordon Sim Assignee: Gordon Sim Affects the 'reactor' type examples post 0.9 release (there is as yet no version available for selection after that). E.g. $ ./simple_send.py Traceback (most recent call last): File "./simple_send.py", line 61, in Container(Send(opts.address, opts.messages)).run() File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/reactor.py", line 120, in run while self.process(): pass File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/reactor.py", line 143, in process self._check_errors() File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", line 3735, in dispatch ev.dispatch(self.handler) File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", line 3663, in dispatch self.dispatch(h, type) File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", line 3660, in dispatch result = dispatch(handler, type.method, self) File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", line 3549, in dispatch return m(*args) File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/handlers.py", line 373, in on_transport_closed if self.delegate and self.is_local_open(event.transport.connection): File "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/handlers.py", line 210, in is_local_open return endpoint.state & Endpoint.LOCAL_ACTIVE AttributeError: 'NoneType' object has no attribute 'state' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-846) error on disconnect or failure to connect
[ https://issues.apache.org/jira/browse/PROTON-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-846. --- Resolution: Fixed This error did not appear in any released version. > error on disconnect or failure to connect > - > > Key: PROTON-846 > URL: https://issues.apache.org/jira/browse/PROTON-846 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Gordon Sim >Assignee: Gordon Sim > > Affects the 'reactor' type examples post 0.9 release (there is as yet no > version available for selection after that). E.g. > $ ./simple_send.py > Traceback (most recent call last): > File "./simple_send.py", line 61, in > Container(Send(opts.address, opts.messages)).run() > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/reactor.py", > line 120, in run > while self.process(): pass > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/reactor.py", > line 143, in process > self._check_errors() > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", > line 3735, in dispatch > ev.dispatch(self.handler) > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", > line 3663, in dispatch > self.dispatch(h, type) > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", > line 3660, in dispatch > result = dispatch(handler, type.method, self) > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/__init__.py", > line 3549, in dispatch > return m(*args) > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/handlers.py", > line 373, in on_transport_closed > if self.delegate and self.is_local_open(event.transport.connection): > File > "/home/gordon/projects/proton-git/installs/master/lib64/proton/bindings/python/proton/handlers.py", > line 210, in is_local_open > return endpoint.state & Endpoint.LOCAL_ACTIVE > AttributeError: 'NoneType' object has no attribute 'state' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-850) link state is incorrect after detach and reattach with same name
Gordon Sim created PROTON-850: - Summary: link state is incorrect after detach and reattach with same name Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim See also QPID=6320 If a peer closes a link, then opens another with the same name, at the point the new PN_LINK_REMOTE_OPEN event is emitted, the link state for the lnk associated with that event is 20 (i.e. LOCAL_CLOSED and REMOTE_ACTIVE). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-850) link state is incorrect after detach and reattach with same name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14496861#comment-14496861 ] Gordon Sim commented on PROTON-850: --- Actually, this is not really a bug as described. The local state *is* closed. If the link is freed before the second attach comes in, a new link object is created. However if not, the original link appears to get used and even if you then open it again, the attach is not sent out. > link state is incorrect after detach and reattach with same name > > > Key: PROTON-850 > URL: https://issues.apache.org/jira/browse/PROTON-850 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 >Reporter: Gordon Sim > > See also QPID=6320 > If a peer closes a link, then opens another with the same name, at the point > the new PN_LINK_REMOTE_OPEN event is emitted, the link state for the lnk > associated with that event is 20 (i.e. LOCAL_CLOSED and REMOTE_ACTIVE). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-850: -- Component/s: python-binding Description: If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. was: See also QPID=6320 If a peer closes a link, then opens another with the same name, at the point the new PN_LINK_REMOTE_OPEN event is emitted, the link state for the lnk associated with that event is 20 (i.e. LOCAL_CLOSED and REMOTE_ACTIVE). Summary: inconsistent state when reusing link name (was: link state is incorrect after detach and reattach with same name) > inconsistent state when reusing link name > - > > Key: PROTON-850 > URL: https://issues.apache.org/jira/browse/PROTON-850 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim > > If a link is closed, and a new link with the same name is created and opened, > the attach received for the second link from the peer is applied to the old > link. > If the old link is freed after being closed, this is avoided, but I'm not > sure that is possible via e.g. the python bindings. > The root of the problem I think is that a handle is reused after the link is > closed, whether freed or not, but when processing an incoming attach, it is > the link name that is used to find the appropriate link, which iterates > through all links until it matches one by name, which in this case is the > old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-850) inconsistent state when reusing link name
[
https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated PROTON-850:
--
Attachment: PROTON_850.py
This is an example using the plain reactor api, that follows the same pattern
as the reproducer attached to QPID-6320. Sample output as follows:
{noformat}
PN_LINK_LOCAL_OPEN()
[0x22134f0]: -> SASL
[0x22134f0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
[0x22134f0]: <- SASL
[0x22134f0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x22134f0]:0 <- @sasl-outcome(68) [code=0]
[0x22134f0]: -> AMQP
[0x22134f0]:0 -> @open(16) [container-id="", hostname="localhost"]
[0x22134f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]: <- AMQP
[0x22134f0]:0 <- @open(16) [container-id="ba1d5e12-b282-491c-965d-32fd9bd44ab1"]
[0x22134f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN()
PN_LINK_FLOW()
[0x22134f0]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1",
message-format=0, settled=true, more=false] (75)
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa0\x09message-0"
[0x22134f0]:0 -> @detach(22) [handle=0, closed=true]
PN_LINK_LOCAL_CLOSE()
PN_LINK_FLOW()
[0x22134f0]:0 <- @detach(22) [handle=0, closed=true]
PN_LINK_REMOTE_CLOSE()
PN_LINK_LOCAL_OPEN()
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=1, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN()
PN_LINK_FLOW()
{noformat}
> inconsistent state when reusing link name
> -
>
> Key: PROTON-850
> URL: https://issues.apache.org/jira/browse/PROTON-850
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c, python-binding
>Affects Versions: 0.9
>Reporter: Gordon Sim
> Attachments: PROTON_850.py
>
>
> If a link is closed, and a new link with the same name is created and opened,
> the attach received for the second link from the peer is applied to the old
> link.
> If the old link is freed after being closed, this is avoided, but I'm not
> sure that is possible via e.g. the python bindings.
> The root of the problem I think is that a handle is reused after the link is
> closed, whether freed or not, but when processing an incoming attach, it is
> the link name that is used to find the appropriate link, which iterates
> through all links until it matches one by name, which in this case is the
> old, closed link.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PROTON-850) inconsistent state when reusing link name
[
https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498365#comment-14498365
]
Gordon Sim edited comment on PROTON-850 at 4/16/15 5:43 PM:
This is an example using the plain reactor api, that follows the same pattern
as the reproducer attached to QPID-6320. Sample output as follows:
{noformat}
PN_LINK_LOCAL_OPEN()
[0x22134f0]: -> SASL
[0x22134f0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
[0x22134f0]: <- SASL
[0x22134f0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x22134f0]:0 <- @sasl-outcome(68) [code=0]
[0x22134f0]: -> AMQP
[0x22134f0]:0 -> @open(16) [container-id="", hostname="localhost"]
[0x22134f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]: <- AMQP
[0x22134f0]:0 <- @open(16) [container-id="ba1d5e12-b282-491c-965d-32fd9bd44ab1"]
[0x22134f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN()
PN_LINK_FLOW()
[0x22134f0]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1",
message-format=0, settled=true, more=false] (75)
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa0\x09message-0"
[0x22134f0]:0 -> @detach(22) [handle=0, closed=true]
PN_LINK_LOCAL_CLOSE()
PN_LINK_FLOW()
[0x22134f0]:0 <- @detach(22) [handle=0, closed=true]
PN_LINK_REMOTE_CLOSE()
PN_LINK_LOCAL_OPEN()
Note a new link object associated with the local open
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=1, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN()
but the remote is associated with the old link object
PN_LINK_FLOW()
{noformat}
was (Author: gsim):
This is an example using the plain reactor api, that follows the same pattern
as the reproducer attached to QPID-6320. Sample output as follows:
{noformat}
PN_LINK_LOCAL_OPEN()
[0x22134f0]: -> SASL
[0x22134f0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b""]
[0x22134f0]: <- SASL
[0x22134f0]:0 <- @sasl-mechanisms(64)
[sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :PLAIN]]
[0x22134f0]:0 <- @sasl-outcome(68) [code=0]
[0x22134f0]: -> AMQP
[0x22134f0]:0 -> @open(16) [container-id="", hostname="localhost"]
[0x22134f0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647,
outgoing-window=0]
[0x22134f0]:0 -> @attach(18) [name="sender", handle=0, role=false,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]: <- AMQP
[0x22134f0]:0 <- @open(16) [container-id="ba1d5e12-b282-491c-965d-32fd9bd44ab1"]
[0x22134f0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
incoming-window=2147483647, outgoing-window=0]
[0x22134f0]:0 <- @attach(18) [name="sender", handle=0, role=true,
snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0,
dynamic=false], target=@target(41) [address="queue", durable=0, timeout=0,
dynamic=false], initial-delivery-count=0]
[0x22134f0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647,
next-outgoing-id=0, outgoing-window=0, handle=0, delivery-count=0,
link-credit=500, drain=false]
PN_LINK_REMOTE_OPEN()
PN_LINK_FLOW()
[0x22134f0]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"1",
message-format=0, settl
[jira] [Issue Comment Deleted] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-850: -- Comment: was deleted (was: Actually, this is not really a bug as described. The local state *is* closed. If the link is freed before the second attach comes in, a new link object is created. However if not, the original link appears to get used and even if you then open it again, the attach is not sent out.) > inconsistent state when reusing link name > - > > Key: PROTON-850 > URL: https://issues.apache.org/jira/browse/PROTON-850 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim > Attachments: PROTON_850.py > > > If a link is closed, and a new link with the same name is created and opened, > the attach received for the second link from the peer is applied to the old > link. > If the old link is freed after being closed, this is avoided, but I'm not > sure that is possible via e.g. the python bindings. > The root of the problem I think is that a handle is reused after the link is > closed, whether freed or not, but when processing an incoming attach, it is > the link name that is used to find the appropriate link, which iterates > through all links until it matches one by name, which in this case is the > old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14499658#comment-14499658 ] Gordon Sim commented on PROTON-850: --- Proposed fix: https://reviews.apache.org/r/33300/ > inconsistent state when reusing link name > - > > Key: PROTON-850 > URL: https://issues.apache.org/jira/browse/PROTON-850 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim > Attachments: PROTON_850.py > > > If a link is closed, and a new link with the same name is created and opened, > the attach received for the second link from the peer is applied to the old > link. > If the old link is freed after being closed, this is avoided, but I'm not > sure that is possible via e.g. the python bindings. > The root of the problem I think is that a handle is reused after the link is > closed, whether freed or not, but when processing an incoming attach, it is > the link name that is used to find the appropriate link, which iterates > through all links until it matches one by name, which in this case is the > old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-858) unbalanced maps can get corrupted
Gordon Sim created PROTON-858: - Summary: unbalanced maps can get corrupted Key: PROTON-858 URL: https://issues.apache.org/jira/browse/PROTON-858 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim Priority: Critical I came across an issue caused by proton's inability to find a delivery for the id specified in a disposition it received, although the delivery with that id did indeed exist. On further analysis, it appears that maps that are not well balanced can get corrupted, such that the lookup function fails, even when the map 'contains' an entry with the required key. When adding an entry whose key maps to the same addressable index in the map as an existing entry, a free entry is taken from the end of the list and linked to that existing entry. However if all the entries outside the addressable range are used - and since addressable = 0.86*capacity, there are actually not that many of those - then a free entry from the addressable range is used for a key that does not map to that index. This can then lead to a situation where the deletion of an entry causes another to become unfindable. (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to 12) are addressable, last three (indices 13, 14 and 15) are not. Add value a with key 1, value b with key 2, value c with key 3. These take the first three addressable entries respectively. Now add items that map to those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with key 16. The three free non-addressable entries at the end are used for these i.e. indices 15, 14 and 13 respectively, and they are linked to the first three entries (at indices 1, 2 and 3 respectively). Now add d with key 4, which takes the 4th addressable index, then add d2 with key 17, which maps to the same addressable index. We take the next free entry which is at index 12 - *inside* the addressable range - set the key to 10, value to d2 and link it to the entry at index 4. Now delete key 17, which is at index 15. Then add value n with key 12. Index 12 is already taken by d2, so we use the newly vacated entry at index15 and link that to the end of d2 at index 12. Now we delete key 20 at index 12. Its the middle link in a chain of three so we join the previous entry - d at index 4 to the next entry n at index 15. Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14506923#comment-14506923 ] Gordon Sim commented on PROTON-858: --- Note that in example above, size is never greater than 8, so load is at most 0.5 and expansion is never necessary. Note also that although the description says 'unbalanced', it doesn't require a huge imbalance for there to be problems, just an 'unlucky' sequence. > unbalanced maps can get corrupted > - > > Key: PROTON-858 > URL: https://issues.apache.org/jira/browse/PROTON-858 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 >Reporter: Gordon Sim >Priority: Critical > > I came across an issue caused by proton's inability to find a delivery for > the id specified in a disposition it received, although the delivery with > that id did indeed exist. > On further analysis, it appears that maps that are not well balanced can get > corrupted, such that the lookup function fails, even when the map 'contains' > an entry with the required key. > When adding an entry whose key maps to the same addressable index in the map > as an existing entry, a free entry is taken from the end of the list and > linked to that existing entry. However if all the entries outside the > addressable range are used - and since addressable = 0.86*capacity, there are > actually not that many of those - then a free entry from the addressable > range is used for a key that does not map to that index. This can then lead > to a situation where the deletion of an entry causes another to become > unfindable. > (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to > 12) are addressable, last three (indices 13, 14 and 15) are not. > Add value a with key 1, value b with key 2, value c with key 3. These take > the first three addressable entries respectively. Now add items that map to > those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with > key 16. The three free non-addressable entries at the end are used for these > i.e. indices 15, 14 and 13 respectively, and they are linked to the first > three entries (at indices 1, 2 and 3 respectively). > Now add d with key 4, which takes the 4th addressable index, then add d2 with > key 17, which maps to the same addressable index. We take the next free entry > which is at index 12 - *inside* the addressable range - set the key to 10, > value to d2 and link it to the entry at index 4. > Now delete key 17, which is at index 15. Then add value n with key 12. Index > 12 is already taken by d2, so we use the newly vacated entry at index15 and > link that to the end of d2 at index 12. > Now we delete key 20 at index 12. Its the middle link in a chain of three so > we join the previous entry - d at index 4 to the next entry n at index 15. > Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-859) cyrus sasl not compatible with pre 2.1.24 versions
Gordon Sim created PROTON-859: - Summary: cyrus sasl not compatible with pre 2.1.24 versions Key: PROTON-859 URL: https://issues.apache.org/jira/browse/PROTON-859 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Gordon Sim Assignee: Andrew Stitcher sasl_client_done/sasl_server_done are not available (sasl_done is) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-850. --- Resolution: Fixed Fix Version/s: 0.10 Assignee: Gordon Sim > inconsistent state when reusing link name > - > > Key: PROTON-850 > URL: https://issues.apache.org/jira/browse/PROTON-850 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.10 > > Attachments: PROTON_850.py > > > If a link is closed, and a new link with the same name is created and opened, > the attach received for the second link from the peer is applied to the old > link. > If the old link is freed after being closed, this is avoided, but I'm not > sure that is possible via e.g. the python bindings. > The root of the problem I think is that a handle is reused after the link is > closed, whether freed or not, but when processing an incoming attach, it is > the link name that is used to find the appropriate link, which iterates > through all links until it matches one by name, which in this case is the > old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-860) make ssl config for acceptor configurable
Gordon Sim created PROTON-860: - Summary: make ssl config for acceptor configurable Key: PROTON-860 URL: https://issues.apache.org/jira/browse/PROTON-860 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 Before it wrapped the c-reactor, the Container.listen() method allowed an ssl domain object to be passed to configure handling of incoming connections (or it could indeed use the container.ssl.server defaults). Need to update the current code to get that functionality working again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-861) need to get at aspect of the client certificate when for authenticated clients
Gordon Sim created PROTON-861: - Summary: need to get at aspect of the client certificate when for authenticated clients Key: PROTON-861 URL: https://issues.apache.org/jira/browse/PROTON-861 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 e.g. in order to do authorisation or whatever based on the authenticated identity -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514059#comment-14514059 ] Gordon Sim commented on PROTON-858: --- As it turns out the use of the addressable region for entries that don't actually map there is *intended* and is a technique known as coalesced hashing. The error then is on the delete algorithm. > unbalanced maps can get corrupted > - > > Key: PROTON-858 > URL: https://issues.apache.org/jira/browse/PROTON-858 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 >Reporter: Gordon Sim >Priority: Critical > Fix For: 0.9.1 > > > I came across an issue caused by proton's inability to find a delivery for > the id specified in a disposition it received, although the delivery with > that id did indeed exist. > On further analysis, it appears that maps that are not well balanced can get > corrupted, such that the lookup function fails, even when the map 'contains' > an entry with the required key. > When adding an entry whose key maps to the same addressable index in the map > as an existing entry, a free entry is taken from the end of the list and > linked to that existing entry. However if all the entries outside the > addressable range are used - and since addressable = 0.86*capacity, there are > actually not that many of those - then a free entry from the addressable > range is used for a key that does not map to that index. This can then lead > to a situation where the deletion of an entry causes another to become > unfindable. > (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to > 12) are addressable, last three (indices 13, 14 and 15) are not. > Add value a with key 1, value b with key 2, value c with key 3. These take > the first three addressable entries respectively. Now add items that map to > those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with > key 16. The three free non-addressable entries at the end are used for these > i.e. indices 15, 14 and 13 respectively, and they are linked to the first > three entries (at indices 1, 2 and 3 respectively). > Now add d with key 4, which takes the 4th addressable index, then add d2 with > key 17, which maps to the same addressable index. We take the next free entry > which is at index 12 - *inside* the addressable range - set the key to 10, > value to d2 and link it to the entry at index 4. > Now delete key 17, which is at index 15. Then add value n with key 12. Index > 12 is already taken by d2, so we use the newly vacated entry at index15 and > link that to the end of d2 at index 12. > Now we delete key 20 at index 12. Its the middle link in a chain of three so > we join the previous entry - d at index 4 to the next entry n at index 15. > Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14516805#comment-14516805 ] Gordon Sim commented on PROTON-858: --- I've posted a fix here: https://reviews.apache.org/r/33623/. This is I think the simplest possible, though it can be optimised further. > unbalanced maps can get corrupted > - > > Key: PROTON-858 > URL: https://issues.apache.org/jira/browse/PROTON-858 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 >Reporter: Gordon Sim >Priority: Critical > Fix For: 0.9.1 > > > I came across an issue caused by proton's inability to find a delivery for > the id specified in a disposition it received, although the delivery with > that id did indeed exist. > On further analysis, it appears that maps that are not well balanced can get > corrupted, such that the lookup function fails, even when the map 'contains' > an entry with the required key. > When adding an entry whose key maps to the same addressable index in the map > as an existing entry, a free entry is taken from the end of the list and > linked to that existing entry. However if all the entries outside the > addressable range are used - and since addressable = 0.86*capacity, there are > actually not that many of those - then a free entry from the addressable > range is used for a key that does not map to that index. This can then lead > to a situation where the deletion of an entry causes another to become > unfindable. > (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to > 12) are addressable, last three (indices 13, 14 and 15) are not. > Add value a with key 1, value b with key 2, value c with key 3. These take > the first three addressable entries respectively. Now add items that map to > those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with > key 16. The three free non-addressable entries at the end are used for these > i.e. indices 15, 14 and 13 respectively, and they are linked to the first > three entries (at indices 1, 2 and 3 respectively). > Now add d with key 4, which takes the 4th addressable index, then add d2 with > key 17, which maps to the same addressable index. We take the next free entry > which is at index 12 - *inside* the addressable range - set the key to 10, > value to d2 and link it to the entry at index 4. > Now delete key 17, which is at index 15. Then add value n with key 12. Index > 12 is already taken by d2, so we use the newly vacated entry at index15 and > link that to the end of d2 at index 12. > Now we delete key 20 at index 12. Its the middle link in a chain of three so > we join the previous entry - d at index 4 to the next entry n at index 15. > Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-876) python examples installed under share are not executable
Gordon Sim created PROTON-876: - Summary: 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.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-858. --- Resolution: Fixed Fix Version/s: (was: 0.9.1) 0.10 Assignee: Gordon Sim > unbalanced maps can get corrupted > - > > Key: PROTON-858 > URL: https://issues.apache.org/jira/browse/PROTON-858 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.9 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Critical > Fix For: 0.10 > > > I came across an issue caused by proton's inability to find a delivery for > the id specified in a disposition it received, although the delivery with > that id did indeed exist. > On further analysis, it appears that maps that are not well balanced can get > corrupted, such that the lookup function fails, even when the map 'contains' > an entry with the required key. > When adding an entry whose key maps to the same addressable index in the map > as an existing entry, a free entry is taken from the end of the list and > linked to that existing entry. However if all the entries outside the > addressable range are used - and since addressable = 0.86*capacity, there are > actually not that many of those - then a free entry from the addressable > range is used for a key that does not map to that index. This can then lead > to a situation where the deletion of an entry causes another to become > unfindable. > (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to > 12) are addressable, last three (indices 13, 14 and 15) are not. > Add value a with key 1, value b with key 2, value c with key 3. These take > the first three addressable entries respectively. Now add items that map to > those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with > key 16. The three free non-addressable entries at the end are used for these > i.e. indices 15, 14 and 13 respectively, and they are linked to the first > three entries (at indices 1, 2 and 3 respectively). > Now add d with key 4, which takes the 4th addressable index, then add d2 with > key 17, which maps to the same addressable index. We take the next free entry > which is at index 12 - *inside* the addressable range - set the key to 10, > value to d2 and link it to the entry at index 4. > Now delete key 17, which is at index 15. Then add value n with key 12. Index > 12 is already taken by d2, so we use the newly vacated entry at index15 and > link that to the end of d2 at index 12. > Now we delete key 20 at index 12. Its the middle link in a chain of three so > we join the previous entry - d at index 4 to the next entry n at index 15. > Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-860) make ssl config for acceptor configurable
[ https://issues.apache.org/jira/browse/PROTON-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531007#comment-14531007 ] Gordon Sim commented on PROTON-860: --- Patch for review: https://reviews.apache.org/r/33902/ > make ssl config for acceptor configurable > - > > Key: PROTON-860 > URL: https://issues.apache.org/jira/browse/PROTON-860 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.10 > > > Before it wrapped the c-reactor, the Container.listen() method allowed an ssl > domain object to be passed to configure handling of incoming connections (or > it could indeed use the container.ssl.server defaults). > Need to update the current code to get that functionality working again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-880) make Array iterable
Gordon Sim created PROTON-880: - Summary: make Array iterable Key: PROTON-880 URL: https://issues.apache.org/jira/browse/PROTON-880 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 Handy for e.g. offered capabilities (avoids having to explicitly use elements). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-880) make Array iterable
[ https://issues.apache.org/jira/browse/PROTON-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-880. --- Resolution: Fixed > make Array iterable > --- > > Key: PROTON-880 > URL: https://issues.apache.org/jira/browse/PROTON-880 > 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 > > > Handy for e.g. offered capabilities (avoids having to explicitly use > elements). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-860) make ssl config for acceptor configurable
[ https://issues.apache.org/jira/browse/PROTON-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-860. --- Resolution: Pending Closed > make ssl config for acceptor configurable > - > > Key: PROTON-860 > URL: https://issues.apache.org/jira/browse/PROTON-860 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.10 > > > Before it wrapped the c-reactor, the Container.listen() method allowed an ssl > domain object to be passed to configure handling of incoming connections (or > it could indeed use the container.ssl.server defaults). > Need to update the current code to get that functionality working again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-861) need to get at aspect of the client certificate when for authenticated clients
[ https://issues.apache.org/jira/browse/PROTON-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14544260#comment-14544260 ] Gordon Sim commented on PROTON-861: --- proposal available for review here: https://reviews.apache.org/r/34229/ > need to get at aspect of the client certificate when for authenticated clients > -- > > Key: PROTON-861 > URL: https://issues.apache.org/jira/browse/PROTON-861 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.10 > > > e.g. in order to do authorisation or whatever based on the authenticated > identity -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-861) need to get at aspect of the client certificate when for authenticated clients
[
https://issues.apache.org/jira/browse/PROTON-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim resolved PROTON-861.
---
Resolution: Fixed
The subject from the peer's certificate is now available through the ssl object
associated with the transport, so e.g.
{noformat}
def on_connection_opening(self, event):
ssl = event.transport.ssl()
if ssl:
print "%s connected" % ssl.remote_subject
{noformat}
> need to get at aspect of the client certificate when for authenticated clients
> --
>
> Key: PROTON-861
> URL: https://issues.apache.org/jira/browse/PROTON-861
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: 0.9
>Reporter: Gordon Sim
>Assignee: Gordon Sim
> Fix For: 0.10
>
>
> e.g. in order to do authorisation or whatever based on the authenticated
> identity
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-901) No constants defined for Termins.expiry_policy
Gordon Sim created PROTON-901: - Summary: No constants defined for Termins.expiry_policy Key: PROTON-901 URL: https://issues.apache.org/jira/browse/PROTON-901 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9, 0.10 Reporter: Gordon Sim Assignee: Gordon Sim Priority: Minor Fix For: 0.10 The other c enumerations have python constants defined for them, but not pn_expiry_policy_t. This means applications either have to use magic numbers based on reading the .h or import from cproton which is ugly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-901) No constants defined for Termins.expiry_policy
[ https://issues.apache.org/jira/browse/PROTON-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved PROTON-901. --- Resolution: Fixed > No constants defined for Termins.expiry_policy > -- > > Key: PROTON-901 > URL: https://issues.apache.org/jira/browse/PROTON-901 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.10 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > Fix For: 0.10 > > > The other c enumerations have python constants defined for them, but not > pn_expiry_policy_t. This means applications either have to use magic numbers > based on reading the .h or import from cproton which is ugly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-901) No constants defined for Terminus.expiry_policy
[ https://issues.apache.org/jira/browse/PROTON-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim updated PROTON-901: -- Summary: No constants defined for Terminus.expiry_policy (was: No constants defined for Termins.expiry_policy) > No constants defined for Terminus.expiry_policy > --- > > Key: PROTON-901 > URL: https://issues.apache.org/jira/browse/PROTON-901 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9, 0.10 >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Minor > Fix For: 0.10 > > > The other c enumerations have python constants defined for them, but not > pn_expiry_policy_t. This means applications either have to use magic numbers > based on reading the .h or import from cproton which is ugly. -- 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)
[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] [Created] (PROTON-906) Would be nice to make durable subscriptions simpler
Gordon Sim created PROTON-906: - Summary: 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-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)
