axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathieu Chauvin (JIRA)" <>
Subject [jira] Commented: (AXIS-2446) Buggy handling of one way invocation of a service
Date Tue, 28 Mar 2006 08:19:36 GMT
    [ ] 

Mathieu Chauvin commented on AXIS-2446:

To reproduce this issue:
- Write a simple valid WSDL declaring a service with a one-way operation, even if you have
no implementation (it won't actually be called)
- Build the stubs using axis wsdl2java
- Write a junit test or anything you want to invoke the one way operation

To make yourself sure that there *is* a problem, use a debugger that will allow you to force
the Thread scheeduling.
I personnaly use Eclipse.
- Enable a breakpoint on the first line of the run() method declared
   in the invokeEngineOneWay() method of the org.apache.axis.client.Call class.
- Ensure that the main Thread won't be stopped by any breakpoints.
- Launch test in debug mode.

When the breakpoint is reached, the sender Thread is blocked. When the main thread ends, the
JVM simlply exits, and you
will see that even though the sender Thread was still running, it was also terminated.

> Buggy handling of one way invocation of a service
> -------------------------------------------------
>          Key: AXIS-2446
>          URL:
>      Project: Apache Axis
>         Type: Bug
>   Components: Basic Architecture
>     Versions: 1.3
>     Reporter: Mathieu Chauvin

> There are already known issues about the 
> org.apache.axis.client.Call.invokeEngineOneWay()
> method (see for instance).
> But beyong the fact that exceptions raised while sending can't be catched, using another
Thread to send the message
> has other side effects that lead, under certain circonstances, to a buggy behaviour.
> I am currently implementing a one way service invocation upon JMS transport.
> The invocation should be done from a stateless session bean, and *must* be part
> of the underlying JTA transaction.
> Trying to do this using Axis 1.3, I'm facing issues that are likely to be bugs:
> - once the sending Thread is started, we have no control on it.
>    If the main Thread terminates without synchronizing upon the end of sub-Threads, then
>    the JVM will "kill" any running Thread, no matter wether they have done their job
or not.
>    As a result, a main() that just invokes a one way service is likely (depending on
the Threads
>    scheeduling) to see *no* exception, neither raised, neither in the logs even in DEBUG
level, and *no*
>    message will be sent !!!!! Adding a Thread.sleep() after the invocation can solve
the problem, but it's not a
>    good solution.
>    In a J2EE environnment, the JVM does not terminate very often (hopefully), but some
messages could be
>    lost anyway.
> - Another issue may occur in a J2EE environnement. In J2EE, user Thread should be prohibited.
The sender thread
>    might not be part of the underlying JTA transaction, and will probably not be able
to send JMS messages in XA mode.
>    Moreover, even if the sender Thread is part of the JTA transaction, the Thread scheeduling
policy can't ensure that the
>    sender Thread will execute *before* the calling Thread, and thus the JTA transaction
is likely to be already commited
>    when the sender Thread tries to send it's message.
> Yours,
> Mathieu.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message