Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
Received-SPF: pass (nike.apache.org: domain of msa@schor.com designates
 67.18.62.17 as permitted sender)
Message-ID: <4F2AD3B4.4020500@schor.com>
Date: Thu, 02 Feb 2012 13:19:32 -0500
From: Marshall Schor <msa@schor.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: user@uima.apache.org
Subject: Re: UimaAsynchronousEngine client poor performance when the pipeline
 is slow processing the CAS
References: 
 <CAOy42CsHqo=RxL37BERnZh7uOx388ZB7oXmx8psHom9cO-Rdxw@mail.gmail.com>
 <CAO329yCMyiPZJn9ZiV4iH3A0wvPgLUHnX4zYTaXj3A+NZiXm=g@mail.gmail.com>
 <CAO329yC=fAs2VkdW=9ykixCp3jnPxkrL3=HC5EJh+F=0zmSPRA@mail.gmail.com>
 <CAOy42Cv+8wknOZb=OW3tcrbQCbqWUHmuVvpeift8KA8uAf4VMg@mail.gmail.com>
In-Reply-To: 
 <CAOy42Cv+8wknOZb=OW3tcrbQCbqWUHmuVvpeift8KA8uAf4VMg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020804000300050408090003"

--------------020804000300050408090003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


On 2/2/2012 9:34 AM, Spico Florin wrote:
>
>
> Hello!
>
>   Thank you for your answers. I'm using uima 2.3.1. Here is my testing code:
> //Endpoint initialization
>     private int fsHeapSize = 2000000;
>     private int timeout = 600;
>     private int getmeta_timeout = 60;
>     private int cpc_timeout = 1;
>
>       Map<String, Object> appCtx = new HashMap<String, Object>();
>             uimaEEEngine = new BaseUIMAAsynchronousEngine_impl();
>
>         appCtx.put(UimaAsynchronousEngine.ServerUri, "tcp://localhost:61616");
>         ppCtx.put(UimaAsynchronousEngine.Endpoint, "myEndpoint");
>         appCtx.put(UimaAsynchronousEngine.Timeout, timeout * 1000);
>         appCtx.put(UimaAsynchronousEngine.GetMetaTimeout,
>                 getmeta_timeout * 1000);
>         appCtx.put(UimaAsynchronousEngine.CpcTimeout, cpc_timeout * 1000);
> *     appCtx.put(UimaAsynchronousEngine.CasPoolSize, 50);
> *    appCtx.put(UIMAFramework.CAS_INITIAL_HEAP_SIZE,
>                 Integer.valueOf(fsHeapSize / 4).toString());
>         uimaEEEngine.initialize(appCtx);
>
> //sending message to UIMA
> public void sendToUIMA(String msg) throws Exception {
>         long startTime = System.currentTimeMillis();
>         System.out.println("Preparing CAS");
> *   CAS cas = uimaEEEngine.getCAS();
> *   long eTime = System.currentTimeMillis();
>         System.out.println("Prepared CAS time:"+(eTime-startTome));
> *
> *
>         JCas jcas;
>         try {
> **  jcas = cas.getJCas();*
> * } catch (CASException e) {
>             throw new CollectionException(e);
>         }
>         uimaEEEngine.sendCAS(jcas.getCas());
> }
>
> //calls from main() to UIMA client
>
> public static void main(String[] args) throws Exception {
>         UIMAPipelineConnector runner = new UIMAPipelineConnector();
>
>         for (int i = 0; i < 1000; i++) {
>             runner.sendToUIMA("A message that takes a lot of time for the UIMA 
> pipeline to process");
>
>             Thread.sleep(10);
>         }
> }
>
>
> //deployment descriptor main set up
>
> endpoint flow controller descriptor (main entry of the pipeline):
>
> <deployment protocol="jms" provider="activemq">
> *<casPool numberOfCASes="15"/>
> *<service>
> <inputQueue endpoint="myEndpoint" brokerURL="${defaultBrokerURL}"/>
>
>
> In my pipeline I have a component that is running slow (aprox 14s). What is 
> interesting is when the pool size is reaching its limits (50), the time spent 
> by the UIMAEngine to get a new CAS (getCAS() method) is almost the same time 
> with the time spent by the slower component. 

hmmm, I think this may be working exactly as it should?   It's supposed to work 
like this:

1) you set up a pool size in your client of 50.
2) The client starts sending CASes to the server(s).
3) Each CAS it sends depletes the pool; each CAS that finishes is added back to 
the pool.
4) Since you can generate CASes in the client faster than the pipeline can 
process them, a Queue builds up to hold the CASes the client has submitted, but 
are not yet being processed.  The size of this queue is limited to 50 - the size 
of the client CAS pool.
5) At some point the pool is empty - all 50 CASes are out either at the broker 
(in queue) or being processed.  At that point, the client's call to getCas will 
"hang" because the pool is empty, until one of the 50 outstanding CASes returns.

Does this sound like what's happening, or am I missing something?

-Marshall

> Below is  the output of running the code:
>
> Preparing CAS
> Prepared CAS time:14270
> Preparing CAS
> Prepared CAS time:14478
>
> Another proof the the method getCAS() poor performance is given by the 
> attached snapshot taken from the profiler jVisualVM.
>
> Hope that the above clarifies my problems and concerns.
> I'll look forward for your suggestions and answers.
>
> Thank you.
> Regards,
>   Florin
>
>
>
>
> On Wed, Feb 1, 2012 at 4:55 PM, Jaroslaw Cwiklik <uimaee@gmail.com 
> <mailto:uimaee@gmail.com>> wrote:
>
>     Sorry didnt finish my thought on question #1. If you see sendCAS()
>     blocking, attach jConsole to the application (you may need to enable JMX),
>     view the threads and check where your application thread is blocking.
>
>     JC
>
>     On Wed, Feb 1, 2012 at 9:52 AM, Jaroslaw Cwiklik <uimaee@gmail.com
>     <mailto:uimaee@gmail.com>> wrote:
>
>     > Florin from you description I cant figure out the cause of the slowness
>     > that you see. Are you saying that your application thread is stuck in
>     > sendCAS() method as if it was waiting for a reply? This is certainly not
>     > intent behind this API. It is an asynchronous call and should not wait for
>     > a reply when the request is dispatched. How are you getting CASes? Do you
>     > have your own CAS pool or use the one the UimaAsynchronousEngine provides.
>     > How big is the CAS pool? Are you getting any replies via a
>     > entityProcessComplete() callback? Which version of uima-as are you using:
>     > 2.3.1 or recent build from svn?
>     >
>     > To your questions:
>     >
>     > 1) What do you mean by "..disable the response feature"? The sendCAS() is
>     > asynch method which should not block. If it is blocking, than this is a bug
>     > in UIMA AS client. To debug this problem, you can
>     > 2) The UimaAsynchronousEngine can be called from multiple threads and use
>     > of ThreadPoolExecutor seems fine.
>     > 3) Have you tried to scale the pipeline to allow multiple CASes to be
>     > processed at the same time? .
>     >
>     > Jerry
>     >
>     >
>     > On Wed, Feb 1, 2012 at 5:11 AM, Spico Florin <spicoflorin@gmail.com
>     <mailto:spicoflorin@gmail.com>>wrote:
>     >
>     >> Hello!
>     >> I have application client that is receiving messages from a Queue via JMS.
>     >> The message is then packed in a JCas and sent to the UIMA AS pipeline via
>     >> UimaAsynchronousEngine.
>     >> If the UIMA AS pipeline processing is slow then it impacts the client in
>     >> the way that the received messages from the
>     >> Queue will not be sent as they arrived. I'm using sendCAS(CAS) method of
>     >> UimaAsynchronousEngine, thus the call to pipeline should be asynchronous
>     >> (as specfied in the spec).
>     >>  In my opinion the described behavior is not as expected (i.e. the client
>     >> should not be affected by the UIMA pipeline performance and
>     >> it should send the received messages for processing right away, without
>     >> waiting some responses).
>     >>  My questions are:
>     >> 1. I suspect, that my client is somehow waiting the response from the
>     >> pipeline. Is there any way to disable the response feature?
>     >> 2. I'm using a thread pool executor that is sending the messages to UIMA
>     >> pipeline. Is this a good approach?
>     >> 3. How to design my client in order to send the messages to the pipeline
>     >> without concerning the pipeline performance?
>     >>
>     >> I look forward for your answers and advices.
>     >>  Thank you.
>     >>   Best regards,
>     >>
>     >>    Florin
>     >>
>     >
>     >
>
>

--------------020804000300050408090003--