Looking at the latest code, this situation is now reported as one of three possible errors, with 2 kinds of message header errors and a payload error (which also looks like a bad header). The list of issues fixed does not include anything about payload handling problems.
One thing to try would be to have the remote delegate save Cases before returning them in order to inspect the content. Another thing would be to save the Cas just before sending it to the last delegate and then try to reproduce the problem with runAE and a JMS client descriptor pointing at the last delegate service. Regards, Eddie On Fri, Nov 27, 2009 at 8:39 AM, Matthias Wendt <[email protected]> wrote: > Hello *, > > I have a problem in my UIMA-AS pipeline. Seems that something is wrong with > the active-mq message. The stacktrace is copied below. > > I can't figure out, what's wrong. Maybe it is related to an issue with > serialization. > > Don't know if this is related, but when setting up the pipeline, I was > having serious struggles with XMI-Serialization. Since non-"XML > 1.0"-characters are not allowed, I excluded them, however, there where still > problems when XML-reserved characters like the '&' appeared in the URL-field > of a document. Since URLs are not needed, I excluded them but maybe there is > yet another caveat correlated to this.? > > The affected queue seems to be the reply queue of the last remote delegate > in the aggregate. > > As you can see from the stacktrace, the exception does not come from any of > the delegates, but it is handled like a process-Error and the enclosing > aggregate is stopped when the error threshold is exceeded. Also, the > delegate service was still up and running and JMX monitoring displayed no > process errors - and the logs didn't either. > > > WARN org.apache.uima.aae.error.handler.ProcessCasErrorHandler - {0} > org.apache.uima.aae.error.InvalidMessageException > at > org.apache.uima.adapter.jms.activemq.JmsInputChannel.onMessage(JmsInputChannel.java:554) > at > org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:518) > at > org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:479) > at > org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:451) > at > org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:32 > 3) > at > org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:261) > at > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer. > java:982) > at > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContai > ner.java:974) > at > org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:876) > at java.lang.Thread.run(Thread.java:619) > > Any hints are welcome. I guess more detail is needed to ultimately identify > the problem, but I have no idea in which direction I have to look for it.... > > Regards, > Matthias > >
