Re: Qpid broker gives out a warning when polling messages from a Queue.
Hi Charith,
can you confirm which release version of the Java Broker you are using
(it's always worth trying the latest version - in this case I'd grab
the latest 0.16 RC that Justin posted a couple of days ago - though
I'm not aware of any bugs that would cause this error)?
It would also help if you could send full broker log files that are
generated when this occurs - the best way is to raise a JIRA and
attach the log file there (stripped of any confidential information it
might contain - obviously).
Cheers,
Rob
On 11 May 2012 11:24, Charith Wickramarachchi
charith.dhanus...@gmail.com wrote:
Hi,
I m using qpid java jms client to publish and consume messages from a queue
in Qpid java broker.
When my application polling messages from a queue. Broker gives out a
warning :
WARN
{org.apache.qpid.server.subscription.ExplicitAcceptDispositionChangeListener}
- MessageAccept received for message which has not been acquired (likely
client error)
And if continue this publish poll scenario for some time i can see
following log in the Broker logs.
{org.apache.qpid.transport.network.mina.MINANetworkDriver} - Exception
thrown and no ProtocolEngine to handle it
org.apache.qpid.transport.ProtocolViolationException: Received frames for
an already dettached session
at
org.apache.qpid.transport.Connection.dispatch(Connection.java:408)
at
org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:64)
at
org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:40)
at
org.apache.qpid.transport.MethodDelegate.sessionKnownCompleted(MethodDelegate.java:95)
at
org.apache.qpid.transport.SessionKnownCompleted.dispatch(SessionKnownCompleted.java:96)
at
org.apache.qpid.transport.ConnectionDelegate.control(ConnectionDelegate.java:49)
at
org.apache.qpid.transport.ConnectionDelegate.control(ConnectionDelegate.java:40)
at org.apache.qpid.transport.Method.delegate(Method.java:163)
at
org.apache.qpid.transport.Connection.received(Connection.java:369)
at
org.apache.qpid.server.transport.ServerConnection.received(ServerConnection.java:196)
at
org.apache.qpid.server.transport.ServerConnection.received(ServerConnection.java:53)
at
org.apache.qpid.transport.network.Assembler.emit(Assembler.java:95)
at
org.apache.qpid.transport.network.Assembler.assemble(Assembler.java:181)
at
org.apache.qpid.transport.network.Assembler.frame(Assembler.java:129)
at org.apache.qpid.transport.network.Frame.delegate(Frame.java:133)
at
org.apache.qpid.transport.network.Assembler.received(Assembler.java:100)
at
org.apache.qpid.transport.network.Assembler.received(Assembler.java:42)
at
org.apache.qpid.transport.network.InputHandler.next(InputHandler.java:187)
at
org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:103)
at
org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:42)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:102)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:36)
at
org.apache.qpid.transport.network.mina.MINANetworkDriver.messageReceived(MINANetworkDriver.java:337)
at
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at
org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243)
at
org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:662)
My Polling message logic looks like :
Connection con = // create Connection
Session session = con.createSession(false,Session.AUTO_ACKNOWLEDGE);
Destination destination = context.lookup(name);
MessageConsumer consumer =session.createConsumer(destination);
Object msg = consumer.receive(1000);
Any idea on whats happening and how to overcome this issue is highly
appreciated.
thanks,
Charith
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
-
To unsubscribe, e-mail:
[jira] [Assigned] (QPID-3979) Last value queue memory leak
[ https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-3979: --- Assignee: Philip Harvey 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 Assignee: 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] [Assigned] (QPID-3979) Last value queue memory leak
[ https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned QPID-3979: --- Assignee: Keith Wall (was: Philip Harvey) Keith - please commit the patch. 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 Assignee: Keith Wall Attachments: 0001-QPID-3979-Java-Broker-Conflation-queues.patch 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] [Updated] (QPID-3979) Last value queue memory leak
[ https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-3979: Attachment: 0001-QPID-3979-Java-Broker-Conflation-queues.patch Attached patch to be committed to SVN. The patch fixes a bug in ConflationQueueList.add and adds a conflation queue system test to exercise parallel producer/consumer operation. 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 Assignee: Philip Harvey Attachments: 0001-QPID-3979-Java-Broker-Conflation-queues.patch 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
Re: Qpid broker gives out a warning when polling messages from a Queue.
Thanks Rob for the Quick response I'll check with the latest RC. In my case
i m using Qpid v 0.10
regards,
Charith
On Fri, May 11, 2012 at 3:02 PM, Rob Godfrey rob.j.godf...@gmail.comwrote:
Hi Charith,
can you confirm which release version of the Java Broker you are using
(it's always worth trying the latest version - in this case I'd grab
the latest 0.16 RC that Justin posted a couple of days ago - though
I'm not aware of any bugs that would cause this error)?
It would also help if you could send full broker log files that are
generated when this occurs - the best way is to raise a JIRA and
attach the log file there (stripped of any confidential information it
might contain - obviously).
Cheers,
Rob
On 11 May 2012 11:24, Charith Wickramarachchi
charith.dhanus...@gmail.com wrote:
Hi,
I m using qpid java jms client to publish and consume messages from a
queue
in Qpid java broker.
When my application polling messages from a queue. Broker gives out a
warning :
WARN
{org.apache.qpid.server.subscription.ExplicitAcceptDispositionChangeListener}
- MessageAccept received for message which has not been acquired (likely
client error)
And if continue this publish poll scenario for some time i can see
following log in the Broker logs.
{org.apache.qpid.transport.network.mina.MINANetworkDriver} - Exception
thrown and no ProtocolEngine to handle it
org.apache.qpid.transport.ProtocolViolationException: Received frames for
an already dettached session
at
org.apache.qpid.transport.Connection.dispatch(Connection.java:408)
at
org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:64)
at
org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:40)
at
org.apache.qpid.transport.MethodDelegate.sessionKnownCompleted(MethodDelegate.java:95)
at
org.apache.qpid.transport.SessionKnownCompleted.dispatch(SessionKnownCompleted.java:96)
at
org.apache.qpid.transport.ConnectionDelegate.control(ConnectionDelegate.java:49)
at
org.apache.qpid.transport.ConnectionDelegate.control(ConnectionDelegate.java:40)
at org.apache.qpid.transport.Method.delegate(Method.java:163)
at
org.apache.qpid.transport.Connection.received(Connection.java:369)
at
org.apache.qpid.server.transport.ServerConnection.received(ServerConnection.java:196)
at
org.apache.qpid.server.transport.ServerConnection.received(ServerConnection.java:53)
at
org.apache.qpid.transport.network.Assembler.emit(Assembler.java:95)
at
org.apache.qpid.transport.network.Assembler.assemble(Assembler.java:181)
at
org.apache.qpid.transport.network.Assembler.frame(Assembler.java:129)
at
org.apache.qpid.transport.network.Frame.delegate(Frame.java:133)
at
org.apache.qpid.transport.network.Assembler.received(Assembler.java:100)
at
org.apache.qpid.transport.network.Assembler.received(Assembler.java:42)
at
org.apache.qpid.transport.network.InputHandler.next(InputHandler.java:187)
at
org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:103)
at
org.apache.qpid.transport.network.InputHandler.received(InputHandler.java:42)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:102)
at
org.apache.qpid.server.protocol.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:36)
at
org.apache.qpid.transport.network.mina.MINANetworkDriver.messageReceived(MINANetworkDriver.java:337)
at
org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at
org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:54)
at
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at
org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:243)
at
org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:305)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
at java.lang.Thread.run(Thread.java:662)
My Polling message logic looks like :
Connection con = // create Connection
Session session =
con.createSession(false,Session.AUTO_ACKNOWLEDGE);
Destination destination = context.lookup(name);
MessageConsumer consumer
[jira] [Created] (QPID-3993) [Java AMQP 1.0] NPE on receiving continuation transfers which do not have the delvieryId set
Rob Godfrey created QPID-3993: - Summary: [Java AMQP 1.0] NPE on receiving continuation transfers which do not have the delvieryId set Key: QPID-3993 URL: https://issues.apache.org/jira/browse/QPID-3993 Project: Qpid Issue Type: Bug Components: Java Broker, Java Common Affects Versions: 0.17 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 The SessionEndpoint is trying to lookup the delivery using the deliveryId, but this can be ommitted on conitnuation transfers. The LinkEndpoint needs to store the deliveryId of any non-complete transfers -- 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-3993) [Java AMQP 1.0] NPE on receiving continuation transfers which do not have the delvieryId set
[ https://issues.apache.org/jira/browse/QPID-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved QPID-3993. --- Resolution: Fixed [Java AMQP 1.0] NPE on receiving continuation transfers which do not have the delvieryId set Key: QPID-3993 URL: https://issues.apache.org/jira/browse/QPID-3993 Project: Qpid Issue Type: Bug Components: Java Broker, Java Common Affects Versions: 0.17 Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.17 The SessionEndpoint is trying to lookup the delivery using the deliveryId, but this can be ommitted on conitnuation transfers. The LinkEndpoint needs to store the deliveryId of any non-complete transfers -- 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: [VOTE] Release 0.16
+1 - Original Message - From: Justin Ross jr...@redhat.com To: dev@qpid.apache.org Sent: Wednesday, May 9, 2012 8:57:47 PM Subject: [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 - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [VOTE] Release 0.16
+1 On 05/09/2012 08:57 PM, Justin Ross 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
Re: [VOTE] Release 0.16
On Wed, May 09, 2012 at 08:57:47PM -0400, Justin Ross 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. +1 -- 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/ pgpE30b7poiTl.pgp Description: PGP signature
[jira] [Updated] (QPID-3979) Last value queue memory leak
[ https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3979: - Status: Ready To Review (was: In Progress) 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 Assignee: Keith Wall Attachments: 0001-QPID-3979-Java-Broker-Conflation-queues.patch 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] [Resolved] (QPID-3979) Last value queue memory leak
[ https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-3979. -- Resolution: Fixed 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 Assignee: Keith Wall Attachments: 0001-QPID-3979-Java-Broker-Conflation-queues.patch 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] [Assigned] (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:all-tabpanel ] Keith Wall reassigned QPID-3980: Assignee: Keith Wall 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 Assignee: Keith Wall Fix For: 0.17 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] [Updated] (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:all-tabpanel ] Keith Wall updated QPID-3980: - Fix Version/s: 0.17 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 Fix For: 0.17 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] [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=13273343#comment-13273343 ] Keith Wall commented on QPID-3979: -- Patch applied. 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 Assignee: Keith Wall Attachments: 0001-QPID-3979-Java-Broker-Conflation-queues.patch 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] [Updated] (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:all-tabpanel ] Keith Wall updated QPID-3980: - Status: Ready To Review (was: In Progress) 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 Assignee: Keith Wall Fix For: 0.17 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] [Resolved] (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:all-tabpanel ] Keith Wall resolved QPID-3980. -- Resolution: Fixed 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 Assignee: Keith Wall Fix For: 0.17 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-3994) enable use of Ivy to retrieve dependencies for the Java components
Robbie Gemmell created QPID-3994: Summary: enable use of Ivy to retrieve dependencies for the Java components Key: QPID-3994 URL: https://issues.apache.org/jira/browse/QPID-3994 Project: Qpid Issue Type: Task Components: Java Broker, Java Broker BDB Store, Java Client, Java Common, Java Performance Tests, Java Tests, Java Tools, JCA Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.17 Enable use of Ivy to retrieve dependencies for the Java components. This will alllow us to stop putting binaries into svn, reducing checkout times and the size of the 'source' release artefacts. -- 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: Release artifacts (was: [VOTE] Release 0.16)
Justin, Robbie, I tested Java Broker, Java Client and Management Console artefacts. Everything worked fine for me. No issue is found. Details of the tests: Started Java Broker. Created test queue using Management Console and bound that queue to the direct exchange. Published test messages into the test queue using Spout example. Consumed test messages from the test queue using Drain example. Used Management Console to verify test queue attributes before and after publishing and consuming. The scenario above was used to test broker with Memory message store and Berkeley Message Store. I have not tested maven artefacts. Kind Regards, Alex - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-3979) Last value queue memory leak
[ https://issues.apache.org/jira/browse/QPID-3979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3979: - Attachment: config-long-lvq-test-1p1c-with-asc-keys.json config-long-lvq-test-1p0c-with-two-keys.json 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 Assignee: Keith Wall Attachments: 0001-QPID-3979-Java-Broker-Conflation-queues.patch, config-long-lvq-test-1p0c-with-two-keys.json, config-long-lvq-test-1p1c-with-asc-keys.json 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] [Updated] (QPID-3994) enable use of Ivy to retrieve dependencies for the Java components
[ https://issues.apache.org/jira/browse/QPID-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3994: - Status: Ready To Review (was: In Progress) enable use of Ivy to retrieve dependencies for the Java components -- Key: QPID-3994 URL: https://issues.apache.org/jira/browse/QPID-3994 Project: Qpid Issue Type: Task Components: Java Broker, Java Broker BDB Store, Java Client, Java Common, Java Performance Tests, Java Tests, Java Tools, JCA Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.17 Enable use of Ivy to retrieve dependencies for the Java components. This will alllow us to stop putting binaries into svn, reducing checkout times and the size of the 'source' release artefacts. -- 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] [Assigned] (QPID-3994) enable use of Ivy to retrieve dependencies for the Java components
[ https://issues.apache.org/jira/browse/QPID-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3994: Assignee: Rob Godfrey (was: Robbie Gemmell) Rob, can you review this change please? Robbie enable use of Ivy to retrieve dependencies for the Java components -- Key: QPID-3994 URL: https://issues.apache.org/jira/browse/QPID-3994 Project: Qpid Issue Type: Task Components: Java Broker, Java Broker BDB Store, Java Client, Java Common, Java Performance Tests, Java Tests, Java Tools, JCA Reporter: Robbie Gemmell Assignee: Rob Godfrey Fix For: 0.17 Enable use of Ivy to retrieve dependencies for the Java components. This will alllow us to stop putting binaries into svn, reducing checkout times and the size of the 'source' release artefacts. -- 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: Setting up SSL certs to run broker on Windows
Not terribly simple, but this is a good place to start. Yes, it talks in terms of IIS... that's the way I got it to work way back when. http://technet.microsoft.com/en-us/library/cc732230.aspx -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Thursday, May 10, 2012 5:23 PM To: Qpid Dev List; Steve Huston; Clifford Jansen Subject: Setting up SSL certs to run broker on Windows Simple enough question - how do I set up the appropriate certificates and certificate stores to get ssl working on a C++ windows broker? (I hope that answer's simple too, but I have some doubts!) Thanks Andrew - 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
Re: Setting up SSL certs to run broker on Windows
Here is a recipe for using the tools you are used to on Linux and
interoperating with Windows. Hopefully you can find the info you are
looking for buried inside.
For general info, see qpid/cpp/SSL and note in particular that the
current Qpid implementation is Registry based. Type qpidd --help
for ssl specific args.
I tried to avoid the GUI on Windows but failed, sorry. I was also
unable to find any way to create a new certificate store without the
hack of creating a sacrificial self signed cert first.
notused.example.com is that sacrificial cert.
I had to run mmc, makecert, and qpidd as an administrator. I could
run qpid-perftest without exalted privilege.
I used two separate stores on Linux, but that wasn't necessary.
CASE 1: Windows client + Linux broker (linux1.example.com)
[ on Linux ]
$ pwd
/b/amqp/b/q16b9/ssltest/l
$ export QPID_SSL_CERT_PASSWORD_FILE=`pwd`/pwf
$ export QPID_SSL_CERT_DB=`pwd`/db
$ export QPID_SSL_CERT_NAME=linux1.example.com
$ echo secret pwf
$ mkdir db
$ certutil -N -d ${QPID_SSL_CERT_DB} -f ${QPID_SSL_CERT_PASSWORD_FILE}
$ certutil -S -d ${QPID_SSL_CERT_DB} -n ${QPID_SSL_CERT_NAME} -s
CN=${QPID_SSL_CERT_NAME} -t CT,, -x -f ${QPID_SSL_CERT_PASSWORD_FILE} -v 36
[ entropy stuff ... ]
$
$ /b/amqp/b/q16b9/rt/sbin/qpidd --auth no -p 18641 --ssl-cert-password-file
$QPID_SSL_CERT_PASSWORD_FILE --ssl-cert-name $QPID_SSL_CERT_NAME --ssl-port
18642 --ssl-cert-db $QPID_SSL_CERT_DB --module-dir
/b/amqp/b/q16b9/rt/lib/qpid/daemon
[1] 20016
$
[export cert]
$ certutil -L -d ${QPID_SSL_CERT_DB} -n ${QPID_SSL_CERT_NAME} -f
${QPID_SSL_CERT_PASSWORD_FILE} -a /tmp/linux1.pub.cer
[ on Windows ]
mmc [run as administrator]
File-snap-in-Certificates-add
Computer account [not User or Service] - Local computer
Certificates- Trusted Root CAs - right click - all tasks - Import...
[in wizard] - browse to linux1.pub.cer - open - finish
PS C:\cj\work\amqp\wcf\q1701\bin .\qpid-perftest.exe -b linux1.example.com -p
5672 -P ssl --count 1 --summary
CASE 2: Windows broker (win1.example.com) + Linux client
$ mkdir db
$ echo secret pwf
$ export QPID_SSL_CERT_PASSWORD_FILE=`pwd`/pwf
$ export QPID_SSL_CERT_DB=`pwd`/db
$ pwd
/b/amqp/b/q16b9/ssltest/w
$
$ certutil -N -d ${QPID_SSL_CERT_DB} -f ${QPID_SSL_CERT_PASSWORD_FILE}
$
$ export QPID_SSL_CERT_NAME=win1.example.com
$ certutil -S -d ${QPID_SSL_CERT_DB} -n ${QPID_SSL_CERT_NAME} -s
CN=${QPID_SSL_CERT_NAME} -t CT,, -x -f ${QPID_SSL_CERT_PASSWORD_FILE} -v 36
[entropy stuff]
[ this time need to export private key too, so use pk12util ]
$ pk12util -o win1.p12 -n ${QPID_SSL_CERT_NAME} -d ${QPID_SSL_CERT_DB}
Enter Password or Pin for NSS Certificate DB:secret
Enter password for PKCS12 file: very_secret
Re-enter password: very_secret
pk12util: PKCS12 EXPORT SUCCESSFUL
$
[ on Windows ]
[ hack to create qpidtest certificate store ]
cd C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin
makecert -ss qpidtest -n CN=notused.example.com -r -sr localmachine
notused.cer
[ import the cert for win1.example.com ]
same mmc GUI steps except
right click from qpidtest store you just created
browse to win1.p12 and select file type PKCS#12 if it is not listed
PS C:\cj\work\amqp\wcf\q1701\bin .\qpidd.exe --auth no --no-data-dir
--ssl-cert-store qpidtest --ssl-cert-name win1.example.com
[ back on Linux ]
$ export QPID_LOAD_MODULE=/b/amqp/b/q16b9/rt/lib/qpid/client/sslconnector.so
$ env | grep QPID
QPID_LOAD_MODULE=/b/amqp/b/q16b9/rt/lib/qpid/client/sslconnector.so
QPID_SSL_CERT_DB=/b/amqp/b/q16b9/ssltest/w/db
QPID_SSL_CERT_NAME=win1.example.com
QPID_SSL_CERT_PASSWORD_FILE=/b/amqp/b/q16b9/ssltest/w/pwf
$ /b/amqp/b/q16b9/rt/libexec/qpid/tests/qpid-perftest -p 5671 --count 1 -P
ssl --summary -b win1.example.com
464.89 452.492 918.965 0.897427
$
- Original Message -
From: Andrew Stitcher astitc...@redhat.com
To: Qpid Dev List dev@qpid.apache.org, Steve Huston
shus...@riverace.com, Clifford Jansen cjan...@redhat.com
Sent: Thursday, May 10, 2012 5:23:26 PM
Subject: Setting up SSL certs to run broker on Windows
Simple enough question - how do I set up the appropriate certificates
and certificate stores to get ssl working on a C++ windows broker?
(I hope that answer's simple too, but I have some doubts!)
Thanks
Andrew
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-2518) Qpid C++ broker can easily be blocked by client trying to connect over SSL port
[ https://issues.apache.org/jira/browse/QPID-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13273591#comment-13273591 ] Andrew Stitcher commented on QPID-2518: --- This bug also applies to regular TCP connections Qpid C++ broker can easily be blocked by client trying to connect over SSL port --- Key: QPID-2518 URL: https://issues.apache.org/jira/browse/QPID-2518 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Red Hat Enterprise MRG 1.2 Reporter: Armin Noll Assignee: Andrew Stitcher We are running a C++ broker as deamon with the following configuration: log-enable=info+ log-to-file=/var/lib/qpidd/op_prod09/data/0097/qpidd.log log-to-syslog=no auth=yes acl-file=qpidd.acl realm=QPID0097 data-dir=/var/lib/qpidd/op_prod09/data/0097 pid-dir=/var/lib/qpidd/op_prod09/data/0097 port=20097 wait=30 num-jfiles=4 jfile-size-pgs=1 wcache-page-size=128 tpl-num-jfiles=4 tpl-jfile-size-pgs=1 tpl-wcache-page-size=128 ssl-cert-db=/var/lib/qpidd/op_prod09/data/0097 ssl-port=10097 ssl-cert-name=RGC001 ssl-cert-password-file=/var/lib/qpidd/op_prod09/data/0097/amq_cert_db.pwd ssl-require-client-authentication=yes cluster-name=QPID0097 cluster-url=amqp:tcp:172.16.45.198:20097 cluster-username=x cluster-password=x We tried to connect an application to the SSL port which does not talk the correct protocol. We simply used telnet: $ telnet 172.16.45.198 10097 The result was (we waited at least 30 min, then killed the process running telnet): The broker doesn't react anymore, no more new client connections can be established, the broker even cannot be stopped with qpidd -p 20097 -q. This way anybody in the world could easily block our service provided over a Qpid broker. Is there a way to get around this? This issue has also been reported as Red Hat service request no. 2014266. -- 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] [Reopened] (QPID-2518) Qpid C++ broker can easily be blocked by client trying to connect over SSL port
[ https://issues.apache.org/jira/browse/QPID-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reopened QPID-2518: --- Assignee: Andrew Stitcher As far as I can tell this bug is still present. Despite any comments above. Qpid C++ broker can easily be blocked by client trying to connect over SSL port --- Key: QPID-2518 URL: https://issues.apache.org/jira/browse/QPID-2518 Project: Qpid Issue Type: Bug Components: C++ Broker Environment: Red Hat Enterprise MRG 1.2 Reporter: Armin Noll Assignee: Andrew Stitcher We are running a C++ broker as deamon with the following configuration: log-enable=info+ log-to-file=/var/lib/qpidd/op_prod09/data/0097/qpidd.log log-to-syslog=no auth=yes acl-file=qpidd.acl realm=QPID0097 data-dir=/var/lib/qpidd/op_prod09/data/0097 pid-dir=/var/lib/qpidd/op_prod09/data/0097 port=20097 wait=30 num-jfiles=4 jfile-size-pgs=1 wcache-page-size=128 tpl-num-jfiles=4 tpl-jfile-size-pgs=1 tpl-wcache-page-size=128 ssl-cert-db=/var/lib/qpidd/op_prod09/data/0097 ssl-port=10097 ssl-cert-name=RGC001 ssl-cert-password-file=/var/lib/qpidd/op_prod09/data/0097/amq_cert_db.pwd ssl-require-client-authentication=yes cluster-name=QPID0097 cluster-url=amqp:tcp:172.16.45.198:20097 cluster-username=x cluster-password=x We tried to connect an application to the SSL port which does not talk the correct protocol. We simply used telnet: $ telnet 172.16.45.198 10097 The result was (we waited at least 30 min, then killed the process running telnet): The broker doesn't react anymore, no more new client connections can be established, the broker even cannot be stopped with qpidd -p 20097 -q. This way anybody in the world could easily block our service provided over a Qpid broker. Is there a way to get around this? This issue has also been reported as Red Hat service request no. 2014266. -- 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
Info
Hi , I am trying to understand and I cannot find the answer in any places I have looked at. Can someone answer the following: 1. If we have a multiple card system and there are local qpidd C++ brokers that are to be run on each card. If each broker starts up independently, do they find out about each other automatically if there is network connectivity between all the cards ( I mean IP connectivity)? Can you elaborate on how this works if possible ( I tried to look at the AMQP standard to see if I can work it out). 2. If a message is sent to a particular client queue, is my assumption right when I say that only the addressed client get the message and no other broker is sent the same message? In other words, no broadcasting/multicasting is taking place. Thanks Nitin [cid:image001.png@01CD2F92.F8E0DFB0]
RE: Info
Hi Nitin, 1. No, different brokers would not automatically learn about each other. 2. Correct, there is no broadcast/multicast taking place. -Steve From: Nitin Shah [mailto:ns...@btisystems.com] Sent: Friday, May 11, 2012 4:41 PM To: dev@qpid.apache.org Subject: Info Hi , I am trying to understand and I cannot find the answer in any places I have looked at. Can someone answer the following: 1. If we have a multiple card system and there are local qpidd C++ brokers that are to be run on each card. If each broker starts up independently, do they find out about each other automatically if there is network connectivity between all the cards ( I mean IP connectivity)? Can you elaborate on how this works if possible ( I tried to look at the AMQP standard to see if I can work it out). 2. If a message is sent to a particular client queue, is my assumption right when I say that only the addressed client get the message and no other broker is sent the same message? In other words, no broadcasting/multicasting is taking place. Thanks Nitin Description: bti_logo_small
[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=13273742#comment-13273742 ] jirapos...@reviews.apache.org commented on QPID-3990: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5079/#review7820 --- Based on the description of the problem and the proposed solution the code appears to be doing whats expected. There are a few whitespace errors that could be removed. On eclipse ctr-a and ctr-i should take care of it provided you have set tabs to whitespace. For my own understand, could you please explain if there could be any implications/corner cases when a particular XAResource calls start and end on the other XAResources participating in the transaction even though they are all managed by the same Resource Manager. In particular is there some sort of ordering that should be preserved when this is called? How about error handling? What if one of the XAResources fail/throw exception when start or end is called ? (I assume under normal circumstances the RM would call these methods and would be in a position to handle these situations. In the above case the XAResource (all though being called by an RM) would act as a proxy for it's siblings). Is my understanding correct ? If not are you able to briefly explain the flow here ? - rajith On 2012-05-09 17:41:59, Weston Price wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/5079/ bq. --- bq. bq. (Updated 2012-05-09 17:41:59) bq. bq. bq. Review request for Ted Ross, Robbie Gemmell, rajith attapattu, and Rob Godfrey. bq. bq. bq. Summary bq. --- bq. bq. 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. bq. bq. 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. bq. bq. 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. bq. bq. bq. This addresses bug QPID-3990. bq. https://issues.apache.org/jira/browse/QPID-3990 bq. bq. bq. Diffs bq. - bq. bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQXAResource.java PRE-CREATION bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/XAResourceImpl.java 1336275 bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/jca/src/main/java/org/apache/qpid/ra/QpidRAXAResource.java 1336275 bq. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/jms/xa/XAResourceTest.java 1336275 bq. bq. Diff: https://reviews.apache.org/r/5079/diff bq. bq. bq. Testing bq. --- bq. bq. Added system test to XAResourceTest to exercise new behavior. Tested against both the Java and C++ Brokers using the 0.10 profile. bq. bq. bq. Thanks, bq. bq. Weston bq. bq. 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
