[
https://issues.apache.org/jira/browse/OODT-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13476553#comment-13476553
]
Brian Foster edited comment on OODT-491 at 10/15/12 11:13 PM:
--------------------------------------------------------------
1) For us, model ID is WorkflowId, we should set this probably when the
workflow is initially created, and then later in fromWorkflowInstance, maybe?
- Still not sure how this is going to work... each WorkflowProcessor will
usually have multiple WorkflowIds, 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)... 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.
2) 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
3) Yeah maybe we can make a function to handle this. Thoughts? Or make it part
of OODT-495 maybe.
- Determining status, whether moving forward or backwards is really the same
thing, a WorkflowProcessor has a set of children WorkflowProcessor and based on
their statuses, it has a status... so when update status is call on any
WorkflowProcessor it should just analyze it's children WorkflowProcessor's
status and if it needs to update it's status because one or more of them
changed then it should notify it's parent WorkflowProcessor to do the same.
This could be a task that is part of OODT-495 i believe.
was (Author: bfoster):
1) For us, model ID is WorkflowId, we should set this probably when the
workflow is initially created, and then later in fromWorkflowInstance, maybe?
- Still not sure how this is going to work... each workflow may have multiple
WorkflowIds, 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)... 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.
2) 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
3) Yeah maybe we can make a function to handle this. Thoughts? Or make it part
of OODT-495 maybe.
- Determining status, whether moving forward or backwards is really the same
thing, a WorkflowProcessor has a set of children WorkflowProcessor and based on
their statuses, it has a status... so when update status is call on any
WorkflowProcessor it should just analyze it's children WorkflowProcessor's
status and if it needs to update it's status because one or more of them
changed then it should notify it's parent WorkflowProcessor to do the same.
This could be a task that is part of OODT-495 i believe.
> 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
