Uploaded image for project: 'Axis'
  1. Axis
  2. AXIS-2446

Buggy handling of one way invocation of a service

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.3
    • None
    • Basic Architecture

    Description

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            mchauvin Mathieu Chauvin
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: