Kepler

This is happening because the "iterations" parameter of the SDF director is set to 0 in your workflow. In the actual demo workflow (under getting_started directory) this is set to 1 -- but probably this is not mentioned in the documentation/getting started guide?

BTW, you can also set the "firingCountLimit" of the String Constant actor to 1 as well (currently set to NONE). Either setting "iterations" or "firingCountLimit" will result in the desired behavior.

So, technically, this is not a bug in the system, but possibly a bug in the documentation. So, I'm changing it to a "documentation" bug ...

The odd thing is that if you set up a different network with an SDF Director with interations set to zero, for example, a File Reader going into a text display, the UI does not freeze and you are able to stop it out of the loop. The problem is not a function of SDF Director's iterations set to 0, there is something else there.

Second, if the default configuration of a module leads the program to an unrecoverable state without any warning at all, I would very much call that a bug, not a documentation problem.

(In reply to comment #2)

The odd thing is that if you set up a different network with an SDF Director
with interations set to zero, for example, a File Reader going into a text
display, the UI does not freeze and you are able to stop it out of the loop.
The problem is not a function of SDF Director's iterations set to 0, there is
something else there.

Yes -- this is because of the nature of the FileReader actor. Of course, the workflow you describe is very different, and here if you were to set the iterations parameter of SDF to 1 you probably would not get the behavior you desire.

Second, if the default configuration of a module leads the program to an
unrecoverable state without any warning at all, I would very much call that a
bug, not a documentation problem.

You might enter a new bug for what you would like to see here. For instance, it sounds like you might want to change the default configuration of the String Constant actor to have the firingCountLimit be set to 1. Alternatively, this might be a larger issue in which the solution to the bug is that the default configuration of all actors should not result in an "unrecoverable state" within Kepler w.r.t. infinitely running workflows.

However, as I read your original bug report -- it sounds like you tried to recreate the workflow, and in doing so, didn't carry over the various parameter settings which led to the workflow running essentially in an infinite loop. However, the actual Hello World demo does not have this problem, which is why I think at least for this bug, it is a documentation issue.

I think it would be impossible to have each actor have a default state that never failed in any situation. Under some directors, any particular actor may work in its default state but not under a different director. This isn't to say that we couldn't improve the default state of various actors, but I think it would be impossible to guarantee correct operation in all permutations of directors and workflows.

That's true that trying to guarantee that no possible combination of modules would fail is impossible.

IMO the quick and dirty fix would be to add an autosave on run option. If a workflow will crash, at least it won't take all your work down with it.

The better fix I suspect is to move the actual running of the workflow into a separate thread so that regardless of which modules decide to go haywire, the workflow is unable of capturing the UI and causing a problem. I've only just started looking at the code so I don't know how difficult/feasible this would be.

As I digest this more, I think I agree that there is a problem if it completely seized up the UI. Were you able to hit the 'Stop' button to stop the execution and regain control? If not, then that is probably a bug -- even when a workflow is in an infinite loop, the controls should still work to let it trigger execution to stop (although it does generally take a little bit for the director to let actors that are in mid-fire to complete their work).

(In reply to comment #6)

As I digest this more, I think I agree that there is a problem if it completely
seized up the UI. Were you able to hit the 'Stop' button to stop the execution
and regain control?

No, the stop button, nor anything in the UI for that matter, completely stops responding to user input.

Edward writes:

I think what is going on is that the display actor queues
up a large number of events for the swing thread to deal
with, and when you hit the stop button, that event just goes
to the end of the queue. The swing thread won't respond
to the stop until it has processed all the display events.

The only fix I can think of is to put a Thread.sleep()
in the display actor. Thread.yield() is not enough
(we are already doing that, I think). But Thread.sleep()
will introduce a noticeable performance hit...

What we really need is some mechanism to get to the head
of the swing event queue, or to cancel pending events...

Original Bugzilla ID was 3774