[jira] [Updated] (PROTON-302) Messenger does not verify the hostname in the peer's SSL certificate.
[ https://issues.apache.org/jira/browse/PROTON-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-302: --- Fix Version/s: 0.6 > Messenger does not verify the hostname in the peer's SSL certificate. > - > > Key: PROTON-302 > URL: https://issues.apache.org/jira/browse/PROTON-302 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Blocker > Fix For: 0.6 > > > When Messenger is configured to use SSL, and a CA database is provided (via > set_trusted_certificates), messenger fails to check that the > CommonName/Subject Alternate Name provided in the peer's certificate. > Currently, it merely validates that the certificate is signed correctly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (PROTON-302) Messenger does not verify the hostname in the peer's SSL certificate.
[ https://issues.apache.org/jira/browse/PROTON-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-302: -- Assignee: Rafael H. Schloming (was: Ken Giusti) > Messenger does not verify the hostname in the peer's SSL certificate. > - > > Key: PROTON-302 > URL: https://issues.apache.org/jira/browse/PROTON-302 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 >Reporter: Ken Giusti >Assignee: Rafael H. Schloming >Priority: Blocker > Fix For: 0.6 > > > When Messenger is configured to use SSL, and a CA database is provided (via > set_trusted_certificates), messenger fails to check that the > CommonName/Subject Alternate Name provided in the peer's certificate. > Currently, it merely validates that the certificate is signed correctly. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-255) Messenger stall in send(): frames buffered in transport not written to driver.
[ https://issues.apache.org/jira/browse/PROTON-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-255. Resolution: Fixed Fix Version/s: 0.5 > Messenger stall in send(): frames buffered in transport not written to driver. > -- > > Key: PROTON-255 > URL: https://issues.apache.org/jira/browse/PROTON-255 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Priority: Blocker > Fix For: 0.5 > > > I've created a simple "ping-pong" test between two Messenger clients. One > client sends 10k messages to the other, which replies. The test stalls after > sending 10 messages in each direction, which is the value used for link > credit. > The cause of the problem is that the FLOW frame sent by one client is not be > received by the other. The failure is due to the FLOW frame remaining > buffered in the sender's transport buffer, not being written to the driver. > The driver is waiting for socket activity, and never "sees" the pending > output sitting in the transport. > This bug appears to have been introduced by PROTON-225 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-33) Provide API for user managed pn_message_t payload/memory
[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-33: -- Priority: Major (was: Blocker) > Provide API for user managed pn_message_t payload/memory > > > Key: PROTON-33 > URL: https://issues.apache.org/jira/browse/PROTON-33 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: William Henry > Labels: api > > Some users will have their own frameworks and methods of managing the data > received. > Currently in the pn_message_t the only way to get at the payload/data is to > call pn_message_save with a pre-allocated buffer of data. pn_message_save > copies to that data buffer and returns the actual size. (so for example if I > passed an allocated buffer of 1028 I might be returned 8 bytes). > In many situations this alloc is expensive - especially when integrating with > established frameworks that already do the copy - now there are two allocs. > I suggest an API call that returns the message payload as a pointer. There > is a risk that this might get deleted and a pn_message_t should check that > it's buffer is still valid (I assume it would.) In the case I'm looking at > the "other" framework is merely making it's own copy but doesn't free the > memory (but, as I said, there is a risk it could). > I'm willing to debate pn_message_t having an API that returns a copy but I > imagine many users will any up complaining about the alloc in the that API > call. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-33) Provide API for user managed pn_message_t payload/memory
[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-33: -- Issue Type: New Feature (was: Bug) > Provide API for user managed pn_message_t payload/memory > > > Key: PROTON-33 > URL: https://issues.apache.org/jira/browse/PROTON-33 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: William Henry > Labels: api > > Some users will have their own frameworks and methods of managing the data > received. > Currently in the pn_message_t the only way to get at the payload/data is to > call pn_message_save with a pre-allocated buffer of data. pn_message_save > copies to that data buffer and returns the actual size. (so for example if I > passed an allocated buffer of 1028 I might be returned 8 bytes). > In many situations this alloc is expensive - especially when integrating with > established frameworks that already do the copy - now there are two allocs. > I suggest an API call that returns the message payload as a pointer. There > is a risk that this might get deleted and a pn_message_t should check that > it's buffer is still valid (I assume it would.) In the case I'm looking at > the "other" framework is merely making it's own copy but doesn't free the > memory (but, as I said, there is a risk it could). > I'm willing to debate pn_message_t having an API that returns a copy but I > imagine many users will any up complaining about the alloc in the that API > call. -- This message was sent by Atlassian JIRA (v6.1#6144)
[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 ] Rafael H. Schloming updated PROTON-62: -- Labels: api transactions (was: api) > 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-c, proton-j >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming >Priority: Blocker > 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.1#6144)
[jira] [Updated] (PROTON-152) SASL architecture does not support security layers
[ https://issues.apache.org/jira/browse/PROTON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-152: --- Issue Type: Improvement (was: Bug) > SASL architecture does not support security layers > -- > > Key: PROTON-152 > URL: https://issues.apache.org/jira/browse/PROTON-152 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross >Priority: Blocker > Labels: security > > SASL can optionally insert a security layer in the data stream for a > connection. The security layer encrypts/signs/decrypts the data stream. In > this way it is architecturally similar to SSL: It performs a handshake > in-the-clear and then inserts itself into the stream to provide link security. > Without this support, mechanisms like GSSAPI (Kerberos5) cannot be used. -- This message was sent by Atlassian JIRA (v6.1#6144)
[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 ] Rafael H. Schloming updated PROTON-62: -- Priority: Major (was: Blocker) > 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-c, 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.1#6144)
[jira] [Updated] (PROTON-152) SASL architecture does not support security layers
[ https://issues.apache.org/jira/browse/PROTON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-152: --- Priority: Major (was: Blocker) > SASL architecture does not support security layers > -- > > Key: PROTON-152 > URL: https://issues.apache.org/jira/browse/PROTON-152 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross > Labels: security > > SASL can optionally insert a security layer in the data stream for a > connection. The security layer encrypts/signs/decrypts the data stream. In > this way it is architecturally similar to SSL: It performs a handshake > in-the-clear and then inserts itself into the stream to provide link security. > Without this support, mechanisms like GSSAPI (Kerberos5) cannot be used. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-152) SASL architecture does not support security layers
[ https://issues.apache.org/jira/browse/PROTON-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-152: --- Labels: security (was: ) > SASL architecture does not support security layers > -- > > Key: PROTON-152 > URL: https://issues.apache.org/jira/browse/PROTON-152 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.2 >Reporter: Ted Ross >Priority: Blocker > Labels: security > > SASL can optionally insert a security layer in the data stream for a > connection. The security layer encrypts/signs/decrypts the data stream. In > this way it is architecturally similar to SSL: It performs a handshake > in-the-clear and then inserts itself into the stream to provide link security. > Without this support, mechanisms like GSSAPI (Kerberos5) cannot be used. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-439) Support for dynamic reply-to address in Messenger
[ https://issues.apache.org/jira/browse/PROTON-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-439: Fix Version/s: 0.6 > Support for dynamic reply-to address in Messenger > - > > Key: PROTON-439 > URL: https://issues.apache.org/jira/browse/PROTON-439 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.5 >Reporter: Ted Ross > Fix For: 0.6 > > > Messenger has no support for creating dynamic receivers for reply-to > addresses. Please refer to the following email thread for prior discussion > on the topic. > http://qpid.2158936.n2.nabble.com/Proton-Messenger-and-the-Request-Response-pattern-tp7586653.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-161: --- Labels: security (was: ) > SSL impl does not allow verification of the peer's identity > --- > > Key: PROTON-161 > URL: https://issues.apache.org/jira/browse/PROTON-161 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.3 >Reporter: Ken Giusti >Assignee: Philip Harvey >Priority: Blocker > Labels: security > > The current SSL implementation validates the peer's certificate, and will not > permit the connection to come up if the certificate is invalid. > However - it does not provide a way to check if the peer's identity as > provided in the certificate is the expected identity (eg, the same hostname > used to set up the TCP connection). While a certificate may be valid (that > is, signed by a CA trusted by the client), it may not belong to the intended > destination. > RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-161: --- Priority: Critical (was: Blocker) > SSL impl does not allow verification of the peer's identity > --- > > Key: PROTON-161 > URL: https://issues.apache.org/jira/browse/PROTON-161 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.3 >Reporter: Ken Giusti >Assignee: Philip Harvey >Priority: Critical > Labels: security > > The current SSL implementation validates the peer's certificate, and will not > permit the connection to come up if the certificate is invalid. > However - it does not provide a way to check if the peer's identity as > provided in the certificate is the expected identity (eg, the same hostname > used to set up the TCP connection). While a certificate may be valid (that > is, signed by a CA trusted by the client), it may not belong to the intended > destination. > RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-161) SSL impl does not allow verification of the peer's identity
[ https://issues.apache.org/jira/browse/PROTON-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-161: --- Issue Type: Improvement (was: Bug) > SSL impl does not allow verification of the peer's identity > --- > > Key: PROTON-161 > URL: https://issues.apache.org/jira/browse/PROTON-161 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.3 >Reporter: Ken Giusti >Assignee: Philip Harvey >Priority: Critical > Labels: security > > The current SSL implementation validates the peer's certificate, and will not > permit the connection to come up if the certificate is invalid. > However - it does not provide a way to check if the peer's identity as > provided in the certificate is the expected identity (eg, the same hostname > used to set up the TCP connection). While a certificate may be valid (that > is, signed by a CA trusted by the client), it may not belong to the intended > destination. > RFC2818 explains how this should be done - see section 3.1 Server Identity. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (PROTON-441) Provide hooks for alternative sources of Messenger routes
Ted Ross created PROTON-441: --- Summary: Provide hooks for alternative sources of Messenger routes Key: PROTON-441 URL: https://issues.apache.org/jira/browse/PROTON-441 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ted Ross Fix For: 0.6 This is a request to add the capability to set Messenger routes automatically on Messenger startup. Where the routes come from may be platform-specific (i.e. environment variables, configuration files, registries, network-based lookup, etc.). The desire is to allow Messenger applications to be wholly unaware of the route mappings that come from other sources. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-278) Messenger - allow the application to control the use of the message reply-to field.
[ https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-278: --- Labels: reply-to (was: ) > Messenger - allow the application to control the use of the message reply-to > field. > --- > > Key: PROTON-278 > URL: https://issues.apache.org/jira/browse/PROTON-278 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Priority: Blocker > Labels: reply-to > > Currently, messenger always sets the reply-to field in a sent message. > This should be changed to allow the application to set the reply-to field > only when a reply is desired. Messenger should be changed to not > unconditionally set this field. > In order to set this field in the case of a client that has not established a > subscription, the client needs to be able to query messenger for the proper > value of the reply-to address. A new api would need to be created for this. > Proposal: > int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg ) > Set the proper reply-to address in msg. msg would need to have its "to" > address configured in order for this method to succeed. > At least, I think the value for the reply-to may depend on the 'to' > address... I may be wrong about that > Opinions? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-278) Messenger - allow the application to control the use of the message reply-to field.
[ https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-278: --- Priority: Critical (was: Blocker) > Messenger - allow the application to control the use of the message reply-to > field. > --- > > Key: PROTON-278 > URL: https://issues.apache.org/jira/browse/PROTON-278 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Rafael H. Schloming >Priority: Critical > Labels: reply-to > Fix For: 0.6 > > > Currently, messenger always sets the reply-to field in a sent message. > This should be changed to allow the application to set the reply-to field > only when a reply is desired. Messenger should be changed to not > unconditionally set this field. > In order to set this field in the case of a client that has not established a > subscription, the client needs to be able to query messenger for the proper > value of the reply-to address. A new api would need to be created for this. > Proposal: > int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg ) > Set the proper reply-to address in msg. msg would need to have its "to" > address configured in order for this method to succeed. > At least, I think the value for the reply-to may depend on the 'to' > address... I may be wrong about that > Opinions? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (PROTON-278) Messenger - allow the application to control the use of the message reply-to field.
[ https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-278: -- Assignee: Rafael H. Schloming > Messenger - allow the application to control the use of the message reply-to > field. > --- > > Key: PROTON-278 > URL: https://issues.apache.org/jira/browse/PROTON-278 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Rafael H. Schloming >Priority: Blocker > Labels: reply-to > Fix For: 0.6 > > > Currently, messenger always sets the reply-to field in a sent message. > This should be changed to allow the application to set the reply-to field > only when a reply is desired. Messenger should be changed to not > unconditionally set this field. > In order to set this field in the case of a client that has not established a > subscription, the client needs to be able to query messenger for the proper > value of the reply-to address. A new api would need to be created for this. > Proposal: > int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg ) > Set the proper reply-to address in msg. msg would need to have its "to" > address configured in order for this method to succeed. > At least, I think the value for the reply-to may depend on the 'to' > address... I may be wrong about that > Opinions? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-278) Messenger - allow the application to control the use of the message reply-to field.
[ https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-278: --- Issue Type: Bug (was: Improvement) > Messenger - allow the application to control the use of the message reply-to > field. > --- > > Key: PROTON-278 > URL: https://issues.apache.org/jira/browse/PROTON-278 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Assignee: Rafael H. Schloming >Priority: Critical > Labels: reply-to > Fix For: 0.6 > > > Currently, messenger always sets the reply-to field in a sent message. > This should be changed to allow the application to set the reply-to field > only when a reply is desired. Messenger should be changed to not > unconditionally set this field. > In order to set this field in the case of a client that has not established a > subscription, the client needs to be able to query messenger for the proper > value of the reply-to address. A new api would need to be created for this. > Proposal: > int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg ) > Set the proper reply-to address in msg. msg would need to have its "to" > address configured in order for this method to succeed. > At least, I think the value for the reply-to may depend on the 'to' > address... I may be wrong about that > Opinions? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-278) Messenger - allow the application to control the use of the message reply-to field.
[ https://issues.apache.org/jira/browse/PROTON-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-278: --- Fix Version/s: 0.6 > Messenger - allow the application to control the use of the message reply-to > field. > --- > > Key: PROTON-278 > URL: https://issues.apache.org/jira/browse/PROTON-278 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ken Giusti >Priority: Blocker > Labels: reply-to > Fix For: 0.6 > > > Currently, messenger always sets the reply-to field in a sent message. > This should be changed to allow the application to set the reply-to field > only when a reply is desired. Messenger should be changed to not > unconditionally set this field. > In order to set this field in the case of a client that has not established a > subscription, the client needs to be able to query messenger for the proper > value of the reply-to address. A new api would need to be created for this. > Proposal: > int pn_messenger_set_reply( pn_messenger_t *msgr, pn_message_t *msg ) > Set the proper reply-to address in msg. msg would need to have its "to" > address configured in order for this method to succeed. > At least, I think the value for the reply-to may depend on the 'to' > address... I may be wrong about that > Opinions? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-323) Regression: Messenger sends "null" in disposition state after accept
[
https://issues.apache.org/jira/browse/PROTON-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming updated PROTON-323:
---
Fix Version/s: 0.6
> Regression: Messenger sends "null" in disposition state after accept
>
>
> Key: PROTON-323
> URL: https://issues.apache.org/jira/browse/PROTON-323
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Ted Ross
>Priority: Blocker
> Fix For: 0.6
>
>
> Using the following Python code snippet:
> from proton import *
> mng = Messenger()
> mng.start()
> mng.subscribe("amqp://0.0.0.0/Queue_1")
> mng.timeout=100
> mng.recv()
> msg = Message()
> t = mng.get(msg)
> mng.accept(t)
> mng.stop()
> The following trace is seen after the call to stop:
> [0xf7f6a0:1] -> DISPOSITION @21 [true, 0, 0, true, null]
> On Proton 0.4, this problem does not exist. The trace is:
> [0x1087bb0:1] -> DISPOSITION @21 [true, 0, 0, true, @36 []]
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (PROTON-356) PHP bindings are not built on MacOS 10.8
[ https://issues.apache.org/jira/browse/PROTON-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-356: --- Priority: Critical (was: Blocker) > PHP bindings are not built on MacOS 10.8 > > > Key: PROTON-356 > URL: https://issues.apache.org/jira/browse/PROTON-356 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: MacOS X 10.8, Homebrew >Reporter: Serge Smertin >Priority: Critical > > it's not possible to build PHP extension for MacOS, as it gives linking > error. Relates to issue - https://issues.apache.org/jira/browse/PROTON-108, > which is not resolved properly. > Short-term viable solution: > - Attach *.so files to this ticket for macos x exactly > Long-term solution: > - Make proper linking -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-356) PHP bindings are not built on MacOS 10.8
[ https://issues.apache.org/jira/browse/PROTON-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798246#comment-13798246 ] Rafael H. Schloming commented on PROTON-356: Do you have a patch file capturing what you did to get the build working? > PHP bindings are not built on MacOS 10.8 > > > Key: PROTON-356 > URL: https://issues.apache.org/jira/browse/PROTON-356 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: MacOS X 10.8, Homebrew >Reporter: Serge Smertin >Priority: Critical > > it's not possible to build PHP extension for MacOS, as it gives linking > error. Relates to issue - https://issues.apache.org/jira/browse/PROTON-108, > which is not resolved properly. > Short-term viable solution: > - Attach *.so files to this ticket for macos x exactly > Long-term solution: > - Make proper linking -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-39) Implement pn_offer for sender links
[ https://issues.apache.org/jira/browse/PROTON-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-39: -- Labels: api credit (was: api) > Implement pn_offer for sender links > --- > > Key: PROTON-39 > URL: https://issues.apache.org/jira/browse/PROTON-39 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c, proton-j >Reporter: Ted Ross > Labels: api, credit > Attachments: proton-39.patch > > > The proposed patch adds two functions to the engine API: > void pn_offer(link, credit) > bool pn_connection_links_writeable(conn) > pn_offer is used by the attached node to indicate to the engine that it has > messages available for immediate transfer over the link. > pn_connection_links_writable returns true if the connection has at least one > outgoing link with both receiver credit and offered credit. This is used by > the driver to ensure that the connection's FD (or equivalent) is in the set > of writable FDs to be processed it the outgoing transport is writable. > Note that pn_offer is absolute (not cumulative). The attached node is > responsible for keeping the offer vaule up-to-date as messages are sent and > received. > The patch does not make any changes to the protocol exchange. Additional > work is needed to communicate the offer information to the remote receiver so > the receiver can intelligently manage its credits. > The driving need for this change is for driver functionality. pn_offer is > the cleanest mechanism for a node to tell the driver that an outbound link's > connection should be processed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-39) Implement pn_offer for sender links
[ https://issues.apache.org/jira/browse/PROTON-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-39: -- Priority: Minor (was: Major) > Implement pn_offer for sender links > --- > > Key: PROTON-39 > URL: https://issues.apache.org/jira/browse/PROTON-39 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c, proton-j >Reporter: Ted Ross >Priority: Minor > Labels: api, credit > Attachments: proton-39.patch > > > The proposed patch adds two functions to the engine API: > void pn_offer(link, credit) > bool pn_connection_links_writeable(conn) > pn_offer is used by the attached node to indicate to the engine that it has > messages available for immediate transfer over the link. > pn_connection_links_writable returns true if the connection has at least one > outgoing link with both receiver credit and offered credit. This is used by > the driver to ensure that the connection's FD (or equivalent) is in the set > of writable FDs to be processed it the outgoing transport is writable. > Note that pn_offer is absolute (not cumulative). The attached node is > responsible for keeping the offer vaule up-to-date as messages are sent and > received. > The patch does not make any changes to the protocol exchange. Additional > work is needed to communicate the offer information to the remote receiver so > the receiver can intelligently manage its credits. > The driving need for this change is for driver functionality. pn_offer is > the cleanest mechanism for a node to tell the driver that an outbound link's > connection should be processed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-90) SSL: provide access to the certificate provided by the peer.
[ https://issues.apache.org/jira/browse/PROTON-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798259#comment-13798259 ] Rafael H. Schloming commented on PROTON-90: --- This feature is no longer necessary now that we do hostname authentication, and providing it would require exposing a lot of the low level details of the internal SSL implementation. For these reasons I'm going to close this as won't fix. > SSL: provide access to the certificate provided by the peer. > > > Key: PROTON-90 > URL: https://issues.apache.org/jira/browse/PROTON-90 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ken Giusti > > Currently, the SSL implementation merely verifies that the certificate > supplied by the remote is signed by the configured CA. There is no way to > extract information from that certificate - such as the CN, subject, etc. > It would be useful to provide an accessor api to get at the contents of the > certificate. This could be used by the application to, for example, verify > the CN and decide whether or not to close the connection. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-90) SSL: provide access to the certificate provided by the peer.
[ https://issues.apache.org/jira/browse/PROTON-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-90. --- Resolution: Won't Fix > SSL: provide access to the certificate provided by the peer. > > > Key: PROTON-90 > URL: https://issues.apache.org/jira/browse/PROTON-90 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ken Giusti > > Currently, the SSL implementation merely verifies that the certificate > supplied by the remote is signed by the configured CA. There is no way to > extract information from that certificate - such as the CN, subject, etc. > It would be useful to provide an accessor api to get at the contents of the > certificate. This could be used by the application to, for example, verify > the CN and decide whether or not to close the connection. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-165) SSL: provide access to the certificate provided by the peer (Java implementation)
[ https://issues.apache.org/jira/browse/PROTON-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-165. Resolution: Won't Fix See comment on PROTON-90. > SSL: provide access to the certificate provided by the peer (Java > implementation) > - > > Key: PROTON-165 > URL: https://issues.apache.org/jira/browse/PROTON-165 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Reporter: Philip Harvey > > This is the Java-equivalent of the change being made in PROTON-90 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798263#comment-13798263 ] Rafael H. Schloming commented on PROTON-236: Cliff, what's the status on this? > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-234) Add lots of logging to better understand inner working of proton
[ https://issues.apache.org/jira/browse/PROTON-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-234: --- Labels: logging (was: ) > Add lots of logging to better understand inner working of proton > > > Key: PROTON-234 > URL: https://issues.apache.org/jira/browse/PROTON-234 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Bozo Dragojevic > Labels: logging > > Add lots of logging to proton to ease understnding of it's inner workings > Introduce object naming facility as some layers are coupled really loosely > for now the logging route will just dump everything out to stderr, as it was > before > This is currently one giant commit off 0.3: > https://github.com/ttlj/qpid-proton/commits/upstream-logging > It doesn't merge quite cleanly to trunk. If this is interesting thing to have > I'd be willing to merge or rebase whichever is preferred. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798263#comment-13798263 ] Rafael H. Schloming commented on PROTON-236: Cliff, what's the status on this? > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (PROTON-193) Proton-j API omits some functionality
[ https://issues.apache.org/jira/browse/PROTON-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-193. Resolution: Invalid I'm going to kill this in favor of more specific JIRAs. > Proton-j API omits some functionality > - > > Key: PROTON-193 > URL: https://issues.apache.org/jira/browse/PROTON-193 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Reporter: Keith Wall > > A reconciliation of the proton-j API has revealed a number of areas where the > projon-j api is deficient when compared with the proton-c api. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora
[ https://issues.apache.org/jira/browse/PROTON-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-287: --- Assignee: Cliff Jansen > Fix Qpid Proton-C build with MinGW on Fedora > > > Key: PROTON-287 > URL: https://issues.apache.org/jira/browse/PROTON-287 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 > Environment: mingw32-gcc-4.7.2-7.fc18.x86_64 >Reporter: Robin Lee >Assignee: Cliff Jansen > Labels: build, patch > Fix For: 0.6 > > > This is my first submit on ASF JIRA. > Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided: > Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff > Description: %z format specifier is not provided by MSVCRT, use MinGW version > of *printf to get it. Otherwise build failed with: > "proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character > 'z' in format [-Werror=format]" > Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff > Description: Libraries and header files should be written in small cases, > otherwise build failed in cross build environment of Unix-like platforms: > "proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file > or directory" > Patch 3: > http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff > Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, > since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build > failed with: "proton-c/src/windows/driver.c:785:11: error: comparison between > signed and unsigned integer expressions [-Werror=sign-compare]" > Patch 4: > http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff > Description: Commented unimplemented functions. Otherwise build failed with > "proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared > 'static' but never defined [-Werror=unused-function]" > Patch 5: > http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff > Description: > 1. ID is not used, build failed with "../wincompat/internal/getopt.c:43:20: > error: 'ID' defined but not used [-Werror=unused-variable]" > 2. Corrected getopt signiture, otherwise build failed with > "proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' > but argument is of type 'const char *'" > 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so > #include wincompat/getopt.h in .c files instead of .h, otherwise build failed > with multiple definitions. > Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff > Description: WIN32 macro is not defined with -std=c99 but defined with > -std=gnu99. Use _WIN32 macro in all places. > Built on Fedora and examples of recv and send are tested on Windows 7. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-287) Fix Qpid Proton-C build with MinGW on Fedora
[ https://issues.apache.org/jira/browse/PROTON-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-287: --- Fix Version/s: 0.6 > Fix Qpid Proton-C build with MinGW on Fedora > > > Key: PROTON-287 > URL: https://issues.apache.org/jira/browse/PROTON-287 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 > Environment: mingw32-gcc-4.7.2-7.fc18.x86_64 >Reporter: Robin Lee > Labels: build, patch > Fix For: 0.6 > > > This is my first submit on ASF JIRA. > Fix Qpid Proton-C build with MinGW on Fedora. Patches are provided: > Patch 1: http://cheeselee.fedorapeople.org/qpid-proton_trunk_MinGW_STDIO.diff > Description: %z format specifier is not provided by MSVCRT, use MinGW version > of *printf to get it. Otherwise build failed with: > "proton-c/src/codec/codec.c:1951:3: error: unknown conversion type character > 'z' in format [-Werror=format]" > Patch 2: http://cheeselee.fedorapeople.org/qpid-proton_trunk_small_cases.diff > Description: Libraries and header files should be written in small cases, > otherwise build failed in cross build environment of Unix-like platforms: > "proton-c/src/windows/driver.c:44:22: fatal error: Ws2tcpip.h: No such file > or directory" > Patch 3: > http://cheeselee.fedorapeople.org/qpid-proton_trunk_pn_connector_t.diff > Description: Change pn_connector_t::fd to type of pn_socket_t. Otherwise, > since on Windows platform, pn_socket_t (typedef of SOCKET) is unsigned, build > failed with: "proton-c/src/windows/driver.c:785:11: error: comparison between > signed and unsigned integer expressions [-Werror=sign-compare]" > Patch 4: > http://cheeselee.fedorapeople.org/qpid-proton_trunk_unimplemented_functions.diff > Description: Commented unimplemented functions. Otherwise build failed with > "proton-c/src/windows/driver.c:416:13: error: 'pn_connector_write' declared > 'static' but never defined [-Werror=unused-function]" > Patch 5: > http://cheeselee.fedorapeople.org/qpid-proton_trunk_wincompat-getopt.diff > Description: > 1. ID is not used, build failed with "../wincompat/internal/getopt.c:43:20: > error: 'ID' defined but not used [-Werror=unused-variable]" > 2. Corrected getopt signiture, otherwise build failed with > "proton-c/src/../wincompat/internal/getopt.c:97:5: note: expected 'char *' > but argument is of type 'const char *'" > 3. wincompat/getopt.h #include wincompat/internal/getopt.c directly, so > #include wincompat/getopt.h in .c files instead of .h, otherwise build failed > with multiple definitions. > Patch 6: http://cheeselee.fedorapeople.org/qpid-proton_trunk_WIN32_macro.diff > Description: WIN32 macro is not defined with -std=c99 but defined with > -std=gnu99. Use _WIN32 macro in all places. > Built on Fedora and examples of recv and send are tested on Windows 7. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-332) SASL module needs access to the SSL module
[ https://issues.apache.org/jira/browse/PROTON-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-332: --- Labels: security (was: ) > SASL module needs access to the SSL module > -- > > Key: PROTON-332 > URL: https://issues.apache.org/jira/browse/PROTON-332 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 >Reporter: Ted Ross > Labels: security > > The SASL interface needs to be extended with a function that provides a > pointer to an SSL session. This is needed because the EXTERNAL mechanism > handshake requires access to the authentication ID from the external (ssl) > layer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-441) Provide hooks for alternative sources of Messenger routes
[ https://issues.apache.org/jira/browse/PROTON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-441: --- Fix Version/s: (was: 0.6) > Provide hooks for alternative sources of Messenger routes > - > > Key: PROTON-441 > URL: https://issues.apache.org/jira/browse/PROTON-441 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.5 >Reporter: Ted Ross > > This is a request to add the capability to set Messenger routes automatically > on Messenger startup. Where the routes come from may be platform-specific > (i.e. environment variables, configuration files, registries, network-based > lookup, etc.). > The desire is to allow Messenger applications to be wholly unaware of the > route mappings that come from other sources. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (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
]
Rafael H. Schloming resolved PROTON-426.
Resolution: Won't Fix
This is impossible to fix inside messenger because there is no way using the
1.0 protocol to ask the broker to create a queue. This particular scenario will
be more generally handled by qpidd functionality to dynamically create nodes
within certain configured namespaces.
> [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] [Updated] (PROTON-439) Support for dynamic reply-to address in Messenger
[ https://issues.apache.org/jira/browse/PROTON-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated PROTON-439: Assignee: Rafael H. Schloming > Support for dynamic reply-to address in Messenger > - > > Key: PROTON-439 > URL: https://issues.apache.org/jira/browse/PROTON-439 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.5 >Reporter: Ted Ross >Assignee: Rafael H. Schloming > Fix For: 0.6 > > > Messenger has no support for creating dynamic receivers for reply-to > addresses. Please refer to the following email thread for prior discussion > on the topic. > http://qpid.2158936.n2.nabble.com/Proton-Messenger-and-the-Request-Response-pattern-tp7586653.html -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (PROTON-323) Regression: Messenger sends "null" in disposition state after accept
[
https://issues.apache.org/jira/browse/PROTON-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated PROTON-323:
Assignee: Rafael H. Schloming
> Regression: Messenger sends "null" in disposition state after accept
>
>
> Key: PROTON-323
> URL: https://issues.apache.org/jira/browse/PROTON-323
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Ted Ross
>Assignee: Rafael H. Schloming
>Priority: Blocker
> Fix For: 0.6
>
>
> Using the following Python code snippet:
> from proton import *
> mng = Messenger()
> mng.start()
> mng.subscribe("amqp://0.0.0.0/Queue_1")
> mng.timeout=100
> mng.recv()
> msg = Message()
> t = mng.get(msg)
> mng.accept(t)
> mng.stop()
> The following trace is seen after the call to stop:
> [0xf7f6a0:1] -> DISPOSITION @21 [true, 0, 0, true, null]
> On Proton 0.4, this problem does not exist. The trace is:
> [0x1087bb0:1] -> DISPOSITION @21 [true, 0, 0, true, @36 []]
--
This message was sent by Atlassian JIRA
(v6.1#6144)
