Jorn, I've fixed this under UIMA-1540. Let me know if this fixes the
problem.
Thanks for pointing this out.
Jerry
On Tue, Sep 1, 2009 at 8:26 AM, Jörn Kottmann <kottm...@gmail.com> wrote:
> Posted it a few days ago, would be nice if someone
> could have a look. I assume there is a wait missing, right ?
> If so the fix is simple and we can include it in 2.3.0.
>
> Jörn
>
>
> Jörn Kottmann wrote:
>
>> Hi everyone,
>>
>> to put some load on one of our UIMA AS system I wrote
>> a small tool which uses the client API to send CASes to
>> a processing pipeline.
>>
>> This tool has an endless loop which waits for work
>> to arrive and then sends it to the processing pipeline.
>>
>> It basically looks like this:
>>
>> text = getNextDocument() // returns plain text which should be analyzed
>>
>> CAS cas = uimASEngine.getCAS();
>> cas.setDocumentText(text)
>> uimaAsEngine.sendCAS(cas)
>>
>> When the tool is started there is usually lots of work waiting
>> and all available CASes are sent out to the service. It takes a while
>> until the first CAS is completly processed. Now the
>> tool gets a new text and waits for a new CAS inside getCAS().
>>
>> Now I wonder why waiting for a CAS inside getCAS() puts 95 to 100 % CPU
>> load
>> on one core on my client machine.
>>
>> I looked at the place where it waits in
>> BaseUIMAAsynchronousEngineCommon_impl
>> around line 536 in getCAS().
>>
>> Here is the wait loop:
>> while (running) {
>> try {
>> // Wait until the CAS producer adds the CAS to the CasQueueEntry
>> and
>> // signals CAS availability.
>> entry.getSemaphore().acquire();
>> if (entry.getCas() == null) {
>> continue;
>> } else {
>> return entry.getCas();
>> }
>> } finally {
>> entry.getSemaphore().release();
>> } } // while
>>
>> For me it looks like that if entry.getCAS() returns null it immediately
>> tries again and polls entry.getCAS() as often as possible.
>>
>> Jörn
>>
>>
>
