Process Debugger

[ruediger_hain]

Hi,
we are prototyping a process debugger for Activiti.
One feature we need in the debugger is setting breakpoints so that the process execution will stop before/after reaching a certain activity.

Our idea was to merge an artificial breakpoint activity into the original process definition which would behave as a wait state.
This might work (we havent tried yet) but seems like an ugly hack, there should be some support for this in the engine.

Are there any hooks planned to support breakpoints in the future?
Or can you give any hints how to accomplish this?

[tombaeyens]

In the next release, we should be able to finish a so called process event bus.  It's similar to what was called a HistorySession in jBPM 4.  When a process instance executes, events are fired.  Listeners are notified synchronously.  Such a listener would be ideal for implementing breakpoints, I think.

It would be really cool to have that capability then in the engine build in.

I believe in the XML parsing, we already switched from DOM to use a SAX parser in order to capture the line numbers of the Activities.  I don't know by heart, but it should be possible to get that data as well.

[ruediger_hain]

Do you mean the execution would block in the Listener call which implements the breakpoint?
Or would there be a way in the listener to safely suspend the execution and resume it later?
In my opinion it would be better to ensure the execution is in a stable state when the breakpoint is reached - that's where the idea to add "breakpoint activities" that simply behave as wait states came from.

[tombaeyens]

a listener implementation can block the process execution.  i think that is preferable.  as then you get the exact same behaviour in debug as in real execution.

you say you want to ensure a stable state for the execution.  i don't see yet what you would call an unstable state.  can you clarify that what you meant with that?

[ruediger_hain]

With stable I mean the process execution is in a wait state, i.e. it is waiting for an external trigger. So the method that initiated the process (for example ProcessService#startProcessInstance) returns even when the execution has reached a breakpoint.

In a process that splits up into multiple concurrent paths on a parallel gateway I would like to have all concurrent paths being executed "to the end". In other words, for a concurrent path that contains a breakpoint the token is at that breakpoint whereas all other tokens are at the end of their respective paths, for example at a merging gateway.

If I understand the engine correctly, this behaviour would not be achievable by just blocking the process execution in a listener because the concurrent execution paths would be blocked as well, leaving the process in a somewhat non-deterministic state.

[tombaeyens]

process concurrency doesn't make a difference.  you want the debugger to block on breakpoints and for the rest it should behave just the same like it does in real execution mode.  so having a blocking call on an process event listener being dispatched is still a good solution imo.

i don't see the counter argument yet.

[bernd_ruecker]

Hey guys.

I think you are basically talking about different things.

The Breakpoint as Tom sees it behaves like a Java Breakpoint: The Thread stops and waits for action. The transaction is kept open and is waiting. If you wait too long, it times out and is aborted. This make sense for debugging and is what you expect from a breakpoint.

What Rüdiger has in mind is more like an additional persistent stop, to have "transactional breakpoint". I think I can understand why you want to have something like that, but it is true, that this will change the runtime behavior of the process instance (if now the instances crashes afterwards, it will rollback to the breakpoint, not the last wait state!).

I need to have a look at the current implementation of the Event Bus, but maybe it would be cool if a listener can set a transaction boundary (@Tom: maybe that could be used for asynchronous continuation as well?), then both could be implemented. But it would be good to see the exact use case for the Debugger (development time, runtime inspection, marketing demos, …?).

Cheers
Bernd

[tombaeyens]

@ Bernd, if your interpretation of Ruediger is correct, then he's talking about an asynchronous continuation, right?

[bernd_ruecker]

Basically yes, but on an instance level during runtime, and not triggered automatically, but from the "Debugger-App"

[ruediger_hain]

I'm not sure what an async. continuation means, but Bernd's interpretation is right, I basically want a transactional breakpoint not a Java breakpoint. The intended use case of a breakpoint is to debug process semantics not the internal functions of the process engine.
When the breakpoint is reached, I want to be able to introspect all process variables, pending user tasks etc.
Is this really possible when the transaction is not yet committed and the executing thread is blocked in an event listener?

Cheers,
Rüdiger