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 client is blocking
Date Thu, 01 Apr 2010 13:14:51 GMT
Pierre, this is a bug in the UIMA AS. I will create JIRA for this and
provide a fix today. Failures like the one you describe should be handled in
the UIMA AS. Clients should not have special purpose code to recover from
framework type of problems.

Thanks for finding this

JC


On Thu, Apr 1, 2010 at 5:45 AM, Pierre Pujalon <ppujalon@yahoo.fr> wrote:

> Hi ,
>
> I had already the exact same test program, which never failed or blocked...
> But your answer combined with  Eddie's answer gave me  a new angle to
> apprehend the issue.
> The framework releases the CAS when it has finished the processing, but
> nobody  release the CAS if something went wrong when you send the CAS to the
> queue. In my case , I have non XML character in some documents... I got the
> following exception, and the CAS were never released....
>
> org.xml.sax.SAXParseException: Trying to serialize non-XML 1.0 character:
>  , 0x1f
>    at
> org.apache.uima.util.XMLSerializer$CharacterValidatingContentHandler.checkForInvalidXmlChars(XMLSerializer.java:235)
>    at
> org.apache.uima.util.XMLSerializer$CharacterValidatingContentHandler.startElement(XMLSerializer.java:155)
>    at
> org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.startElement(XmiCasSerializer.java:986)
>    at
> org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.encodeFS(XmiCasSerializer.java:739)
>    at
> org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.encodeIndexed(XmiCasSerializer.java:684)
>    at
> org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.serialize(XmiCasSerializer.java:268)
>    at
> org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.access$700(XmiCasSerializer.java:108)
>    at
> org.apache.uima.cas.impl.XmiCasSerializer.serialize(XmiCasSerializer.java:1522)
>    at
> org.apache.uima.aae.UimaSerializer.serializeCasToXmi(UimaSerializer.java:136)
>    at
> org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl.serializeCAS(BaseUIMAAsynchronousEngineCommon_impl.java:259)
>    at
> org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngineCommon_impl.sendCAS(BaseUIMAAsynchronousEngineCommon_impl.java:759)
>
> I wrote my client as the following. It works as a charm now...
>
>        CAS cas = null;
>
>        try {
>
>
>            cas = uimaEEEngine.getCAS();
>
>            JCas jcas;
>
>        try {
>                jcas = cas.getJCas();
>            } catch (CASException e) {
>                throw new ResourceProcessException(e);
>            }
>            fillCas(jcas);
>            uimaEEEngine.sendCAS(cas);
>        }
>        catch (Exception e) {
>            // something wrong happen, release the CAS if you got one
>            if (cas !=null) {
>                cas.release();
>           }
>       }
>
>
> I don't know if this should be handled in the asynchronous client or if it
> has to be documented. I have the feeling, it could happen to somebody else.
> I let you decide...
>
> Thank you very much
> Pierre
>
>
> Le 31/03/2010 17:36, Jaroslaw Cwiklik a écrit :
>
>  My bad. Indeed when getCas() is used there is no need to call reset nor
>> release.
>>
>> The framework calls release() when the listener  callback finishes. I've
>> created a test program to run the client without a listener and I see no
>> hang. Here is the complete test program:
>>
>> import java.util.HashMap;
>> import java.util.Map;
>>
>> import org.apache.uima.aae.client.UimaAsynchronousEngine;
>> import org.apache.uima.adapter.jms.client.BaseUIMAAsynchronousEngine_impl;
>> import org.apache.uima.cas.CAS;
>> import org.apache.uima.cas.CASException;
>> import org.apache.uima.jcas.JCas;
>> import org.apache.uima.resource.ResourceProcessException;
>>
>>
>> public class TestUimaASClient {
>>
>>   BaseUIMAAsynchronousEngine_impl uimaAsEngine;
>>
>>   public void initialize() throws Exception {
>>     uimaAsEngine = new BaseUIMAAsynchronousEngine_impl();
>>     Map<String, Object>  appCtx = new HashMap<String, Object>();
>>     appCtx.put(UimaAsynchronousEngine.ServerUri, "tcp://localhost:61616");
>>     appCtx.put(UimaAsynchronousEngine.Endpoint,
>> "RoomNumberAnnotatorQueue");
>>     appCtx.put(UimaAsynchronousEngine.CasPoolSize, 1);
>>     appCtx.put(UimaAsynchronousEngine.Timeout, 0);
>>     uimaAsEngine.initialize(appCtx);
>>   }
>>   public void run() throws Exception {
>>     for (int i = 0; i<  150; i++) {
>>       CAS cas = uimaAsEngine.getCAS();
>>       JCas jcas;
>>       try {
>>         System.out.println("UIMA AS Client Sending CAS#" + (i + 1) + "
>> Request to a Service");
>>         jcas = cas.getJCas();
>>         jcas.setDocumentText("Some Text");
>>       } catch (CASException e) {
>>         throw new ResourceProcessException(e);
>>       }
>>       uimaAsEngine.sendCAS(cas);
>>     }
>>     // done
>>     uimaAsEngine.stop();
>>
>>   }
>>   public static void main(String[] args ) {
>>     TestUimaASClient client = new TestUimaASClient();
>>     try {
>>       client.initialize();
>>       client.run();
>>     } catch( Exception e) {
>>       e.printStackTrace();
>>     }
>>   }
>>
>> }
>>
>> The above runs to completion no matter how many CASes are sent.
>>
>> Pierre, can you test the above client with your service? Just change the
>> ServerUri and Endpoint settings in the initialize() method.
>>
>> JC
>>
>> On Wed, Mar 31, 2010 at 10:53 AM, Eddie Epstein<eaepstein@gmail.com>
>>  wrote:
>>
>>
>>
>>> This sounds correct when using sendAndReceiveCAS, but not when
>>> using sendCAS.
>>>
>>> With the asynchronous sendCAS interface the application gets the CAS
>>> back within the callback listener registered via
>>> addStatusCallbackListener.
>>> And the CAS is *not* supposed to be released in the user's
>>> entityProcessComplete method in the listener class.
>>>
>>> Perhaps there is a bug if no listener class is registered?
>>>
>>> Eddie
>>>
>>> On Wed, Mar 31, 2010 at 9:52 AM, Jaroslaw Cwiklik<uimaee@gmail.com>
>>> wrote:
>>>
>>>
>>>> You are not calling cas.release() when you are done with the CAS.
>>>> Per UIMA AS documentation ("4.2 The UimaAsynchronousEngine Interface -
>>>>
>>>>
>>> CAS
>>>
>>>
>>>> getCAS()"
>>>>
>>>> "...CAS getCAS(): Requests a new CAS instance from the CAS pool. This
>>>>
>>>>
>>> method
>>>
>>>
>>>> blocks until a free instance of CAS is available in the CAS pool.
>>>> Applications that
>>>> use getCAS() need to call CAS.reset() before reusing the CAS, or
>>>> CAS.release()
>>>> to return it to the Cas pool."
>>>>
>>>> The release() places a CAS back into the pool so the subsequent call to
>>>> getCAS()
>>>> succeeds. An alternate strategy is to have a single CAS instance in the
>>>>
>>>>
>>> CAS
>>>
>>>
>>>> pool
>>>> call getCAS() to get that instance and enter a while loop. When done
>>>> processing
>>>> reply, call cas.reset() and do *not* call getCAS() again.
>>>>
>>>> JC
>>>>
>>>> On Tue, Mar 30, 2010 at 5:41 AM, pierre yahoo<ppujalon@yahoo.fr>
>>>>  wrote:
>>>>
>>>>
>>>>
>>>>> I'm trying to use UIMA-AS to scale a part of the process of our
>>>>> application.
>>>>> I have successfully deployed our process as asynchronous services but
I
>>>>> have tremendous issues with the client.
>>>>>
>>>>> I'm basically looping synchronously(one at a time) on the following
>>>>>
>>>>>
>>>> code.
>>>
>>>
>>>>     CAS cas = uimaEEEngine.getCAS();
>>>>>     JCas jcas;
>>>>>     try {
>>>>>        jcas = cas.getJCas();
>>>>>     } catch (CASException e) {
>>>>>         throw new ResourceProcessException(e);
>>>>>     }
>>>>>     fillCas(jcas);
>>>>>     uimaEEEngine.sendCAS(cas);
>>>>>
>>>>> When I run the application, the client works fine for a while and
>>>>>
>>>>>
>>>> suddenly
>>>
>>>
>>>> gets stuck waiting on cas.getJCas()..
>>>>> I have checked that the asynchronous service have processed all the
>>>>> previous  CAS.  The service is still up and running as I can send
>>>>>
>>>>>
>>>> requests
>>>
>>>
>>>> from an another client.
>>>>> When I tracked down who locks the process, I can see that the semaphore
>>>>>
>>>>>
>>>> on
>>>
>>>
>>>> CasQueueEntry is not released.
>>>>> When I looked further, I noticed that the all process is basically lock
>>>>> when the CasManager_Impl is calling CasPool.getCas(0) . The CasPool is
>>>>>
>>>>>
>>>> then
>>>
>>>
>>>> waiting with no timeout for someone to notify it.
>>>>>
>>>>> I try to change the size of the client CasPool but it didn't really fix
>>>>>
>>>>>
>>>> the
>>>
>>>
>>>> issue. Just pushing further the lock...
>>>>>
>>>>> Does anyone have ever experienced this? Am I doing something wrong ?
>>>>>
>>>>> Pierre
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

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