Hi Chris,
Thanks for the code snippet.
I'm running my XmlRpcBatchStub on the same host as my workflow manager, so I
don't think that is the issue.
I looked at my XmlRpcBatchStub log however, and found the following exception
being issued whenever one of my tasks was sent to this batch stub:
org.apache.xmlrpc.XmlRpcException: java.lang.Exception:
java.lang.ClassCastException:
org.apache.oodt.cas.workflow.engine.SequentialProcessor cannot be cast to
org.apache.oodt.cas.workflow.engine.ThreadPoolWorkflowEngine$ThreadedProcessor
at
org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeException(XmlRpcClientResponseProcessor.java:104)
at
org.apache.xmlrpc.XmlRpcClientResponseProcessor.decodeResponse(XmlRpcClientResponseProcessor.java:71)
at
org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:73)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:194)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:185)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:178)
at
org.apache.oodt.cas.workflow.system.XmlRpcWorkflowManagerClient.updateMetadataForWorkflow(XmlRpcWorkflowManagerClient.java:424)
at
org.apache.oodt.cas.workflow.structs.TaskJob.updateMetadata(TaskJob.java:137)
at
org.apache.oodt.cas.workflow.structs.TaskJob.execute(TaskJob.java:113)
at
org.apache.oodt.cas.resource.system.extern.XmlRpcBatchStub$RunnableJob.run(XmlRpcBatchStub.java:229)
at java.lang.Thread.run(Thread.java:619)
I'm using workflow-manager 0.4-SNAPSHOT (not the latest trunk). Off the bat,
does anything look strange to you? It seems from the exception, that the
workflow met is definitely not being properly passed to the batch stub.
I know a lot of updates have been made to WM lately, so I tried to build the
latest trunk version of 0.4-SNAPSHOT; however, it currently fails the
'TestXmlRpcWorkflowManagerClient' test with:
java.text.ParseException: An exception occurred because the input date/time
string was not at least 24 characters in length.
at
org.apache.oodt.commons.util.DateConvert.isoParse(DateConvert.java:165)
at
org.apache.oodt.cas.workflow.structs.WorkflowInstance.setCurrentTaskStartDateTimeIsoStr(WorkflowInstance.java:339)
I'm going to look more into it and investigate, but maybe I will try deploying
with 0.3 OODT and see if the problem persists.
Thanks!
rishi
On Oct 24, 2011, at 9:07 PM, Mattmann, Chris A (388J) wrote:
> Hi Rishi,
>
> The metadata context should be persisted, based on updates made during the
> tasks themselves. If you have a look at
> TaskJob [1], you'll see the last step in the execute(JobInput in) method is:
>
> {code}
> // now we have to update the workflow manager with the metadata
> // that may have been updated
> updateMetadata(taskInput.getDynMetadata());
> {code}
>
> which should call back to the parent workflow manager and update the workflow
> instance
> with the current metadata. If you're not seeing this it's possible that your
> XmlRpcBatchStub
> on your executing node cannot see back to the parent WM running on host:port.
>
> Is this the case?
>
> Cheers,
> Chris
>
> On Oct 24, 2011, at 4:52 PM, Verma, Rishi (388J) wrote:
>
>> Hi all,
>>
>> I'm trying to pass generated metadata from a workflow task to another
>> workflow task (both in the same workflow) when using a resource manager to
>> execute workflow task jobs.
>>
>> I've done this before successfully when workflow tasks within a given
>> workflow are run locally (by the workflow manager itself) but when I point
>> workflow manager to have tasks execute through a resource manager, my
>> generated metadata does not seem to transfer from one task to the next.
>>
>> By "generated" metadata, I mean metadata that is added within the "run"
>> method of an implemented WorkflowTaskInstance. It's worth noting though,
>> that metadata passed into the initial XmlRpc call of a workflow task seems
>> to be passed to all subsequent tasks just fine. Just not generated metadata
>> - which passes only when not using a resource manager.
>>
>> I'm trying to ascertain if this issue is a bug or not. To find out, could
>> someone elaborate a bit on which resmgr (or other) classes would include
>> code that actually shows metadata for a job being passed through a remotely
>> running job? I've been trying to find such code within the codebase but have
>> not come across it yet.
>>
>> Thanks!
>> rishi
>>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: [email protected]
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
