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 86499 - There is a way to hang a BPEL process
Summary: There is a way to hang a BPEL process
Alias: None
Product: soa
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: _ gmpatil
Depends on:
Reported: 2006-10-04 16:23 UTC by Nikita Krjukov
Modified: 2007-09-03 13:48 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

A fragment of the App Server console output (for the LoanApplication example) (6.21 KB, text/plain)
2006-10-04 16:26 UTC, Nikita Krjukov

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Krjukov 2006-10-04 16:23:42 UTC
I know that it is the BPEL runtime's problem but there is not a runtime 

There is a way to hang a BPEL process.  without any error notifications.

Steps to reproduce:

It requires quite complicated preparations but they are described with full 
details in the Loan Application tutorial here:
The URL can be not final so it can becumes invalid. 
But Sherry (Sherry.Barkodar@Sun.COM) can be asked for an actual location of the 

Here is the short description:

-- create a new Enterprise/EJB Module which will be called by the BPEL as a 
-- create a new WEB Service there
-- add a new operation to the web service with a parameter(s) of the double 
-- compile and deploy the EJB Module to the Java Application Server.

-- create a new BPEL project which will call the EJB Web Service.
-- Drag&Drop the WEB service node (EJB module project) from the Project view to 
the BPEL and then press Ok in the Partner Link dialog. The new WSDL is added to 
the BPEL project here: Partners/EJB Module Name/WEB Service name.wsdl
-- Add Invoke and tune it to call the operation from the EJB Web service.

-- Then it's necessary to create in the BPEL all other elements like receive 
and reply so it can be initiated. 
-- Create a new composite application, add the BPEL module there, add a test 
case which will call the BPEL and finally deploy the comp app project to the 
application server. 

-- Now you can try to run test case. It will call the BPEL process and the 
process will call the EJB Web service. It should work here. 


-- Modify the signature of the EJB Web service operation by changing the type 
of parameter from double to float and redeploy the EJB project. 

-- Run test case of the composite application again. 
The BPEL process hangs when it run the Invoke which call the EJB web service 
operation. The test case is failed only after the timeout. 

The BPEL process should be terminated with a fault here instead of hang. 

The application server's console contains some error messages (see attachment) 
but they seems not informative enough.

Also it worth to check how the BPEL process will behave in other conditions, 
for example, if the EJB WEB service operaton's name is changed or if the 
operation throws an exception.
Comment 1 Nikita Krjukov 2006-10-04 16:26:14 UTC
Created attachment 34872 [details]
A fragment of the App Server console output (for the LoanApplication example)
Comment 2 Nikita Krjukov 2006-10-04 18:24:33 UTC
I just tried to add a Fault Handler with the CatchAll element.
I supposed that the execution of the process could be continued there after an 
exception. But it didn't managed to stop with the debuger inside of the 
Comment 3 Nikita Krjukov 2006-10-04 18:27:21 UTC
I suppose that it is not so difficult to reprodice the same defect with the 
Travel Reservation Example because of it also used the EJB web services. 

Comment 4 Sreenivasan Genipudi 2006-10-04 22:29:58 UTC
Runtime issue. Created an issue in bugster 
CR 6478384. Please close this.
Comment 5 Alexander Pepin 2006-10-09 14:11:18 UTC
See comments above.
Comment 6 lchang 2006-10-13 00:18:54 UTC
Reopening, so we can track this on the dashboard.  This will be fixed with 
Comment 7 Venkat Chellasamy 2006-10-13 23:52:53 UTC
This is a negative test case. The correct behaviour is to propogate the error  
to the user. This will be fixed in the next release as we are running out of 
time. The fix is in JavaEE service engine and BPEL Service engine.

In this scenario, the user changed one of the partner's interface. For the 
comp app to work now, the user should make the change in the bpel process 
(i.e. use the new wsdl).

Given that typically users in the field will make corresponding changes when 
interfaces are changed inorder to get the composite applications to work, we 
can reduce the priority of this bug for this release.
Comment 8 pcmreddy 2006-10-14 01:53:01 UTC
This bug needs to be documented.
Comment 9 Todd Fast 2006-10-14 05:14:35 UTC
The real bug here is that the error handling and notification in the runtime is
insufficient or broken. The engine should receive a fault when invoking a
service endpoint incorrectly, which should then be propagated to the test client.

I agree with Venkat, at least for the design-time; this is not a high-priority
use case in this release--the user must perform manual refactoring as they would
if any external Web service changed its interface. In a future release, we will
have refactoring between Java EE services and clients so that this problem is
avoided for developers working on both ends of the invocation. However, the real
fix should be in the BPEL runtime.

Comment 10 Michael Frisino 2006-10-16 11:11:29 UTC

Also, are there any tell tale error messages in AS log file that can identify
this condition when it occurs?

In order for documentation to proceed, runtime team please indicate what
corrective action, if any, is required on the runtime side.

Assuming user re-imports modified WSDL into BPEL project. 
Assume user redeploys project.
Is that sufficient?

Or does user have to restart the BPEL SE? Stop/Shutdown/Restart? What?
Comment 11 astashkova 2006-10-20 15:30:05 UTC
Added to RNs.

Use the following link to review the wording and location of the issue in the
staged Release Notes
Comment 12 Venkat Chellasamy 2007-02-27 02:35:54 UTC
please analyse this scenario with the current builds
Comment 13 _ gmpatil 2007-02-28 20:29:08 UTC
Runtime issue is still present in the latest build.
GF 9.1 B36. 
BPEL nighltly build 02/16/2007.

Below information is not relevant to Netbeans tooling support.

This happens with JAX-RPC/J2EE 1.4 EJB project and calls going thru Java EE Svc
Engine. JAX-WS/Java EE 5 EJB project is able to handle data type change from
double to float with out any exception.

Thru debugger and logs, one can see both engines are throwing exception, but
SOAP fault is not sent back to client from BPEL.
There seems to be issue with sending fault message from Java EE Svc engine to
BPEL though ME status is set to "error" .

There is CR 6478384 assigned to Java EE Svc Eng team.

In the latest GF build auto endpoint activation in Java EE Svc Engine is
disabled. To enable, start GF with system proerty
Comment 14 _ gmpatil 2007-03-02 18:05:44 UTC
Closing the issue it is not a bug in Netbeans. It is a bug in runtime
exception/fault handling between BPEL and Java EE Svc Engine. There is an issue
already for this CR 6478384.

If any, refactoring or change propagation between Java EE and BPEL projects in
Netbeans should be new feature request.
Comment 15 Alexei Mokeev 2007-03-06 11:48:20 UTC