Re: DUCC 2.0.1 : JP Http Client Unable to Communicate with JD

Adding to this, Jd is showing this log: 12 Jan 2016 15:25:52,028 INFO ActionGet - T[37] engage seqNo=21 remote=user.13895.34 [Fatal Error] :1:7109: The element type "org.apache.uima.ducc.container.net.impl.MetaCasTransaction" must be terminated by the matching end-tag "". 12 Jan 2016

Re: DUCC 2.0.1 : JP Http Client Unable to Communicate with JD

Hi Reshu, This is caused by the CollectionReader running in the JobDriver putting character data in the work item CAS that cannot be XML serialized. DUCC needs to do better in making this problem clear. Two choices to fix this: 1) have the CR screen for illegal characters and not put them in the

RE: CAS serializationWithCompression

Thanks Marshall. Will do. I just completed upgrading from UIMA 2.6.0 to 2.8.1 just to make sure there were no issues there. Will now get back to the CAS serialization issue. Yes, I've been trying to think of where there could be retained junk that is getting added back into the CAS with each

Re: CAS serializationWithCompression

Is the CAS.size() larger than the serialized version or smaller? What are you actually doing to the CAS? Just serializing/deserializing a couple of times in a row, or do you actually add feature structures? The sample code you show doesn't give any hint about where the CAS comes from and what is

Re: DUCC - Work Item Queue Time Management

Reshu, Very good. Looks to me like no DUCC changes are needed with respect to this issue. Lou. On Tue, Jan 12, 2016 at 12:07 AM, reshu.agarwal wrote: > Lou, > > I placed names.txt in config directory of current working Directory. > > Reshu. > > Signature On

Re: CAS serializationWithCompression

hmmm, seems like unusual behavior. It would help a lot to diagnose this if you could construct a small test case - one which perhaps creates a cas, fills it with a bit of data, does the compressed serialization, resets the cas, and loops and see if that produces "expanding" serializations. --

RE: CAS serializationWithCompression

The CAS.size() starts as larger than the serializedWithCompression version, but eventually the serializedWithCompression version grows to be larger than the CAS.size(). The overall process is: * Create a new CAS * Read in an xml document and store the structure and content in the cas. * Tokenize