[jira] Commented: (AMQ-768) Client and Broker hang trying to start a connection
[ https://issues.apache.org/activemq/browse/AMQ-768?page=comments#action_36454 ] christy c commented on AMQ-768: --- We're seeing a similiar problem, and wanted to see if this is the same issue. We have two web apps in Tomcat 2.2.9 that use JMS connections on Linux Red Hat 4. We were using ActiveMQ3.0, things were fine, and now we're testing with ActiveMQ 4.0 where I changed the package names (and I tried 4.0.1 with the same results) and the results are: the first web app starting a JMS connection works fine. When the second web app tries to start a JMS connection (after successfully getting a ConnectionFactory as the first web app did also), it hangs. We shut down Tomcat, leave the broker running, and turn on Tomcat and the first web app hangs when it tries to start a JMS connection and same with the second web app. Here's the stack trace: Thread [Thread-2] (Suspended) Object.wait(long) line: not available [native method] CountDownLatch(Object).wait() line: not available CountDownLatch.await() line: 179 WireFormatNegotiator.oneway(Command) line: 73 MutexTransport.oneway(Command) line: 44 ResponseCorrelator.asyncRequest(Command, ResponseCallback) line: 68 ResponseCorrelator.request(Command) line: 73 ActiveMQConnection.syncSendPacket(Command) line: 1112 ActiveMQConnection.ensureConnectionInfoSent() line: 1200 ActiveMQConnection.start() line: 434 JMSUtil.getConnection(String) line: 170 JMSUtil.getSession(boolean, String) line: 225 JMSUtil.getSession(boolean) line: 193 SourceListener.registerForSourceTopic() line: 46 Client and Broker hang trying to start a connection --- Key: AMQ-768 URL: https://issues.apache.org/activemq/browse/AMQ-768 Project: ActiveMQ Type: Bug Versions: 4.0 Environment: JDK 1.5.0_06, Windows XP SP2 Reporter: Jamie McCrindle Assignee: Hiram Chirino Fix For: 4.1, 4.0.2 Every now and again a client hangs connecting to the broker. The broker is configured with the default activemq.xml. The stack dumps are as follows: ACTIVEMQ_HOME: C:\Java\incubator-activemq-4.0\bin\.. Loading message broker from: xbean:activemq.xml INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhos t) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ INFO ManagementContext - JMX consoles can connect to service:jmx:r mi:///jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby _embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Jou rnal: using 5 x 20.0 Megs at: C:\Java\incubator-activemq-4.0\activemq-data\journ al INFO JournalPersistenceAdapter - Journal Recovered: 1 message(s) in transa ctions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://SIM-J amesM:61616 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://SIM-J amesM:61613?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, I D:SIM-JamesM-2205-1149180591980-1:0) started WARN ManagedTransportConnection - Failed to unregister mbean: org.apache.ac tivemq:BrokerName=localhost,Type=Connection,ConnectorName=default,Connection=9 the stack dump is: main prio=6 tid=0x000379d0 nid=0x93d0 in Object.wait() [0x0007e000..0x0007fc40 ] at java.lang.Object.wait(Native Method) - waiting on 0x02b66278 (a edu.emory.mathcs.backport.java.util.concurr ent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(C ountDownLatch.java:179) - locked 0x02b66278 (a edu.emory.mathcs.backport.java.util.concurrent. CountDownLatch) at org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatN egotiator.java:73) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.ja va:44) - locked 0x02b64098 (a java.lang.Object) at org.apache.activemq.transport.ResponseCorrelator.asyncRequest(Respons eCorrelator.java:68) at org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorr elator.java:73) at org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnect
[jira] Created: (AMQ-770) consumer.dispatchAsync defaults to false
consumer.dispatchAsync defaults to false Key: AMQ-770 URL: https://issues.apache.org/activemq/browse/AMQ-770 Project: ActiveMQ Type: Bug Components: JMS client Versions: 4.0, 4.0.1 Reporter: Kevin Yaussy Priority: Minor Seems like there was a change between 4.0-RC3 and incubator-4.0(.1) with regards to the default value for the destination option consumer.dispatchAsync. According to the web documentation for destination options, as well as behavior in RC3, the default is true. However, it looks like incubator-4.0(.1) defaults to false. I have to explicitly give the consumer.dispatchAsync=true for a destination option, in order to get async dispatch in the Broker. Is this a code bug, or documentation bug? -- 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: AMQP
I liked Hiram's blog today http://hiramchirino.com/2006/06/amqp-interesting-start.html it looks way too early to be able to implement this specification in a JMS provider yet as there's no standard way to map JMS semantics to AMQP yet - which would prevent JMS providers from interoperating - but I'm sure that will come along later. On 6/21/06, Hiram Chirino [EMAIL PROTECTED] wrote: +1 ! BTW IMO the spec is still fuzzy. I think they need to clarify it a bit more. But I think it's something we should be able to implement really easy. On 6/20/06, Brian McCallister [EMAIL PROTECTED] wrote: FYI: http://www.infoq.com/news/amq AMQP looks to be an attempt at wire protocol specification like openwire or stomp. Probably good for us to look at, though the licensing probably needs to bounce through [EMAIL PROTECTED] before we do much as it is not immediately clear if it is okay. I probably is, but I'd love to get Cliff's opinion. -Brian -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-771) org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection.
org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection. -- Key: AMQ-771 URL: https://issues.apache.org/activemq/browse/AMQ-771 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0.1, 4.0 Reporter: Kevin Yaussy Especially when using failover, there can be a problem with respect to TransportConnection::stop attempting to send a shutdown message over the connection. If another thread is sending messages to the connection, and it gets stuck for some reason, such as a network freeze, the target machine panics, or the target process freezes for some reason, the TransportConnection::dispatch will eventually block, locking the MutextTransport object. When the InactivityMonitor wakes up and detects that the connection is dead, it will go through the process of stopping the connection. This goes back into TransportConnection, and calls stop, which attemtps to lock the MutexTransport so it can send the shutdown command. Now, both threads are stuck, potentially for a long time, as a box panic will not cleanly close the tcp connection. I'm not sure the rationale for wanting to send a shutdown command to the other side of the connection, since the target has to handle the connection going down hard anyway. Seems to me, if you are intending on closing the connection, just close it - don't try to be nice to the other side. Especially in this code path, there is something wrong with the other side anyway. -- 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] Reopened: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Kevin Yaussy reopened AMQ-608: -- Hiram, Very sorry that I did not look at the 4.0.1 source until the last couple days. I'd like to submit patches this time (I don't have svn, but I will attach regular diff -u patches). For DemandForwardingBridgeSupport, there was just one change that was left out. For FailoverTransport, it looks like things got changed around in kind of the opposite direction I was looking for. For me, I really don't care about the message waiting for transport to reconnect that comes out once a second during a send. Seemed like that one was less meaningful than the message waiting + reconnectDelay + ms before attempting connection. That's the one I would prefer to be debug, whereas the other message would be trace. Then, additionally, I am including a logging patch for InactivityMonitor.java. I would like to be able to see when readCheck is going to throw InactivityIOException and also show the connection info. I also don't care about the other debug stuff. So, I changed the readCheck log message to be info and added the toString to the message. Alternatively, I have a second patch that does the same thing, but turns all current debug into trace, and just the readCheck message to debug. Either way is good for me. The issue here is that the Broker won't show this InactivityIOException, and I'd like to see it (just not all the other debug stuff). The client-side, I think, is OK since now the TransportListener interrupted / resumed works. But the broker is silent about this and I would like to see it. Thanks. Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, FailoverTransport.java, FailoverTransport.java In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- 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] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Kevin Yaussy updated AMQ-608: - Attachment: DemandForwardingBridgeSupport.patch FailoverTransport.patch InactivityMonitor.patch Hope this is the way to attach the patches... Kevin. Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, InactivityMonitor.patch In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- 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] Updated: (AMQ-608) Change logging level of some DemandForwardingBridge log messages.
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ] Kevin Yaussy updated AMQ-608: - Attachment: InactivityMonitor.patch2 Change logging level of some DemandForwardingBridge log messages. - Key: AMQ-608 URL: https://issues.apache.org/activemq/browse/AMQ-608 Project: ActiveMQ Type: Improvement Components: Broker Versions: 4.0 Reporter: Kevin Yaussy Assignee: Hiram Chirino Fix For: 4.0.1, 4.1 Attachments: DemandForwardingBridge.java, DemandForwardingBridgeSupport.java, DemandForwardingBridgeSupport.patch, FailoverTransport.java, FailoverTransport.java, FailoverTransport.patch, InactivityMonitor.patch, InactivityMonitor.patch2 In DemandForwardingBridge, I'd like to be able to see subscription messages (and unsubscription messages), but not bridging messages. Both classes of log messages are log.trace. Seems like the bridging messages should remain trace, as you would want to look at that when you are doing pretty detailed debugging. However, I'd like to see subscribe/unsubscribe messages all the time. If those could be either info or debug, that would allow me to turn those on separately. I realize that I can see what is currently subscribed via the JMX console. However, seeing the subscribe/unsubscribe messages will allow diagnostics over time - who subscribed when type of questions. Mainly, I'm referring to messages logged as trace in: DemandForwardingBridge.serviceRemoteConsumerAdvisory DemandForwardingBridge.removeDemandSubscription -- 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-772) Build ships without activemq-web-4.0.jar
Build ships without activemq-web-4.0.jar Key: AMQ-772 URL: https://issues.apache.org/activemq/browse/AMQ-772 Project: ActiveMQ Type: Bug Reporter: Matt Parker Build ships without activemq-web-4.0.jar, so WAR generated by ant task incomplete. I had to add this myself. Can you please add it to the release? -- 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-773) Build ships without incompatitable commons-logging and log4j
Build ships without incompatitable commons-logging and log4j Key: AMQ-773 URL: https://issues.apache.org/activemq/browse/AMQ-773 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0.1 Reporter: Matt Parker Fix For: 4.0.2 commons-logging calls Category.log in lo4j, which is depericated in the version of log4j that ships in 4.0.1. Please upgrade the commons-log to commons-logging-1.1.jar -- 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-774) Can't deploy RAR on weblogic 9.1
Can't deploy RAR on weblogic 9.1 Key: AMQ-774 URL: https://issues.apache.org/activemq/browse/AMQ-774 Project: ActiveMQ Type: Bug Components: Broker Versions: 4.0.1 Environment: BEA Weblogic 9.1 Reporter: Matt Parker I've been through the doc: http://www.activemq.org/site/how-to-deploy-activemq-ra-versionrar-to-weblogic.html However, when I attempt to deploy the broker on Weblogic 9.1 (actually, when i click on activate changes), i get the following error: weblogic.connector.exception.RAException: There are 1 nested errors: javax.resource.spi.ResourceAdapterInternalException: Failed to startup an embedded broker: file://../broker-config.xml, due to: java.io.IOException: Could load file factory:java.io.IOException: Could not find factory class for resource: META-INF/services/org/apache/activemq/broker/file at org.apache.activemq.ra.ActiveMQResourceAdapter.start(ActiveMQResourceAdapter.java:82) at weblogic.connector.security.layer.AdapterLayer.start(AdapterLayer.java:979) at weblogic.connector.common.RAInstanceManager.initialize(RAInstanceManager.java:1139) at weblogic.connector.common.RAInstanceManager.init(RAInstanceManager.java:333) at weblogic.connector.deploy.ConnectorModule.prepare(ConnectorModule.java:178) at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:90) at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:318) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:53) at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:43) at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:620) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:231) at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:147) at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:183) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:84) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:219) at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:750) at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1209) at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:246) at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:157) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207) at weblogic.work.ExecuteThread.run(ExecuteThread.java:179) Caused by: java.io.IOException: Could load file factory:java.io.IOException: Could not find factory class for resource: META-INF/services/org/apache/activemq/broker/file at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:24) at org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:42) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:55) at org.apache.activemq.ra.ActiveMQResourceAdapter.start(ActiveMQResourceAdapter.java:79) ... 27 more Caused by: java.io.IOException: Could not find factory class for resource: META-INF/services/org/apache/activemq/broker/file at org.apache.activeio.util.FactoryFinder.doFindFactoryProperies(FactoryFinder.java:87) at org.apache.activeio.util.FactoryFinder.newInstance(FactoryFinder.java:57) at org.apache.activeio.util.FactoryFinder.newInstance(FactoryFinder.java:46) at org.apache.activemq.broker.BrokerFactory.createBrokerFactoryHandler(BrokerFactory.java:40) ... 29 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:
