Re: 0.16 release update - proposed final RC is available
Hi Justin, I've run some tests against the Java Broker 0-16 RC3 and encountered no issues. Details of tests run: used java Drain/Spout examples to publish/receive messages to/from Java Broker. monitored queues using Java Broker Management Console. No issues found. Kind Regards, Alex - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Strange situation with qpid::sys::Thread and fds
On 05/08/2012 10:03 AM, Darryl L. Pierce wrote: On Tue, May 08, 2012 at 08:52:32AM -0500, Steve Huston wrote: What kind of fd is this? Linux? Yes. There's a class named Prong that creates a one-way pipe for sending a notification to the Ruby thread to wake it up. The pipe is created using the pipe() API, then fcntl() to make the descriptor non-blocking. The symptom sounds like what would happen if a TCP socket write were done and TCP buffered the byte. Setting no-delay on the socket would resolve that. I tried adding O_NDELAY to the flags for the fds and it made no difference: flags = ::fcntl(yourHandle, F_GETFL); if((::fcntl(yourHandle, F_SETFL, flags | O_NONBLOCK | O_NDELAY))== -1) throw MessagingException(Unable to make your handle non-blocking.); Sounds like you are doing something very similar to qpid::sys::PollableQueue or qpid::sys::Condition. You might be able to cut/paste some of the code. PollableCondition exposes an FD to be added to qpid::sys::Poller. The FD is readable iff the condition is set. PollableQueue is a work queue that uses a PollableCondition so that it is pollable iff there is data in the queue. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Strange situation with qpid::sys::Thread and fds
On Wed, May 09, 2012 at 08:33:58AM -0400, Alan Conway wrote: On 05/08/2012 10:03 AM, Darryl L. Pierce wrote: On Tue, May 08, 2012 at 08:52:32AM -0500, Steve Huston wrote: What kind of fd is this? Linux? Yes. There's a class named Prong that creates a one-way pipe for sending a notification to the Ruby thread to wake it up. The pipe is created using the pipe() API, then fcntl() to make the descriptor non-blocking. The symptom sounds like what would happen if a TCP socket write were done and TCP buffered the byte. Setting no-delay on the socket would resolve that. I tried adding O_NDELAY to the flags for the fds and it made no difference: flags = ::fcntl(yourHandle, F_GETFL); if((::fcntl(yourHandle, F_SETFL, flags | O_NONBLOCK | O_NDELAY))== -1) throw MessagingException(Unable to make your handle non-blocking.); Sounds like you are doing something very similar to qpid::sys::PollableQueue or qpid::sys::Condition. You might be able to cut/paste some of the code. PollableCondition exposes an FD to be added to qpid::sys::Poller. The FD is readable iff the condition is set. PollableQueue is a work queue that uses a PollableCondition so that it is pollable iff there is data in the queue. Looking through the code it looks like the ideal for what I'm going for. I would like the CommandRunner (renamed the class) to not sleep but to respond immediately to a new command being enqueued. I'll pull what I can out of this code and see if that helps. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgplvL1KbTeFA.pgp Description: PGP signature
[jira] [Commented] (QPID-3979) Last value queue memory leak
[
https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271399#comment-13271399
]
Rob Godfrey commented on QPID-3979:
---
In general the change looks good. I have one comment in that I think the method
{noformat}
private AtomicReferenceQueueEntry getOrPutIfAbsent(final Object key, final
AtomicReferenceQueueEntry referenceToValue)
{
AtomicReferenceQueueEntry latestValueReference =
_latestValuesMap.putIfAbsent(key, referenceToValue);
if(latestValueReference == null)
{
latestValueReference = _latestValuesMap.get(key);
}
return latestValueReference;
}
{noformat}
may return null. Which would result in an NPE in the code that calls this.
The null would occur in the very unlikely case that between the insert into the
map, and the retrieval from the map a separate thread updates with a newer
value, and then this value is consumed (and thus deleted).
Last value queue memory leak
Key: QPID-3979
URL: https://issues.apache.org/jira/browse/QPID-3979
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: 0.12, 0.14, 0.16, 0.17
Reporter: Philip Harvey
I have observed a memory leak when using a last value queue.
Upon investigation, it seems that this is due to a bug in the management of
ConflationQueueList._latestValuesMap. This map is keyed by the configured
conflation key. Whilst entries are correctly replaced when new messages
arrive, they are never *deleted*. Therefore, an entry remains in the map for
every key value that has ever existed.
The problem is compounded by the fact that the retained
ConflationQueueEntry's can reference other entries - that is how the linked
list behaviour of the queue list is achieved. Therefore, retaining a single
entry in the aforementioned map can cause a large number of other entries to
remain in memory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3980) Last value queue - entries replaced by conflation are never deleted, causing memory leak
[ https://issues.apache.org/jira/browse/QPID-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271401#comment-13271401 ] Rob Godfrey commented on QPID-3980: --- Change looks good to me Last value queue - entries replaced by conflation are never deleted, causing memory leak Key: QPID-3980 URL: https://issues.apache.org/jira/browse/QPID-3980 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.16 Reporter: Philip Harvey Attachments: send-lvq-messages-without-a-consumer.json This issue was uncovered while investigating QPID-3979. The conflation behaviour of last value queues appears correct from the perspective of consumers. However, the message count suggests that conflation is *not* occurring. I checked what happens when ConflationQueueList.add(..) is replacing an existing ConflationQueueEntry. ConflationQueueList calls acquire() on the entry and then tries to discard it. The discard does nothing because it tries again to acquire the message. Therefore, the message stays in the list, causing a memory leak. Because the message has been acquired, it is not delivered to consumers - that is why everything appears to work correctly from their point of view. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3990) Multiple XAResources isSameRM behavior
Weston M. Price created QPID-3990: - Summary: Multiple XAResources isSameRM behavior Key: QPID-3990 URL: https://issues.apache.org/jira/browse/QPID-3990 Project: Qpid Issue Type: Bug Components: Java Client, JCA Affects Versions: 0.14, 0.17 Environment: All supported OS platforms. All supported JEE platforms. Reporter: Weston M. Price Assignee: Weston M. Price Priority: Critical In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RM's were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. According to Gordon, this may be a discrepancy between XA and the AMQP .10 specification. This has inadvertently worked in the JCA code due to bug in the isSameRM method and the use of the QpidRAXAResourceWrapper. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. I have a fix for this issue that allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3991) QpidMessageHandler should be selective in tearing down and re-establishing Connection/Sessions on AMQException
Weston M. Price created QPID-3991: - Summary: QpidMessageHandler should be selective in tearing down and re-establishing Connection/Sessions on AMQException Key: QPID-3991 URL: https://issues.apache.org/jira/browse/QPID-3991 Project: Qpid Issue Type: Improvement Components: JCA Environment: All supported OS platforms. All supported JEE platforms. Reporter: Weston M. Price Assignee: Weston M. Price Priority: Minor Fix For: 0.17 Currently the QpidMessageHandler, the primary class for handling incoming messages for the JCA adapter, tears down both the JMS Connection and Session in the event of any AMQException received from the Broker. It would be better if we could evaluate the exception and determine if the teardown is actually warranted (i.e. the connection has completely stopped). This will improve performance in general as this is a fairly expensive operation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
General Question
Hi, I wanted to understand where we stand on the release AMQP 1.0 vs. the current broker implementation based on version 0-10 of the AMPQ standard. Are all implementations proceeding to the 1.0 AMQP release standard and where can I find out what the schedules are? I would like to use the current C++ broker and client implementations and develop our software based on that. I would like to understand the plans and may be someone can point me to the relevant information. Thanks Nitin [cid:image001.png@01CD2DD0.11A0F0E0]
[jira] [Commented] (QPID-3990) Multiple XAResources isSameRM behavior
[ https://issues.apache.org/jira/browse/QPID-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271617#comment-13271617 ] jirapos...@reviews.apache.org commented on QPID-3990: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5079/ --- Review request for Ted Ross, Robbie Gemmell, rajith attapattu, and Rob Godfrey. Summary --- In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RMs were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. The following patch/diff allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. This addresses bug QPID-3990. https://issues.apache.org/jira/browse/QPID-3990 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/XAResourceImpl.java 1336275 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java 1336275 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/jms/xa/XAResourceTest.java 1336275 Diff: https://reviews.apache.org/r/5079/diff Testing --- Added system test to XAResourceTest to exercise new behavior. Tested against both the Java and C++ Brokers using the 0.10 profile. Thanks, Weston Multiple XAResources isSameRM behavior -- Key: QPID-3990 URL: https://issues.apache.org/jira/browse/QPID-3990 Project: Qpid Issue Type: Bug Components: Java Client, JCA Affects Versions: 0.14, 0.17 Environment: All supported OS platforms. All supported JEE platforms. Reporter: Weston M. Price Assignee: Weston M. Price Priority: Critical In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RM's were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. According to Gordon, this may be a discrepancy between XA and the AMQP .10 specification. This has inadvertently worked in the JCA code due to bug in the isSameRM method and the use of the QpidRAXAResourceWrapper. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. I have a fix for this issue that allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3990) Multiple XAResources isSameRM behavior
[ https://issues.apache.org/jira/browse/QPID-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271620#comment-13271620 ] jirapos...@reviews.apache.org commented on QPID-3990: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5079/ --- (Updated 2012-05-09 17:37:24.510238) Review request for Ted Ross, Robbie Gemmell, rajith attapattu, and Rob Godfrey. Changes --- Diff for QPID-3990 Summary --- In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RMs were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. The following patch/diff allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. This addresses bug QPID-3990. https://issues.apache.org/jira/browse/QPID-3990 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/XAResourceImpl.java 1336275 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java 1336275 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/jms/xa/XAResourceTest.java 1336275 Diff: https://reviews.apache.org/r/5079/diff Testing --- Added system test to XAResourceTest to exercise new behavior. Tested against both the Java and C++ Brokers using the 0.10 profile. Thanks, Weston Multiple XAResources isSameRM behavior -- Key: QPID-3990 URL: https://issues.apache.org/jira/browse/QPID-3990 Project: Qpid Issue Type: Bug Components: Java Client, JCA Affects Versions: 0.14, 0.17 Environment: All supported OS platforms. All supported JEE platforms. Reporter: Weston M. Price Assignee: Weston M. Price Priority: Critical In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RM's were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. According to Gordon, this may be a discrepancy between XA and the AMQP .10 specification. This has inadvertently worked in the JCA code due to bug in the isSameRM method and the use of the QpidRAXAResourceWrapper. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. I have a fix for this issue that allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3990) Multiple XAResources isSameRM behavior
[ https://issues.apache.org/jira/browse/QPID-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271625#comment-13271625 ] jirapos...@reviews.apache.org commented on QPID-3990: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5079/ --- (Updated 2012-05-09 17:41:59.301972) Review request for Ted Ross, Robbie Gemmell, rajith attapattu, and Rob Godfrey. Changes --- Sorry, did the SVN diff incorrectly and forgot to add new file qpid/java/client/src/main/java/org/apache/qpid/client/AMQXAResource.java. New diff has missing file included. Please use this as the definitive diff. Summary --- In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RMs were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. The following patch/diff allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. This addresses bug QPID-3990. https://issues.apache.org/jira/browse/QPID-3990 Diffs (updated) - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQXAResource.java PRE-CREATION http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/XAResourceImpl.java 1336275 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java 1336275 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/jms/xa/XAResourceTest.java 1336275 Diff: https://reviews.apache.org/r/5079/diff Testing --- Added system test to XAResourceTest to exercise new behavior. Tested against both the Java and C++ Brokers using the 0.10 profile. Thanks, Weston Multiple XAResources isSameRM behavior -- Key: QPID-3990 URL: https://issues.apache.org/jira/browse/QPID-3990 Project: Qpid Issue Type: Bug Components: Java Client, JCA Affects Versions: 0.14, 0.17 Environment: All supported OS platforms. All supported JEE platforms. Reporter: Weston M. Price Assignee: Weston M. Price Priority: Critical In fixing QPID-3263, an issue has cropped up when two XAResources have the same underlying ResourceManager(RM). Originally the isSameRM method returned false regardless of whether or not the RM's were the same. Since we now return true when two or more XAResources are involved, we get an ILLEGAL_STATE exception being that the DtxStart/DtxEnd calls are not paired for each XAResource because the TransactionManager (TM) treats the XAResource(s) as being on the same transaction branch. As a result, DtxEnd is only called on one resource. According to Gordon, this may be a discrepancy between XA and the AMQP .10 specification. This has inadvertently worked in the JCA code due to bug in the isSameRM method and the use of the QpidRAXAResourceWrapper. While it might make sense to simply roll back to the old behavior, this is not going to perform as well being that most TM's can optimize underlying transaction state with isSameRM is true. This has performance implications for the TM in terms of logging, management etc. I have a fix for this issue that allows XAResources to be aware of each other in a transaction chain. When DtxEnd is called on one resource, the sibling XAResources.end method is called thereby matching the DtxStart/DtxEnd invocations appropriately allowing the transaction to complete. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (QPID-3984) HA tests fail in distribution
[ https://issues.apache.org/jira/browse/QPID-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271720#comment-13271720 ] Justin Ross commented on QPID-3984: --- Reviewed by me. Approved for 0.16. HA tests fail in distribution - Key: QPID-3984 URL: https://issues.apache.org/jira/browse/QPID-3984 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.15 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.16 The HA tests fail on an installed qpid distribution because they rely on scripts in the qpid/tools directory. This patch runs the tests conditionally, skipping them if the tools aren't available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
RE: General Question
Hi Nitin, Some work has begun on AMQP 1.0 for the C++ side but I'm not aware of any planned date for when it may be available for wider use. As far as I know, the intent of the qpid::messaging client API is that it will enable one to move to the AMQP 1.0 standard without (or with minimal) code changes. -Steve From: Nitin Shah [mailto:ns...@btisystems.com] Sent: Wednesday, May 09, 2012 10:42 AM To: dev@qpid.apache.org Cc: Nitin Shah Subject: General Question Hi, I wanted to understand where we stand on the release AMQP 1.0 vs. the current broker implementation based on version 0-10 of the AMPQ standard. Are all implementations proceeding to the 1.0 AMQP release standard and where can I find out what the schedules are? I would like to use the current C++ broker and client implementations and develop our software based on that. I would like to understand the plans and may be someone can point me to the relevant information. Thanks Nitin Description: bti_logo_small
[jira] [Commented] (QPID-3984) HA tests fail in distribution
[ https://issues.apache.org/jira/browse/QPID-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271770#comment-13271770 ] Alan Conway commented on QPID-3984: --- Merged to 0.16 branch r1336378 | aconway | 2012-05-09 16:27:35 -0400 (Wed, 09 May 2012) | 4 lines NO-JIRA: Skip HA tests if required python tools are not available. Backported from trunk r1335218 HA tests fail in distribution - Key: QPID-3984 URL: https://issues.apache.org/jira/browse/QPID-3984 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.15 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.16 The HA tests fail on an installed qpid distribution because they rely on scripts in the qpid/tools directory. This patch runs the tests conditionally, skipping them if the tools aren't available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3984) HA tests fail in distribution
[ https://issues.apache.org/jira/browse/QPID-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-3984. --- Resolution: Fixed HA tests fail in distribution - Key: QPID-3984 URL: https://issues.apache.org/jira/browse/QPID-3984 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.15 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.16 The HA tests fail on an installed qpid distribution because they rely on scripts in the qpid/tools directory. This patch runs the tests conditionally, skipping them if the tools aren't available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3936) Add new framework for running distributed tests, eg for performance testing
[ https://issues.apache.org/jira/browse/QPID-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3936: - Attachment: 0001-QPID-3936-producer-participant-can-be-interrupt-mess.patch Patch: Producer participant can be interrupt message sends when maximumDuration is reached. Useful for use with PSFC. Add new framework for running distributed tests, eg for performance testing --- Key: QPID-3936 URL: https://issues.apache.org/jira/browse/QPID-3936 Project: Qpid Issue Type: New Feature Components: Java Tests Reporter: Philip Harvey Assignee: Philip Harvey Fix For: 0.17 Attachments: 0001-QPID-3936-initial-checkin-of-new-testing-framework-i.patch, 0001-QPID-3936-producer-participant-can-be-interrupt-mess.patch We would like a framework that makes it easy to run configuration-driven distributed Qpid tests. The framework should read a configuration file that specifies a number of queues, producers, and consumers. It should then run the test, collecting statistics along the way. This is being initially implemented in Java, but is ultimately intended to be language-neutral. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
Re: Review Request: Destination refactoring
On 2012-04-06 11:06:40, Rob Godfrey wrote: Agree with all of Robbie's comments, and added a few more of my own... The work in general looks good, but a) we really need testing on this as it has caused us so many issues in the past and b) we need to do the work to integrate this into the session/consumer/etc - I think adding this code without deleting the old stuff would not make sense. Yes I totally agree about deleting the old stuff, as soon as we are happy with the integration. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 42-43 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line42 I think it would be better to move everything to do with DestSyntax to the parser I totally agree with you! There is no reason to really have this code in the QpidDestination class. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, line 51 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line51 Rather than having this as a member variable you could simply define abstract public DestinationType getType(); and provide implementations in the two direct subclasses Agreed! On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 79-96 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line79 Wouldn't it make more sense to move this code to the DestinationStringParser? agreed as mentioned above. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 117-122 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line117 Move to the parser class? agreed as mentioned above. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 124-144 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line124 move to the parser class, also could this not be simplified to return Enum.valueOf(DestSyntax.class, str); will do. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 146-160 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line146 Move to parser agreed as mentioned above. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 162-172 https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line162 Move to parser agreed as mentioned above. On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java, lines 53-56 https://reviews.apache.org/r/4658/diff/2/?file=100198#file100198line53 should this not be if(obj.getClass() != getClass()) otherwise you will (incorrectly) have temporary queues equalling non-temporary queues Good point ! On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryQueue.java, line 28 https://reviews.apache.org/r/4658/diff/2/?file=100199#file100199line28 Visibility/access - member variables should be private with setters/getters of appropriate visibility as necessary. Also can this not be made final? agreed On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java, line 28 https://reviews.apache.org/r/4658/diff/2/?file=100200#file100200line28 And access - should be private with package local getter/setter if necessary agreed On 2012-04-06 11:06:40, Rob Godfrey wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java, lines 37-40 https://reviews.apache.org/r/4658/diff/2/?file=100200#file100200line37 Should not the delete method actually delete? Why is this commented out? It certainly should! I wasn't sure how best to keep track of the subscription queue, hence determing the queue-name to delete. What if the TempTopic was used by more than one Consumer (the same issue for QpidTopic). Previously I used to clone the Topic object so each consumer is using a different destination object so as to keep the
[jira] [Commented] (QPID-3401) Refactor address resolution code
[ https://issues.apache.org/jira/browse/QPID-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13271871#comment-13271871 ] jirapos...@reviews.apache.org commented on QPID-3401: - bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. Agree with all of Robbie's comments, and added a few more of my own... bq. bq. The work in general looks good, but a) we really need testing on this as it has caused us so many issues in the past and b) we need to do the work to integrate this into the session/consumer/etc - I think adding this code without deleting the old stuff would not make sense. Yes I totally agree about deleting the old stuff, as soon as we are happy with the integration. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 42-43 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line42 bq. bq. I think it would be better to move everything to do with DestSyntax to the parser I totally agree with you! There is no reason to really have this code in the QpidDestination class. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, line 51 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line51 bq. bq. Rather than having this as a member variable you could simply define bq. bq. abstract public DestinationType getType(); bq. bq. and provide implementations in the two direct subclasses Agreed! bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 79-96 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line79 bq. bq. Wouldn't it make more sense to move this code to the DestinationStringParser? agreed as mentioned above. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 117-122 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line117 bq. bq. Move to the parser class? agreed as mentioned above. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 124-144 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line124 bq. bq. move to the parser class, also could this not be simplified to bq. bq. return Enum.valueOf(DestSyntax.class, str); will do. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 146-160 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line146 bq. bq. Move to parser agreed as mentioned above. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidDestination.java, lines 162-172 bq. https://reviews.apache.org/r/4658/diff/2/?file=100197#file100197line162 bq. bq. Move to parser agreed as mentioned above. bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidQueue.java, lines 53-56 bq. https://reviews.apache.org/r/4658/diff/2/?file=100198#file100198line53 bq. bq. should this not be bq. bq. if(obj.getClass() != getClass()) bq. bq. otherwise you will (incorrectly) have temporary queues equalling non-temporary queues Good point ! bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryQueue.java, line 28 bq. https://reviews.apache.org/r/4658/diff/2/?file=100199#file100199line28 bq. bq. Visibility/access - member variables should be private with setters/getters of appropriate visibility as necessary. Also can this not be made final? bq. agreed bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/jms/QpidTemporaryTopic.java, line 28 bq. https://reviews.apache.org/r/4658/diff/2/?file=100200#file100200line28 bq. bq. And access - should be private with package local getter/setter if necessary agreed bq. On 2012-04-06 11:06:40, Rob Godfrey wrote: bq.
[VOTE] Release 0.16
Hi. I've now produced 0.16-rc4 at the following location: http://people.apache.org/~jross/qpid-0.16-rc4/ It has just one change beyond RC3, r1336378, which disables the HA tests if required test tools are not in the environment (Thanks, Alan). There was one other issue with RC3 that Cajus raised, the Perl client install on Debian. Darryl looked into it, and it seems to be a Debian specific problem. With this information, I think it's best we press ahead with the release. If the fix is minor, we can consider introducing it on the 0.16 release branch when it becomes available. So, I'd like to jump straight to the vote. If you favor releasing the 0.16-rc4 bits as 0.16, vote +1. If you have a reason to think RC4 is not ready for release, vote -1. Thanks! Justin --- 0.16 release page: https://cwiki.apache.org/qpid/016-release.html - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Release artifacts (was: [VOTE] Release 0.16)
Hi Justin, I think it would be good to prepare the final artifacts (some seem like they could just be renamed, but others indicate RC4 in their content) so we can test them before we vote, and signing them would also allow the maven artifacts to be deployed to a staging repo and tested in advance of the vote closing rather than afterwards. Also, looking at the RC3 thread I notice Darryl raised a request for inclusion relating to updating the ruby gem name which still seems open, is that being deferred to 0.18? Robbie On 10 May 2012 01:57, Justin Ross jr...@redhat.com wrote: Hi. I've now produced 0.16-rc4 at the following location: http://people.apache.org/~jross/qpid-0.16-rc4/ It has just one change beyond RC3, r1336378, which disables the HA tests if required test tools are not in the environment (Thanks, Alan). There was one other issue with RC3 that Cajus raised, the Perl client install on Debian. Darryl looked into it, and it seems to be a Debian specific problem. With this information, I think it's best we press ahead with the release. If the fix is minor, we can consider introducing it on the 0.16 release branch when it becomes available. So, I'd like to jump straight to the vote. If you favor releasing the 0.16-rc4 bits as 0.16, vote +1. If you have a reason to think RC4 is not ready for release, vote -1. Thanks! Justin --- 0.16 release page: https://cwiki.apache.org/qpid/016-release.html - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
