This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 85847 - When the debugger is resumed, any previously suspended process instance should become the active process instance.
Summary: When the debugger is resumed, any previously suspended process instance shoul...
Status: RESOLVED INVALID
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL Debugger (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@soa
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-27 02:24 UTC by Joshua Sandusky
Modified: 2006-10-09 19:47 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Sandusky 2006-09-27 02:24:30 UTC 
If there are multiple process instances running, and two or more of them suspend
at about the same time, only one process instance (the first one) will be made
the active process instance. All others will be suspended, but they will not be
the active process instance. When the user hits the Continue button to resume
the debugger, the active process instance will resume. However, assuming that
the process instance finishes and does not suspend again, the user then must
manually Make Current the other process instances in order to resume them.
This should be done automatically so that the user does not have to manually
make one of the other process instances current.

One way of achieving this is to implement a stack-based way to track the active
position.

In Netbeans, both Java debug sessions and Java threads behave the same way. If
the user resumes one session/thread and that session/thread finishes, then the
active position changes to that of a previously suspended session/thread.
Comment 1 Alexander Zgursky 2006-10-03 17:23:28 UTC 
In Java Debugger the actions like "Continue" and "Step Over" work different from
that of the BPEL Debugger. In Java Debugger "Step Over" resumes ALL the
suspended threads and stops at the next position of the current thread. For
"Continue" it's the same - it resumes ALL the suspended threads.
In BPEL Debugger "Continue" and "Step Over" actions are bind to the current
Process Instance, they don't affect other (i.e. not current) Process Instances.
Although, there is a way to resume a single thread in Java Debugger - you need
to select "Resume" from the Thread's context menu in the Threads View. This is
very similar to what we have in BPEL Debugger both for "Resume" and for "Continue".

Another thing about Java Debugger is that it suspends ALL the Threads whenever
the breakpoint is reached, unless you have changed the Breakpoint's properties.
In Java Breakpoint properties there is an option to suspend either all threads
(the default) or just the thread that has reached the breakpoint. So, if you
want to make a situation when more than one breakpoints are hit simulteniously
in different threads - you need to customize those breakpoints properties.
Otherwise, the breakpoints will be hit one by one.

So, if you have more than one thread suspended in Java Debugger and one of them
is current, and you select "Resume" in the context menu of the current Thread,
the thread will be executed to its completion (unless there are some other
breakpoints or infinite loops, of course) and its state will be changed to
"Zombie". But this Thread will stay the current Thread - no switching to other
threads will occur.
Comment 2 Alexander Zgursky 2006-10-03 17:38:52 UTC 
As I can see, we have two different situations here:
1) current process instance resumes
2) current process instance completes

For #1 I would suggest to do nothing and for #2 do the following:
- print a message in the Output Window
- activate the BPEL Process Instances View so user could select another Process
Instance as current

I like the idea of constructing the stack of suspended process instances
proposed by Josh, but I don't really like it to be automatically selected. And I
don't think we would want to display any dialogs for users to select the current
process instance.
Comment 3 Alexander Zgursky 2006-10-09 19:46:59 UTC 
I've created two issues to cover two cases described in my last comment - issue
86799 and issue 86800.
Closing this issue as INVALID since it's too complex to track as a single issue.
Please feel free to file other Enhancement Requests if you feel that the created
issues are not fully covering this one.