uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaroslaw Cwiklik <uim...@gmail.com>
Subject Re: UIMA AS: Invalid destination after broker restart
Date Fri, 10 Feb 2012 15:06:13 GMT
Frank, so far I dont see the problem with uima-as code from the svn trunk.
I set up a client with a synchronous sendAndReceive() which sends CASes
repeatedly. While the client is sending CASes I kill the broker, wait a few
minutes and restart it. I checked the log for invalid destination
exception. None was logged.

In your test case, do you send just one CAS after bouncing the broker or
does your client send multiple CASes and each fails the same way
(InvalidDestination) in the service?

Jerry C

On Wed, Feb 8, 2012 at 2:38 PM, Jaroslaw Cwiklik <uimaee@gmail.com> wrote:

> Frank, I will try to recreate the problem. Yesterday, I tried the scenario
> with async sendCAS() and saw no problems after bouncing a broker. Will test
> the scenario with sendAndReceive().
> Jerry C
> On Wed, Feb 8, 2012 at 9:32 AM, Frank Enders <enders@averbis.de> wrote:
>> Jerry, thanks for your reply first of all.
>> Pending messages don't seem to play a role in our scenario. I am just
>> sending single messages synchronously using sendAndReceiveCAS().
>> So when I restart the broker no messages are pending.
>> I attached jconsole to the broker in order to observe its behaviour:
>> A strange thing is that when the error occurs I can see that the missing
>> queue actually should be present:
>> i.e.:
>> The error states:
>> "javax.jms.InvalidDestinationException: Cannot publish to a deleted
>> Destination: temp-queue://ID:xubuntu-VirtualBox-42260-1328698333409-0:2:1"
>> But in jconsole I can see:
>> |- org.apache.acticemq
>>        |- OurBroker
>>                |- TempQueue
>>                        |- ID_xubuntu-VirtualBox-42260-1328698333409-0_2_1
>> appearing at the same time (until the UimaASMetaRequestTimeout is
>> reached).
>> Each subsequent request I send produces the same error (only the temp
>> queue's id changes for each request).
>> After stopping and redeploying the endpoint, everything works fine again.
>> All the best,
>> Frank

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message