[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) >
[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.(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: http://www.atlassian.com/software/
[jira] Commented: (AMQ-721) Openwire client hangs after receiving 999 messages
[
https://issues.apache.org/activemq/browse/AMQ-721?page=comments#action_36458 ]
Robert Winslow commented on AMQ-721:
I also have been dealing with this issue.
While I dont know if this is the correct solution (Dont know the code well
enough yet) however, it did fix the issue for me.
Th eonly change I made was to MessageConsumer::DispatchAsyncMessages I added a
call to AutoAcknowledge. This allowed me to get past the 1000 message Limit
[code]
public void DispatchAsyncMessages()
{
while (Listener != null)
{
IMessage message = dispatcher.DequeueNoWait();
if (message != null)
{
Listener(message);
**AutoAcknowledge(message);**
}
else
{
break;
}
}
}
[/code]
> Openwire client hangs after receiving 999 messages
> --
>
> Key: AMQ-721
> URL: https://issues.apache.org/activemq/browse/AMQ-721
> Project: ActiveMQ
> Type: Bug
> Components: JMS client
> Versions: 4.0
> Environment: .NET 2.0 ,C# + trunk
> Reporter: vincent boilay
> Priority: Blocker
>
>
> Openwire client hangs after receiving 999 messages
> changing Session.Prefetch postpone the problem...
> Current code is :
>public class Session : ISession
> {
>:
>:
> private int prefetchSize = 1000;
> this block at message #999
> changing private int prefetchSize = 2000 ==> blocks at message #1999
--
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
