Re: Possible cause of nullPointerException in casmultiplier?

[nelson rivera]

You are absolutely right, I should not release the input CAS in my AE.
This was apparently the cause of the error. thank you very much

2016-11-28 13:09 GMT-05:00, Jaroslaw Cwiklik :
> An input CAS should not be released in the AE (user code). The Flow
> Controller should be used
> to prevent a CAS from flowing downstream. UIMA-AS will try to release a CAS
> in a Final Step
> of processing and this may cause an error like
>
> "The system tried to return a common analysis structure to the pool from
> which it was not checked out."
>
> Jerry
>
>
> On Mon, Nov 28, 2016 at 12:40 PM, nelson rivera 
> wrote:
>
>> I have deployed the aggregate of asynchronous way.
>>  And i configure this aggregate to processing one request at the same
>> time(numberOfCASes=1,default), because as i commented on previous
>> email, in my flow: The first casmultiplier receive a annotation with
>> the path of a folder and creates a new child cas for each file in the
>> folder, the child cas
>> continue the flow in the other primitive annotators and at the end it
>> go to the second casmultipler, in the second casmultipler can or not
>> create new child cas, in the case of not i release the cas. I am
>> assuming (numberOfCASes=1,default) that until all child has finished
>> its processing, the aggregate not going processing other input cas of
>> other request, it is correct?.
>>
>>
>>
>> 2016-11-28 12:00 GMT-05:00, Jaroslaw Cwiklik :
>> > Nelson, this error:
>> >
>> > "The system tried to return a common analysis structure to the pool
>> > from
>> > which it was not checked out."
>> >
>> > I think this is caused if you try to release a CAS that has been
>> previously
>> > released. Sure you
>> > are not trying to release it twice? I think releasing an input CAS in
>> > AE
>> > code is not a good idea. I am assuming
>> > you have an asynchronous aggregate (queue in front of each AE). In such
>> > deployments, the UIMA-AS is
>> > responsible for releasing a CAS once it reaches a Final state. Within a
>> > synchronous aggregate I am not sure
>> > if you are allowed to release a CAS in your code. Perhaps others can
>> chime
>> > in. Can you confirm which
>> > deployment you chose for this aggregate (synch or asynch)
>> > Jerry
>> >
>> > On Fri, Nov 25, 2016 at 11:14 AM, nelson rivera <
>> nelsonriver...@gmail.com>
>> > wrote:
>> >
>> >> The errores related are very random. I found a patron of error ( don't
>> >> know if it's the only one): The caspool of the first casmultipler
>> >> have size of 8, if i send a request to the aggregate in which the
>> >> first casmultipler have to generate more than 8 child cas, i get
>> >> random errors, the childs cas generated after the number 8, sometimes
>> >> is empty, sometimes have less annotations than it should have (I see
>> >> this with a own XCasSerializer annotator) or get nullPointerException.
>> >> I don't know why can happen, because in the method "process()" of the
>> >> second casmultipler i release the incoming cas (aJCas.release();)
>> >> directly in my source code, for that the caspool of the first
>> >> casmultipler will not empty. There is something taht i am not doing
>> >> well?
>> >>
>> >> I don't have idea what may be going on?, i will appreciate the help
>> >>
>> >> 2016-11-24 19:24 GMT-05:00, nelson rivera :
>> >> > I continued investigating  and according to the stacktrace and
>> >> > source
>> >> > code of of FSIndexRepositoryImpl.ll_addFS_common() the exception is
>> >> > from line 2805 , in this part
>> >> >
>> >> > final ArrayList
>> >> > indexes = this.indexArray[typeCode];
>> >> > // Add fsRef to all indexes.
>> >> > boolean noIndexOrOnlySetindexes = true;
>> >> > for (IndexIteratorCachePair iicp :
>> >> > indexes) {} //here
>> >> >
>> >> > apparently loop on a null value, any idea of why can happen this
>> >> exception?
>> >> >
>> >> > 2016-11-24 16:27 GMT-05:00, nelson rivera
>> >> > :
>> >> >> the error continue ocurring , this is the log, my casmultiplier is
>> >> >> FileSystemMultiplerCas
>> >> >>
>> >> >> 04:04:17.520 - 23:
>> >> >> cu.datys.xinetica.uima.core.FileSystemMultiplerCas.next(334): INFO:
>> >> >> Adicionando annotation tipo
>> >> >> cu.datys.xinetica.uima.ContinueOnFailure
>> >> >> 04:04:17.522 - 23: org.apache.uima.util.CasPool.releaseCas:
>> >> >> WARNING:
>> >> >> The system tried to return a common analysis structure to the pool
>> >> >> from which it was not checked out.
>> >> >> 04:04:17.523 - 23:
>> >> >> org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.
>> >> callAnalysisComponentNext(549):
>> >> >> SEVERE: Exception occurred
>> >> >> org.apache.uima.analysis_engine.AnalysisEngineProcessException
>> >> >>  at
>> >> >> cu.datys.xinetica.uima.core.FileSystemMultiplerCas.next(
>> >> FileSystemMultiplerCas.java:351)
>> >> >>  at
>> >> >> 

Re: XmiCasSerializer omits namespace prefixes in XML elements

[Burn Lewis]

I've also seen what appear to be namespace problems with Saxon8 ...
investigating.  I haven't tried older UIMAs.

On Mon, Nov 28, 2016 at 1:31 PM, Marshall Schor  wrote:

> just to note, the Saxon incompatibilities started with Saxon 9; earlier
> versions
> I think work OK.
>
> Might be useful for a "work-around".
>
> -Marshall
>
> On 11/28/2016 10:01 AM, Oliver Ferschke wrote:
> > Hi Mashall,
> > We switched from UIMA 2.6.0 right to 2.9.0 when it came out, but I
> haven't tried this particular scenario with older UIMA versions.
> > Worth to give it a shot.
> > I can confirm that SAXON is on the classpath and it's probably not easy
> to remove since other components require it.
> > But it's good to know what the possible cause of this issue might be.
> >
> > -Oliver
> >
> > -Original Message-
> > From: Marshall Schor [mailto:m...@schor.com]
> > Sent: Wednesday, November 23, 2016 4:49 PM
> > To: user@uima.apache.org
> > Subject: Re: XmiCasSerializer omits namespace prefixes in XML elements
> >
> > Do you see failures in UIMA 2.9.0, but no failures for earlier versions
> of UIMA?
> > (in other words, can you tell if this is a 2.9.0 issue, or is more
> general)?
> >
> > -Marshall
> >
> >
> > On 11/23/2016 1:24 PM, Oliver Ferschke wrote:
> >> Hi all,
> >> I'm experiencing some odd behavior of the XmiCasSerializer (UIMA 2.9.0).
> >> When I pass a CAS to the static "serialize(CAS aCAS,
> >> java.io.OutputStream aStream)" method within our runtime environment,
> it produces an XMI with XML-Elements without namespace prefixes, e.g.
> >>  hidden="false" ..
> >> instead of
> >>  hidden="false"
> >>
> >> This also happens if I use the non-static methods.
> >> In a minimal example that doesn't use our pipeline deployment
> environment, this does not happen.
> >> It seems like there is something in the classpath that changes the
> behavior of the serializer but I haven't been able to pinpoint what this
> could be.
> >>
> >> Has anyone ever experienced a behavior like this or knows what else I
> could look into?
> >>
> >> Thanks a lot.
> >> Oliver
> >>
> >>
> >
>
>