[
https://issues.apache.org/jira/browse/AXIS2-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen moved TRANSPORTS-49 to AXIS2-5567:
--------------------------------------------------
Component/s: (was: JMS)
JMS
Fix Version/s: (was: 1.0.0)
Affects Version/s: (was: 1.0.0)
1.0.0
Key: AXIS2-5567 (was: TRANSPORTS-49)
Project: Axis2 (was: Axis2 Transports)
> timeout on WS client call using JMS transport cannot be identified
> ------------------------------------------------------------------
>
> Key: AXIS2-5567
> URL: https://issues.apache.org/jira/browse/AXIS2-5567
> Project: Axis2
> Issue Type: Improvement
> Components: JMS
> Affects Versions: 1.0.0
> Environment: Axis2 1.6.1 and jms transport 1.0.0
> Reporter: Mario Coeckelberghs
> Priority: Blocker
>
> 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 thrown.
> 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 else.
> Either throw a specific subclass of AxisFault (AxisTimeoutFault) or throw an
> AxisFault with a faultcode which represents the timeout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
