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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/
>

Reply via email to