[jira] [Resolved] (QPID-4125) [Java Broker] Improve persistent transacted message performance for multiple channels on same connection
[ https://issues.apache.org/jira/browse/QPID-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-4125. -- Resolution: Fixed Resolving. [Java Broker] Improve persistent transacted message performance for multiple channels on same connection Key: QPID-4125 URL: https://issues.apache.org/jira/browse/QPID-4125 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.19 Use asynchronous transaction commits on channels to allow coalescing of commits on multiple channels on the same connection. Defer the sending of commit-ok until the end of processing for the current incoming data / more work arrives on the same channel -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3602) Fix Consumer message credit issues in 0-10 codepath
[ https://issues.apache.org/jira/browse/QPID-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3602: --- Fix Version/s: (was: 0.15) Future Fix Consumer message credit issues in 0-10 codepath --- Key: QPID-3602 URL: https://issues.apache.org/jira/browse/QPID-3602 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.14 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Labels: message-credit Fix For: Future Currently there are several issues related to message credits. 1. QPID-2604 - Getting more messages than required by the prefetch value. 2. QPID-3604 - If connection is started and stopped, the client *may* get more messages than required by the prefetch value. 3. QPID-3562 - Prefetch=1 case doesn't work properly. 4. Prefetch-0 case doesn't work properly (well completely broken). 5. QPID-3612 -Message credits are affected by Command Completions and not message-acks. However these two are intertwined in the logic causing some issues. For example when in client-ack mode or using transactions, if the client has exhausted the credits, but is waiting for more messages to come before it acks or commits a transaction, then the client will appear hung (This issue is currently masked due to some of the above bugs). 6. QPID-3613 Credit should be managed on a per subscription basis than on a per session basis. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3612) Sending of completions should be independent of sending message acks
[ https://issues.apache.org/jira/browse/QPID-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3612: --- Fix Version/s: (was: 0.15) Future Sending of completions should be independent of sending message acks Key: QPID-3612 URL: https://issues.apache.org/jira/browse/QPID-3612 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.14 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Fix For: Future Message credits are affected by Command Completions and not message-acks. However in the current codebase,these two are intertwined in the logic causing some issues. For example when in client-ack mode or using transactions, if the client has exhausted the credits, but is waiting for more messages to come before it acks or commits a transaction, then the client will appear hung (This issue is currently masked due to some other bugs - see QPID-3602). We need to send completions independent of message-acks. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3613) Management of message credits should be on a per subscription basis (not on a per session basis)
[
https://issues.apache.org/jira/browse/QPID-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajith Attapattu updated QPID-3613:
---
Fix Version/s: (was: 0.15)
Future
Management of message credits should be on a per subscription basis (not on a
per session basis)
Key: QPID-3613
URL: https://issues.apache.org/jira/browse/QPID-3613
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.14
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Labels: message-credit
Fix For: Future
We currently calculate credit replenishment at the session level completely
ignoring the capacity of each individual subscription. Further more as per
QPID-3612 the completions are tied to message-acks further complicating the
issue.
The general formula used for calculating the replenishment rate is as
follows.
{code}
if (unackedCount = prefetch/2 || maxAckDelay = 0 || _acknowledgeMode ==
javax.jms.Session.AUTO_ACKNOWLEDGE)
{
flushAcknowledgments();
}
{code}
There are several issues with this.
1. If the application doesn't ack (in CLIENT_ACK) or commit a transaction
before it exhaust the credits, the consumer will starve. See QPID-3612. A
recent change done in rev 1195213 fixes the TX case.
2. Ineffective flow control as the calculation happens globally at the
session level instead at the subscription level. Due to this, slow consumers
can affect fast consumers.
Ex . Assume there are two fast consumers and a slow consumer each with an
individual capacity of 20 and the max_prefetch for the connection to be 100.
The threshold for sending acks (and therefore completions) is 50. If the fast
consumers have already done with their 20 messages, they will have to wait
for the slow consumer to do atleast 10 messages before the threshold is hit.
--
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
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3462) Failover is not transparent when using CLIENT_ACK mode
[ https://issues.apache.org/jira/browse/QPID-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3462: --- Fix Version/s: (was: 0.15) Future Failover is not transparent when using CLIENT_ACK mode -- Key: QPID-3462 URL: https://issues.apache.org/jira/browse/QPID-3462 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.10, 0.12 Reporter: Rajith Attapattu Assignee: Rajith Attapattu Labels: failover Fix For: Future If a session is using CLIENT_ACK mode fails over to another broker, and calls acknowledge on a message it received before failover, the client throws an IllegalStateException. The JMS spec states, that the IllegalStateException should only be thrown if the session is closed. When failover happens the JMS session (or the JMS Connection) is not closed, instead we transparently reconnect and create a new AMQP session and allow the application to continue as nothing happens. Therefore throwing the above exception is incorrect. We have three options for handling this case. 1. Throw a JMSException notifying the application that this message was received in the previous session. This notifies the application that the acknowledge didn't succeed and the message is going to be redelivered. 2. Not throw an exception at all. The application is anyhow prepared to handle duplicates, so this would not be an issue at all. With JMS the last acked message is always in doubt. If the application is using CLIENT_ACK and acknowledging after 'n' messages, then it should be prepared to handle 'n' duplicates in the event of a failover. 2. The client library can make it totally transparent by not throwing an exception at all. Instead it can look up this messages (along with all the other unacked messages upto that point) in it's dispatch queue received after failover. The messages can be identified using the message ID (and they will also be marked re-delivered by the broker). It can then call acknowledge on these messages and remove them from the dispatch queue. i.e they will not be redelivered to the application at all. What do you think is the best option? Regards, Rajith -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3618) c++ broker dies if federation link is flaky and errors out
[ https://issues.apache.org/jira/browse/QPID-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated QPID-3618: -- Fix Version/s: (was: 0.15) c++ broker dies if federation link is flaky and errors out -- Key: QPID-3618 URL: https://issues.apache.org/jira/browse/QPID-3618 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.12 Environment: Linux, ARM platform. Limited hardware resources. Federation link over a cellular data connection. Reporter: Brandon Pedersen Assignee: Andrew Stitcher Labels: federation, push PROBLEM STATEMENT: I have a durable queue push route configured to send messages to a central broker. The link between the source broker and the destination broker is a flaky cellular connection. When the link goes on and off it will very frequently cause the broker to seg fault and die. STEPS TO REPRODUCE: This is tricky to reproduce but it most often occurs when the physical data connection is just being brought up. i.e. the cell connection went down, qpid releases the connectionafter a while the connection comes back up and qpid tries to reconnect *possibly* (not certain) when the connection has not been completely set up. RESULTS: The broker receives some sort of data frame before the connection is fully established and therefore throws and exception. During this process it appears there is another thread that accesses some pointer that is invalid and causes the program to die. LOGS: The log shows the following messages just before dieing: Nov 14 15:43:35 mtcdp daemon.err qpidd[6790]: 2011-11-14 15:43:35 error Connection local:55764-remote:5672 closed by error: Connection not yet open, invalid frame received.(501) Nov 14 15:43:35 mtcdp daemon.err qpidd[6790]: 2011-11-14 15:43:35 error Connection local:55764-remote:5672 closed by error: Connection not yet open, invalid frame received.(501) Notice that the connection error message shows up twice, this seems suspicious to me. This occurs every time the broker dies. I got a core dump from the seg fault (a couple of times) and this is the backtrace Core was generated by `qpidd'. Program terminated with signal 11, Segmentation fault. #0 0x403fdc98 in qpid::SessionState::disableReceiverTracking() () from /usr/lib/libqpidcommon.so.2 (gdb) backtrace #0 0x403fdc98 in qpid::SessionState::disableReceiverTracking() () from /usr/lib/libqpidcommon.so.2 #1 0x4010e8a8 in qpid::broker::Bridge::create(qpid::broker::Connection) () from /usr/lib/libqpidbroker.so.2 #2 0x4017ed18 in qpid::broker::Link::ioThreadProcessing() () from /usr/lib/libqpidbroker.so.2 #3 0x40180920 in ?? () from /usr/lib/libqpidbroker.so.2 Cannot access memory at address 0x2d74c0f8 -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4302) make sure the 0-8..0-9-1 client message.acknowledge() actually acknowledges messages immediately, and does so synchronously
Keith Wall created QPID-4302: Summary: make sure the 0-8..0-9-1 client message.acknowledge() actually acknowledges messages immediately, and does so synchronously Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.18, 0.16, 0.14, 0.12, 0.10, 0.8, 0.6 Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediatelly in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4302) make sure the 0-8..0-9-1 client message.acknowledge() does so synchronously
[ https://issues.apache.org/jira/browse/QPID-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-4302: - Description: For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. (was: For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediatelly in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired.) Summary: make sure the 0-8..0-9-1 client message.acknowledge() does so synchronously (was: make sure the 0-8..0-9-1 client message.acknowledge() actually acknowledges messages immediately, and does so synchronously) make sure the 0-8..0-9-1 client message.acknowledge() does so synchronously --- Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4302) 0-8..0-9-1 client should sync after message.acknowledge()
[ https://issues.apache.org/jira/browse/QPID-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-4302: - Description: In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again. Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully. The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. was:For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. Summary: 0-8..0-9-1 client should sync after message.acknowledge() (was: make sure the 0-8..0-9-1 client message.acknowledge() does so synchronously) 0-8..0-9-1 client should sync after message.acknowledge() - Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again. Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully. The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
0.20 release update - important upcoming dates
Hi, everyone. 0.20 has been open for development for about two months. Here are some upcoming dates to keep in mind: Alpha - 17 October, in just under five weeks Beta - 31 October, in just under seven weeks Alpha is the deadline for major feature inclusiion. If you miss it, you'll have to wait for 0.22 in another four months! The release page (linked below) is now up to date. Let me know if you have questions. Thanks, Justin --- 0.20 release page: https://cwiki.apache.org/qpid/020-release.html - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4284) Remove system test dependencies on development and localhost virtual hosts
[ https://issues.apache.org/jira/browse/QPID-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-4284: - Attachment: (was: 0001-WIP-sync-after-client-ack-ack.patch) Remove system test dependencies on development and localhost virtual hosts -- Key: QPID-4284 URL: https://issues.apache.org/jira/browse/QPID-4284 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 Attachments: 0001-QPID-4284-Remove-system-test-dependencies-on-develop.patch, TEST-org.apache.qpid.test.unit.ack.ClientAcknowledgeTest.testClientAckWithLargeFlusherPeriod-derby-0-9-1.out Currently the system tests rely on three virtualhost (namely test, development and localhost) being defined in the system test configuration. This arrangement has the disadvantage that each system test must initialise three virtual hosts and for persistent stores (derby/BDB), this adds significant time to the test run. On the whole, tests use only the 'test' virtualhost. This change will remove the dependency on the development and localhost virtual hosts. It will also remove the remaining few dependencies on the hardcoded queues ping and queue. In addition to the time saving, this change will help when we come to eliminate the configuration files entirely. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4302) 0-8..0-9-1 client should sync after message.acknowledge()
[ https://issues.apache.org/jira/browse/QPID-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-4302: - Status: Ready To Review (was: In Progress) 0-8..0-9-1 client should sync after message.acknowledge() - Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again. Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully. The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4302) 0-8..0-9-1 client should sync after message.acknowledge()
[ https://issues.apache.org/jira/browse/QPID-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13455230#comment-13455230 ] Keith Wall commented on QPID-4302: -- Patch applied. Hi Robbie, could you review please? 0-8..0-9-1 client should sync after message.acknowledge() - Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again. Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully. The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4302) 0-8..0-9-1 client should sync after message.acknowledge()
[ https://issues.apache.org/jira/browse/QPID-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-4302: Assignee: Robbie Gemmell (was: Keith Wall) 0-8..0-9-1 client should sync after message.acknowledge() - Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Robbie Gemmell Fix For: 0.19 In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again. Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully. The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4302) 0-8..0-9-1 client should sync after message.acknowledge()
[ https://issues.apache.org/jira/browse/QPID-4302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-4302. -- Resolution: Fixed Looks good to me. 0-8..0-9-1 client should sync after message.acknowledge() - Key: QPID-4302 URL: https://issues.apache.org/jira/browse/QPID-4302 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.8, 0.10, 0.12, 0.14, 0.16, 0.18 Reporter: Keith Wall Assignee: Robbie Gemmell Fix For: 0.19 In 0-8..0-9-1 protocols, message acknowledgement (BasicAck) is async by design. There is no BasicAckOk. This presents a problem for JMS CLIENT_ACK mode. When Message#acknowledge() returns the spec requires that the Broker has processed the ack and the client won't see the message(s) again. Currently calling Message#acknowledge() merely puts the command in buffer to be put on the wire later by the IoSender. There is no assurance that the Broker has even received the command let alone process it successfully. The client should be changed to sync() once before returning the the client to give assurance that the Broker has received and processed the commands. For the 0-8..0-9-1 code paths acknowledgement of messages in CLIENT_ACK mode might not happen immediately in Message#acknowledge. It should be updated to acknowledge messages synchronously. There will be a system property to allow the old behaviour to be restored if so desired. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3906) Implement a ListMessage interface to accept amqp/list messages as java.util.List
[ https://issues.apache.org/jira/browse/QPID-3906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajith Attapattu updated QPID-3906: --- Assignee: Rajith Attapattu Implement a ListMessage interface to accept amqp/list messages as java.util.List Key: QPID-3906 URL: https://issues.apache.org/jira/browse/QPID-3906 Project: Qpid Issue Type: Improvement Components: Java Client Reporter: Siddhesh Poyarekar Assignee: Rajith Attapattu Attachments: 0001-java-ListMessage-support.patch Currently, the qpid java client accepts amqp/list messages as a javax.jms.BytesMessage. This is not good because it means that one cannot easily use the java client to write QMF clients. I have written an interface org.apache.qpid.jms.ListMessage that extends the javax.jms.StreamMessage interface. Attachment and details coming up. -- 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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
