axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepal Jayasinghe (JIRA)" <>
Subject [jira] [Updated] (AXIS2-5567) timeout on WS client call using JMS transport cannot be identified
Date Sun, 30 Mar 2014 17:22:16 GMT


Deepal Jayasinghe updated AXIS2-5567:

    Priority: Major  (was: Blocker)

> timeout on WS client call using JMS transport cannot be identified
> ------------------------------------------------------------------
>                 Key: AXIS2-5567
>                 URL:
>             Project: Axis2
>          Issue Type: Improvement
>          Components: JMS transport
>    Affects Versions: Transports 1.0.0
>         Environment: Axis2 1.6.1 and jms transport 1.0.0
>            Reporter: Mario Coeckelberghs
> When a out/in synchronous webservice call is executed on client side and there is no
response within the specified time there is no specific AxisFault thrown. A generic AxisFault
> org.apache.axis2.AxisFault: The input stream for an incoming message is null.
> However, it is crutial to be able to determine if the exception (AxisFault) is a timeout
or a communication problem, in context of exception handling. When using the Http transport
you can get the root exception and it it is of type SocketTimeoutException, you know you're
dealing with a response timeout and not a technical problem.
> Axis2 JMS Transport should provide a way to identify if the AxisFault is due to a timeout
or not.
> Extending the JMSSenderclass to solve this is not a nice solution because a lot of private
methods need to be redefined. To be best location and only location you know you're dealing
with a timeout is in the JMSSender class, method waitForResponseAndProcess(Session session,
Destination replyDestination, MessageContext msgCtx, String correlationId, String contentTypeProperty).
> if (reply != null) {
> ...
> } else {
>     log.warn("Did not receive a JMS response within " +
>                     timeout + " ms to destination : " + replyDestination +
>                     " with JMS correlation ID : " + correlationId);
>                 metrics.incrementTimeoutsReceiving()
> }
> Add the throw AxisFaultException in the else clause. Now if there was a timeout, an AsxisFault
is thrown anyway but not with the needed information to determin if it was a timeout or something
> Either throw a specific subclass of AxisFault (AxisTimeoutFault) or throw an AxisFault
with a faultcode which represents the timeout.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message