I've done some more experimenting with this, and found a few new facts. 1) it doesn't matter whether I put the endpoints in two SAs or one- it still hangs if I try to create four queues (it creates three and hangs). 2) the thread that's trying to start the jms endpoint is waiting for a notify on an AtomicBoolean. here's the relevant part of the call stack: (this test was on 3.1-incubating code) StandardConsumerProcessor.doStart() : 62 StandardConsumerProcessor.start() : 76 JmsEndpoint.activate() : 348
I didn't get around to hunting down the thread started by execute() to see what it was up to. Anyone seen this problem before, or have an idea? Thanks :) Sam samg wrote: > > Hello, > I've been experimenting with different ways of doing this, and haven't > found a solution. My configuration is ServiceMix 3.1.1 SNAPSHOT running > under Tomcat 5.2.20. I'm trying to create explicit ActiveMQ queues > between some of my components as a way of having persistence and single > threading on the output side; I found an explanation that I can set > 'processorName="standard"' to force this (which seems not to be possible > setting the exchange to be persistent). > This works great for a single SA containing several SUs, one of which > defines four JMS endpoints for two queues (see below for configuration). > When I try to deploy a second identical (except for module names and > namespaces) SA onto ServiceMix, it hangs trying to start the JMS SU- the > log ends like this: > Mar 13, 2007 7:06:14 PM > org.apache.servicemix.jbi.framework.ServiceUnitLifeCycle start > INFO: Starting service unit: dup-testtask-jms-auditedqueue-su > > > Looking at ServiceMix through the JMX console shows that ActiveMQ created > the two queues for the SA that deployed okay, and created only one of them > for the one that didn't. > > Here's what my JMS SU xbean.xml looks like (both SAs use one like this, > just changed namespaces): > <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"; > > xmlns:dup-testtask="urn:com:wellogic:synapse:integration:tasks:dup-testtask"> > <jms:endpoint service="dup-testtask:ReceivedQueue" > endpoint="endpoint" > role="provider" > destinationStyle="queue" > > jmsProviderDestinationName="com.test.tasks.dup-testtask.received" > connectionFactory="#jmsFactory" /> > > <jms:endpoint service="dup-testtask:ReceivedQueueSender" > endpoint="endpoint" > targetService="dup-testtask:Auditor" > role="consumer" > connectionFactory="#jmsFactory" > destinationStyle="queue" > processorName="standard" > defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; > > jmsProviderDestinationName="com.test.tasks.dup-testtask.received" /> > > <jms:endpoint service="dup-testtask:AuditedQueue" > endpoint="endpoint" > role="provider" > destinationStyle="queue" > jmsProviderDestinationName="com.test.tasks.dup-testtask.audited" > connectionFactory="#jmsFactory" /> > > <jms:endpoint service="dup-testtask:AuditedQueueSender" > endpoint="endpoint" > targetService="dup-testtask:Test_Rec_RoutingSlip" > role="consumer" > connectionFactory="#jmsFactory" > destinationStyle="queue" > processorName="standard" > defaultMep="http://www.w3.org/2004/08/wsdl/in-out"; > > jmsProviderDestinationName="com.test.tasks.dup-testtask.audited" /> > > <bean id="jmsFactory" > class="org.apache.activemq.pool.PooledConnectionFactory"> > <property name="connectionFactory"> > <bean > class="org.apache.activemq.ActiveMQConnectionFactory"> > <property name="brokerURL" > value="tcp://localhost:61616" /> > </bean> > </property> > </bean> > </beans> > > Have I done something wrong in the configuration? If not, could you give > me a suggestion for how to debug this in ServiceMix? Wondering if > something was deadlocked, I connected jdb and looked at the threads before > and after trying to deploy the second SA but couldn't glean anything from > that.. I could send the diff along if you think that'd be useful. > Thanks! > Sam > -- View this message in context: http://www.nabble.com/Problem-deploying-multiple-JMS-endpoints-queues-tf3399576s12049.html#a9505162 Sent from the ServiceMix - User mailing list archive at Nabble.com.
