[
http://opencast.jira.com/browse/MH-9235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32112#comment-32112
]
Andreas Krieger edited comment on MH-9235 at 11/2/12 8:31 PM:
--------------------------------------------------------------
I could not find out anything useful, I fear. Things still happen here, I can
see no pattern.
>From the logs I find consitently that the workflows which go on hold with no
>status do get "PAUSED" somehow and somewhere:
opencast.log.2012-10-31-14:2012-10-31 14:09:24 INFO (WorkflowServiceImpl:772)
- Workflow state for Workflow {1771205} was changed to 'PAUSED' from the outside
The source of WorkflowServiceImpl.java suggests that
"!dbWorkflowState.equals(initialState)", ie that the state of the workflow has
changed intermittendly by some magic.
I suspect that also the processings, which go to state "Captured: Sending to
processing" get PAUSED in a similar way, but without the application getting
aware of it (no log entries of any kind).
I have too little insight into the database management and why the state
changes, or why the app thinks it changed to go any further from here.
One other thought out of the wild (idea taken from
http://lists.opencastproject.org/pipermail/matterhorn/2012-August/020577.html,
since we also have those not so unrare 401-failures on the 1.3.1 capture
agents): can this behaviour be a side effect of mysql contention (we observe
high CPU load for mysql during processing), ie. the mysql-database being to
slow to give a good response to dbWorkflowState, or something, and thus the
unequality on check? Just shooting.
was (Author: akrieger):
I could not find out anything useful, I fear. Things still happen here, I
can see no pattern.
>From the logs I find consitently that the workflows which go on hold with no
>status do get "PAUSED" somehow and somewhere:
opencast.log.2012-10-31-14:2012-10-31 14:09:24 INFO (WorkflowServiceImpl:772)
- Workflow state for Workflow {1771205} was changed to 'PAUSED' from the outside
The source of WorkflowServiceImpl.java suggests that
"!dbWorkflowState.equals(initialState)", ie that the state of the workflow has
changed intermittendly by some magic.
I suspect that also the processings, which go to state "Captured: Sending to
processing" get PAUSED in a similar way, but without the application getting
aware of it (no log entries of any kind).
I have too little insight into the database management and why the state
changes, or why the app thinks it changed to go any further from here.
> Failure of worker machine caused admin app failure in a distributed
> environment
> -------------------------------------------------------------------------------
>
> Key: MH-9235
> URL: http://opencast.jira.com/browse/MH-9235
> Project: Matterhorn Project
> Issue Type: Bug
> Components: Administrative Tools, encoding
> Affects Versions: 1.3.1
> Reporter: Jonathan Felder
> Attachments: image001.png, image002.png
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://opencast.jira.com/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
