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.
Steps to reproduce: - create Asynchronous sample project - start AS - deploy the project - set a breakpoint on invoke ("invokepartner") activity in AsychronousSampleClient.bpel - set a breakpoint on invoke ("end") activity in AsynchronousSample.bpel - start debug session - run test - when the first breakpoint is reached do stepInto twice Result: State of the process becomes unclear: continue and stepInto buttons on toolbar are disabled, no currently executed activity mark on the diagram/code. Workaround: Switch to BPEL Process Instances wndow and make AsynchronousSample current then continue will be allowed. Sometimes after that process can not be undeployed. see 81280.
fixed together with 81280
verified in build 060810
The bug was marked as VERIFIED FIXED by mistake
The described behaivor seems OK to me: We are trying to debug two bpel processes - AsychronousSampleClient and AsychronousSample, which are asynchronously exchanging messages with each other. When do a described scenario, after AsychronousSampleClient process instance reached the first breakpoint, if you hit "step into" - it will asynchronously invoke a AsychronousSample, i.e. the AsychronousSample process instance will be created but the AsychronousSampleClient process instance will not block. As the AsychronousSample process instance executes it reaches the second breakpoint and suspends. At this point we have both process instances suspended and the AsychronousSample is the current one. From this point you can choose to debug (step through) either first or second process instance by making the current one or another. When you hit "step into" for the second time, the AsychronousSample process instance tries to send a reply message to the AsychronousSampleClient, but since AsychronousSampleClient is suspended BEFORE it reached a "receive" activity - it's not receiving any messages. So, as expected, AsychronousSample is left in the "Running" state untill AsychronousSampleClient reaches a "receive" activity. If you use a "workaround" described in the original scenario, i.e. go to the BPEL Process Instances view and select AsychronousSampleClient as the current process instance - you will be able to continue the execution of AsychronousSampleClient. As AsychronousSampleClient starts a "receive" activity the AsychronousSample process instance continue its execution since it's not blocked on the "invoke" activity anymore. So, AsychronousSample completes and only one process instance left - AsychronousSampleClient, which is the current. I'm closing the issue as INVALID, since everything works as expected (although, the scenario itself is a little bit tricky, so its difficult to understand what are we really doing)
Indeed there is no any bug but anyway debugging of several processes should be more clear.
From my understanding there are two things here that might be confusing to users: 1) when a proces instance is executing a synchronous "invoke" activity which takes a significant time to execute (extreme case - partner service hung or suspended by the debugger), debugger should visualize somehow that activity is being executed 2) when there are more than one suspended process instances (one of them is current) and the current process instance completes - user have to go to the Process Instances View to select another process instance as current to proceed with the debugging. I'm going to create separate issues to track them.
Created two issues to track the cases listed in the previous comment: issue 86800 and issue 86804. Closing as INVALID since it seems too complex to track as a single issue.