uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Proefrock <chas....@hotmail.com>
Subject RE: UimaASProcessCasTimeout exception hangs application
Date Tue, 07 Oct 2008 20:22:40 GMT
I don't have ready access to the test environment, so I'll have to go back and play with the
-t value.  It isn't clear if you are saying that a longer timeout "will succeed" in avoiding
the hanging problem, or "will succeed" in repeating the problem we've observed.  Clarification
on that would help, especially if some min or max timeout avoids the problem.
Yes, the queue name should match the name configured in the deploy descriptor.  I think we
had a more complex example running and then simplified it before posting, so the queue name
documented here was probably just a mistype.
To be a little more specific, we are testing both the natural timeout when a deployed process
runs too long, and also the scenario where a deployed process crashes/exits with ^C.  Both
seem to generate the same exception when the client timeout occurs, so the nature of the remote
failure does not seem to be in play.  This makes sense since the remote is on the other side
of a message queue, the client does not see a direct connection dropped on the crash.  It
must also mean that the remote is not connected to the anything while it is running, so nothing
detects the crash itself.  Confirmation of this understanding would help as well. Are there
any options on the message queue (initiation or response queues) that would allow for configuring
timeouts for specific named queues?
- Charles

> Date: Tue, 7 Oct 2008 10:10:21 -0400> From: burnlewis@gmail.com> To: uima-user@incubator.apache.org>
Subject: Re: UimaASProcessCasTimeout exception hangs application> > I also see that
the -t process timeout value has to be > 10 for this to> succeed ... I'd have assumed
anything > 5 secs would be safe, but the> default value of -p 2 means that the client's
timeout must be 2x the service> process time when 2 CASes are in play, since the 2nd is
queued immediately> behind the first. Perhaps the default should be -p 1 for simplicity.>
> P.S. I assume you meant RoomNumberAnnotatorQueue as the 2nd arg in step 4.> > On
Tue, Oct 7, 2008 at 9:34 AM, Jaroslaw Cwiklik <cwiklik@us.ibm.com> wrote:> > >
Charles, this appears to be a bug in the UIMA AS client code. The only work> > around
that comes to mind right now> > is to run without -i. Without -i the runRemoteAE should
terminate on> > exception.> >> > We will investigate this problem and post
a patch on apache.> >> > Thanks> >> > Jerry> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>
> Jerry Cwiklik> > UIMA Extensions> > IBM T.J. Watson Research Center> >
Hawtorne, NY, 10532> > Tel: 914-784-7665, T/L: 863-7665> > Email: cwiklik@us.ibm.com>
>> > [image: Inactive hide details for Charles Proefrock <chas.pro@hotmail.com>]Charles>
> Proefrock <chas.pro@hotmail.com>> >> >> >> > *Charles Proefrock
<chas.pro@hotmail.com>*> >> > 10/06/2008 05:59 PM> > Please respond
to> > uima-user@incubator.apache.org> >> >> > To> >> >
UIMA User <uima-user@incubator.apache.org>> > cc> >> >> > Subject>
>> > UimaASProcessCasTimeout exception hangs application> >> >> >>
> When experimenting with the UIMA-AS examples and how the error handling> > mechanisms
work in terms of timeouts due to AS Aggregates taking too long or> > going offline,
we came across a situation in which the RunRemoteAsyncAE> > hangs and never returns
after receiving and processing a> > UimaASProcessCasTimeout exception. Ultimately, we
simply want the system to> > recover and try the next CAS or return gracefully without
having to call a> > hard System.exit(1).> >> > Our tests are based on the
Deploy_MeetingDetectorTAE_RemoteRoomNumber.xml> > example. All we did was the following:>
> (1) added "Thread.sleep(5000);" to RoomNumberAnnotator.java process to> > simulate
a longer process.> > (2) Executed: startBroker.bat> > (3) Executed: deployAsyncService
<DIR>\Deploy_RoomNumberAnnotator.xml> > (4) Executed: runRemoteAsyncAE tcp://localhost:61616>
> MeetingDetectorTaeQueue –c <DIR>\FileSystemCollectionReader.xml -t 4 -i> >>
> In summary: when setting and triggering the time outs on the RoomNumber> > remoteAnalysisEngine,
the exception is thrown and caught, each additional> > CAS is tried, and the system
exists gracefully. If the> > UimaAsynchronousEngine within the runRemoteAsyncAE times
out, then the> > system hangs and never returns.> >> > Is there a trick
that we're missing? Is this expected?> >> > - Charles> >> >> >
_________________________________________________________________> > See how Windows
Mobile brings your life together—at home, work, or on the> > go.> > http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/>
See how Windows Mobile brings your life together—at home, work, or on the go.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message