Frank, is it possible that when you bounce a broker, the service queue might still contain messages with a stale temp reply queue? If this is the case, the service attempts to deliver them a temp queue which no longer exists (broker was bounced). If your client keeps sending CASes, eventually the ones with a stale reply queue will be drained and the work will resume. You can attach jConsole to the broker and watch the depth of the service queue to check how many CASes are in the queue when you bounce the broker. Keep your client sending CASes and let me know if eventually normal processing resumes.
Jerry C On Tue, Feb 7, 2012 at 10:25 AM, Frank Enders <[email protected]> wrote: > Dear all, > > I am having problems in a UIMA AS 2.3.1 setting when restarting the > broker while endpoints are currently running and deployed to it. > After restarting the broker, JMS states correct reconnection to the > queues. But when sending a request to the endpoint I get the following > error: > > javax.jms.InvalidDestinationException: Cannot publish to a deleted > Destination: temp-queue://ID:xubuntu-VirtualBox-59422-1328615372283-0:1:1 > at > org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1696) > at > > org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:231) > at > > org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:300) > at > > org.apache.uima.adapter.jms.activemq.JmsEndpointConnection_impl.send(JmsEndpointConnection_impl.java:572) > at > > org.apache.uima.adapter.jms.activemq.JmsOutputChannel.sendReply(JmsOutputChannel.java:796) > at > > org.apache.uima.adapter.jms.activemq.JmsInputChannel.onMessage(JmsInputChannel.java:637) > at > > org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535) > at > > org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495) > at > > org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467) > at > > org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:323) > at > > org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:261) > at > > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1056) > at > > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1048) > at > > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947) > at > > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at > org.apache.uima.aae.UimaAsThreadFactory$1.run(UimaAsThreadFactory.java:118) > at java.lang.Thread.run(Thread.java:662) > Feb 7, 2012 12:52:25 PM > org.apache.uima.adapter.jms.activemq.JmsEndpointConnection_impl > handleJmsException > INFO: >>>> Controller: LanguageGuesser_AAE - Failed to Send Message To > Queue: : temp-queue://ID:xubuntu-VirtualBox-59422-1328615372283-0:1:1. > The Queue Has Been Deleted From > Broker:failover:tcp://xubuntu-VirtualBox:61616. > > I found a similar thread in this mailinglist (subject: "Lost Connection > to Delegate", 22.03.2011) dealing with problems of remote delegates when > restarting the broker. > It was associated with this JIRA ticket: > https://issues.apache.org/jira/browse/UIMA-2105 > Although my AAE only uses colocated delegates I tried the current > UIMA-AS trunk, hoping the fix would perhaps affect my scenario as well. > But it doesn't seems to have any effect. I still get the error. > > I also tried to adjust error processing within the deployment descriptor to > <processCasErrors maxRetries="1" timeout="15000" thresholdCount="1" > thresholdAction="terminate" /> > as suggested in the thread mentioned above, but that didn't help neither. > > Any ideas? Are there any configuration parameters, which have to be > taken into consideration when deploying an endpoint in order to survive > a broker restart? Or is it just a bug? > > Thanks and all the best, Frank >
