You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@uima.apache.org by Prokopis Prokopidis <pr...@ilsp.gr> on 2013/10/17 18:19:48 UTC
XmiCasSerializer error in UIMA-AS
Hi all,
I have an AE that produces the error below when deployed as a UIMA-AS
2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit 2.*
pipeline does not produce any errors and works as expected.
Among other things, this AE uses ruta rules to process the CAS. When the
rules are not used, the AE works as expected in both UIMA and UIMA-AS.
I have tried to log all annotations generated by the AE when the rules
are used and just before the AE processing is finished. The annotations
seem the same in both the UIMA and the UIMA-AS processing scenarios.
Does anyone have hints on what the cause of this might be or how I
should proceed in debugging?
Many thanks in advance,
Prokopis
WARNING:
java.lang.ArrayIndexOutOfBoundsException
at
org.apache.uima.internal.util.IntVector.remove(IntVector.java:207)
at org.apache.uima.internal.util.IntSet.remove(IntSet.java:77)
at
org.apache.uima.cas.impl.FSIndexRepositoryImpl.processIndexUpdates(FSIndexRepositoryImpl.java:1756)
at
org.apache.uima.cas.impl.FSIndexRepositoryImpl.isModified(FSIndexRepositoryImpl.java:1800)
at
org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.serialize(XmiCasSerializer.java:256)
at
org.apache.uima.cas.impl.XmiCasSerializer$XmiCasDocSerializer.access$700(XmiCasSerializer.java:108)
at
org.apache.uima.cas.impl.XmiCasSerializer.serialize(XmiCasSerializer.java:1566)
at
org.apache.uima.aae.UimaSerializer.serializeCasToXmi(UimaSerializer.java:160)
at
org.apache.uima.adapter.jms.activemq.JmsOutputChannel.serializeCAS(JmsOutputChannel.java:237)
at
org.apache.uima.adapter.jms.activemq.JmsOutputChannel.getSerializedCas(JmsOutputChannel.java:1223)
at
org.apache.uima.adapter.jms.activemq.JmsOutputChannel.sendReply(JmsOutputChannel.java:786)
at
org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl.process(PrimitiveAnalysisEngineController_impl.java:1036)
at
org.apache.uima.aae.handler.HandlerBase.invokeProcess(HandlerBase.java:121)
at
org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handleProcessRequestFromRemoteClient(ProcessRequestHandler_impl.java:542)
at
org.apache.uima.aae.handler.input.ProcessRequestHandler_impl.handle(ProcessRequestHandler_impl.java:1041)
at
org.apache.uima.aae.handler.input.MetadataRequestHandler_impl.handle(MetadataRequestHandler_impl.java:78)
at
org.apache.uima.adapter.jms.activemq.JmsInputChannel.onMessage(JmsInputChannel.java:706)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:535)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:495)
at
org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
at
org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
at
org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:952)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.uima.aae.UimaAsThreadFactory$1.run(UimaAsThreadFactory.java:118)
at java.lang.Thread.run(Thread.java:724)
Re: XmiCasSerializer error in UIMA-AS
Posted by Marshall Schor <ms...@schor.com>.
Hi,
This is I think a plain and simple bug.
Here's the Jira I created: https://issues.apache.org/jira/browse/UIMA-3396
I'll do a fix...
-Marshall
On 10/30/2013 9:11 AM, Eddie Epstein wrote:
> Other than reordering the CAS within an annotator via CAS
> serialization/deserialization, nothing else comes to mind. So the next idea
> would be to pursue a UIMA bug.
>
> Looking at the exception stack shows the problem is associated with
> deleting an FS from the index repository. Code in ruta-core does
> cas.addFsToIndexes and cas.removeFsFromIndexes. Perhaps there is a bug in
> UIMA delta CAS processing associated with this scenario. Much as I would
> like to,
> can't think of any way to blade Ruta code for this.
>
> Eddie
>
>
> On Wed, Oct 30, 2013 at 4:38 AM, Peter Klügl <pk...@uni-wuerzburg.de>wrote:
>
>> On 29.10.2013 17:36, Eddie Epstein wrote:
>>> Hi Peter,
>>>
>>> Things like XmiCasDeserializer.deserialize(new FileInputStream(each),
>> cas,
>>> true) in RutaInterpreterRunner?
>> Ah ok, that shouldn't cause any problems. It's code of the eclipse-based
>> tooling and should not be used in a normal pipeline. The problem (if
>> ruta causes it) has to be in ruta-core, I think.
>>
>>> I am only looking for things that would do something unexpected to a
>> CAS. I
>>> would not be so concerned with the new Ruta annotations as with changes
>> to
>>> previously existing annotations.
>> Are there any known modifications that cause problems?
>>
>> Peter
>>
>>> Eddie
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Oct 29, 2013 at 9:39 AM, Peter Klügl <pkluegl@uni-wuerzburg.de
>>> wrote:
>>>
>>>> On 28.10.2013 13:47, Eddie Epstein wrote:
>>>>> Assuming you would rather not share the CAS files, what I'd be looking
>>>> for
>>>>> is the xmi:id values changing between the before and after files. There
>>>> is
>>>>> some code in ruta that replaces CASes with serialization from files
>> which
>>>>> could be the cause of this problem.
>>>> What code do you mean?
>>>>
>>>> I have no idea what the problem could be. I would have bet that the
>>>> RutaBasic annotation cause the problem, but the problem apparently still
>>>> exists if all ruta specific annotations are yet removed in the analysis
>>>> engine.
>>>>
>>>> Peter
>>>>
>>>>> Eddie
>>>>>
>>>>>
>>>>> On Tue, Oct 22, 2013 at 10:21 AM, Eddie Epstein <ea...@gmail.com>
>>>> wrote:
>>>>>> Can you share the before and after XmiCas files for a case where
>> UIMA-AS
>>>>>> service serialization failed? No confidential info please!
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <
>> prokopis@ilsp.gr
>>>>> wrote:
>>>>>>> No, this is not an easily reproduced error: I have noticed it so far
>>>> only
>>>>>>> upon application of typesystem-specific ruta rules. I will try to
>> come
>>>> up
>>>>>>> with an easily reproducible example.
>>>>>>>
>>>>>>> In the meantime, I followed your suggestions and added 2 XMI
>>>>>>> serialization calls at the end of the AE processing for the failing
>>>> case,
>>>>>>> just before and just after using the ruta rules for modifying the
>>>>>>> annotations in my CAS. In both cases, serialization to file
>> succeeded,
>>>> with
>>>>>>> the second file containing the expected results of rule application.
>>>>>>>
>>>>>>> Unfortunately, the UIMA-AS serialization still produces the error in
>> my
>>>>>>> original mail.
>>>>>>>
>>>>>>> Prokopis
>>>>>>>
>>>>>>>
>>>>>>> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
>>>>>>>
>>>>>>>> Is this a solid error that is easily reproduced?
>>>>>>>>
>>>>>>>> The error is occurring when UIMA-AS is returning the CAS from the
>>>>>>>> service.
>>>>>>>> You could add XMI serialization to file at the end of AE processing,
>>>> for
>>>>>>>> the good and failing cases. If so lucky to have that serialization
>>>> fail
>>>>>>>> too, could try inserting the serialization at points earlier.
>>>>>>>>
>>>>>>>> Note that the UIMA-AS serialization is only serializing the delta
>>>> changes
>>>>>>>> from the input CAS, different from what you would do.
>>>>>>>>
>>>>>>>> Eddie
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <
>>>> prokopis@ilsp.gr
>>>>>>>>> wrote:
>>>>>>>> Hi all,
>>>>>>>>> I have an AE that produces the error below when deployed as a
>> UIMA-AS
>>>>>>>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit
>>>> 2.*
>>>>>>>>> pipeline does not produce any errors and works as expected.
>>>>>>>>>
>>>>>>>>> Among other things, this AE uses ruta rules to process the CAS.
>> When
>>>> the
>>>>>>>>> rules are not used, the AE works as expected in both UIMA and
>>>> UIMA-AS.
>>>>>>>>> I have tried to log all annotations generated by the AE when the
>>>> rules
>>>>>>>>> are
>>>>>>>>> used and just before the AE processing is finished. The annotations
>>>> seem
>>>>>>>>> the same in both the UIMA and the UIMA-AS processing scenarios.
>>>>>>>>>
>>>>>>>>> Does anyone have hints on what the cause of this might be or how I
>>>>>>>>> should
>>>>>>>>> proceed in debugging?
>>>>>>>>>
>>>>>>>>> Many thanks in advance,
>>>>>>>>>
>>>>>>>>> Prokopis
>>>>>>>>>
>>>>>>>>> WARNING:
>>>>>>>>> java.lang.****ArrayIndexOutOfBoundsException
>>>>>>>>> at org.apache.uima.internal.util.**
>>>>>>>>> **IntVector.remove(IntVector.****
>>>>>>>>> java:207)
>>>>>>>>> at org.apache.uima.internal.util.**
>>>>>>>>> **IntSet.remove(IntSet.java:**77)
>>>>>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
>>>>>>>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
>>>>>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
>>>>>>>>> isModified(*
>>>>>>>>> *FSIndexRepositoryImpl.java:****1800)
>>>>>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>>>>>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
>>>>>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>>>>>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
>>>>>>>>> at
>>>> org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
>>>>>>>>> XmiCasSerializer.java:1566)
>>>>>>>>> at org.apache.uima.aae.****UimaSerializer.****
>>>>>>>>> serializeCasToXmi(**
>>>>>>>>> UimaSerializer.java:160)
>>>>>>>>> at org.apache.uima.adapter.jms.****
>>>>>>>>> activemq.JmsOutputChannel.**
>>>>>>>>> serializeCAS(JmsOutputChannel.****java:237)
>>>>>>>>> at org.apache.uima.adapter.jms.****
>>>>>>>>> activemq.JmsOutputChannel.**
>>>>>>>>> getSerializedCas(****JmsOutputChannel.java:1223)
>>>>>>>>> at org.apache.uima.adapter.jms.****
>>>>>>>>> activemq.JmsOutputChannel.**
>>>>>>>>> sendReply(JmsOutputChannel.****java:786)
>>>>>>>>> at org.apache.uima.aae.****controller.**
>>>>>>>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
>>>>>>>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
>>>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>>>> HandlerBase.invokeProcess(**
>>>>>>>>> HandlerBase.java:121)
>>>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>>>> input.ProcessRequestHandler_**
>>>>>>>>> impl.****handleProcessRequestFromRemote****Client(**
>>>>>>>>> ProcessRequestHandler_**
>>>>>>>>> impl.java:542)
>>>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>>>> input.ProcessRequestHandler_**
>>>>>>>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
>>>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>>>> input.MetadataRequestHandler_****
>>>>>>>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
>>>>>>>>> at
>>>> org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
>>>>>>>>> onMessage(JmsInputChannel.****java:706)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>> AbstractMessageListenerContain****er.doInvokeListener(**
>>>>>>>>> AbstractMessageListenerContain****er.java:535)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>> AbstractMessageListenerContain****er.invokeListener(**
>>>>>>>>> AbstractMessageListenerContain****er.java:495)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>> AbstractMessageListenerContain****er.doExecuteListener(**
>>>>>>>>> AbstractMessageListenerContain****er.java:467)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>>
>> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
>>>>>>>>> AbstractPollingMessageListener****Container.java:325)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
>>>>>>>>> AbstractPollingMessageListener****Container.java:263)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>>
>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
>>>>>>>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
>>>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>>>
>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
>>>>>>>>> run(**
>>>>>>>>> DefaultMessageListenerContaine****r.java:952)
>>>>>>>>> at
>>>> java.util.concurrent.****ThreadPoolExecutor.runWorker(****
>>>>>>>>> ThreadPoolExecutor.java:1145)
>>>>>>>>> at
>>>> java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
>>>>>>>>> ThreadPoolExecutor.java:615)
>>>>>>>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
>>>>>>>>> UimaAsThreadFactory.java:118)
>>>>>>>>> at java.lang.Thread.run(Thread.****java:724)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
Re: XmiCasSerializer error in UIMA-AS
Posted by Eddie Epstein <ea...@gmail.com>.
Other than reordering the CAS within an annotator via CAS
serialization/deserialization, nothing else comes to mind. So the next idea
would be to pursue a UIMA bug.
Looking at the exception stack shows the problem is associated with
deleting an FS from the index repository. Code in ruta-core does
cas.addFsToIndexes and cas.removeFsFromIndexes. Perhaps there is a bug in
UIMA delta CAS processing associated with this scenario. Much as I would
like to,
can't think of any way to blade Ruta code for this.
Eddie
On Wed, Oct 30, 2013 at 4:38 AM, Peter Klügl <pk...@uni-wuerzburg.de>wrote:
> On 29.10.2013 17:36, Eddie Epstein wrote:
> > Hi Peter,
> >
> > Things like XmiCasDeserializer.deserialize(new FileInputStream(each),
> cas,
> > true) in RutaInterpreterRunner?
>
> Ah ok, that shouldn't cause any problems. It's code of the eclipse-based
> tooling and should not be used in a normal pipeline. The problem (if
> ruta causes it) has to be in ruta-core, I think.
>
> > I am only looking for things that would do something unexpected to a
> CAS. I
> > would not be so concerned with the new Ruta annotations as with changes
> to
> > previously existing annotations.
>
> Are there any known modifications that cause problems?
>
> Peter
>
> > Eddie
> >
> >
> >
> >
> >
> > On Tue, Oct 29, 2013 at 9:39 AM, Peter Klügl <pkluegl@uni-wuerzburg.de
> >wrote:
> >
> >> On 28.10.2013 13:47, Eddie Epstein wrote:
> >>> Assuming you would rather not share the CAS files, what I'd be looking
> >> for
> >>> is the xmi:id values changing between the before and after files. There
> >> is
> >>> some code in ruta that replaces CASes with serialization from files
> which
> >>> could be the cause of this problem.
> >> What code do you mean?
> >>
> >> I have no idea what the problem could be. I would have bet that the
> >> RutaBasic annotation cause the problem, but the problem apparently still
> >> exists if all ruta specific annotations are yet removed in the analysis
> >> engine.
> >>
> >> Peter
> >>
> >>> Eddie
> >>>
> >>>
> >>> On Tue, Oct 22, 2013 at 10:21 AM, Eddie Epstein <ea...@gmail.com>
> >> wrote:
> >>>> Can you share the before and after XmiCas files for a case where
> UIMA-AS
> >>>> service serialization failed? No confidential info please!
> >>>>
> >>>> Eddie
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <
> prokopis@ilsp.gr
> >>> wrote:
> >>>>> No, this is not an easily reproduced error: I have noticed it so far
> >> only
> >>>>> upon application of typesystem-specific ruta rules. I will try to
> come
> >> up
> >>>>> with an easily reproducible example.
> >>>>>
> >>>>> In the meantime, I followed your suggestions and added 2 XMI
> >>>>> serialization calls at the end of the AE processing for the failing
> >> case,
> >>>>> just before and just after using the ruta rules for modifying the
> >>>>> annotations in my CAS. In both cases, serialization to file
> succeeded,
> >> with
> >>>>> the second file containing the expected results of rule application.
> >>>>>
> >>>>> Unfortunately, the UIMA-AS serialization still produces the error in
> my
> >>>>> original mail.
> >>>>>
> >>>>> Prokopis
> >>>>>
> >>>>>
> >>>>> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
> >>>>>
> >>>>>> Is this a solid error that is easily reproduced?
> >>>>>>
> >>>>>> The error is occurring when UIMA-AS is returning the CAS from the
> >>>>>> service.
> >>>>>> You could add XMI serialization to file at the end of AE processing,
> >> for
> >>>>>> the good and failing cases. If so lucky to have that serialization
> >> fail
> >>>>>> too, could try inserting the serialization at points earlier.
> >>>>>>
> >>>>>> Note that the UIMA-AS serialization is only serializing the delta
> >> changes
> >>>>>> from the input CAS, different from what you would do.
> >>>>>>
> >>>>>> Eddie
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <
> >> prokopis@ilsp.gr
> >>>>>>> wrote:
> >>>>>> Hi all,
> >>>>>>> I have an AE that produces the error below when deployed as a
> UIMA-AS
> >>>>>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit
> >> 2.*
> >>>>>>> pipeline does not produce any errors and works as expected.
> >>>>>>>
> >>>>>>> Among other things, this AE uses ruta rules to process the CAS.
> When
> >> the
> >>>>>>> rules are not used, the AE works as expected in both UIMA and
> >> UIMA-AS.
> >>>>>>> I have tried to log all annotations generated by the AE when the
> >> rules
> >>>>>>> are
> >>>>>>> used and just before the AE processing is finished. The annotations
> >> seem
> >>>>>>> the same in both the UIMA and the UIMA-AS processing scenarios.
> >>>>>>>
> >>>>>>> Does anyone have hints on what the cause of this might be or how I
> >>>>>>> should
> >>>>>>> proceed in debugging?
> >>>>>>>
> >>>>>>> Many thanks in advance,
> >>>>>>>
> >>>>>>> Prokopis
> >>>>>>>
> >>>>>>> WARNING:
> >>>>>>> java.lang.****ArrayIndexOutOfBoundsException
> >>>>>>> at org.apache.uima.internal.util.**
> >>>>>>> **IntVector.remove(IntVector.****
> >>>>>>> java:207)
> >>>>>>> at org.apache.uima.internal.util.**
> >>>>>>> **IntSet.remove(IntSet.java:**77)
> >>>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
> >>>>>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
> >>>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
> >>>>>>> isModified(*
> >>>>>>> *FSIndexRepositoryImpl.java:****1800)
> >>>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
> >>>>>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
> >>>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
> >>>>>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
> >>>>>>> at
> >> org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
> >>>>>>> XmiCasSerializer.java:1566)
> >>>>>>> at org.apache.uima.aae.****UimaSerializer.****
> >>>>>>> serializeCasToXmi(**
> >>>>>>> UimaSerializer.java:160)
> >>>>>>> at org.apache.uima.adapter.jms.****
> >>>>>>> activemq.JmsOutputChannel.**
> >>>>>>> serializeCAS(JmsOutputChannel.****java:237)
> >>>>>>> at org.apache.uima.adapter.jms.****
> >>>>>>> activemq.JmsOutputChannel.**
> >>>>>>> getSerializedCas(****JmsOutputChannel.java:1223)
> >>>>>>> at org.apache.uima.adapter.jms.****
> >>>>>>> activemq.JmsOutputChannel.**
> >>>>>>> sendReply(JmsOutputChannel.****java:786)
> >>>>>>> at org.apache.uima.aae.****controller.**
> >>>>>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
> >>>>>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
> >>>>>>> at org.apache.uima.aae.handler.****
> >>>>>>> HandlerBase.invokeProcess(**
> >>>>>>> HandlerBase.java:121)
> >>>>>>> at org.apache.uima.aae.handler.****
> >>>>>>> input.ProcessRequestHandler_**
> >>>>>>> impl.****handleProcessRequestFromRemote****Client(**
> >>>>>>> ProcessRequestHandler_**
> >>>>>>> impl.java:542)
> >>>>>>> at org.apache.uima.aae.handler.****
> >>>>>>> input.ProcessRequestHandler_**
> >>>>>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
> >>>>>>> at org.apache.uima.aae.handler.****
> >>>>>>> input.MetadataRequestHandler_****
> >>>>>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
> >>>>>>> at
> >> org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
> >>>>>>> onMessage(JmsInputChannel.****java:706)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>> AbstractMessageListenerContain****er.doInvokeListener(**
> >>>>>>> AbstractMessageListenerContain****er.java:535)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>> AbstractMessageListenerContain****er.invokeListener(**
> >>>>>>> AbstractMessageListenerContain****er.java:495)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>> AbstractMessageListenerContain****er.doExecuteListener(**
> >>>>>>> AbstractMessageListenerContain****er.java:467)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>>
> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
> >>>>>>> AbstractPollingMessageListener****Container.java:325)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
> >>>>>>> AbstractPollingMessageListener****Container.java:263)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>>
> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
> >>>>>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
> >>>>>>> at org.springframework.jms.****listener.**
> >>>>>>>
> >> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
> >>>>>>> run(**
> >>>>>>> DefaultMessageListenerContaine****r.java:952)
> >>>>>>> at
> >> java.util.concurrent.****ThreadPoolExecutor.runWorker(****
> >>>>>>> ThreadPoolExecutor.java:1145)
> >>>>>>> at
> >> java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
> >>>>>>> ThreadPoolExecutor.java:615)
> >>>>>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
> >>>>>>> UimaAsThreadFactory.java:118)
> >>>>>>> at java.lang.Thread.run(Thread.****java:724)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>
>
>
Re: XmiCasSerializer error in UIMA-AS
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 29.10.2013 17:36, Eddie Epstein wrote:
> Hi Peter,
>
> Things like XmiCasDeserializer.deserialize(new FileInputStream(each), cas,
> true) in RutaInterpreterRunner?
Ah ok, that shouldn't cause any problems. It's code of the eclipse-based
tooling and should not be used in a normal pipeline. The problem (if
ruta causes it) has to be in ruta-core, I think.
> I am only looking for things that would do something unexpected to a CAS. I
> would not be so concerned with the new Ruta annotations as with changes to
> previously existing annotations.
Are there any known modifications that cause problems?
Peter
> Eddie
>
>
>
>
>
> On Tue, Oct 29, 2013 at 9:39 AM, Peter Klügl <pk...@uni-wuerzburg.de>wrote:
>
>> On 28.10.2013 13:47, Eddie Epstein wrote:
>>> Assuming you would rather not share the CAS files, what I'd be looking
>> for
>>> is the xmi:id values changing between the before and after files. There
>> is
>>> some code in ruta that replaces CASes with serialization from files which
>>> could be the cause of this problem.
>> What code do you mean?
>>
>> I have no idea what the problem could be. I would have bet that the
>> RutaBasic annotation cause the problem, but the problem apparently still
>> exists if all ruta specific annotations are yet removed in the analysis
>> engine.
>>
>> Peter
>>
>>> Eddie
>>>
>>>
>>> On Tue, Oct 22, 2013 at 10:21 AM, Eddie Epstein <ea...@gmail.com>
>> wrote:
>>>> Can you share the before and after XmiCas files for a case where UIMA-AS
>>>> service serialization failed? No confidential info please!
>>>>
>>>> Eddie
>>>>
>>>>
>>>>
>>>> On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <prokopis@ilsp.gr
>>> wrote:
>>>>> No, this is not an easily reproduced error: I have noticed it so far
>> only
>>>>> upon application of typesystem-specific ruta rules. I will try to come
>> up
>>>>> with an easily reproducible example.
>>>>>
>>>>> In the meantime, I followed your suggestions and added 2 XMI
>>>>> serialization calls at the end of the AE processing for the failing
>> case,
>>>>> just before and just after using the ruta rules for modifying the
>>>>> annotations in my CAS. In both cases, serialization to file succeeded,
>> with
>>>>> the second file containing the expected results of rule application.
>>>>>
>>>>> Unfortunately, the UIMA-AS serialization still produces the error in my
>>>>> original mail.
>>>>>
>>>>> Prokopis
>>>>>
>>>>>
>>>>> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
>>>>>
>>>>>> Is this a solid error that is easily reproduced?
>>>>>>
>>>>>> The error is occurring when UIMA-AS is returning the CAS from the
>>>>>> service.
>>>>>> You could add XMI serialization to file at the end of AE processing,
>> for
>>>>>> the good and failing cases. If so lucky to have that serialization
>> fail
>>>>>> too, could try inserting the serialization at points earlier.
>>>>>>
>>>>>> Note that the UIMA-AS serialization is only serializing the delta
>> changes
>>>>>> from the input CAS, different from what you would do.
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <
>> prokopis@ilsp.gr
>>>>>>> wrote:
>>>>>> Hi all,
>>>>>>> I have an AE that produces the error below when deployed as a UIMA-AS
>>>>>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit
>> 2.*
>>>>>>> pipeline does not produce any errors and works as expected.
>>>>>>>
>>>>>>> Among other things, this AE uses ruta rules to process the CAS. When
>> the
>>>>>>> rules are not used, the AE works as expected in both UIMA and
>> UIMA-AS.
>>>>>>> I have tried to log all annotations generated by the AE when the
>> rules
>>>>>>> are
>>>>>>> used and just before the AE processing is finished. The annotations
>> seem
>>>>>>> the same in both the UIMA and the UIMA-AS processing scenarios.
>>>>>>>
>>>>>>> Does anyone have hints on what the cause of this might be or how I
>>>>>>> should
>>>>>>> proceed in debugging?
>>>>>>>
>>>>>>> Many thanks in advance,
>>>>>>>
>>>>>>> Prokopis
>>>>>>>
>>>>>>> WARNING:
>>>>>>> java.lang.****ArrayIndexOutOfBoundsException
>>>>>>> at org.apache.uima.internal.util.**
>>>>>>> **IntVector.remove(IntVector.****
>>>>>>> java:207)
>>>>>>> at org.apache.uima.internal.util.**
>>>>>>> **IntSet.remove(IntSet.java:**77)
>>>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
>>>>>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
>>>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
>>>>>>> isModified(*
>>>>>>> *FSIndexRepositoryImpl.java:****1800)
>>>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>>>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
>>>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>>>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
>>>>>>> at
>> org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
>>>>>>> XmiCasSerializer.java:1566)
>>>>>>> at org.apache.uima.aae.****UimaSerializer.****
>>>>>>> serializeCasToXmi(**
>>>>>>> UimaSerializer.java:160)
>>>>>>> at org.apache.uima.adapter.jms.****
>>>>>>> activemq.JmsOutputChannel.**
>>>>>>> serializeCAS(JmsOutputChannel.****java:237)
>>>>>>> at org.apache.uima.adapter.jms.****
>>>>>>> activemq.JmsOutputChannel.**
>>>>>>> getSerializedCas(****JmsOutputChannel.java:1223)
>>>>>>> at org.apache.uima.adapter.jms.****
>>>>>>> activemq.JmsOutputChannel.**
>>>>>>> sendReply(JmsOutputChannel.****java:786)
>>>>>>> at org.apache.uima.aae.****controller.**
>>>>>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
>>>>>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>> HandlerBase.invokeProcess(**
>>>>>>> HandlerBase.java:121)
>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>> input.ProcessRequestHandler_**
>>>>>>> impl.****handleProcessRequestFromRemote****Client(**
>>>>>>> ProcessRequestHandler_**
>>>>>>> impl.java:542)
>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>> input.ProcessRequestHandler_**
>>>>>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
>>>>>>> at org.apache.uima.aae.handler.****
>>>>>>> input.MetadataRequestHandler_****
>>>>>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
>>>>>>> at
>> org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
>>>>>>> onMessage(JmsInputChannel.****java:706)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>> AbstractMessageListenerContain****er.doInvokeListener(**
>>>>>>> AbstractMessageListenerContain****er.java:535)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>> AbstractMessageListenerContain****er.invokeListener(**
>>>>>>> AbstractMessageListenerContain****er.java:495)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>> AbstractMessageListenerContain****er.doExecuteListener(**
>>>>>>> AbstractMessageListenerContain****er.java:467)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
>>>>>>> AbstractPollingMessageListener****Container.java:325)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
>>>>>>> AbstractPollingMessageListener****Container.java:263)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
>>>>>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
>>>>>>> at org.springframework.jms.****listener.**
>>>>>>>
>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
>>>>>>> run(**
>>>>>>> DefaultMessageListenerContaine****r.java:952)
>>>>>>> at
>> java.util.concurrent.****ThreadPoolExecutor.runWorker(****
>>>>>>> ThreadPoolExecutor.java:1145)
>>>>>>> at
>> java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
>>>>>>> ThreadPoolExecutor.java:615)
>>>>>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
>>>>>>> UimaAsThreadFactory.java:118)
>>>>>>> at java.lang.Thread.run(Thread.****java:724)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>
Re: XmiCasSerializer error in UIMA-AS
Posted by Eddie Epstein <ea...@gmail.com>.
Hi Peter,
Things like XmiCasDeserializer.deserialize(new FileInputStream(each), cas,
true) in RutaInterpreterRunner?
I am only looking for things that would do something unexpected to a CAS. I
would not be so concerned with the new Ruta annotations as with changes to
previously existing annotations.
Eddie
On Tue, Oct 29, 2013 at 9:39 AM, Peter Klügl <pk...@uni-wuerzburg.de>wrote:
> On 28.10.2013 13:47, Eddie Epstein wrote:
> > Assuming you would rather not share the CAS files, what I'd be looking
> for
> > is the xmi:id values changing between the before and after files. There
> is
> > some code in ruta that replaces CASes with serialization from files which
> > could be the cause of this problem.
>
> What code do you mean?
>
> I have no idea what the problem could be. I would have bet that the
> RutaBasic annotation cause the problem, but the problem apparently still
> exists if all ruta specific annotations are yet removed in the analysis
> engine.
>
> Peter
>
> >
> > Eddie
> >
> >
> > On Tue, Oct 22, 2013 at 10:21 AM, Eddie Epstein <ea...@gmail.com>
> wrote:
> >
> >> Can you share the before and after XmiCas files for a case where UIMA-AS
> >> service serialization failed? No confidential info please!
> >>
> >> Eddie
> >>
> >>
> >>
> >> On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <prokopis@ilsp.gr
> >wrote:
> >>
> >>> No, this is not an easily reproduced error: I have noticed it so far
> only
> >>> upon application of typesystem-specific ruta rules. I will try to come
> up
> >>> with an easily reproducible example.
> >>>
> >>> In the meantime, I followed your suggestions and added 2 XMI
> >>> serialization calls at the end of the AE processing for the failing
> case,
> >>> just before and just after using the ruta rules for modifying the
> >>> annotations in my CAS. In both cases, serialization to file succeeded,
> with
> >>> the second file containing the expected results of rule application.
> >>>
> >>> Unfortunately, the UIMA-AS serialization still produces the error in my
> >>> original mail.
> >>>
> >>> Prokopis
> >>>
> >>>
> >>> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
> >>>
> >>>> Is this a solid error that is easily reproduced?
> >>>>
> >>>> The error is occurring when UIMA-AS is returning the CAS from the
> >>>> service.
> >>>> You could add XMI serialization to file at the end of AE processing,
> for
> >>>> the good and failing cases. If so lucky to have that serialization
> fail
> >>>> too, could try inserting the serialization at points earlier.
> >>>>
> >>>> Note that the UIMA-AS serialization is only serializing the delta
> changes
> >>>> from the input CAS, different from what you would do.
> >>>>
> >>>> Eddie
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <
> prokopis@ilsp.gr
> >>>>> wrote:
> >>>> Hi all,
> >>>>> I have an AE that produces the error below when deployed as a UIMA-AS
> >>>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit
> 2.*
> >>>>> pipeline does not produce any errors and works as expected.
> >>>>>
> >>>>> Among other things, this AE uses ruta rules to process the CAS. When
> the
> >>>>> rules are not used, the AE works as expected in both UIMA and
> UIMA-AS.
> >>>>>
> >>>>> I have tried to log all annotations generated by the AE when the
> rules
> >>>>> are
> >>>>> used and just before the AE processing is finished. The annotations
> seem
> >>>>> the same in both the UIMA and the UIMA-AS processing scenarios.
> >>>>>
> >>>>> Does anyone have hints on what the cause of this might be or how I
> >>>>> should
> >>>>> proceed in debugging?
> >>>>>
> >>>>> Many thanks in advance,
> >>>>>
> >>>>> Prokopis
> >>>>>
> >>>>> WARNING:
> >>>>> java.lang.****ArrayIndexOutOfBoundsException
> >>>>> at org.apache.uima.internal.util.**
> >>>>> **IntVector.remove(IntVector.****
> >>>>> java:207)
> >>>>> at org.apache.uima.internal.util.**
> >>>>> **IntSet.remove(IntSet.java:**77)
> >>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
> >>>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
> >>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
> >>>>> isModified(*
> >>>>> *FSIndexRepositoryImpl.java:****1800)
> >>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
> >>>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
> >>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
> >>>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
> >>>>> at
> org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
> >>>>> XmiCasSerializer.java:1566)
> >>>>> at org.apache.uima.aae.****UimaSerializer.****
> >>>>> serializeCasToXmi(**
> >>>>> UimaSerializer.java:160)
> >>>>> at org.apache.uima.adapter.jms.****
> >>>>> activemq.JmsOutputChannel.**
> >>>>> serializeCAS(JmsOutputChannel.****java:237)
> >>>>> at org.apache.uima.adapter.jms.****
> >>>>> activemq.JmsOutputChannel.**
> >>>>> getSerializedCas(****JmsOutputChannel.java:1223)
> >>>>> at org.apache.uima.adapter.jms.****
> >>>>> activemq.JmsOutputChannel.**
> >>>>> sendReply(JmsOutputChannel.****java:786)
> >>>>> at org.apache.uima.aae.****controller.**
> >>>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
> >>>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
> >>>>> at org.apache.uima.aae.handler.****
> >>>>> HandlerBase.invokeProcess(**
> >>>>> HandlerBase.java:121)
> >>>>> at org.apache.uima.aae.handler.****
> >>>>> input.ProcessRequestHandler_**
> >>>>> impl.****handleProcessRequestFromRemote****Client(**
> >>>>> ProcessRequestHandler_**
> >>>>> impl.java:542)
> >>>>> at org.apache.uima.aae.handler.****
> >>>>> input.ProcessRequestHandler_**
> >>>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
> >>>>> at org.apache.uima.aae.handler.****
> >>>>> input.MetadataRequestHandler_****
> >>>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
> >>>>> at
> org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
> >>>>> onMessage(JmsInputChannel.****java:706)
> >>>>> at org.springframework.jms.****listener.**
> >>>>> AbstractMessageListenerContain****er.doInvokeListener(**
> >>>>> AbstractMessageListenerContain****er.java:535)
> >>>>> at org.springframework.jms.****listener.**
> >>>>> AbstractMessageListenerContain****er.invokeListener(**
> >>>>> AbstractMessageListenerContain****er.java:495)
> >>>>> at org.springframework.jms.****listener.**
> >>>>> AbstractMessageListenerContain****er.doExecuteListener(**
> >>>>> AbstractMessageListenerContain****er.java:467)
> >>>>> at org.springframework.jms.****listener.**
> >>>>> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
> >>>>> AbstractPollingMessageListener****Container.java:325)
> >>>>> at org.springframework.jms.****listener.**
> >>>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
> >>>>> AbstractPollingMessageListener****Container.java:263)
> >>>>> at org.springframework.jms.****listener.**
> >>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
> >>>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
> >>>>> at org.springframework.jms.****listener.**
> >>>>>
> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
> >>>>> run(**
> >>>>> DefaultMessageListenerContaine****r.java:952)
> >>>>> at
> java.util.concurrent.****ThreadPoolExecutor.runWorker(****
> >>>>> ThreadPoolExecutor.java:1145)
> >>>>> at
> java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
> >>>>> ThreadPoolExecutor.java:615)
> >>>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
> >>>>> UimaAsThreadFactory.java:118)
> >>>>> at java.lang.Thread.run(Thread.****java:724)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>
>
Re: XmiCasSerializer error in UIMA-AS
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
On 28.10.2013 13:47, Eddie Epstein wrote:
> Assuming you would rather not share the CAS files, what I'd be looking for
> is the xmi:id values changing between the before and after files. There is
> some code in ruta that replaces CASes with serialization from files which
> could be the cause of this problem.
What code do you mean?
I have no idea what the problem could be. I would have bet that the
RutaBasic annotation cause the problem, but the problem apparently still
exists if all ruta specific annotations are yet removed in the analysis
engine.
Peter
>
> Eddie
>
>
> On Tue, Oct 22, 2013 at 10:21 AM, Eddie Epstein <ea...@gmail.com> wrote:
>
>> Can you share the before and after XmiCas files for a case where UIMA-AS
>> service serialization failed? No confidential info please!
>>
>> Eddie
>>
>>
>>
>> On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <pr...@ilsp.gr>wrote:
>>
>>> No, this is not an easily reproduced error: I have noticed it so far only
>>> upon application of typesystem-specific ruta rules. I will try to come up
>>> with an easily reproducible example.
>>>
>>> In the meantime, I followed your suggestions and added 2 XMI
>>> serialization calls at the end of the AE processing for the failing case,
>>> just before and just after using the ruta rules for modifying the
>>> annotations in my CAS. In both cases, serialization to file succeeded, with
>>> the second file containing the expected results of rule application.
>>>
>>> Unfortunately, the UIMA-AS serialization still produces the error in my
>>> original mail.
>>>
>>> Prokopis
>>>
>>>
>>> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
>>>
>>>> Is this a solid error that is easily reproduced?
>>>>
>>>> The error is occurring when UIMA-AS is returning the CAS from the
>>>> service.
>>>> You could add XMI serialization to file at the end of AE processing, for
>>>> the good and failing cases. If so lucky to have that serialization fail
>>>> too, could try inserting the serialization at points earlier.
>>>>
>>>> Note that the UIMA-AS serialization is only serializing the delta changes
>>>> from the input CAS, different from what you would do.
>>>>
>>>> Eddie
>>>>
>>>>
>>>>
>>>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <prokopis@ilsp.gr
>>>>> wrote:
>>>> Hi all,
>>>>> I have an AE that produces the error below when deployed as a UIMA-AS
>>>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit 2.*
>>>>> pipeline does not produce any errors and works as expected.
>>>>>
>>>>> Among other things, this AE uses ruta rules to process the CAS. When the
>>>>> rules are not used, the AE works as expected in both UIMA and UIMA-AS.
>>>>>
>>>>> I have tried to log all annotations generated by the AE when the rules
>>>>> are
>>>>> used and just before the AE processing is finished. The annotations seem
>>>>> the same in both the UIMA and the UIMA-AS processing scenarios.
>>>>>
>>>>> Does anyone have hints on what the cause of this might be or how I
>>>>> should
>>>>> proceed in debugging?
>>>>>
>>>>> Many thanks in advance,
>>>>>
>>>>> Prokopis
>>>>>
>>>>> WARNING:
>>>>> java.lang.****ArrayIndexOutOfBoundsException
>>>>> at org.apache.uima.internal.util.**
>>>>> **IntVector.remove(IntVector.****
>>>>> java:207)
>>>>> at org.apache.uima.internal.util.**
>>>>> **IntSet.remove(IntSet.java:**77)
>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
>>>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
>>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
>>>>> isModified(*
>>>>> *FSIndexRepositoryImpl.java:****1800)
>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
>>>>> at org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
>>>>> XmiCasSerializer.java:1566)
>>>>> at org.apache.uima.aae.****UimaSerializer.****
>>>>> serializeCasToXmi(**
>>>>> UimaSerializer.java:160)
>>>>> at org.apache.uima.adapter.jms.****
>>>>> activemq.JmsOutputChannel.**
>>>>> serializeCAS(JmsOutputChannel.****java:237)
>>>>> at org.apache.uima.adapter.jms.****
>>>>> activemq.JmsOutputChannel.**
>>>>> getSerializedCas(****JmsOutputChannel.java:1223)
>>>>> at org.apache.uima.adapter.jms.****
>>>>> activemq.JmsOutputChannel.**
>>>>> sendReply(JmsOutputChannel.****java:786)
>>>>> at org.apache.uima.aae.****controller.**
>>>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
>>>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
>>>>> at org.apache.uima.aae.handler.****
>>>>> HandlerBase.invokeProcess(**
>>>>> HandlerBase.java:121)
>>>>> at org.apache.uima.aae.handler.****
>>>>> input.ProcessRequestHandler_**
>>>>> impl.****handleProcessRequestFromRemote****Client(**
>>>>> ProcessRequestHandler_**
>>>>> impl.java:542)
>>>>> at org.apache.uima.aae.handler.****
>>>>> input.ProcessRequestHandler_**
>>>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
>>>>> at org.apache.uima.aae.handler.****
>>>>> input.MetadataRequestHandler_****
>>>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
>>>>> at org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
>>>>> onMessage(JmsInputChannel.****java:706)
>>>>> at org.springframework.jms.****listener.**
>>>>> AbstractMessageListenerContain****er.doInvokeListener(**
>>>>> AbstractMessageListenerContain****er.java:535)
>>>>> at org.springframework.jms.****listener.**
>>>>> AbstractMessageListenerContain****er.invokeListener(**
>>>>> AbstractMessageListenerContain****er.java:495)
>>>>> at org.springframework.jms.****listener.**
>>>>> AbstractMessageListenerContain****er.doExecuteListener(**
>>>>> AbstractMessageListenerContain****er.java:467)
>>>>> at org.springframework.jms.****listener.**
>>>>> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
>>>>> AbstractPollingMessageListener****Container.java:325)
>>>>> at org.springframework.jms.****listener.**
>>>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
>>>>> AbstractPollingMessageListener****Container.java:263)
>>>>> at org.springframework.jms.****listener.**
>>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
>>>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
>>>>> at org.springframework.jms.****listener.**
>>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
>>>>> run(**
>>>>> DefaultMessageListenerContaine****r.java:952)
>>>>> at java.util.concurrent.****ThreadPoolExecutor.runWorker(****
>>>>> ThreadPoolExecutor.java:1145)
>>>>> at java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
>>>>> ThreadPoolExecutor.java:615)
>>>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
>>>>> UimaAsThreadFactory.java:118)
>>>>> at java.lang.Thread.run(Thread.****java:724)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
Re: XmiCasSerializer error in UIMA-AS
Posted by Eddie Epstein <ea...@gmail.com>.
Assuming you would rather not share the CAS files, what I'd be looking for
is the xmi:id values changing between the before and after files. There is
some code in ruta that replaces CASes with serialization from files which
could be the cause of this problem.
Eddie
On Tue, Oct 22, 2013 at 10:21 AM, Eddie Epstein <ea...@gmail.com> wrote:
> Can you share the before and after XmiCas files for a case where UIMA-AS
> service serialization failed? No confidential info please!
>
> Eddie
>
>
>
> On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <pr...@ilsp.gr>wrote:
>
>> No, this is not an easily reproduced error: I have noticed it so far only
>> upon application of typesystem-specific ruta rules. I will try to come up
>> with an easily reproducible example.
>>
>> In the meantime, I followed your suggestions and added 2 XMI
>> serialization calls at the end of the AE processing for the failing case,
>> just before and just after using the ruta rules for modifying the
>> annotations in my CAS. In both cases, serialization to file succeeded, with
>> the second file containing the expected results of rule application.
>>
>> Unfortunately, the UIMA-AS serialization still produces the error in my
>> original mail.
>>
>> Prokopis
>>
>>
>> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
>>
>>> Is this a solid error that is easily reproduced?
>>>
>>> The error is occurring when UIMA-AS is returning the CAS from the
>>> service.
>>> You could add XMI serialization to file at the end of AE processing, for
>>> the good and failing cases. If so lucky to have that serialization fail
>>> too, could try inserting the serialization at points earlier.
>>>
>>> Note that the UIMA-AS serialization is only serializing the delta changes
>>> from the input CAS, different from what you would do.
>>>
>>> Eddie
>>>
>>>
>>>
>>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <prokopis@ilsp.gr
>>> >wrote:
>>>
>>> Hi all,
>>>>
>>>> I have an AE that produces the error below when deployed as a UIMA-AS
>>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit 2.*
>>>> pipeline does not produce any errors and works as expected.
>>>>
>>>> Among other things, this AE uses ruta rules to process the CAS. When the
>>>> rules are not used, the AE works as expected in both UIMA and UIMA-AS.
>>>>
>>>> I have tried to log all annotations generated by the AE when the rules
>>>> are
>>>> used and just before the AE processing is finished. The annotations seem
>>>> the same in both the UIMA and the UIMA-AS processing scenarios.
>>>>
>>>> Does anyone have hints on what the cause of this might be or how I
>>>> should
>>>> proceed in debugging?
>>>>
>>>> Many thanks in advance,
>>>>
>>>> Prokopis
>>>>
>>>> WARNING:
>>>> java.lang.****ArrayIndexOutOfBoundsException
>>>> at org.apache.uima.internal.util.**
>>>> **IntVector.remove(IntVector.****
>>>> java:207)
>>>> at org.apache.uima.internal.util.**
>>>> **IntSet.remove(IntSet.java:**77)
>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
>>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
>>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
>>>> isModified(*
>>>> *FSIndexRepositoryImpl.java:****1800)
>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
>>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
>>>> at org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
>>>> XmiCasSerializer.java:1566)
>>>> at org.apache.uima.aae.****UimaSerializer.****
>>>> serializeCasToXmi(**
>>>> UimaSerializer.java:160)
>>>> at org.apache.uima.adapter.jms.****
>>>> activemq.JmsOutputChannel.**
>>>> serializeCAS(JmsOutputChannel.****java:237)
>>>> at org.apache.uima.adapter.jms.****
>>>> activemq.JmsOutputChannel.**
>>>> getSerializedCas(****JmsOutputChannel.java:1223)
>>>> at org.apache.uima.adapter.jms.****
>>>> activemq.JmsOutputChannel.**
>>>> sendReply(JmsOutputChannel.****java:786)
>>>> at org.apache.uima.aae.****controller.**
>>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
>>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
>>>> at org.apache.uima.aae.handler.****
>>>> HandlerBase.invokeProcess(**
>>>> HandlerBase.java:121)
>>>> at org.apache.uima.aae.handler.****
>>>> input.ProcessRequestHandler_**
>>>> impl.****handleProcessRequestFromRemote****Client(**
>>>> ProcessRequestHandler_**
>>>> impl.java:542)
>>>> at org.apache.uima.aae.handler.****
>>>> input.ProcessRequestHandler_**
>>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
>>>> at org.apache.uima.aae.handler.****
>>>> input.MetadataRequestHandler_****
>>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
>>>> at org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
>>>> onMessage(JmsInputChannel.****java:706)
>>>> at org.springframework.jms.****listener.**
>>>> AbstractMessageListenerContain****er.doInvokeListener(**
>>>> AbstractMessageListenerContain****er.java:535)
>>>> at org.springframework.jms.****listener.**
>>>> AbstractMessageListenerContain****er.invokeListener(**
>>>> AbstractMessageListenerContain****er.java:495)
>>>> at org.springframework.jms.****listener.**
>>>> AbstractMessageListenerContain****er.doExecuteListener(**
>>>> AbstractMessageListenerContain****er.java:467)
>>>> at org.springframework.jms.****listener.**
>>>> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
>>>> AbstractPollingMessageListener****Container.java:325)
>>>> at org.springframework.jms.****listener.**
>>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
>>>> AbstractPollingMessageListener****Container.java:263)
>>>> at org.springframework.jms.****listener.**
>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
>>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
>>>> at org.springframework.jms.****listener.**
>>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
>>>> run(**
>>>> DefaultMessageListenerContaine****r.java:952)
>>>> at java.util.concurrent.****ThreadPoolExecutor.runWorker(****
>>>> ThreadPoolExecutor.java:1145)
>>>> at java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
>>>> ThreadPoolExecutor.java:615)
>>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
>>>> UimaAsThreadFactory.java:118)
>>>> at java.lang.Thread.run(Thread.****java:724)
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>
Re: XmiCasSerializer error in UIMA-AS
Posted by Eddie Epstein <ea...@gmail.com>.
Can you share the before and after XmiCas files for a case where UIMA-AS
service serialization failed? No confidential info please!
Eddie
On Tue, Oct 22, 2013 at 2:27 AM, Prokopis Prokopidis <pr...@ilsp.gr>wrote:
> No, this is not an easily reproduced error: I have noticed it so far only
> upon application of typesystem-specific ruta rules. I will try to come up
> with an easily reproducible example.
>
> In the meantime, I followed your suggestions and added 2 XMI serialization
> calls at the end of the AE processing for the failing case, just before and
> just after using the ruta rules for modifying the annotations in my CAS. In
> both cases, serialization to file succeeded, with the second file
> containing the expected results of rule application.
>
> Unfortunately, the UIMA-AS serialization still produces the error in my
> original mail.
>
> Prokopis
>
>
> On 10/18/2013 07:09 PM, Eddie Epstein wrote:
>
>> Is this a solid error that is easily reproduced?
>>
>> The error is occurring when UIMA-AS is returning the CAS from the service.
>> You could add XMI serialization to file at the end of AE processing, for
>> the good and failing cases. If so lucky to have that serialization fail
>> too, could try inserting the serialization at points earlier.
>>
>> Note that the UIMA-AS serialization is only serializing the delta changes
>> from the input CAS, different from what you would do.
>>
>> Eddie
>>
>>
>>
>> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <prokopis@ilsp.gr
>> >wrote:
>>
>> Hi all,
>>>
>>> I have an AE that produces the error below when deployed as a UIMA-AS
>>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit 2.*
>>> pipeline does not produce any errors and works as expected.
>>>
>>> Among other things, this AE uses ruta rules to process the CAS. When the
>>> rules are not used, the AE works as expected in both UIMA and UIMA-AS.
>>>
>>> I have tried to log all annotations generated by the AE when the rules
>>> are
>>> used and just before the AE processing is finished. The annotations seem
>>> the same in both the UIMA and the UIMA-AS processing scenarios.
>>>
>>> Does anyone have hints on what the cause of this might be or how I should
>>> proceed in debugging?
>>>
>>> Many thanks in advance,
>>>
>>> Prokopis
>>>
>>> WARNING:
>>> java.lang.****ArrayIndexOutOfBoundsException
>>> at org.apache.uima.internal.util.**
>>> **IntVector.remove(IntVector.****
>>> java:207)
>>> at org.apache.uima.internal.util.****IntSet.remove(IntSet.java:
>>> **77)
>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.**
>>> processIndexUpdates(****FSIndexRepositoryImpl.java:****1756)
>>> at org.apache.uima.cas.impl.****FSIndexRepositoryImpl.****
>>> isModified(*
>>> *FSIndexRepositoryImpl.java:****1800)
>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>> XmiCasDocSerializer.serialize(****XmiCasSerializer.java:256)
>>> at org.apache.uima.cas.impl.****XmiCasSerializer$**
>>> XmiCasDocSerializer.access$****700(XmiCasSerializer.java:108)
>>> at org.apache.uima.cas.impl.****XmiCasSerializer.serialize(**
>>> XmiCasSerializer.java:1566)
>>> at org.apache.uima.aae.****UimaSerializer.****
>>> serializeCasToXmi(**
>>> UimaSerializer.java:160)
>>> at org.apache.uima.adapter.jms.****activemq.JmsOutputChannel.**
>>> serializeCAS(JmsOutputChannel.****java:237)
>>> at org.apache.uima.adapter.jms.****activemq.JmsOutputChannel.**
>>> getSerializedCas(****JmsOutputChannel.java:1223)
>>> at org.apache.uima.adapter.jms.****activemq.JmsOutputChannel.**
>>> sendReply(JmsOutputChannel.****java:786)
>>> at org.apache.uima.aae.****controller.**
>>> PrimitiveAnalysisEngineControl****ler_impl.process(**
>>> PrimitiveAnalysisEngineControl****ler_impl.java:1036)
>>> at org.apache.uima.aae.handler.****HandlerBase.invokeProcess(**
>>> HandlerBase.java:121)
>>> at org.apache.uima.aae.handler.****
>>> input.ProcessRequestHandler_**
>>> impl.****handleProcessRequestFromRemote****Client(**
>>> ProcessRequestHandler_**
>>> impl.java:542)
>>> at org.apache.uima.aae.handler.****
>>> input.ProcessRequestHandler_**
>>> impl.handle(****ProcessRequestHandler_impl.****java:1041)
>>> at org.apache.uima.aae.handler.****
>>> input.MetadataRequestHandler_****
>>> impl.handle(****MetadataRequestHandler_impl.****java:78)
>>> at org.apache.uima.adapter.jms.****activemq.JmsInputChannel.**
>>> onMessage(JmsInputChannel.****java:706)
>>> at org.springframework.jms.****listener.**
>>> AbstractMessageListenerContain****er.doInvokeListener(**
>>> AbstractMessageListenerContain****er.java:535)
>>> at org.springframework.jms.****listener.**
>>> AbstractMessageListenerContain****er.invokeListener(**
>>> AbstractMessageListenerContain****er.java:495)
>>> at org.springframework.jms.****listener.**
>>> AbstractMessageListenerContain****er.doExecuteListener(**
>>> AbstractMessageListenerContain****er.java:467)
>>> at org.springframework.jms.****listener.**
>>> AbstractPollingMessageListener****Container.**doReceiveAndExecute(**
>>> AbstractPollingMessageListener****Container.java:325)
>>> at org.springframework.jms.****listener.**
>>> AbstractPollingMessageListener****Container.receiveAndExecute(****
>>> AbstractPollingMessageListener****Container.java:263)
>>> at org.springframework.jms.****listener.**
>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.**
>>> invokeListener(****DefaultMessageListenerContaine****r.java:1058)
>>> at org.springframework.jms.****listener.**
>>> DefaultMessageListenerContaine****r$**AsyncMessageListenerInvoker.****
>>> run(**
>>> DefaultMessageListenerContaine****r.java:952)
>>> at java.util.concurrent.****ThreadPoolExecutor.runWorker(****
>>> ThreadPoolExecutor.java:1145)
>>> at java.util.concurrent.****ThreadPoolExecutor$Worker.run(****
>>> ThreadPoolExecutor.java:615)
>>> at org.apache.uima.aae.****UimaAsThreadFactory$1.run(**
>>> UimaAsThreadFactory.java:118)
>>> at java.lang.Thread.run(Thread.****java:724)
>>>
>>>
>>>
>>>
>>>
>
Re: XmiCasSerializer error in UIMA-AS
Posted by Prokopis Prokopidis <pr...@ilsp.gr>.
No, this is not an easily reproduced error: I have noticed it so far
only upon application of typesystem-specific ruta rules. I will try to
come up with an easily reproducible example.
In the meantime, I followed your suggestions and added 2 XMI
serialization calls at the end of the AE processing for the failing
case, just before and just after using the ruta rules for modifying the
annotations in my CAS. In both cases, serialization to file succeeded,
with the second file containing the expected results of rule application.
Unfortunately, the UIMA-AS serialization still produces the error in my
original mail.
Prokopis
On 10/18/2013 07:09 PM, Eddie Epstein wrote:
> Is this a solid error that is easily reproduced?
>
> The error is occurring when UIMA-AS is returning the CAS from the service.
> You could add XMI serialization to file at the end of AE processing, for
> the good and failing cases. If so lucky to have that serialization fail
> too, could try inserting the serialization at points earlier.
>
> Note that the UIMA-AS serialization is only serializing the delta changes
> from the input CAS, different from what you would do.
>
> Eddie
>
>
>
> On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <pr...@ilsp.gr>wrote:
>
>> Hi all,
>>
>> I have an AE that produces the error below when deployed as a UIMA-AS
>> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit 2.*
>> pipeline does not produce any errors and works as expected.
>>
>> Among other things, this AE uses ruta rules to process the CAS. When the
>> rules are not used, the AE works as expected in both UIMA and UIMA-AS.
>>
>> I have tried to log all annotations generated by the AE when the rules are
>> used and just before the AE processing is finished. The annotations seem
>> the same in both the UIMA and the UIMA-AS processing scenarios.
>>
>> Does anyone have hints on what the cause of this might be or how I should
>> proceed in debugging?
>>
>> Many thanks in advance,
>>
>> Prokopis
>>
>> WARNING:
>> java.lang.**ArrayIndexOutOfBoundsException
>> at org.apache.uima.internal.util.**IntVector.remove(IntVector.**
>> java:207)
>> at org.apache.uima.internal.util.**IntSet.remove(IntSet.java:77)
>> at org.apache.uima.cas.impl.**FSIndexRepositoryImpl.**
>> processIndexUpdates(**FSIndexRepositoryImpl.java:**1756)
>> at org.apache.uima.cas.impl.**FSIndexRepositoryImpl.**isModified(*
>> *FSIndexRepositoryImpl.java:**1800)
>> at org.apache.uima.cas.impl.**XmiCasSerializer$**
>> XmiCasDocSerializer.serialize(**XmiCasSerializer.java:256)
>> at org.apache.uima.cas.impl.**XmiCasSerializer$**
>> XmiCasDocSerializer.access$**700(XmiCasSerializer.java:108)
>> at org.apache.uima.cas.impl.**XmiCasSerializer.serialize(**
>> XmiCasSerializer.java:1566)
>> at org.apache.uima.aae.**UimaSerializer.**serializeCasToXmi(**
>> UimaSerializer.java:160)
>> at org.apache.uima.adapter.jms.**activemq.JmsOutputChannel.**
>> serializeCAS(JmsOutputChannel.**java:237)
>> at org.apache.uima.adapter.jms.**activemq.JmsOutputChannel.**
>> getSerializedCas(**JmsOutputChannel.java:1223)
>> at org.apache.uima.adapter.jms.**activemq.JmsOutputChannel.**
>> sendReply(JmsOutputChannel.**java:786)
>> at org.apache.uima.aae.**controller.**
>> PrimitiveAnalysisEngineControl**ler_impl.process(**
>> PrimitiveAnalysisEngineControl**ler_impl.java:1036)
>> at org.apache.uima.aae.handler.**HandlerBase.invokeProcess(**
>> HandlerBase.java:121)
>> at org.apache.uima.aae.handler.**input.ProcessRequestHandler_**
>> impl.**handleProcessRequestFromRemote**Client(ProcessRequestHandler_**
>> impl.java:542)
>> at org.apache.uima.aae.handler.**input.ProcessRequestHandler_**
>> impl.handle(**ProcessRequestHandler_impl.**java:1041)
>> at org.apache.uima.aae.handler.**input.MetadataRequestHandler_**
>> impl.handle(**MetadataRequestHandler_impl.**java:78)
>> at org.apache.uima.adapter.jms.**activemq.JmsInputChannel.**
>> onMessage(JmsInputChannel.**java:706)
>> at org.springframework.jms.**listener.**
>> AbstractMessageListenerContain**er.doInvokeListener(**
>> AbstractMessageListenerContain**er.java:535)
>> at org.springframework.jms.**listener.**
>> AbstractMessageListenerContain**er.invokeListener(**
>> AbstractMessageListenerContain**er.java:495)
>> at org.springframework.jms.**listener.**
>> AbstractMessageListenerContain**er.doExecuteListener(**
>> AbstractMessageListenerContain**er.java:467)
>> at org.springframework.jms.**listener.**
>> AbstractPollingMessageListener**Container.doReceiveAndExecute(**
>> AbstractPollingMessageListener**Container.java:325)
>> at org.springframework.jms.**listener.**
>> AbstractPollingMessageListener**Container.receiveAndExecute(**
>> AbstractPollingMessageListener**Container.java:263)
>> at org.springframework.jms.**listener.**
>> DefaultMessageListenerContaine**r$AsyncMessageListenerInvoker.**
>> invokeListener(**DefaultMessageListenerContaine**r.java:1058)
>> at org.springframework.jms.**listener.**
>> DefaultMessageListenerContaine**r$AsyncMessageListenerInvoker.**run(**
>> DefaultMessageListenerContaine**r.java:952)
>> at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
>> ThreadPoolExecutor.java:1145)
>> at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
>> ThreadPoolExecutor.java:615)
>> at org.apache.uima.aae.**UimaAsThreadFactory$1.run(**
>> UimaAsThreadFactory.java:118)
>> at java.lang.Thread.run(Thread.**java:724)
>>
>>
>>
>>
Re: "Run as AS aggregate" and pre-fetching
Posted by Eddie Epstein <ea...@gmail.com>.
In a core UIMA aggregate engine all annotators run in a single thread, and
the code length moving from one annotator to another is "small". When
deployed asynchronously, each annotator in a different thread, the code
length is much higher and there is thread switching overhead as well.
In my experience there are two generally successful approaches to deploying
UIMA-AS multithreaded.
The simplest is to keep the entire pipeline synchronous and deploy N
pipeline instances, each running in its own thread; this design is good for
high throughput.
The second approach deploys only the top level aggregate (and carefully
selected 2nd or 3rd level aggregates) with the idea that operations can
proceed in parallel and slower components be replicated; this design is
good for low latency. Note that asynchronous components can only operate in
parallel if they are working on different CASes, so the use of CAS
Multipliers each with a pool of CASes is needed.
It is best to keep aggregates synchronous unless there is a useful reason
not to.
Eddie
On Sat, Oct 19, 2013 at 1:25 PM, John David Osborne (Campus) <ozborn@uab.edu
> wrote:
> What are the consequences of selecting in a UIMA-AS deployment descriptor
> "Run as AS aggregate"?
>
> I found an email from a year ago online where Eddie Epstein wrote:
> "UIMA-AS will put every asynchronous component in a separate thread.Using
> the ComponentDescriptorEditor on a UIMA-AS deployment
> descriptor, marking an aggregate with "Run as AS aggregate" will make
> every delegate in *that* aggregate an asynchronous component."
>
> I have a deployment with 32 aggregate analysis engines but I have not
> checked the box "Run as AS aggregate" in the deployment descriptor. Should
> I generally be doing this for all aggregate analysis engines? I'm not sure
> I understand the tradeoff very well, it sounds like I could get some
> performance improvements by checking this box since everything could run
> asynchronously however it sounds like if my pipeline isn't really ready to
> be run asynchronously some things may break..
>
> Did I get that right?
>
> Also I noticed the Eclipse component editor for UIMA-AS deployment
> descriptor doesn't provide the option to set pre-fetching (you can't see
> it either).
>
> -John
>
>
>
>
> --
> John David Osborne
>
> Research Associate
> University of Alabama at Birmingham
> Biomedical Informatics
> Center for Clinical and Translational Science
> 1720 7th Avenue South
> Sparks Building, Suite 175
> Birmingham, AL, 35294
>
>
>
> >
>
>
"Run as AS aggregate" and pre-fetching
Posted by "John David Osborne (Campus)" <oz...@uab.edu>.
What are the consequences of selecting in a UIMA-AS deployment descriptor
"Run as AS aggregate"?
I found an email from a year ago online where Eddie Epstein wrote:
"UIMA-AS will put every asynchronous component in a separate thread.Using
the ComponentDescriptorEditor on a UIMA-AS deployment
descriptor, marking an aggregate with "Run as AS aggregate" will make
every delegate in *that* aggregate an asynchronous component."
I have a deployment with 32 aggregate analysis engines but I have not
checked the box "Run as AS aggregate" in the deployment descriptor. Should
I generally be doing this for all aggregate analysis engines? I'm not sure
I understand the tradeoff very well, it sounds like I could get some
performance improvements by checking this box since everything could run
asynchronously however it sounds like if my pipeline isn't really ready to
be run asynchronously some things may break..
Did I get that right?
Also I noticed the Eclipse component editor for UIMA-AS deployment
descriptor doesn't provide the option to set pre-fetching (you can't see
it either).
-John
--
John David Osborne
Research Associate
University of Alabama at Birmingham
Biomedical Informatics
Center for Clinical and Translational Science
1720 7th Avenue South
Sparks Building, Suite 175
Birmingham, AL, 35294
>
Re: XmiCasSerializer error in UIMA-AS
Posted by Eddie Epstein <ea...@gmail.com>.
Is this a solid error that is easily reproduced?
The error is occurring when UIMA-AS is returning the CAS from the service.
You could add XMI serialization to file at the end of AE processing, for
the good and failing cases. If so lucky to have that serialization fail
too, could try inserting the serialization at points earlier.
Note that the UIMA-AS serialization is only serializing the delta changes
from the input CAS, different from what you would do.
Eddie
On Thu, Oct 17, 2013 at 12:19 PM, Prokopis Prokopidis <pr...@ilsp.gr>wrote:
> Hi all,
>
> I have an AE that produces the error below when deployed as a UIMA-AS
> 2.4.0 service. The same AE as part of a UIMA 2.4.2 CPE or a uimafit 2.*
> pipeline does not produce any errors and works as expected.
>
> Among other things, this AE uses ruta rules to process the CAS. When the
> rules are not used, the AE works as expected in both UIMA and UIMA-AS.
>
> I have tried to log all annotations generated by the AE when the rules are
> used and just before the AE processing is finished. The annotations seem
> the same in both the UIMA and the UIMA-AS processing scenarios.
>
> Does anyone have hints on what the cause of this might be or how I should
> proceed in debugging?
>
> Many thanks in advance,
>
> Prokopis
>
> WARNING:
> java.lang.**ArrayIndexOutOfBoundsException
> at org.apache.uima.internal.util.**IntVector.remove(IntVector.**
> java:207)
> at org.apache.uima.internal.util.**IntSet.remove(IntSet.java:77)
> at org.apache.uima.cas.impl.**FSIndexRepositoryImpl.**
> processIndexUpdates(**FSIndexRepositoryImpl.java:**1756)
> at org.apache.uima.cas.impl.**FSIndexRepositoryImpl.**isModified(*
> *FSIndexRepositoryImpl.java:**1800)
> at org.apache.uima.cas.impl.**XmiCasSerializer$**
> XmiCasDocSerializer.serialize(**XmiCasSerializer.java:256)
> at org.apache.uima.cas.impl.**XmiCasSerializer$**
> XmiCasDocSerializer.access$**700(XmiCasSerializer.java:108)
> at org.apache.uima.cas.impl.**XmiCasSerializer.serialize(**
> XmiCasSerializer.java:1566)
> at org.apache.uima.aae.**UimaSerializer.**serializeCasToXmi(**
> UimaSerializer.java:160)
> at org.apache.uima.adapter.jms.**activemq.JmsOutputChannel.**
> serializeCAS(JmsOutputChannel.**java:237)
> at org.apache.uima.adapter.jms.**activemq.JmsOutputChannel.**
> getSerializedCas(**JmsOutputChannel.java:1223)
> at org.apache.uima.adapter.jms.**activemq.JmsOutputChannel.**
> sendReply(JmsOutputChannel.**java:786)
> at org.apache.uima.aae.**controller.**
> PrimitiveAnalysisEngineControl**ler_impl.process(**
> PrimitiveAnalysisEngineControl**ler_impl.java:1036)
> at org.apache.uima.aae.handler.**HandlerBase.invokeProcess(**
> HandlerBase.java:121)
> at org.apache.uima.aae.handler.**input.ProcessRequestHandler_**
> impl.**handleProcessRequestFromRemote**Client(ProcessRequestHandler_**
> impl.java:542)
> at org.apache.uima.aae.handler.**input.ProcessRequestHandler_**
> impl.handle(**ProcessRequestHandler_impl.**java:1041)
> at org.apache.uima.aae.handler.**input.MetadataRequestHandler_**
> impl.handle(**MetadataRequestHandler_impl.**java:78)
> at org.apache.uima.adapter.jms.**activemq.JmsInputChannel.**
> onMessage(JmsInputChannel.**java:706)
> at org.springframework.jms.**listener.**
> AbstractMessageListenerContain**er.doInvokeListener(**
> AbstractMessageListenerContain**er.java:535)
> at org.springframework.jms.**listener.**
> AbstractMessageListenerContain**er.invokeListener(**
> AbstractMessageListenerContain**er.java:495)
> at org.springframework.jms.**listener.**
> AbstractMessageListenerContain**er.doExecuteListener(**
> AbstractMessageListenerContain**er.java:467)
> at org.springframework.jms.**listener.**
> AbstractPollingMessageListener**Container.doReceiveAndExecute(**
> AbstractPollingMessageListener**Container.java:325)
> at org.springframework.jms.**listener.**
> AbstractPollingMessageListener**Container.receiveAndExecute(**
> AbstractPollingMessageListener**Container.java:263)
> at org.springframework.jms.**listener.**
> DefaultMessageListenerContaine**r$AsyncMessageListenerInvoker.**
> invokeListener(**DefaultMessageListenerContaine**r.java:1058)
> at org.springframework.jms.**listener.**
> DefaultMessageListenerContaine**r$AsyncMessageListenerInvoker.**run(**
> DefaultMessageListenerContaine**r.java:952)
> at java.util.concurrent.**ThreadPoolExecutor.runWorker(**
> ThreadPoolExecutor.java:1145)
> at java.util.concurrent.**ThreadPoolExecutor$Worker.run(**
> ThreadPoolExecutor.java:615)
> at org.apache.uima.aae.**UimaAsThreadFactory$1.run(**
> UimaAsThreadFactory.java:118)
> at java.lang.Thread.run(Thread.**java:724)
>
>
>
>