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
