You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Ryan Moquin <fr...@gmail.com> on 2008/01/01 18:28:24 UTC
More JMS component problems
So I've been tracking down a problem in my servicemix CXF service, where I
have a thread (I know I probably shouldn't be doing it that way, I'm
guessing a quartz task is probably the recommended way) that does some data
collection in the background for the service "appears" to stop running. I
managed to reproduce this state and did a thread dump on the service. I
found trying to send to my jms endpoint is locking the whole thing up. I'm
a little puzzled as to why, and was hoping someone could give me some
insight on this and help me to understand what I need to do to prevent it
from happening. I'm still investigating the stack dump but I'm hoping
someone might just already know the answer of why servicemix would stay
locked at this point. I've been trying to figure out why my JMS messages
seem to "stop" after a while, this would explain that as well.
Here is the code that tries to send some data to a jms queue, the last line
is where it's hanging:
InOnly exchange = client.createInOnlyExchange();
NormalizedMessage message = exchange.getInMessage();
message.setContent(new StreamSource(new StringReader(data)));
exchange.setService(jmsServiceQname);
client.send(exchange);
Here is the stacktrace where it is hung:
"Thread-13" daemon prio=6 tid=0x2925fd10 nid=0xae8 waiting on condition
[0x2f05e000..0x2f05fa18]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(
AbstractQueuedSynchronizer.java:18
41)
at java.util.concurrent.ArrayBlockingQueue.put(
ArrayBlockingQueue.java:368)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
DeliveryChannelImpl.java:663)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
AbstractFlow.java:170)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
SedaFlow.java:167)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
SedaQueue.java:134)
at
java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(
ThreadPoolExecutor.java:1455)
at java.util.concurrent.ThreadPoolExecutor.reject(
ThreadPoolExecutor.java:384)
at java.util.concurrent.ThreadPoolExecutor.execute(
ThreadPoolExecutor.java:867)
at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
ExecutorImpl.java:43)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
SedaQueue.java:128)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(
SedaFlow.java:182)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
SedaFlow.java:162)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
AbstractFlow.java:123)
at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(
DefaultBroker.java:283)
at
org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
SecuredBroker.java:81)
at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
JBIContainer.java:830)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(
DeliveryChannelImpl.java:395)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(
DeliveryChannelImpl.java:431)
at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(
BaseLifeCycle.java:58)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
DeliveryChannelImpl.java:610)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
AbstractFlow.java:170)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
SedaFlow.java:167)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
SedaQueue.java:134)
at
java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution(
ThreadPoolExecutor.java:1455)
at java.util.concurrent.ThreadPoolExecutor.reject(
ThreadPoolExecutor.java:384)
at java.util.concurrent.ThreadPoolExecutor.execute(
ThreadPoolExecutor.java:867)
at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
ExecutorImpl.java:43)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
SedaQueue.java:128)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(
SedaFlow.java:182)
at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
SedaFlow.java:162)
at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
AbstractFlow.java:123)
at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(
DefaultBroker.java:283)
at
org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
SecuredBroker.java:81)
at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
JBIContainer.java:830)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(
DeliveryChannelImpl.java:395)
at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(
DeliveryChannelImpl.java:431)
at org.apache.servicemix.client.DefaultServiceMixClient.send(
DefaultServiceMixClient.java:147)
Re: More JMS component problems
Posted by Ryan Moquin <fr...@gmail.com>.
So has anyone had a problem with a topic filling up and found a way around
it? I thought topic's weren't supposed to be persistent, except for durable
subscribers, which I have non. I wouldn't have thought this would occur. I
think I saw some stuff that said this is fixed in activemq 5.0 (or at least
similar issues), but that doesn't do me any good when servicemix won't be
using 5.0 for a while.
Thanks,
Ryan
On Jan 2, 2008 8:51 AM, Ryan Moquin <fr...@gmail.com> wrote:
> Ah, that's right, I did read about a similar issue and this possibly being
> the issue. I guess I need to have a TTL on the messages being sent? A
> large amount of JMS messages are being sent to a topic, but unless there are
> durable subscribers, I don't understand why the messages aren't discarded
> after either they are delivered or it's determined noone is subscribing yet.
>
>
> Sure, I can send my config. I wasn't initially sure if sending my
> configuration would help. It's very basic since I only modified what I
> found I think in the servicemix-jms example until I figure out more
> specifics of what I want:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <beans xmlns:notservice="urn://notification.service.com"
> xmlns:jms="http://servicemix.apache.org/jms/1.0 ">
> <jms:endpoint service="notservice:notificationJmsService"
> endpoint="notificationServiceJmsProvider"
> role="provider"
> destinationStyle="topic"
> jmsProviderDestinationName="topic/notificationService"
> connectionFactory="#connectionFactory"
> wsdlResource="classpath:notification-service.wsdl " />
>
> <bean id="connectionFactory" class="
> org.apache.activemq.ActiveMQConnectionFactory">
> <property name="brokerURL" value="tcp://localhost:61616" />
> </bean>
> </beans>
>
>
> On Jan 1, 2008 4:07 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > It seems the stack trace shows that the queues / thread pools are
> > totally
> > filled and you are running out of these resources. In such a case, the
> > component sending the jbi exchange will be blocked until there is more
> > room. The behavior can be tuned by changing the seda queue sizes (see
> > http://servicemix.apache.org/thread-pools.html). You can use unbounded
> > queues if you want, but you may run out of memory, use unlimited thread
> > number (which may run out of memory too), or have a maximum for both (in
> > which case the sender would block).
> >
> > I'm not sure what really happens with your JMS endpoint. Could you post
> > the
> > configuration used maybe ?
> >
> > On Jan 1, 2008 6:28 PM, Ryan Moquin <fr...@gmail.com> wrote:
> >
> > > So I've been tracking down a problem in my servicemix CXF service,
> > where I
> > > have a thread (I know I probably shouldn't be doing it that way, I'm
> > > guessing a quartz task is probably the recommended way) that does some
> > > data
> > > collection in the background for the service "appears" to stop
> > running. I
> > > managed to reproduce this state and did a thread dump on the service.
> > I
> > > found trying to send to my jms endpoint is locking the whole thing up.
> > > I'm
> > > a little puzzled as to why, and was hoping someone could give me some
> > > insight on this and help me to understand what I need to do to prevent
> > it
> > > from happening. I'm still investigating the stack dump but I'm hoping
> > > someone might just already know the answer of why servicemix would
> > stay
> > > locked at this point. I've been trying to figure out why my JMS
> > messages
> > > seem to "stop" after a while, this would explain that as well.
> > >
> > >
> > > Here is the code that tries to send some data to a jms queue, the last
> >
> > > line
> > > is where it's hanging:
> > >
> > > InOnly exchange = client.createInOnlyExchange();
> > > NormalizedMessage message = exchange.getInMessage();
> > > message.setContent(new StreamSource(new StringReader(data)));
> > > exchange.setService(jmsServiceQname);
> > > client.send(exchange);
> > >
> > > Here is the stacktrace where it is hung:
> > >
> > > "Thread-13" daemon prio=6 tid=0x2925fd10 nid=0xae8 waiting on
> > condition
> > > [0x2f05e000..0x2f05fa18]
> > > at sun.misc.Unsafe.park(Native Method)
> > > at java.util.concurrent.locks.LockSupport.park(LockSupport.java
> > > :118)
> > > at
> > >
> > >
> > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await
> > > (
> > > AbstractQueuedSynchronizer.java:18
> > > 41)
> > > at java.util.concurrent.ArrayBlockingQueue.put(
> > > ArrayBlockingQueue.java:368)
> > > at
> > > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
> > > DeliveryChannelImpl.java:663)
> > > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
> > > AbstractFlow.java:170)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting (
> > > SedaFlow.java:167)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
> > > SedaQueue.java:134)
> > > at
> > >
> > java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
> > > (
> > > ThreadPoolExecutor.java:1455)
> > > at java.util.concurrent.ThreadPoolExecutor.reject(
> > > ThreadPoolExecutor.java:384)
> > > at java.util.concurrent.ThreadPoolExecutor.execute(
> > > ThreadPoolExecutor.java:867)
> > > at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
> > > ExecutorImpl.java:43)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
> > > SedaQueue.java:128)
> > > at
> > org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(
> > > SedaFlow.java:182)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
> > > SedaFlow.java :162)
> > > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
> > > AbstractFlow.java:123)
> > > at
> > org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(
> > > DefaultBroker.java:283)
> > > at
> > > org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
> > > SecuredBroker.java:81)
> > > at
> > org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
> > > JBIContainer.java :830)
> > > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(
> > > DeliveryChannelImpl.java:395)
> > > at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send
> > (
> > > DeliveryChannelImpl.java :431)
> > > at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange
> > (
> > > BaseLifeCycle.java:58)
> > > at
> > > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound
> > (
> > > DeliveryChannelImpl.java:610)
> > > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
> > > AbstractFlow.java:170)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
> > > SedaFlow.java:167)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
> > > SedaQueue.java:134)
> > > at
> > >
> > java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
> > > (
> > > ThreadPoolExecutor.java:1455)
> > > at java.util.concurrent.ThreadPoolExecutor.reject(
> > > ThreadPoolExecutor.java:384)
> > > at java.util.concurrent.ThreadPoolExecutor.execute(
> > > ThreadPoolExecutor.java:867)
> > > at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
> > > ExecutorImpl.java:43)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
> > > SedaQueue.java:128)
> > > at
> > org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(
> > > SedaFlow.java:182)
> > > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
> > > SedaFlow.java :162)
> > > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
> > > AbstractFlow.java:123)
> > > at
> > org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(
> > > DefaultBroker.java:283)
> > > at
> > > org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
> > > SecuredBroker.java:81)
> > > at
> > org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
> > > JBIContainer.java :830)
> > > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(
> > > DeliveryChannelImpl.java:395)
> > > at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send
> > (
> > > DeliveryChannelImpl.java :431)
> > > at org.apache.servicemix.client.DefaultServiceMixClient.send(
> > > DefaultServiceMixClient.java:147)
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> >
>
>
Re: More JMS component problems
Posted by Ryan Moquin <fr...@gmail.com>.
Ah, that's right, I did read about a similar issue and this possibly being
the issue. I guess I need to have a TTL on the messages being sent? A
large amount of JMS messages are being sent to a topic, but unless there are
durable subscribers, I don't understand why the messages aren't discarded
after either they are delivered or it's determined noone is subscribing yet.
Sure, I can send my config. I wasn't initially sure if sending my
configuration would help. It's very basic since I only modified what I
found I think in the servicemix-jms example until I figure out more
specifics of what I want:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:notservice="urn://notification.service.com"
xmlns:jms="http://servicemix.apache.org/jms/1.0">
<jms:endpoint service="notservice:notificationJmsService"
endpoint="notificationServiceJmsProvider"
role="provider"
destinationStyle="topic"
jmsProviderDestinationName="topic/notificationService"
connectionFactory="#connectionFactory"
wsdlResource="classpath:notification-service.wsdl" />
<bean id="connectionFactory" class="
org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://localhost:61616" />
</bean>
</beans>
On Jan 1, 2008 4:07 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> It seems the stack trace shows that the queues / thread pools are totally
> filled and you are running out of these resources. In such a case, the
> component sending the jbi exchange will be blocked until there is more
> room. The behavior can be tuned by changing the seda queue sizes (see
> http://servicemix.apache.org/thread-pools.html). You can use unbounded
> queues if you want, but you may run out of memory, use unlimited thread
> number (which may run out of memory too), or have a maximum for both (in
> which case the sender would block).
>
> I'm not sure what really happens with your JMS endpoint. Could you post
> the
> configuration used maybe ?
>
> On Jan 1, 2008 6:28 PM, Ryan Moquin <fr...@gmail.com> wrote:
>
> > So I've been tracking down a problem in my servicemix CXF service, where
> I
> > have a thread (I know I probably shouldn't be doing it that way, I'm
> > guessing a quartz task is probably the recommended way) that does some
> > data
> > collection in the background for the service "appears" to stop running.
> I
> > managed to reproduce this state and did a thread dump on the service. I
> > found trying to send to my jms endpoint is locking the whole thing up.
> > I'm
> > a little puzzled as to why, and was hoping someone could give me some
> > insight on this and help me to understand what I need to do to prevent
> it
> > from happening. I'm still investigating the stack dump but I'm hoping
> > someone might just already know the answer of why servicemix would stay
> > locked at this point. I've been trying to figure out why my JMS
> messages
> > seem to "stop" after a while, this would explain that as well.
> >
> >
> > Here is the code that tries to send some data to a jms queue, the last
> > line
> > is where it's hanging:
> >
> > InOnly exchange = client.createInOnlyExchange();
> > NormalizedMessage message = exchange.getInMessage();
> > message.setContent(new StreamSource(new StringReader(data)));
> > exchange.setService(jmsServiceQname);
> > client.send(exchange);
> >
> > Here is the stacktrace where it is hung:
> >
> > "Thread-13" daemon prio=6 tid=0x2925fd10 nid=0xae8 waiting on condition
> > [0x2f05e000..0x2f05fa18]
> > at sun.misc.Unsafe.park(Native Method)
> > at java.util.concurrent.locks.LockSupport.park(LockSupport.java
> > :118)
> > at
> >
> >
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await
> > (
> > AbstractQueuedSynchronizer.java:18
> > 41)
> > at java.util.concurrent.ArrayBlockingQueue.put(
> > ArrayBlockingQueue.java:368)
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
> > DeliveryChannelImpl.java:663)
> > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
> > AbstractFlow.java:170)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
> > SedaFlow.java:167)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
> > SedaQueue.java:134)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
> > (
> > ThreadPoolExecutor.java:1455)
> > at java.util.concurrent.ThreadPoolExecutor.reject(
> > ThreadPoolExecutor.java:384)
> > at java.util.concurrent.ThreadPoolExecutor.execute(
> > ThreadPoolExecutor.java:867)
> > at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
> > ExecutorImpl.java:43)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
> > SedaQueue.java:128)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket
> (
> > SedaFlow.java:182)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
> > SedaFlow.java:162)
> > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
> > AbstractFlow.java:123)
> > at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket
> (
> > DefaultBroker.java:283)
> > at
> > org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
> > SecuredBroker.java:81)
> > at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
> > JBIContainer.java:830)
> > at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend
> (
> > DeliveryChannelImpl.java:395)
> > at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(
> > DeliveryChannelImpl.java:431)
> > at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(
> > BaseLifeCycle.java:58)
> > at
> > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
> > DeliveryChannelImpl.java:610)
> > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
> > AbstractFlow.java:170)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
> > SedaFlow.java:167)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
> > SedaQueue.java:134)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
> > (
> > ThreadPoolExecutor.java:1455)
> > at java.util.concurrent.ThreadPoolExecutor.reject(
> > ThreadPoolExecutor.java:384)
> > at java.util.concurrent.ThreadPoolExecutor.execute(
> > ThreadPoolExecutor.java:867)
> > at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
> > ExecutorImpl.java:43)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
> > SedaQueue.java:128)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket
> (
> > SedaFlow.java:182)
> > at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
> > SedaFlow.java:162)
> > at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
> > AbstractFlow.java:123)
> > at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket
> (
> > DefaultBroker.java:283)
> > at
> > org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
> > SecuredBroker.java:81)
> > at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
> > JBIContainer.java:830)
> > at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend
> (
> > DeliveryChannelImpl.java:395)
> > at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(
> > DeliveryChannelImpl.java:431)
> > at org.apache.servicemix.client.DefaultServiceMixClient.send(
> > DefaultServiceMixClient.java:147)
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: More JMS component problems
Posted by Guillaume Nodet <gn...@gmail.com>.
It seems the stack trace shows that the queues / thread pools are totally
filled and you are running out of these resources. In such a case, the
component sending the jbi exchange will be blocked until there is more
room. The behavior can be tuned by changing the seda queue sizes (see
http://servicemix.apache.org/thread-pools.html). You can use unbounded
queues if you want, but you may run out of memory, use unlimited thread
number (which may run out of memory too), or have a maximum for both (in
which case the sender would block).
I'm not sure what really happens with your JMS endpoint. Could you post the
configuration used maybe ?
On Jan 1, 2008 6:28 PM, Ryan Moquin <fr...@gmail.com> wrote:
> So I've been tracking down a problem in my servicemix CXF service, where I
> have a thread (I know I probably shouldn't be doing it that way, I'm
> guessing a quartz task is probably the recommended way) that does some
> data
> collection in the background for the service "appears" to stop running. I
> managed to reproduce this state and did a thread dump on the service. I
> found trying to send to my jms endpoint is locking the whole thing up.
> I'm
> a little puzzled as to why, and was hoping someone could give me some
> insight on this and help me to understand what I need to do to prevent it
> from happening. I'm still investigating the stack dump but I'm hoping
> someone might just already know the answer of why servicemix would stay
> locked at this point. I've been trying to figure out why my JMS messages
> seem to "stop" after a while, this would explain that as well.
>
>
> Here is the code that tries to send some data to a jms queue, the last
> line
> is where it's hanging:
>
> InOnly exchange = client.createInOnlyExchange();
> NormalizedMessage message = exchange.getInMessage();
> message.setContent(new StreamSource(new StringReader(data)));
> exchange.setService(jmsServiceQname);
> client.send(exchange);
>
> Here is the stacktrace where it is hung:
>
> "Thread-13" daemon prio=6 tid=0x2925fd10 nid=0xae8 waiting on condition
> [0x2f05e000..0x2f05fa18]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java
> :118)
> at
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await
> (
> AbstractQueuedSynchronizer.java:18
> 41)
> at java.util.concurrent.ArrayBlockingQueue.put(
> ArrayBlockingQueue.java:368)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
> DeliveryChannelImpl.java:663)
> at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
> AbstractFlow.java:170)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
> SedaFlow.java:167)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
> SedaQueue.java:134)
> at
> java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
> (
> ThreadPoolExecutor.java:1455)
> at java.util.concurrent.ThreadPoolExecutor.reject(
> ThreadPoolExecutor.java:384)
> at java.util.concurrent.ThreadPoolExecutor.execute(
> ThreadPoolExecutor.java:867)
> at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
> ExecutorImpl.java:43)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
> SedaQueue.java:128)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(
> SedaFlow.java:182)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
> SedaFlow.java:162)
> at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
> AbstractFlow.java:123)
> at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(
> DefaultBroker.java:283)
> at
> org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
> SecuredBroker.java:81)
> at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
> JBIContainer.java:830)
> at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(
> DeliveryChannelImpl.java:395)
> at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(
> DeliveryChannelImpl.java:431)
> at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(
> BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(
> DeliveryChannelImpl.java:610)
> at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(
> AbstractFlow.java:170)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(
> SedaFlow.java:167)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(
> SedaQueue.java:134)
> at
> java.util.concurrent.ThreadPoolExecutor$CallerRunsPolicy.rejectedExecution
> (
> ThreadPoolExecutor.java:1455)
> at java.util.concurrent.ThreadPoolExecutor.reject(
> ThreadPoolExecutor.java:384)
> at java.util.concurrent.ThreadPoolExecutor.execute(
> ThreadPoolExecutor.java:867)
> at org.apache.servicemix.executors.impl.ExecutorImpl.execute(
> ExecutorImpl.java:43)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue.enqueue(
> SedaQueue.java:128)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.enqueuePacket(
> SedaFlow.java:182)
> at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doSend(
> SedaFlow.java:162)
> at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.send(
> AbstractFlow.java:123)
> at org.apache.servicemix.jbi.nmr.DefaultBroker.sendExchangePacket(
> DefaultBroker.java:283)
> at
> org.apache.servicemix.jbi.security.SecuredBroker.sendExchangePacket(
> SecuredBroker.java:81)
> at org.apache.servicemix.jbi.container.JBIContainer.sendExchange(
> JBIContainer.java:830)
> at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(
> DeliveryChannelImpl.java:395)
> at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(
> DeliveryChannelImpl.java:431)
> at org.apache.servicemix.client.DefaultServiceMixClient.send(
> DefaultServiceMixClient.java:147)
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/