Hi all,
As no one beat me to it, I tracked down this issue to the following change to
the onFault() method of AddressEndpoint:
/**
* This class represents an actual endpoint to send the message. It is
responsible for sending the
@@ -35,22 +31,32 @@
public void onFault(MessageContext synCtx) {
- // is this really a fault or a timeout/connection close etc?
- if (isTimeout(synCtx)) {
- getContext().onTimeout();
- } else if (isSuspendFault(synCtx)) {
- getContext().onFault();
+ // is this an actual leaf endpoint
+ if (getParentEndpoint() != null) {
+ // is this really a fault or a timeout/connection close etc?
+ if (isTimeout(synCtx)) {
+ getContext().onTimeout();
+ } else if (isSuspendFault(synCtx)) {
+ getContext().onFault();
+ }
}
The added null-check of the parent endpoint causes this trouble. The parent
endpoint of my address endpoint is always null, thus the
EndpointContext.onFault() gets never executed and we run endless circles.
Removing this check, resolves the issue for me, but according to the commit
message this seems to be done on purpose to fix another issue…
Here are the details of the change:
Revision: 727648
Author: indika
Date: 06:38:32, Thursday, 18. Dec 2008
Message:
Fixed an issue - JMX switch off doesn’t work due to a leaf level endpoint (wsdl
/ address) become root endpoint too (when there are only address or wsdl
endpoint - no LB or FO endpoint with address endpoints as children).
----
Modified :
/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/SynapseConstants.java
Modified :
/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/endpoints/AbstractEndpoint.java
Modified :
/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/endpoints/AddressEndpoint.java
Modified :
/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/endpoints/EndpointContext.java
Modified :
/synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/endpoints/WSDLEndpoint.java
Regards,
Eric
________________________________
From: Hubert, Eric [mailto:eric.hub...@foxmobile.com]
Sent: Saturday, April 18, 2009 7:20 PM
To: dev@synapse.apache.org
Subject: RE: Endless recursion in FaultHandler.handleFault()
Hi all,
I'm still facing an issue which looks like a recursion (not the same), if the
endpoint url is a non existing one resulting in a connection refused.
Here is my endpoint config:
<syn:endpoint name="servicename#1.0#lbgroupname#A1###myhost">
<syn:address uri="some_non_existing_url" statistics="false">
<syn:timeout>
<syn:duration>120000</syn:duration>
<syn:action>fault</syn:action>
</syn:timeout>
<syn:markForSuspension>
<syn:retriesBeforeSuspend>3</syn:retriesBeforeSuspend>
<syn:retryDelay>500</syn:retryDelay>
</syn:markForSuspension>
<syn:suspendOnFailure>
<syn:initialDuration>100</syn:initialDuration>
<syn:progressionFactor>3</syn:progressionFactor>
<syn:maximumDuration>300000</syn:maximumDuration>
</syn:suspendOnFailure>
</syn:address>
</syn:endpoint>
[...]
[HttpClientWorker-7] WARN FaultHandler - ERROR_CODE : 101503 ERROR_MESSAGE :
Connection refused or failed for : myhost:6003
[HttpClientWorker-7] DEBUG AxisService - Get operation for anonOutInOp
[HttpClientWorker-7] DEBUG AxisService - Found axis operation:
org.apache.synapse.core.axis2.dynamicaxisoperat...@2720f6
[HttpClientWorker-7] DEBUG ConfigurationContext - registerOperationContext
(false): org.apache.axis2.context.operationcont...@16a9d0a with key:
urn:uuid:EEC7CAA6BBD62D98F91240074657255
[HttpClientWorker-7] DEBUG SandeshaModule$1 - Unsetting USE_ASYNC_OPERATIONS
and DISABLE_RESPONSE_ACK for unreliable message
[HttpClientWorker-7] DEBUG SandeshaModule$1 - Entry:
SandeshaModule::resolveTarget
[HttpClientWorker-7] DEBUG SandeshaUtil - Entry:
SandeshaUtil::isMessageUnreliable
[HttpClientWorker-7] DEBUG SandeshaUtil - Exit:
SandeshaUtil::isMessageUnreliable, false
[HttpClientWorker-7] DEBUG SandeshaModule$1 - Exit:
SandeshaModule::resolveTarget
[HttpClientWorker-7] DEBUG ConfigurationContext - registerOperationContext
(false): org.apache.axis2.context.operationcont...@16a9d0a with key:
urn:uuid:EEC7CAA6BBD62D98F91240074657255
[HttpClientWorker-7] DEBUG ConfigurationContext - msgContext: [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] action:
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for
Phase "soapmonitorPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase
"soapmonitorPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for
phase "soapmonitorPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for
Phase "OperationOutPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase
"OperationOutPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for
phase "OperationOutPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for
Phase "RMPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase "RMPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for
phase "RMPhase"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for
Phase "PolicyDetermination"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase
"PolicyDetermination"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for
phase "PolicyDetermination"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for
Phase "MessageOut"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase "MessageOut"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking Handler
'AddressingOutHandler' in Phase 'MessageOut'
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for
phase "MessageOut"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking pre-condition for
Phase "Security"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Invoking phase "Security"
[HttpClientWorker-7] DEBUG Phase - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] Checking post-conditions for
phase "Security"
[HttpClientWorker-7] DEBUG AddressingHelper - [MessageContext:
logID=urn:uuid:EEC7CAA6BBD62D98F91240074679600] isReplyRedirected: ReplyTo is
null. Returning false
[HttpClientWorker-10] DEBUG SandeshaModule$1 - Unsetting USE_ASYNC_OPERATIONS
and DISABLE_RESPONSE_ACK for unreliable message
[HttpClientWorker-10] DEBUG SandeshaModule$1 - Entry:
SandeshaModule::resolveTarget
[HttpClientWorker-10] DEBUG SandeshaUtil - Entry:
SandeshaUtil::isMessageUnreliable
[HttpClientWorker-10] DEBUG SandeshaUtil - Exit:
SandeshaUtil::isMessageUnreliable, false
[HttpClientWorker-10] DEBUG SandeshaModule$1 - Exit:
SandeshaModule::resolveTarget
[HttpClientWorker-10] DEBUG OMNodeImpl - Builder is already complete.
[HttpClientWorker-10] WARN FaultHandler - ERROR_CODE : 101503 ERROR_MESSAGE :
Connection refused or failed for : pls-svc-2.uat.jamba.net:6003
[HttpClientWorker-10] DEBUG AxisService - Get operation for anonOutInOp
[...]
Any ideas? Otherwise I will try to dig into this if I find the time.
Regards,
Eric
