[
https://issues.apache.org/jira/browse/OODT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476628#comment-13476628
]
Chris A. Mattmann commented on OODT-491:
----------------------------------------
Hey Brian:
{quote}
Still not sure how this is going to work... each WorkflowProcessor will usually
have multiple WorkflowIds,
{quote}
This may have been true in wengine but isn't strictly true in 0.5. Each
Workflow Processor handles a single model id (or Workflow Id in trunk
terminology). Sure, it may have sub processors which themselves have model IDs,
etc., though, which is I think what you are talking below.
{quote}
so for an instance to update it will need: updateStatus(workflowInstanceId,
workflowId, status) and updateMetadata(workflowInstanceId, workflowId, status)
or combine them (which actually is a hugh speed boost):
updateWorkflowInstance(workflowInstanceId, workflowId, status, metadata)...
{quote}
Yep I like the above. I'll file a JIRA issue to support that as part of
OODT-491. Care to take a whack and help me on the above?
{quote}
these methods then have to notify the WorkflowProcessor from which the
WorkflowTaskInstance came from, which then notifies it's parent
WorkflowProcessors to update their status and metadata as well.
{quote}
Yep.
{quote}
There's a method here: updateWorkflowInstanceStatus that we can use for this.
This isn't going to work for parallel workflows... multiple posts from
different tasks in the same workflow are going to clobber each others writes
(since they are unaware of each other's updates to the WorkflowInstance)... i
think the server should be responsible for updating the WorkflowInstance itself
(what this method appears to do is a blank update)... here is an example of
what i mean: Task1 has WorkflowInstance object and Task2 has the same
WorkflowInstance object, both which have Task1 and Task2 as running... now
Task1 finishes and sends an update to WorkflowManager, then Task2 finishes and
sends in an update to the WorkflowManager, the WorkflowManager will perform
Task1 update request, then Task2 update request – WorkflowManager will now
think that Task1 is still running again, because that is the state of it in
Task2 WorkflowInstance... or you will have to request a fresh copy of each
WorkflowInstance before updating but this will be very time consuming and
although will decrease the number of Tasks clobbering each other's writes it
won't completely prevent it
{quote}
Yeah I see what you mean. Take a look at [persist in
WorkflowProcessorQueue|https://builds.apache.org/job/oodt-trunk/javadoc/org/apache/oodt/cas/workflow/engine/processor/WorkflowProcessorQueue.html#persist(org.apache.oodt.cas.workflow.structs.WorkflowInstance)]
which is what I was trying to do to accomplish the same thing you're talking
about (I was running into Lucene issues before that with all the parallel
updating). However it's fixed now and unit-tested :) and they are passing.
> Finish line tasks for Wengine integration
> -----------------------------------------
>
> Key: OODT-491
> URL: https://issues.apache.org/jira/browse/OODT-491
> Project: OODT
> Issue Type: Umbrella
> Components: workflow manager
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Fix For: 0.5
>
> Attachments: NewWorkflowModel.patch.txt
>
>
> The final tasks to wrap up wengine integration into trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
