[ http://issues.apache.org/jira/browse/AXIS-2446?page=comments#action_12372073 ]
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: http://issues.apache.org/jira/browse/AXIS-2446 > 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 http://issues.apache.org/jira/browse/AXIS-1908 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
