[jira] Commented: (AMQ-1121) Kaha DB hangs on restart
[ https://issues.apache.org/activemq/browse/AMQ-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37823 ] Rob Davies commented on AMQ-1121: - could you provide a test case ? Kaha DB hangs on restart Key: AMQ-1121 URL: https://issues.apache.org/activemq/browse/AMQ-1121 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1.0 Environment: Windows XP, NetApp Reporter: Vadim Pesochinskiy Assigned To: Rob Davies Priority: Blocker Fix For: 4.1.0 I run a bunch or messages through AMQ, then restarted AMQ and it hangs. Following are the last messages that I see. AMQ is not listening on the configured port. 2007-01-06 01:35:29,723 [main ] DEBUG DataManager - End of data file reached at (header was invalid): offset = 810, file = 1, size = 219 2007-01-06 01:35:29,754 [JMX connector ] INFO ManagementContext - JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:11099/jmxrmi 2007-01-06 01:35:32,660 [main ] DEBUG DataManager - End of data file reached at (header was invalid): offset = 88244949, file = 5, size = 100856 -- 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] Assigned: (AMQ-1121) Kaha DB hangs on restart
[ https://issues.apache.org/activemq/browse/AMQ-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies reassigned AMQ-1121: --- Assignee: Rob Davies Kaha DB hangs on restart Key: AMQ-1121 URL: https://issues.apache.org/activemq/browse/AMQ-1121 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1.0 Environment: Windows XP, NetApp Reporter: Vadim Pesochinskiy Assigned To: Rob Davies Priority: Blocker Fix For: 4.1.0 I run a bunch or messages through AMQ, then restarted AMQ and it hangs. Following are the last messages that I see. AMQ is not listening on the configured port. 2007-01-06 01:35:29,723 [main ] DEBUG DataManager - End of data file reached at (header was invalid): offset = 810, file = 1, size = 219 2007-01-06 01:35:29,754 [JMX connector ] INFO ManagementContext - JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:11099/jmxrmi 2007-01-06 01:35:32,660 [main ] DEBUG DataManager - End of data file reached at (header was invalid): offset = 88244949, file = 5, size = 100856 -- 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] Assigned: (AMQ-1117) It would be helpful if some of the log messages that are logged at higher severity levels than they are presently
[ https://issues.apache.org/activemq/browse/AMQ-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies reassigned AMQ-1117: --- Assignee: Rob Davies It would be helpful if some of the log messages that are logged at higher severity levels than they are presently - Key: AMQ-1117 URL: https://issues.apache.org/activemq/browse/AMQ-1117 Project: ActiveMQ Issue Type: Wish Affects Versions: 4.0, 4.0.1, 4.0.2, 4.1.0 Reporter: Chris Hofstaedter Assigned To: Rob Davies It would be helpful if the messages pertaining to transport interrupted and transport resumed were logged at INFO rather than DEBUG. It would be helpful if the messages pertaining to security errors were logged at ERROR rather than INFO. All of these log messages are in DemandForwardingBridgeSupport in the following functions: public void start() // for Transport Interrupted public void start() // for Transport Resumed protected void serviceRemoteException() // for Security errors -- 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-1117) It would be helpful if some of the log messages that are logged at higher severity levels than they are presently
[ https://issues.apache.org/activemq/browse/AMQ-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies resolved AMQ-1117. - Resolution: Fixed Fix Version/s: 4.2.0 resolved SVN revision 493696 It would be helpful if some of the log messages that are logged at higher severity levels than they are presently - Key: AMQ-1117 URL: https://issues.apache.org/activemq/browse/AMQ-1117 Project: ActiveMQ Issue Type: Wish Affects Versions: 4.0, 4.0.1, 4.0.2, 4.1.0 Reporter: Chris Hofstaedter Assigned To: Rob Davies Fix For: 4.2.0 It would be helpful if the messages pertaining to transport interrupted and transport resumed were logged at INFO rather than DEBUG. It would be helpful if the messages pertaining to security errors were logged at ERROR rather than INFO. All of these log messages are in DemandForwardingBridgeSupport in the following functions: public void start() // for Transport Interrupted public void start() // for Transport Resumed protected void serviceRemoteException() // for Security errors -- 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] Assigned: (AMQ-1005) Network of brokers duplicates events
[ https://issues.apache.org/activemq/browse/AMQ-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies reassigned AMQ-1005: --- Assignee: Rob Davies Network of brokers duplicates events Key: AMQ-1005 URL: https://issues.apache.org/activemq/browse/AMQ-1005 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1, 4.0.2 Reporter: Linda Floren Assigned To: Rob Davies Priority: Blocker Attachments: ConduitSubscriptionTest.java, SimpleMessageListener.java I've created a test scenario to reproduce the error: Two brokers A and B run with networkconnectors towards each other with conduitSubscriptions=false. The publisher is connected to broker A. There are n Subscribers with identical filters on each broker. Result: The subscribers on broker B receive each event n times. (The subscribers on broker A work fine). It appears as if the subscriptions are treated as conduit subscriptions in the dispatching process on broker B. I've attached my test. -- 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] Assigned: (AMQ-1119) Deadlock in MutexTransport on shutdown with high volume of messages
[
https://issues.apache.org/activemq/browse/AMQ-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies reassigned AMQ-1119:
---
Assignee: Rob Davies
Deadlock in MutexTransport on shutdown with high volume of messages
---
Key: AMQ-1119
URL: https://issues.apache.org/activemq/browse/AMQ-1119
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0, 4.0.1, 4.0.2
Environment: Windows XP, demand forwarding, failover == true
Reporter: Chris Hofstaedter
Assigned To: Rob Davies
I ran into a deadlock in the MutextTransport.oneway(Command command) function
when processing very high message volume (100% cpu utilization) at the time
of a shutdown. I'm running 4.0.2 on WinXP and within a demand forwarding
environment with failover = true.
I did trap this deadlock in the debugger and it looks like two commands are
crossing paths in opposite directions through the MutexTransport. One of the
commands is a MessageDispatch and the other is a ShutdownInfo. Now, when the
ShutdownInfo gets through the MutexTransport first, it tries to shutdown the
background thread of the TcpTransport. However, this thread is currently
servicing the MessageDispatch and is blocked on the MutexTransport. Deadlock.
So, my patch was simply to avoid entering the synchronized(writeMutex) block
in the oneway(Command command) function of MutexTransport if
command.isShutdownInfo() returns true:
if (command.isShutdownInfo())
next.oneway(command);
else
synchronized(writeMutex) {
next.oneway(command);
}
--
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] Assigned: (AMQ-1110) JMS to JMS Bridge fails with Number format exception on physical name
[
https://issues.apache.org/activemq/browse/AMQ-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies reassigned AMQ-1110:
---
Assignee: Rob Davies
JMS to JMS Bridge fails with Number format exception on physical name
-
Key: AMQ-1110
URL: https://issues.apache.org/activemq/browse/AMQ-1110
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 4.1.0
Environment: Using Windows XP SP2, JDK 1.6.0, Bea Weblogic Server 8.1
SP6
Reporter: Kay Stanke
Assigned To: Rob Davies
Attachments: activemq.xml
Maybe this is just some missconfiguration from my site but ...
I'm trying to use activemq to integrate some c++ code with the j2ee world. My
task is to forward messages generated on the c++ side to the JMS of Bea
Weblogic 8.1. ActiveMQ is running outside the WLS in a separate process. The
startup looks fine as the wls context can be used to get references to the
ConnectionFactory and the configured test destination WLSTestQ. On sending a
message to the local queue of the bridge i get the following stacktrace:
java.lang.NumberFormatException: For input string: WLSTESTQ
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
at
org.apache.activemq.command.ActiveMQTempDestination.setPhysicalName(ActiveMQTempDestination.java:66)
at
org.apache.activemq.command.ActiveMQDestination.init(ActiveMQDestination.java:142)
at
org.apache.activemq.command.ActiveMQTempDestination.init(ActiveMQTempDestination.java:38)
at
org.apache.activemq.command.ActiveMQTempQueue.init(ActiveMQTempQueue.java:36)
at
org.apache.activemq.command.ActiveMQDestination.transform(ActiveMQDestination.java:107)
at
org.apache.activemq.command.ActiveMQMessage.setJMSDestination(ActiveMQMessage.java:219)
at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:428)
at weblogic.jms.client.JMSProducer.send(JMSProducer.java:152)
at weblogic.jms.client.JMSProducer.send(JMSProducer.java:215)
at
org.apache.activemq.network.jms.QueueBridge.sendMessage(QueueBridge.java:87)
at
org.apache.activemq.network.jms.DestinationBridge.onMessage(DestinationBridge.java:134)
at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:840)
at
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:96)
at
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:165)
at
org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88)
at
org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:25)
at
org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39)
ERROR DestinationBridge - failed to forward message on attempt: 1
reason: java.lang.NumberFormatException:
For input string: WLSTESTQ message:
ActiveMQTextMessage {
commandId = 14,
responseRequired = false,
messageId = ID:KStanke-1523-1167310376227-0:0:1:1:10,
originalDestination = null,
originalTransactionId = null,
producerId = ID:KStanke-1523-1167310376227-0:0:1:1,
destination = queue://TEST.FOO,
transactionId = null,
expiration = 0,
timestamp = 1167310385795,
arrival = 0,
correlationId = null,
replyTo = null,
persistent = false,
type = null,
priority = 4,
groupID = null,
groupSequence = 0,
targetConsumerId = null,
compressed = false,
userID = null,
content = null,
marshalledProperties = null,
dataStructure = null,
redeliveryCounter = 0,
size = 0,
properties = null,
readOnlyProperties = true,
readOnlyBody = true,
droppable = false,
text = Message: 9 sent at: Thu Dec 28 13:53:05 CET 2006
[Skipped some blank lines]
}
I'm using the message producer from the example to test the routing to wls
JMS. I also attached my activemq.xml configuration for you reference.
--
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-1110) JMS to JMS Bridge fails with Number format exception on physical name
[
https://issues.apache.org/activemq/browse/AMQ-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Davies resolved AMQ-1110.
-
Resolution: Fixed
Fix Version/s: 4.2.0
Fixed by the latest SVN revision 491753
JMS to JMS Bridge fails with Number format exception on physical name
-
Key: AMQ-1110
URL: https://issues.apache.org/activemq/browse/AMQ-1110
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 4.1.0
Environment: Using Windows XP SP2, JDK 1.6.0, Bea Weblogic Server 8.1
SP6
Reporter: Kay Stanke
Assigned To: Rob Davies
Fix For: 4.2.0
Attachments: activemq.xml
Maybe this is just some missconfiguration from my site but ...
I'm trying to use activemq to integrate some c++ code with the j2ee world. My
task is to forward messages generated on the c++ side to the JMS of Bea
Weblogic 8.1. ActiveMQ is running outside the WLS in a separate process. The
startup looks fine as the wls context can be used to get references to the
ConnectionFactory and the configured test destination WLSTestQ. On sending a
message to the local queue of the bridge i get the following stacktrace:
java.lang.NumberFormatException: For input string: WLSTESTQ
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:447)
at java.lang.Integer.parseInt(Integer.java:497)
at
org.apache.activemq.command.ActiveMQTempDestination.setPhysicalName(ActiveMQTempDestination.java:66)
at
org.apache.activemq.command.ActiveMQDestination.init(ActiveMQDestination.java:142)
at
org.apache.activemq.command.ActiveMQTempDestination.init(ActiveMQTempDestination.java:38)
at
org.apache.activemq.command.ActiveMQTempQueue.init(ActiveMQTempQueue.java:36)
at
org.apache.activemq.command.ActiveMQDestination.transform(ActiveMQDestination.java:107)
at
org.apache.activemq.command.ActiveMQMessage.setJMSDestination(ActiveMQMessage.java:219)
at weblogic.jms.client.JMSProducer.sendInternal(JMSProducer.java:428)
at weblogic.jms.client.JMSProducer.send(JMSProducer.java:152)
at weblogic.jms.client.JMSProducer.send(JMSProducer.java:215)
at
org.apache.activemq.network.jms.QueueBridge.sendMessage(QueueBridge.java:87)
at
org.apache.activemq.network.jms.DestinationBridge.onMessage(DestinationBridge.java:134)
at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:840)
at
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:96)
at
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:165)
at
org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:88)
at
org.apache.activemq.thread.DedicatedTaskRunner.access$000(DedicatedTaskRunner.java:25)
at
org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:39)
ERROR DestinationBridge - failed to forward message on attempt: 1
reason: java.lang.NumberFormatException:
For input string: WLSTESTQ message:
ActiveMQTextMessage {
commandId = 14,
responseRequired = false,
messageId = ID:KStanke-1523-1167310376227-0:0:1:1:10,
originalDestination = null,
originalTransactionId = null,
producerId = ID:KStanke-1523-1167310376227-0:0:1:1,
destination = queue://TEST.FOO,
transactionId = null,
expiration = 0,
timestamp = 1167310385795,
arrival = 0,
correlationId = null,
replyTo = null,
persistent = false,
type = null,
priority = 4,
groupID = null,
groupSequence = 0,
targetConsumerId = null,
compressed = false,
userID = null,
content = null,
marshalledProperties = null,
dataStructure = null,
redeliveryCounter = 0,
size = 0,
properties = null,
readOnlyProperties = true,
readOnlyBody = true,
droppable = false,
text = Message: 9 sent at: Thu Dec 28 13:53:05 CET 2006
[Skipped some blank lines]
}
I'm using the message producer from the example to test the routing to wls
JMS. I also attached my activemq.xml configuration for you reference.
--
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] 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
[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
[jira] Created: (AMQ-1112) remove expired messages from Store and update Message cursors
remove expired messages from Store and update Message cursors - Key: AMQ-1112 URL: https://issues.apache.org/activemq/browse/AMQ-1112 Project: ActiveMQ Issue Type: Bug Components: Broker Reporter: Rob Davies Assigned To: Rob Davies Priority: Critical Fix For: 4.2.0 Ensure messages that are expired are removed from message store and message cursrors are also updated consistently -- 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] Assigned: (AMQ-1030) Pure master/slave not replicating messages
[ https://issues.apache.org/activemq/browse/AMQ-1030?page=all ] Rob Davies reassigned AMQ-1030: --- Assignee: Rob Davies Pure master/slave not replicating messages -- Key: AMQ-1030 URL: https://issues.apache.org/activemq/browse/AMQ-1030 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1.0 Environment: rhas4, sun jdk 1.5.0_08 Reporter: Mike Atkin Assigned To: Rob Davies Just did a fresh checkout of 4.1. The pure master/slave replication is not forwarding messages received by master leading to lost messages if master dies. Worked fine in rc-1. Logs on both instances show all the usual slave connected messages. -- 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] Assigned: (AMQ-1079) Slave Fail Error when Receiving message on a MasterSlave configuration
[ https://issues.apache.org/activemq/browse/AMQ-1079?page=all ] Rob Davies reassigned AMQ-1079: --- Assignee: Rob Davies Slave Fail Error when Receiving message on a MasterSlave configuration -- Key: AMQ-1079 URL: https://issues.apache.org/activemq/browse/AMQ-1079 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.2.0 Environment: Windows XP, jdk1.5 Reporter: Marlon Santos Assigned To: Rob Davies Fix For: 4.2.0 Attachments: ConsumerTool.java, MasterSlave.java, ProducerTool.java A slave fail error is caught while receiving message from master broker on a master slave configuration. I included the java files that I used. Running this through xbean/xml config also produces the same error. SEVERE: Slave Failed java.lang.AssertionError: Unsupported Method at org.apache.activemq.transport.TransportSupport.request(TransportSupport.java:71) at org.apache.activemq.transport.TransportFilter.request(TransportFilter.java:88) at org.apache.activemq.transport.TransportFilter.request(TransportFilter.java:88) at org.apache.activemq.transport.MutexTransport.request(MutexTransport.java:49) at org.apache.activemq.broker.ft.MasterBroker.sendSyncToSlave(MasterBroker.java:363) at org.apache.activemq.broker.ft.MasterBroker.sendToSlave(MasterBroker.java:345) at org.apache.activemq.broker.ft.MasterBroker.acknowledge(MasterBroker.java:320) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:88) at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:491) at org.apache.activemq.command.MessageAck.visit(MessageAck.java:179) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:287) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:178) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:133) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) 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-1079) Slave Fail Error when Receiving message on a MasterSlave configuration
[ https://issues.apache.org/activemq/browse/AMQ-1079?page=all ] Rob Davies resolved AMQ-1079. - Resolution: Fixed this is fixed by SVN revision 490454 Slave Fail Error when Receiving message on a MasterSlave configuration -- Key: AMQ-1079 URL: https://issues.apache.org/activemq/browse/AMQ-1079 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.2.0 Environment: Windows XP, jdk1.5 Reporter: Marlon Santos Assigned To: Rob Davies Fix For: 4.2.0 Attachments: ConsumerTool.java, MasterSlave.java, ProducerTool.java A slave fail error is caught while receiving message from master broker on a master slave configuration. I included the java files that I used. Running this through xbean/xml config also produces the same error. SEVERE: Slave Failed java.lang.AssertionError: Unsupported Method at org.apache.activemq.transport.TransportSupport.request(TransportSupport.java:71) at org.apache.activemq.transport.TransportFilter.request(TransportFilter.java:88) at org.apache.activemq.transport.TransportFilter.request(TransportFilter.java:88) at org.apache.activemq.transport.MutexTransport.request(MutexTransport.java:49) at org.apache.activemq.broker.ft.MasterBroker.sendSyncToSlave(MasterBroker.java:363) at org.apache.activemq.broker.ft.MasterBroker.sendToSlave(MasterBroker.java:345) at org.apache.activemq.broker.ft.MasterBroker.acknowledge(MasterBroker.java:320) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:88) at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:491) at org.apache.activemq.command.MessageAck.visit(MessageAck.java:179) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:287) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:178) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:133) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) 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-1030) Pure master/slave not replicating messages
[ https://issues.apache.org/activemq/browse/AMQ-1030?page=all ] Rob Davies resolved AMQ-1030. - Resolution: Fixed this should be fixed by SVN revision 490454 Pure master/slave not replicating messages -- Key: AMQ-1030 URL: https://issues.apache.org/activemq/browse/AMQ-1030 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.1.0 Environment: rhas4, sun jdk 1.5.0_08 Reporter: Mike Atkin Assigned To: Rob Davies Just did a fresh checkout of 4.1. The pure master/slave replication is not forwarding messages received by master leading to lost messages if master dies. Worked fine in rc-1. Logs on both instances show all the usual slave connected messages. -- 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] Assigned: (AMQ-841) NullPointerException when using MasterConnector and specifying the broker name with space in it.
[ https://issues.apache.org/activemq/browse/AMQ-841?page=all ]
Rob Davies reassigned AMQ-841:
--
Assignee: Rob Davies
NullPointerException when using MasterConnector and specifying the broker
name with space in it.
Key: AMQ-841
URL: https://issues.apache.org/activemq/browse/AMQ-841
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 4.0.1
Environment: Linux, jdk1.5.0_06
Reporter: Richard Wafer
Assigned To: Rob Davies
Priority: Minor
I've got a hard time trying to figure out why I got a null pointer trying to
use the Master/slave configuration for ActiveMQ.
Finnally by looking at the code I've saw the following:
In BrokerService.java
public void initializeMasterConnector(URI remoteURI) throws Exception {
...
URI localURI = getVmConnectorURI();
...
}
public URI getVmConnectorURI() {
if (vmConnectorURI == null) {
try {
vmConnectorURI = new URI(vm:// + getBrokerName());
}
catch (URISyntaxException e) {
}
}
return vmConnectorURI;
}
My problem is that I've specified a broker name with space in it Slave
Broker. So I the new URI() here throw a URISyntaxException that was badly
absorb. And this leads to a null pointer at line:159 of TransportFactory.java.
String scheme = location.getScheme(); when location is null du to the
previous exception.
The link between the error and the cause was not clear at the first sigth.
A precondition on the setBrokerName could do the job.
--
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-1070) Deadlock in Queue.java
[ https://issues.apache.org/activemq/browse/AMQ-1070?page=all ] Rob Davies resolved AMQ-1070. - Fix Version/s: 4.2.0 Resolution: Fixed Locking behaviour has changed for 4.2 - can now longer reproduce this Deadlock in Queue.java -- Key: AMQ-1070 URL: https://issues.apache.org/activemq/browse/AMQ-1070 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Tom Kaitchuck Assigned To: Rob Davies Fix For: 4.2.0 It is possible to have a deadlock as follows: ActiveMQ Transport: tcp:///127.0.0.1:53335: at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:66) - waiting to lock 0x90786240 (a org.apache.activemq.broker.region.QueueSubscription) at org.apache.activemq.broker.region.Queue.addSubscription(Queue.java:192) - locked 0x908fa480 (a java.util.LinkedList) at org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:93) - locked 0x903b9b40 (a java.lang.Object) at org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:221) at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:130) at org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:142) at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:130) at org.apache.activemq.broker.MutableBrokerFilter.addDestination(MutableBrokerFilter.java:143) at org.apache.activemq.broker.region.AbstractRegion.addConsumer(AbstractRegion.java:182) - locked 0x908e6cb8 (a java.lang.Object) at org.apache.activemq.broker.region.RegionBroker.addConsumer(RegionBroker.java:297) at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:74) at org.apache.activemq.advisory.AdvisoryBroker.addConsumer(AdvisoryBroker.java:78) at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:74) at org.apache.activemq.broker.MutableBrokerFilter.addConsumer(MutableBrokerFilter.java:87) at org.apache.activemq.broker.AbstractConnection.processAddConsumer(AbstractConnection.java:538) at org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:296) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:237) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:63) 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.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:138) at java.lang.Thread.run(Thread.java:595) ActiveMQ Transport: tcp:///127.0.0.1:53315: at org.apache.activemq.broker.region.Queue.dropEvent(Queue.java:321) - waiting to lock 0x908fa480 (a java.util.LinkedList) at org.apache.activemq.broker.region.Queue.dropEvent(Queue.java:315) at org.apache.activemq.broker.region.QueueSubscription.acknowledge(QueueSubscription.java:54) at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:125) - locked 0x90786240 (a org.apache.activemq.broker.region.QueueSubscription) at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:265) at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:366) at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:177) at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:66) at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:66) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:79) at org.apache.activemq.broker.AbstractConnection.processMessageAck(AbstractConnection.java:445) at org.apache.activemq.command.MessageAck.visit(MessageAck.java:179) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:237) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:63) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at
[jira] Assigned: (AMQ-1062) Closing consumer does not free server memory, server heap overflows
[ https://issues.apache.org/activemq/browse/AMQ-1062?page=all ] Rob Davies reassigned AMQ-1062: --- Assignee: Rob Davies Closing consumer does not free server memory, server heap overflows --- Key: AMQ-1062 URL: https://issues.apache.org/activemq/browse/AMQ-1062 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.2.0 Environment: Windows XP Professional, Java HotSpot(TM) Client VM version 1.5.0_09-b01 Reporter: [EMAIL PROTECTED] Assigned To: Rob Davies Priority: Critical Fix For: 4.2.0 I am using the store durable pending cursor. Create a producer for a topic and let it run continuously for the remainder of the test. Create a durable consumer and kill it immediately. (So now messages are piling up for the consumer, but memory usage is low thanks to the store cursor.) Wait a few minutes. Now, start the same durable consumer again. Memory usage will increase considerably at this point (I get it around 20%). Now, stop the consumer. Memory usage DOES NOT go down. Now, reconnect the same durable consumer. It is possible to get a heap overrun that nukes the server! This is a problem when there are many consumers, and the general use case is that many of them are not active at the same time. I am classifying this as critical bug due to the heap overflow whenI try to reconnect, but it would be great if the memory usage went down as soon as disconnect. I image there may also be problems like this with queues, but did not test. 2006-11-19 17:24:20,015 [/127.0.0.1:3278] DEBUG PrefetchSubscription - Prefetch limit. 2006-11-19 17:24:21,281 [/127.0.0.1:3278] DEBUG Service - Error occured while processing sync command: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space -- 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] Assigned: (AMQ-493) Improve queue and durable subscription recovery performance.
[ https://issues.apache.org/activemq/browse/AMQ-493?page=all ] Rob Davies reassigned AMQ-493: -- Assignee: Rob Davies Improve queue and durable subscription recovery performance. Key: AMQ-493 URL: https://issues.apache.org/activemq/browse/AMQ-493 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Rob Davies Fix For: 4.2.0 The performance of recovering persistent messages for a queue or a durable consumer is not spectacular in our current implementation for several reasons: (1) Producers are paused while recovery is occuring. (2) All messages for the destination are unmarshalled and sometimes even kept in a list when they are recovered (causes scaleability issues) We should provide more of a lazy loading strategy where messages are only loaded based on consumer demand. -- 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-914) OutOfMemoryError
[ https://issues.apache.org/activemq/browse/AMQ-914?page=all ] Rob Davies resolved AMQ-914. Fix Version/s: 4.2.0 Resolution: Fixed Use optional Store cursor to page messages into the broker from the persistent store SVN revision 478967. OutOfMemoryError Key: AMQ-914 URL: https://issues.apache.org/activemq/browse/AMQ-914 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.0.1 Reporter: Daniel Aioanei Assigned To: Rob Davies Fix For: 4.2.0 Attachments: activemq.xml, jmxconsole.png I was doing some testing with a single MDP listening to a queue which had about 247300 messages, with a postgres backend. ActiveMQ server was started using the default activemq startup script (on Linux). In this configuration the cpu normally stays mostly idle and I described this behaviour in another bug report. Another issue came to surface when I tried to profile the client application with EclipseColorer to see why a single MDP can't hog my machine. But when I tried so, 4 OutOfMemoryError messages were logged by ActiveMQ server. Note that I was *not* profiling the server, but the client which is a totally different process. -- 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-1061) Memory usage jumps 100% with durable subscription and stays there
[ https://issues.apache.org/activemq/browse/AMQ-1061?page=all ] Rob Davies resolved AMQ-1061. - Resolution: Fixed SVN revision 478967. Memory usage jumps 100% with durable subscription and stays there --- Key: AMQ-1061 URL: https://issues.apache.org/activemq/browse/AMQ-1061 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.2.0 Environment: Windows XP Professional, JVM 1.5.0_09 Reporter: [EMAIL PROTECTED] Assigned To: Rob Davies Priority: Critical Fix For: 4.2.0 Using the store pending cursor, activemq.xml configured to use 200M of RAM and Kaha store. JVM started with options -Xms512M -Xmx512M -Xmn100M. Messages are 10KB in size, prefetch is default. I am seeing the memory usage immediately jump up really high (100) as soon as a durable consumer is activated when a large number of messages are waiting for that consumer. The producer hangs under this situation. If the consumer is killed before memory usage drops to normal, memory usage does not drop (i.e., the server locks forever). Sometimes, it is possible to exhaust the Java heap and actually crash the server. Here is the kind of things I'm seeing in the DEBUG log: 2006-11-19 13:51:53,046 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 10, to: 9 2006-11-19 13:51:53,046 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 9, to: 8 2006-11-19 13:51:53,046 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 8, to: 7 2006-11-19 13:51:53,046 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 7, to: 6 2006-11-19 13:51:53,046 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 6, to: 5 2006-11-19 13:51:53,062 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 5, to: 4 2006-11-19 13:51:53,062 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 4, to: 3 2006-11-19 13:51:53,062 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 3, to: 2 2006-11-19 13:51:53,062 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 2, to: 1 2006-11-19 13:51:53,062 [ata File Writer] DEBUG UsageManager - Memory usage change. from: 1, to: 0 2006-11-19 13:51:53,468 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 58, to: 59 2006-11-19 13:51:53,593 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 59, to: 60 2006-11-19 13:51:53,812 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 60, to: 61 2006-11-19 13:51:53,843 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 61, to: 62 2006-11-19 13:51:53,890 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 62, to: 63 2006-11-19 13:51:54,015 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 63, to: 64 2006-11-19 13:51:54,015 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 64, to: 65 2006-11-19 13:51:54,046 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 65, to: 66 2006-11-19 13:51:54,062 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 66, to: 67 2006-11-19 13:51:54,109 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 67, to: 68 2006-11-19 13:51:54,109 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 68, to: 69 2006-11-19 13:51:54,109 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 69, to: 70 2006-11-19 13:51:54,125 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 70, to: 71 2006-11-19 13:51:54,171 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 71, to: 72 2006-11-19 13:51:54,171 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 72, to: 73 2006-11-19 13:51:54,171 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 73, to: 74 2006-11-19 13:51:54,187 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 74, to: 75 2006-11-19 13:51:54,234 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 75, to: 76 2006-11-19 13:51:54,234 [/127.0.0.1:1999] DEBUG UsageManager - Memory usage change. from: 76, to: 77 2006-11-19 13:51:54,265
[jira] Resolved: (AMQ-1062) Closing consumer does not free server memory, server heap overflows
[ https://issues.apache.org/activemq/browse/AMQ-1062?page=all ] Rob Davies resolved AMQ-1062. - Resolution: Fixed SVN revision 478967. Closing consumer does not free server memory, server heap overflows --- Key: AMQ-1062 URL: https://issues.apache.org/activemq/browse/AMQ-1062 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.2.0 Environment: Windows XP Professional, Java HotSpot(TM) Client VM version 1.5.0_09-b01 Reporter: [EMAIL PROTECTED] Assigned To: Rob Davies Priority: Critical Fix For: 4.2.0 I am using the store durable pending cursor. Create a producer for a topic and let it run continuously for the remainder of the test. Create a durable consumer and kill it immediately. (So now messages are piling up for the consumer, but memory usage is low thanks to the store cursor.) Wait a few minutes. Now, start the same durable consumer again. Memory usage will increase considerably at this point (I get it around 20%). Now, stop the consumer. Memory usage DOES NOT go down. Now, reconnect the same durable consumer. It is possible to get a heap overrun that nukes the server! This is a problem when there are many consumers, and the general use case is that many of them are not active at the same time. I am classifying this as critical bug due to the heap overflow whenI try to reconnect, but it would be great if the memory usage went down as soon as disconnect. I image there may also be problems like this with queues, but did not test. 2006-11-19 17:24:20,015 [/127.0.0.1:3278] DEBUG PrefetchSubscription - Prefetch limit. 2006-11-19 17:24:21,281 [/127.0.0.1:3278] DEBUG Service - Error occured while processing sync command: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space -- 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] Created: (AMQ-979) Allow NetworkConnections to bi-directional
Allow NetworkConnections to bi-directional -- Key: AMQ-979 URL: https://issues.apache.org/activemq/browse/AMQ-979 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Rob Davies Assigned To: Rob Davies Fix For: 4.1 Network connections are generally one way - with messages only flowing out from the broker that made the network connection. In order to support WAN hub/spoke - where the central broker is behind a firewall, and can only receive inbound connections, it is necessary to enable optional b-idirectional network connections. -- 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-927) Default log4j.properties has stdout enabled and not the out file appender
[ https://issues.apache.org/activemq/browse/AMQ-927?page=all ]
Rob Davies resolved AMQ-927.
Fix Version/s: 4.1
Resolution: Fixed
Fixed by revision 463689
Default log4j.properties has stdout enabled and not the out file appender
-
Key: AMQ-927
URL: https://issues.apache.org/activemq/browse/AMQ-927
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Jason Dillon
Assigned To: Rob Davies
Priority: Trivial
Fix For: 4.1
The default log4j.properties has:
{noformat}
log4j.rootLogger=INFO, stdout
{noformat}
and then goes on to say:
{noformat}
# CONSOLE appender not used by default
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
..
{noformat}
And it also has this header... which is misleading:
{noformat}
#
# The logging properties used during tests..
#
{noformat}
Also not sure why this would be in data... nor do I ever see this being
created, even when out is enabled...
{noformat}
log4j.appender.out.file=${activemq.home}/data/activemq.log
{noformat}
--
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] Commented: (AMQ-876) Kaha DB cannot locate queue data files
[ https://issues.apache.org/activemq/browse/AMQ-876?page=comments#action_37106 ] Rob Davies commented on AMQ-876: Hi Vadim, would you mind trying the latest code ? I've done some bug fixes in the kaha area today - unfortunately one of the bug fixes means it's no longer backwards compatible cheers, Rob Kaha DB cannot locate queue data files -- Key: AMQ-876 URL: https://issues.apache.org/activemq/browse/AMQ-876 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1 Environment: WinXP Reporter: Vadim Pesochinskiy Assigned To: Rob Davies Fix For: 4.1 Attachments: test.zip Keep getting exception below. Note that you are looking for queue-data-1, but actual file name is data-queue-data-1 $ pwd /cygdrive/d/amq/activemq-kaha/kaha.db $ ls data-kaha-1 data-queue-data-1 index-kaha index-queue-data index-transactions javax.jms.JMSException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:46) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1154) at org.apache.activemq.TransactionContext.commit(TransactionContext.java:260) at org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:464) at com.barra.cp.common.io.MultiQueueReceiver.onMessage(MultiQueueReceiver.java:163) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.runMultiQueue(SingleMessageMultiQueueReceiver.java:176) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.doRun(SingleMessageMultiQueueReceiver.java:143) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.run(SingleMessageMultiQueueReceiver.java:124) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.activemq.kaha.RuntimeStoreException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:340) at org.apache.activemq.kaha.impl.MapContainerImpl.remove(MapContainerImpl.java:265) at org.apache.activemq.store.kahadaptor.KahaMessageStore.removeMessage(KahaMessageStore.java:68) at org.apache.activemq.store.kahadaptor.KahaTransaction.commit(KahaTransaction.java:92) at org.apache.activemq.store.kahadaptor.KahaTransactionStore.commit(KahaTransactionStore.java:95) at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:68) at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:154) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:102) at org.apache.activemq.broker.AbstractConnection.processCommitTransactionOnePhase(AbstractConnection.java:330) at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:99) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:228) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:63) 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.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:123) 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:127) ... 1 more Caused by: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.DataManager.getDataFile(DataManager.java:117) at org.apache.activemq.kaha.impl.StoreDataReader.readItem(StoreDataReader.java:62) at org.apache.activemq.kaha.impl.DataManager.readItem(DataManager.java:121) at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:337) ... 20 more -- 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] Assigned: (AMQ-876) Kaha DB cannot locate queue data files
[ https://issues.apache.org/activemq/browse/AMQ-876?page=all ] Rob Davies reassigned AMQ-876: -- Assignee: Rob Davies Kaha DB cannot locate queue data files -- Key: AMQ-876 URL: https://issues.apache.org/activemq/browse/AMQ-876 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1 Environment: WinXP Reporter: Vadim Pesochinskiy Assigned To: Rob Davies Fix For: 4.1 Keep getting exception below. Note that you are looking for queue-data-1, but actual file name is data-queue-data-1 $ pwd /cygdrive/d/amq/activemq-kaha/kaha.db $ ls data-kaha-1 data-queue-data-1 index-kaha index-queue-data index-transactions javax.jms.JMSException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:46) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1154) at org.apache.activemq.TransactionContext.commit(TransactionContext.java:260) at org.apache.activemq.ActiveMQSession.commit(ActiveMQSession.java:464) at com.barra.cp.common.io.MultiQueueReceiver.onMessage(MultiQueueReceiver.java:163) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.runMultiQueue(SingleMessageMultiQueueReceiver.java:176) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.doRun(SingleMessageMultiQueueReceiver.java:143) at com.barra.cp.common.io.SingleMessageMultiQueueReceiver$OneMessageAtATime.run(SingleMessageMultiQueueReceiver.java:124) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.activemq.kaha.RuntimeStoreException: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:340) at org.apache.activemq.kaha.impl.MapContainerImpl.remove(MapContainerImpl.java:265) at org.apache.activemq.store.kahadaptor.KahaMessageStore.removeMessage(KahaMessageStore.java:68) at org.apache.activemq.store.kahadaptor.KahaTransaction.commit(KahaTransaction.java:92) at org.apache.activemq.store.kahadaptor.KahaTransactionStore.commit(KahaTransactionStore.java:95) at org.apache.activemq.transaction.LocalTransaction.commit(LocalTransaction.java:68) at org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:154) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.BrokerFilter.commitTransaction(BrokerFilter.java:92) at org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:102) at org.apache.activemq.broker.AbstractConnection.processCommitTransactionOnePhase(AbstractConnection.java:330) at org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:99) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:228) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:63) 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.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:123) 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:127) ... 1 more Caused by: java.io.IOException: Could not locate data file queue-data-1 at org.apache.activemq.kaha.impl.DataManager.getDataFile(DataManager.java:117) at org.apache.activemq.kaha.impl.StoreDataReader.readItem(StoreDataReader.java:62) at org.apache.activemq.kaha.impl.DataManager.readItem(DataManager.java:121) at org.apache.activemq.kaha.impl.MapContainerImpl.getValue(MapContainerImpl.java:337) ... 20 more -- 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] Commented: (AMQ-845) Sending messages to a topic with an inactive durable subscription will hang producers
[ https://issues.apache.org/activemq/browse/AMQ-845?page=comments#action_36899 ] Rob Davies commented on AMQ-845: currently working a solution to this Sending messages to a topic with an inactive durable subscription will hang producers - Key: AMQ-845 URL: https://issues.apache.org/activemq/browse/AMQ-845 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Environment: Linux Red Hat Enterprise 4 java jdk 1.4.2-b28 (or 1.5.0_06-b05) Reporter: Christopher Mihaly Assigned To: Rob Davies Priority: Blocker Attachments: testcase.zip If you have a durable subsciber that is not on-line, and you have producers sending message, eventually the server will hang on that topic. I have attached a zip file with a junit test case and my activemq configuration. The test case has two tests, one that creates a durable subscription, that will succeed, and a second that starts publishing up to 10 events, which will hang. I don't really know how to interrupt the all, so the test case never finishes. Anyway, it does show the problem and is 100% repeatable on my system. The config file is set to use a SQLServer database, but the stock journal or a derby persistence manager will do the same thing. I just switched to mssql server because I can then see what is going on in the database. And records are being added to the database all the way up to when the server hangs. I also doubled the memory manager limit and moved the jmx rmi port to 1080 since I have another server running at 1099. -- 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] Assigned: (AMQ-755) possible bug with temporary queues and networks?
[ https://issues.apache.org/activemq/browse/AMQ-755?page=all ]
Rob Davies reassigned AMQ-755:
--
Assign To: Rob Davies
possible bug with temporary queues and networks?
Key: AMQ-755
URL: https://issues.apache.org/activemq/browse/AMQ-755
Project: ActiveMQ
Type: Bug
Versions: 4.0
Reporter: james strachan
Assignee: Rob Davies
We have been experiencing some fairly serious problems with timeouts using
Spring, Lingo and a network of ActiveMQ brokers.
As I understand it, lingo creates temporary queues to transport the remote
procedure calls across JMS.
We are suspicious that the messaging roundtrip gets interrupted or lost when
using broker networks.
We integrated ActiveMQ 4.0 into our project this week and ran the JMX
jconsole to look at our broker network.
We see temporary queues come and go, and what we are expecting is complete
replication of the queues on each broker. Is this expectation correct?
This is not what we are seeing.
We believe that two things are happening:
1) Temporary queues are not being cleaned up properly on all brokers.
2) Temporary queues are not being created on a new broker when it is taken
down and then restarted.
Your feedback on these apparent issues would be appreciated.
To substantiate our theory we created a couple of JUnit tests. (Our test
cases do not include Lingo - just ActiveMQ client to broker.)
TEST 1
We create a network of brokers, create a message queue, send a message and
then take a broker down. We are expecting that the temporary message queue
created will be removed from both brokers. It is not.
The test fails on the last assert with:
junit.framework.AssertionFailedError: No queues on broker 3 expected:1 but
was:0
Source code follows:
public void testTempQueueCleanup() throws Exception {
ActiveMQConnectionFactory cf;
Connection conn = null;
Session sess = null;
try {
cf = new ActiveMQConnectionFactory(
failover:(tcp://localhost:61626%3FsoTimeout=5000,tcp://localhost:61627%3FsoTimeout=5000)?maximumRetries=0amp;establishConnectionTimeout=21000amp;keepAliveTimeout=30);
conn = cf.createConnection();
sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
TemporaryQueue q = sess.createTemporaryQueue();
BrokerService broker2 = createBroker(broken2,
tcp://localhost:61627, static:(tcp://localhost:61626));
Thread.sleep(5000);
assertEquals(No queues on broker 1, 1,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(No queues on broker 2, 1,
broker2.getAdminView().getTemporaryQueues().length);
q.delete();
assertEquals(Temp queue left behind on broker 1, 0,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(Temp queue left behind on broker 2, 0,
broker2.getAdminView().getTemporaryQueues().length);
broker2.stop();
} finally {
if (sess!=null)
sess.close();
if (conn!=null)
conn.close();
}
}
TEST 2
When stopping a broker and then restarting it, we expect to see all queues
replicated on the new broker.
This test fails with:
junit.framework.AssertionFailedError: No queues on broker 3 expected:1 but
was:0
Source code:
public void testTempQueueRecovery() throws Exception {
ActiveMQConnectionFactory cf;
Connection conn = null;
Session sess = null;
try {
cf = new ActiveMQConnectionFactory(
failover:(tcp://localhost:61626%3FsoTimeout=5000,tcp://localhost:61627%3FsoTimeout=5000)?maximumRetries=0amp;establishConnectionTimeout=21000amp;keepAliveTimeout=30);
conn = cf.createConnection();
sess = conn.createSession(false, Session.AUTO_ACKNOWLEDGE);
TemporaryQueue q = sess.createTemporaryQueue();
BrokerService broker2 = createBroker(broken2,
tcp://localhost:61627,
static:(tcp://localhost:61626,tcp://localhost:61628));
Thread.sleep(5000);
assertEquals(No queues on broker 1, 1,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(No queues on broker 2, 1,
broker2.getAdminView().getTemporaryQueues().length);
BrokerService broker3 = createBroker(broken3,
tcp://localhost:61628,
static:(tcp://localhost:61626,tcp://localhost:61627));
assertEquals(No queues on broker 3, 1,
broker3.getAdminView().getTemporaryQueues().length);
Thread.sleep(5000);
q.delete();
Thread.sleep(5000);
assertEquals(Temp queue left behind on broker 1, 0,
broker1.getAdminView().getTemporaryQueues().length);
assertEquals(Temp queue left behind on broker 2, 0,
broker2.getAdminView().getTemporaryQueues().length);
assertEquals(Temp queue left behind on broker 3, 0,
broker3.getAdminView().getTemporaryQueues().length);
broker3.stop();
broker2.stop();
} finally {
if (sess!=null)
sess.close();
if (conn!=null)
[jira] Commented: (AMQ-734) Network connections do not reconnect when using static: with failover=true
[ https://issues.apache.org/activemq/browse/AMQ-734?page=comments#action_36274 ] Rob Davies commented on AMQ-734: the reason for the fixed client_id is durable topic consumers. The network bridge amalgamates multiple durable subscribers on the same topic in to one durable subscriber - to avoid duplicates and improve performance. There is a keep alive protocol used with the tcp connector that should detect the network outage - needs some more investigation to see why this doesn't appear to be working Network connections do not reconnect when using static: with failover=true -- Key: AMQ-734 URL: https://issues.apache.org/activemq/browse/AMQ-734 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 Environment: winxp java1.5.6 Reporter: tao Priority: Critical Fix For: 4.0.1 If I pull out RJ45 port from net card ,waiting a time ,then put RJ45 port net card .Network is resume.Other computer always throw errors and net channel can't work. -- 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] Assigned: (AMQ-687) Multiple durable topics don't work with network of brokers
[ https://issues.apache.org/activemq/browse/AMQ-687?page=all ] Rob Davies reassigned AMQ-687: -- Assign To: Rob Davies Multiple durable topics don't work with network of brokers -- Key: AMQ-687 URL: https://issues.apache.org/activemq/browse/AMQ-687 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0 RC 2 Environment: AMQ RC2, Solaris 8 / 10, JDK 1.5 Reporter: Kevin Yaussy Assignee: Rob Davies Priority: Critical There is a problem with a network of brokers with regards to a single consumer subscribing to multiple durable topics. To recreate the issue, I changed examples/ConsumerTool.java to subscribe to two durable topics, with the createDurableSubscriber calls changed to look like this: consumer = session.createDurableSubscriber(topic1, topic1.getTopicName() ); consumer2 = session.createDurableSubscriber( topic2, topic2.getTopicName() ); This ensures that the name of the durable subscriptions are unique, rather than using the consumerName as the base example code does. The problem is with any remote brokers: it appears that the broker-to-broker code for durable subscriptions does not *uniquely* set the subscription name for multiple durable subscriptions to different topics. Here is the message and exception information from the remote broker: INFO org.apache.activemq.broker.AbstractConnection.Service Mon 2006/04/10 10:50:52:660 org.apache.activemq.broker.AbstractConnection.se rviceException Thread[tcp://sbtmdgca/170.137.15.64:61618,5,main] Async error occurred: javax.jms.JMSException: Durable consumer is in use for client: NC_ProdDN3AsbtmdgcasbtmdgcAMQDN_inboundProdDN3Bsbtgc0bsbtgc0AMQDN and subscriptionName: ProdDN3Bsbtgc0bsbtgc0AMQDN INFO Stack Trace follows: javax.jms.JMSException: Durable consumer is in use for client: NC_ProdDN3AsbtmdgcasbtmdgcAMQDN_inboundProdDN3Bsbtgc0bsbtgc0AMQDN and subscriptio nName: ProdDN3Bsbtgc0bsbtgc0AMQDN at org.apache.activemq.broker.region.TopicRegion.addConsumer(TopicRegion.java:81) at org.apache.activemq.broker.region.RegionBroker.addConsumer(RegionBroker.java:276) at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:69) at org.apache.activemq.advisory.AdvisoryBroker.addConsumer(AdvisoryBroker.java:75) at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:69) at org.apache.activemq.broker.MutableBrokerFilter.addConsumer(MutableBrokerFilter.java:81) at org.apache.activemq.broker.AbstractConnection.processAddConsumer(AbstractConnection.java:422) at org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:291) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:88) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:75) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44) at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:55) at org.apache.activemq.network.DemandForwardingBridgeSupport.addSubscription(DemandForwardingBridgeSupport.java:344) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteConsumerAdvisory(DemandForwardingBridgeSupport.java:324) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:274) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport.java:120) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:88) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:103) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:139) at java.lang.Thread.run(Thread.java:595) You can see that the subscriptionName used from the originating broker is the brokerName. This will never handle multiple durable subscriptions (different topics) from the
[jira] Commented: (AMQ-677) ActiveMQ broker leaks advisory topics
[ https://issues.apache.org/activemq/browse/AMQ-677?page=comments#action_36014 ] Rob Davies commented on AMQ-677: destinations that don't exist are added by calling the broker stack from the top to add the destination - which we don't need to do for advisories ActiveMQ broker leaks advisory topics - Key: AMQ-677 URL: https://issues.apache.org/activemq/browse/AMQ-677 Project: ActiveMQ Type: Bug Components: Broker Environment: linux, near-trunk version of ActiveMQ Reporter: Andrew Lusk Assignee: Rob Davies Attachments: ProducerTool.java When I run the attached code, which AFAIK is completely legal JMS, the ActiveMQ broker grows to 500+ mb and crashes due to being out of heap space. Some investigation with hprof has lead me to believe that the advisory topics created by the MessageConsumers (and Producers, but I use the same producer each time so that's not causing a problem) are being put into a DestinationMap and not being removed. The rough origin of this is in the addProducer call in AdvisoryBroker, which creates the advisory topic. Note that this memory is not freed when the DestinationInfo removing the original temptopic is received, nor when the actual client exits. The object lifetime of these advisory destinations seems very poorly defined. If they are implicitly created by the server, they should be implicitly destroyed by the same. To reproduce, I've been running this code with -Dtopic=true and -Dmax=1 (though the problem shows up well before this amount). This is just a modified version of the example ProducerTool (note it doesn't actually send any messages). Please verify the correctness of the attached code. Andrew Lusk -- 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] Created: (AMQ-676) KahaXARecoveryTest fails
KahaXARecoveryTest fails Key: AMQ-676 URL: https://issues.apache.org/activemq/browse/AMQ-676 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Rob Davies Assigned to: Rob Davies KahaXARecoveryTest fails - fix persistence for XA transactions -- 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] Work started: (AMQ-487) Temp Destination definition not sent across network bridge to support request/reply model?
[ http://jira.activemq.org/jira//browse/AMQ-487?page=all ] Work on AMQ-487 started by Rob Davies Temp Destination definition not sent across network bridge to support request/reply model? -- Key: AMQ-487 URL: http://jira.activemq.org/jira//browse/AMQ-487 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 Environment: w2k and linux with jdk 1.5 Reporter: Dennis Cook Assignee: Rob Davies Fix For: 4.0 Attachments: AMQ-487-logs.zip Goal was to test request/response model across a network bridge. The requestor sets up a temporary topic and includes as the reply topic with message sent to the responder. It is expected that the responder will send message on the provide replyTo topic. Using the multicast://default discovery mechanism and networkConnector transport to interconnect two brokers (different hosts harley to roadrash). Responder client attaches to harley and requestor client attaches to roadrash. Requestor client creates temporary topic, sends message. Responder receives message attempt to reply on the temporary topic, but errors with message indicating cannot publish to deleted topic -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-497) receive() call should throw exception when transport fails.
[ http://jira.activemq.org/jira//browse/AMQ-497?page=comments#action_35831 ] Rob Davies commented on AMQ-497: receive() will return null if there's a concurrent close - where do you get the idea that receive() should never return null? ie. the API docs says: Returns: the next message produced for this message consumer, or null if this message consumer is concurrently closed receive() call should throw exception when transport fails. --- Key: AMQ-497 URL: http://jira.activemq.org/jira//browse/AMQ-497 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0 M4 Reporter: Hiram Chirino Assignee: Rob Davies Fix For: 4.0 RC1 Reported at: http://forums.logicblaze.com/posts/list/207.page * A QueueReceiver, running the synchronous receive() call will block indefinitely If you have a QueueReceiver, and it's blocked on the receive() call, it should produce an exception when the ActiveMQ server goes down. Otherwise there is no way for that thread to come back to life. The client does produce an async exception alert... However that is not sufficient. That handles any of your async consumers. This is a sync consumer, it's blocked until it returns, or fails. Your async exception routine should wake up all sync consumers with an exception on their receive() call. The user cannot do this, because even if he could somehow find which Thread is blocked, interrupting the thread is not guaranteed to work. Most JMS providers throw an exception. 3.2.1 threw an exception. Perhaps if I wrote an async exception trigger to close the Sender, it would unblock the other thread.. However the receieve should really throw an exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
