You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Spico Florin <sp...@gmail.com> on 2012/02/01 11:11:06 UTC
UimaAsynchronousEngine client poor performance when the pipeline is
slow processing the CAS
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
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Marshall Schor <ms...@schor.com>.
Are you following the examples in
http://uima.apache.org/downloads/releaseDocs/2.3.0-incubating/docs-uima-as/html/uima_async_scaleout/uima_async_scaleout.html#ugr.ref.async.api.usage
You may be limited by the size of the CAS pool (see the example code for how to
set this).
-Marshall
On 2/1/2012 5:11 AM, Spico Florin 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
>
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Jaroslaw Cwiklik <ui...@gmail.com>.
You dont have to use UimaAsynchronousEngine.getCAS() method to get CASes.
If you want to manage CASes yourself use CasCreationUtils. Here is a
javadoc for this class:
http://uima.apache.org/d/uimaj-2.4.0/apidocs/org/apache/uima/util/CasCreationUtils.html
JC
On Fri, Feb 3, 2012 at 3:10 AM, Spico Florin <sp...@gmail.com> wrote:
> Hello!
>
> Hmmm...My expectations regarding the UIMAASEngine capabilities were
> different than the current implementations.In my opinion the client
> shouldn't hang up due to the poor performance of the processing pipeline.
> It should pump up all the created JCAS to the MQ queue, thus consumer(UIMA
> AS service) MQ queue will be filled up with messages. Also, after the CAS
> was sent to the pipeline the the CAS should be put in the pool. You can see
> my expected feature the same way for a client to the MQ Broker. The JMS
> client puts messages in the queue without any concerns regarding the time
> the message will be consumed by the endpoint.
> What is your opinions regarding my approach? Is it feasible? How this
> will affect the processing pipeline?
>
> I look forward for your answers.
> Thank you.
>
> Kind regards,
> Florin
>
>
>
>
> On Thu, Feb 2, 2012 at 8:19 PM, Marshall Schor <ms...@schor.com> wrote:
>
> >
> >
> > 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
> >> <ma...@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
> >> <ma...@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
> >> >>
> >> >
> >> >
> >>
> >>
> >>
>
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Spico Florin <sp...@gmail.com>.
Hello!
Hmmm...My expectations regarding the UIMAASEngine capabilities were
different than the current implementations.In my opinion the client
shouldn't hang up due to the poor performance of the processing pipeline.
It should pump up all the created JCAS to the MQ queue, thus consumer(UIMA
AS service) MQ queue will be filled up with messages. Also, after the CAS
was sent to the pipeline the the CAS should be put in the pool. You can see
my expected feature the same way for a client to the MQ Broker. The JMS
client puts messages in the queue without any concerns regarding the time
the message will be consumed by the endpoint.
What is your opinions regarding my approach? Is it feasible? How this
will affect the processing pipeline?
I look forward for your answers.
Thank you.
Kind regards,
Florin
On Thu, Feb 2, 2012 at 8:19 PM, Marshall Schor <ms...@schor.com> wrote:
>
>
> 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
>> <ma...@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
>> <ma...@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
>> >>
>> >
>> >
>>
>>
>>
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Marshall Schor <ms...@schor.com>.
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
> <ma...@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
> <ma...@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
> <ma...@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
> >>
> >
> >
>
>
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Spico Florin <sp...@gmail.com>.
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. 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 <ui...@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 <ui...@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
> >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
> >>
> >
> >
>
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Jaroslaw Cwiklik <ui...@gmail.com>.
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 <ui...@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 <sp...@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
>>
>
>
Re: UimaAsynchronousEngine client poor performance when the pipeline
is slow processing the CAS
Posted by Jaroslaw Cwiklik <ui...@gmail.com>.
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 <sp...@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
>