So, I found one GLARING problem that I missed completely: When testing
my CR and CM setup, I looped through the CR's getNext(), adding to the
JCas that I just created. But the CR's getNext() didn't loop internally,
it only added IDs one at a time. So, instead of the CR creating a CAS with
N Workitems and halting, it was create N CASes with 1 workitem. I've
fixed that.
So I've made an Aggregate AE of my CM and a simple AE, and ran them with
my CR in a uimaFit SimplePipeline. The outputs are as I expect for now.
But I do have a question. The Workitems have an option of SendToLast,
which in the RawText Example is set to "true". The DuccCasCC in the
sample pulls WorkItem FSes for output stuff. The CR adds the Workitems,
but the CM doesn't reattach them to the new CASes before returning next().
Should the Workitems stay in the CAS throughout processing (ie., should
the CMs add them to the new CASes) ? OR is SendToLast enough?
Thanks!
Neal
From: Neal R Lewis/Almaden/IBM@IBMUS
To: [email protected]
Date: 11/14/2013 01:20 PM
Subject: Re: DUCC not leaving Initializing State
The minimal wrapper creates a Cas using uimaFit and loop over the CR,
then to run over the iterator from cm.processAndOutputNewCASes, then
output each cas in the loop like below:
CollectionReader cr = CollectionReaderFactory.createReader
("path.to.my.CasReader");
AnalysisEngine cm = AnalysisEngineFactory.createEngine(
"path.to.my.CasMultiplier");
JCas jcas = JCasFactory.createJCas("
desc.DuccJobFlowControlTS);
while (cr.hasNext()){
cr.getNext(jcas.getCas());
}
CasIterator casIterator =
cm.processAndOutputNewCASes(jcas.getCas());
while (casIterator.hasNext()) {
CAS outCas = casIterator.next();
System.out.println(outCas.getDocumentText());
}
I'll need to debug a full standalone PEAR or Pipeline. But at this point I
was able to at least get the CASes out.
Below is the output of the JP file before the stall and after loading JVM
stuff. It stays like this until shutdown. As far as I can tell the CM
Loads and is waiting.
+ JVM
LIB_PATH:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
+------------------------------------------------------------------
13 Nov 2013 15:53:44,761 INFO DUCC.ThreadPoolTaskExecutor - Initializing
ExecutorService 'pooling_ducc.jd.queue.91_1'
03:53:44.794 - 1:
org.apache.uima.adapter.jms.activemq.JmsInputChannel.setEndpointName:
INFO: top_level_input_queue_service_1 Service Starting - Listening for
Messages
13 Nov 2013 15:53:44,795 INFO DUCC.ThreadPoolTaskExecutor - Initializing
ExecutorService 'pooling_ducc.jd.queue.91_1'
03:53:44.797 - 30:
org.apache.uima.aae.UimaAsThreadFactory$1.UimaAsThreadFactory.run(): INFO:
Controller: ducc.jd.queue.91 Initializing AE instance on Thread Id: 30
03:53:44.799 - 1:
org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.waitForServiceNotification:
INFO: Uima EE Client Blocking - Awaiting Top Level Controller
Initialization Notification
03:53:44.887 - 30:
com.ibm.almaden.disco.quartermaster.SimpleQuarterMasterCasMultiplier.logParameters(70):
INFO: Initializing Cas Multiplier Parameters
03:53:44.887 - 30:
com.ibm.almaden.disco.quartermaster.SimpleQuarterMasterCasMultiplier.logParameters(71):
INFO: init HOST ADDRESS:
https://thepit.element.almaden.ibm.com/cgi-bin/qm2
03:53:44.887 - 30:
com.ibm.almaden.disco.quartermaster.SimpleQuarterMasterCasMultiplier.logParameters(72):
INFO: init LENIENT: false
03:53:44.887 - 30:
com.ibm.almaden.disco.quartermaster.SimpleQuarterMasterCasMultiplier.logParameters(73):
INFO: init PARAM_ENCODING: UTF-8
03:53:44.887 - 30:
com.ibm.almaden.disco.quartermaster.SimpleQuarterMasterCasMultiplier.logParameters(74):
INFO: init PARAM_LANGUAGE: en
03:53:44.933 - 30:
org.apache.uima.ducc.sampleapps.DuccCasCC.initialize(74): INFO: Outputting
CASes in XmiCas format, zip compressed at level=7
Service:ducc.jd.queue.91 Initialized. Ready To Process Messages From
Queue:ducc.jd.queue.91
03:53:45.97 - 30:
org.apache.uima.aae.controller.PrimitiveAnalysisEngineController_impl.postInitialize:
INFO: ********* Initialized the Controller. ducc.jd.queue.91 Ready To
Process. ********
03:53:45.97 - 1:
org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.doStartListeners:
INFO: Controller: ducc.jd.queue.91 Starting Listener on Endpoint:
queue://ducc.jd.queue.91 Selector: Command=2000 OR Command=2002 Broker:
tcp://greenfairy:61617?wireFormat.maxInactivityDuration=0&closeAsync=false
03:53:45.290 - 1:
org.apache.uima.adapter.jms.activemq.SpringContainerDeployer.doStartListeners:
INFO: Controller: ducc.jd.queue.91 Starting Listener on Endpoint:
queue://ducc.jd.queue.91 Selector: Command=2001 Broker:
tcp://greenfairy:61617?wireFormat.maxInactivityDuration=0&closeAsync=false
13 Nov 2013 15:53:45,299 INFO DUCC.DuccService - boot N/A ...
Component started: managedService
13 Nov 2013 15:53:45,300 INFO DUCC.DuccService - boot N/A Starting
Camel. Use ctrl + c to terminate the JVM.
From: Eddie Epstein <[email protected]>
To: [email protected]
Date: 11/14/2013 10:37 AM
Subject: Re: DUCC not leaving Initializing State
On Wed, Nov 13, 2013 at 7:10 PM, Neal R Lewis <[email protected]> wrote:
I have modeled a CasReader and CasMultiplier based on the RawTextExample
in the duccbook, and have successfully ran the CR and CM in eclipse with
a
minimal wrapper.
Did you debug the job using one of the --all_in_one varieties, or some
other
minimal wrapper?
I am using the same CC from the Sample (DuccCasCC)
I am experiencing a problem where my DUCC job goes through
WaitingForDriver, WaitingForResources, then Initializing, then doesn't
change state. After several minutes I just cancel the job.
Did you look in the JP logfile?
Eddie
