[jira] [Commented] (QPID-7835) dead lock error

[ https://issues.apache.org/jira/browse/QPID-7835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075959#comment-16075959 ] hanfeng commented on QPID-7835: --- 0.24 > dead lock error > --- > >

[jira] [Commented] (DISPATCH-767) Message Cut-Through/Streaming for efficient handling of large messages

[ https://issues.apache.org/jira/browse/DISPATCH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075693#comment-16075693 ] ASF GitHub Bot commented on DISPATCH-767: - GitHub user ganeshmurthy opened a pul

[GitHub] qpid-dispatch pull request #172: DISPATCH-767 - Added code to support multi ...

GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/172 DISPATCH-767 - Added code to support multi frame message streaming You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid

[jira] [Commented] (QPID-7853) Message enqueued twice to the same queue leads to Broker failure

[ https://issues.apache.org/jira/browse/QPID-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16075508#comment-16075508 ] Keith Wall commented on QPID-7853: -- {{txn.enqueue(queues,message, new ServerTransaction.En

[jira] [Created] (QPID-7853) Message enqueued twice to the same queue leads to Broker failure

Keith Wall created QPID-7853: Summary: Message enqueued twice to the same queue leads to Broker failure Key: QPID-7853 URL: https://issues.apache.org/jira/browse/QPID-7853 Project: Qpid Issue Ty

[jira] [Commented] (DISPATCH-796) The Python and the C management agents do not have an AMQP header in their responses.

[ https://issues.apache.org/jira/browse/DISPATCH-796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074898#comment-16074898 ] ASF subversion and git services commented on DISPATCH-796: -- Com

[jira] [Resolved] (DISPATCH-796) The Python and the C management agents do not have an AMQP header in their responses.

[ https://issues.apache.org/jira/browse/DISPATCH-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-796. Resolution: Fixed > The Python and the C management agents do not have an AMQP header in t

[jira] [Created] (DISPATCH-796) The Python and the C management agents do not have an AMQP header in their responses.

Ganesh Murthy created DISPATCH-796: -- Summary: The Python and the C management agents do not have an AMQP header in their responses. Key: DISPATCH-796 URL: https://issues.apache.org/jira/browse/DISPATCH-796

Re: Question about settled flag on a multi-frame transfer

Thanks Rob, I entered a JIRA for this - https://issues.apache.org/jira/browse/PROTON-1514 On Wed, Jul 5, 2017 at 9:30 AM, Rob Godfrey wrote: > I agree the spec is horribly unclear on this point. > > I wish we had said something along the lines of two transfers in a > multi-transfer delivery must

[jira] [Created] (PROTON-1514) [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled

Ganesh Murthy created PROTON-1514: - Summary: [proton-c] When last frame of multi-frame transfer has settled=true, Proton still considers delivery as unsettled Key: PROTON-1514 URL: https://issues.apache.org/jira/b

Re: Question about settled flag on a multi-frame transfer

I agree the spec is horribly unclear on this point. I wish we had said something along the lines of two transfers in a multi-transfer delivery must either both have the same value for settled, or one must be unset (i.e. you can't have frames for the same transfer saying both settled and not settle

Question about settled flag on a multi-frame transfer

I have a situation where a receiver (proton python's simple_recv.py) is receiving a multi-frame transfer from a Dispatch Router. The settled flag is false on all the transfer frames except on the last frame which has settled=true as seen here - https://pastebin.com/37SYrg92 Proton considers the d

[jira] [Created] (QPIDJMS-297) Consumer receives messages on stopped connection

Alex Rudyy created QPIDJMS-297: -- Summary: Consumer receives messages on stopped connection Key: QPIDJMS-297 URL: https://issues.apache.org/jira/browse/QPIDJMS-297 Project: Qpid JMS Issue Type: B

[jira] [Updated] (QPID-7852) [0-10] Client ignores incoming message.reject

[ https://issues.apache.org/jira/browse/QPID-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7852: - Description: The 0-10 spec says: bq. An AMQP client MUST handle incoming message.reject commands. but the

[jira] [Created] (QPID-7852) [0-10] Client ignores incoming message.reject

Keith Wall created QPID-7852: Summary: [0-10] Client ignores incoming message.reject Key: QPID-7852 URL: https://issues.apache.org/jira/browse/QPID-7852 Project: Qpid Issue Type: Bug Co

[jira] [Commented] (QPID-7815) Reject policy type

[ https://issues.apache.org/jira/browse/QPID-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074456#comment-16074456 ] Alex Rudyy commented on QPID-7815: -- Tomas, As per Keith's comments above, we need to chang

[jira] [Created] (QPID-7851) [Java Broker] [AMQP 1.0] Detaching of broker sending link endpoint might result in increment of a delivery count for messages only being prefetched by the client

Alex Rudyy created QPID-7851: Summary: [Java Broker] [AMQP 1.0] Detaching of broker sending link endpoint might result in increment of a delivery count for messages only being prefetched by the client Key: QPID-7851