[jira] Created: (AMQ-1113) ActiveMQConsumer can catch an error in dispatch but logs it as a warning
ActiveMQConsumer can catch an error in dispatch but logs it as a warning Key: AMQ-1113 URL: https://issues.apache.org/activemq/browse/AMQ-1113 Project: ActiveMQ Issue Type: Bug Components: JMS client Reporter: Rob Davies Assigned To: Rob Davies Priority: Minor Fix For: 4.2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-1113) ActiveMQConsumer can catch an error in dispatch but logs it as a warning
[ https://issues.apache.org/activemq/browse/AMQ-1113?page=all ] Rob Davies resolved AMQ-1113. - Resolution: Fixed Fixed by SVN revision 490967 ActiveMQConsumer can catch an error in dispatch but logs it as a warning Key: AMQ-1113 URL: https://issues.apache.org/activemq/browse/AMQ-1113 Project: ActiveMQ Issue Type: Bug Components: JMS client Reporter: Rob Davies Assigned To: Rob Davies Priority: Minor Fix For: 4.2.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r490789 - /incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/TransportConnection.java
ah - ok - I'll look at servicing the async error from the transport
thread
cheers,
Rob
On 29 Dec 2006, at 17:52, Hiram Chirino wrote:
Hi Rob,
The connection actually has some concurrency to it. This is when an
async error is detected on the connection. Those syncs where there to
ensure that proper cleanup was performed. I.e. if the connection is
adding a consumer and and publisher detects that the consumer failed
it will clean up the consumer's connection and it might not do it
properly if the consumer subscription was still being setup.
so in short that's why the syncs were in place. If we could get the
async errors to get serviced from the transport's thread then we could
eliminate the syncs.
On 12/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: rajdavies
Date: Thu Dec 28 12:44:59 2006
New Revision: 490789
URL: http://svn.apache.org/viewvc?view=revrev=490789
Log:
drop synchronization from connectionState and connection context -
not required when using ConcurrentHashMap and limited concurrency for
publishers or transactions for the same client connection
Modified:
incubator/activemq/trunk/activemq-core/src/main/java/org/
apache/activemq/broker/TransportConnection.java
Modified: incubator/activemq/trunk/activemq-core/src/main/java/org/
apache/activemq/broker/TransportConnection.java
URL: http://svn.apache.org/viewvc/incubator/activemq/trunk/
activemq-core/src/main/java/org/apache/activemq/broker/
TransportConnection.java?view=diffrev=490789r1=490788r2=490789
=
=
--- incubator/activemq/trunk/activemq-core/src/main/java/org/
apache/activemq/broker/TransportConnection.java (original)
+++ incubator/activemq/trunk/activemq-core/src/main/java/org/
apache/activemq/broker/TransportConnection.java Thu Dec 28
12:44:59 2006
@@ -352,7 +352,7 @@
return null;
}
-synchronized public Response processBeginTransaction
(TransactionInfo info) throws Exception {
+public Response processBeginTransaction(TransactionInfo info)
throws Exception {
ConnectionState cs = (ConnectionState)
localConnectionStates.get(info.getConnectionId());
ConnectionContext context=null;
if( cs!=null ) {
@@ -367,14 +367,14 @@
return null;
}
-synchronized public Response processEndTransaction
(TransactionInfo info) throws Exception {
+public Response processEndTransaction(TransactionInfo info)
throws Exception {
// No need to do anything. This packet is just sent by
the client
// make sure he is synced with the server as commit
command could
// come from a different connection.
return null;
}
-synchronized public Response processPrepareTransaction
(TransactionInfo info) throws Exception {
+public Response processPrepareTransaction(TransactionInfo
info) throws Exception {
ConnectionState cs = (ConnectionState)
localConnectionStates.get(info.getConnectionId());
ConnectionContext context=null;
if( cs!=null ) {
@@ -398,7 +398,7 @@
}
}
-synchronized public Response processCommitTransactionOnePhase
(TransactionInfo info) throws Exception {
+public Response processCommitTransactionOnePhase
(TransactionInfo info) throws Exception {
ConnectionState cs = (ConnectionState)
localConnectionStates.get(info.getConnectionId());
ConnectionContext context=null;
if( cs!=null ) {
@@ -412,7 +412,7 @@
}
-synchronized public Response processCommitTransactionTwoPhase
(TransactionInfo info) throws Exception {
+public Response processCommitTransactionTwoPhase
(TransactionInfo info) throws Exception {
ConnectionState cs = (ConnectionState)
localConnectionStates.get(info.getConnectionId());
ConnectionContext context=null;
if( cs!=null ) {
@@ -424,7 +424,7 @@
return null;
}
-synchronized public Response processRollbackTransaction
(TransactionInfo info) throws Exception {
+public Response processRollbackTransaction(TransactionInfo
info) throws Exception {
ConnectionState cs = (ConnectionState)
localConnectionStates.get(info.getConnectionId());
ConnectionContext context=null;
if( cs!=null ) {
@@ -436,7 +436,7 @@
return null;
}
-synchronized public Response processForgetTransaction
(TransactionInfo info) throws Exception {
+public Response processForgetTransaction(TransactionInfo
info) throws Exception {
ConnectionState cs = (ConnectionState)
localConnectionStates.get(info.getConnectionId());
ConnectionContext context=null;
if( cs!=null ) {
@@ -446,7 +446,7 @@
return null;
}
-synchronized public Response processRecoverTransactions
(TransactionInfo info) throws Exception {
+public Response processRecoverTransactions(TransactionInfo
info) throws Exception {
[jira] Assigned: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2
[ https://issues.apache.org/activemq/browse/AMQ-961?page=all ] Rob Davies reassigned AMQ-961: -- Assignee: Rob Davies Problem with subscription passing with network of brokers in AMQ 4.0.2 -- Key: AMQ-961 URL: https://issues.apache.org/activemq/browse/AMQ-961 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Kevin Yaussy Assigned To: Rob Davies Priority: Critical Attachments: RestartDFBOnResume.diff There's an occasional problem with subscription propagation when using a network of brokers. Test scenario uses ConsumerTool and PublisherTool in examples area of distribution. 1) Start broker A (has a network connection to broker B) 2) Start broker B (has a network connection to broker A) 3) start consumer C against broker A, on FOO 4) start publisher P against broker B, on FOO Messages do not flow to consumer C. In the broker B log, there's no indication it got any subscriptions from broker A. Again, this is occasional. I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine. There's an obvious difference in one of the threads that hopefully will bring light to the problem. I've not gone into the code yet to try and find the issue, but figured I would open this issue first. Stack trace of broker A when subscriptions did NOT pass, and message flow is broken: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8 e2ff000..0x8e2ff8f0] at java.lang.Object.wait(Native Method) - waiting on 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179) - locked 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport .java:830) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid geSupport.java:329) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport .java:130) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Stack trace of broker A when everything works correctly: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2
[ https://issues.apache.org/activemq/browse/AMQ-961?page=all ] Rob Davies resolved AMQ-961. Fix Version/s: 4.2.0 Resolution: Fixed Applied patch in SVN revision 491185 thanks kevin Yaussy! Problem with subscription passing with network of brokers in AMQ 4.0.2 -- Key: AMQ-961 URL: https://issues.apache.org/activemq/browse/AMQ-961 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Kevin Yaussy Assigned To: Rob Davies Priority: Critical Fix For: 4.2.0 Attachments: RestartDFBOnResume.diff There's an occasional problem with subscription propagation when using a network of brokers. Test scenario uses ConsumerTool and PublisherTool in examples area of distribution. 1) Start broker A (has a network connection to broker B) 2) Start broker B (has a network connection to broker A) 3) start consumer C against broker A, on FOO 4) start publisher P against broker B, on FOO Messages do not flow to consumer C. In the broker B log, there's no indication it got any subscriptions from broker A. Again, this is occasional. I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine. There's an obvious difference in one of the threads that hopefully will bring light to the problem. I've not gone into the code yet to try and find the issue, but figured I would open this issue first. Stack trace of broker A when subscriptions did NOT pass, and message flow is broken: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8 e2ff000..0x8e2ff8f0] at java.lang.Object.wait(Native Method) - waiting on 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179) - locked 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport .java:830) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid geSupport.java:329) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport .java:130) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Stack trace of broker A when everything works correctly: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=all ] Rob Davies resolved AMQ-776. Fix Version/s: 4.2.0 (was: 4.0.3) Resolution: Fixed patch applied for associated issue: http://issues.apache.org/activemq/browse/AMQ-961 ConduitBridge can malfunction when first of a set of consumers goes away Key: AMQ-776 URL: https://issues.apache.org/activemq/browse/AMQ-776 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Reporter: Kevin Yaussy Assigned To: Rob Davies Priority: Critical Fix For: 4.2.0 Attachments: ConduitBridge.patch, DemandForwardingBridgeSupport.patch When the following scenario is followed, any of the subsequent consumers will stop receiving messages. I've reproduced this using the ConsumerTool, and ProducerTool supplied in the example area of the distribution. +++ Start Broker A Start Broker B Start Consumer 1, connecting to Broker B, consuming FOO Start Consumer 2, connecting to Broker B, consuming FOO Start Publisher, connecting to Broker A, publishing FOO Ctl-C out of Consumer 1 Consumer 2 stops receiving messages +++ Seems to me that ConduitBridge is supposed to track all consumers for a given subscription, by way of DemandSubscription. It is seeding DemandSubscription with the originating consumer, but when subsequent consumers are added, the ConduitBridge::addToAlreadyInterestedConsumers re-adds the original subscriber to the DemandSubscription's map - so the map only ever has the original subscription. I've attached a patch. Hope the change is good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
