[jira] Commented: (SYNAPSE-525) Option to preserve addressing headers should be available
[ https://issues.apache.org/jira/browse/SYNAPSE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700446#action_12700446 ] Andreas Veithen commented on SYNAPSE-525: - The following change in Axis2FlexibleMEPClient causes a serious issue: -Options clientOptions = new Options(); +Options clientOptions = MessageHelper.cloneOptions(originalInMsgCtx.getOptions()); With this change, if the incoming request has no WS-Addressing headers, the proxy service seems to attempt sending the outgoing message to itself instead of the target endpoint! The issue can be reproduced with sample 150: use SOAPUI to send a message without WS-Addressing to the proxy service. It will fail saying that Axis2 can't infer the outgoing transport. The endpoint URI from which it tries to infer the transport is the URI of the proxy service, not the target service. Option to preserve addressing headers should be available - Key: SYNAPSE-525 URL: https://issues.apache.org/jira/browse/SYNAPSE-525 Project: Synapse Issue Type: Bug Components: Core Affects Versions: 1.2 Environment: all env Reporter: Ruwan Linton Assignee: Ruwan Linton Fix For: 1.3 For the moment Synapse replaces all the addressing headers when sending the message out to the routed service, but there can be case where the mediation configuration should preserve the addressing headers. For example like wsa:Reply-To So this requires a switch to configure the send mediator to not to alter addressing headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Endless recursion in FaultHandler.handleFault()
See SYNAPSE-525. Andreas On Fri, Apr 17, 2009 at 02:58, Hubert, Eric eric.hub...@foxmobile.com wrote: Hi all, Has someone ever seen something like that? It happened while local testing with Synapse trunk. [...] at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) at org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:181) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167) at org.apache.synapse.transport.nhttp.ServerWorker.processPost(ServerWorker.java:287) at org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:194) at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) [HttpServerWorker-1] WARN FaultHandler - ERROR_CODE : 0 ERROR_MESSAGE : Unexpected error during sending message out [HttpServerWorker-1] DEBUG AxisService - Get operation for anonOutInOp [HttpServerWorker-1] DEBUG AxisService - Found axis operation: org.apache.synapse.core.axis2.dynamicaxisoperat...@2f06b6 [HttpServerWorker-1] DEBUG ConfigurationContext - registerOperationContext (false): org.apache.axis2.context.operationcont...@cbbdf3 with key: urn:uuid:9FBF099295ABAFDCF71239925998622 [HttpServerWorker-1] DEBUG SandeshaModule$1 - Unsetting USE_ASYNC_OPERATIONS and DISABLE_RESPONSE_ACK for unreliable message [HttpServerWorker-1] DEBUG SandeshaModule$1 - Entry: SandeshaModule::resolveTarget [HttpServerWorker-1] DEBUG SandeshaUtil - Entry: SandeshaUtil::isMessageUnreliable [HttpServerWorker-1] DEBUG SandeshaUtil - Exit: SandeshaUtil::isMessageUnreliable, false [HttpServerWorker-1] DEBUG SandeshaModule$1 - Exit: SandeshaModule::resolveTarget [HttpServerWorker-1] DEBUG ProjectResourceBundle - org.apache.axis2.i18n.resource::handleGetObject(cannotInferTransport) [HttpServerWorker-1] ERROR ClientUtils - The system cannot infer the transport information from the /services/cmretrieval-game URL. [HttpServerWorker-1] DEBUG ProjectResourceBundle - org.apache.axis2.i18n.resource::handleGetObject(cannotInferTransport) [HttpServerWorker-1] ERROR Axis2Sender - Unexpected error during sending message out org.apache.axis2.AxisFault: The system cannot infer the transport information from the /services/myservice URL. at org.apache.axis2.description.ClientUtils.inferOutTransport(ClientUtils.java:82) at org.apache.synapse.core.axis2.DynamicAxisOperation$DynamicOperationClient.executeImpl(DynamicAxisOperation.java:123) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165) at org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send(Axis2FlexibleMEPClient.java:317) at org.apache.synapse.core.axis2.Axis2Sender.sendOn(Axis2Sender.java:56) at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.send(Axis2SynapseEnvironment.java:191) at org.apache.synapse.endpoints.AbstractEndpoint.send(AbstractEndpoint.java:194) at org.apache.synapse.endpoints.AddressEndpoint.send(AddressEndpoint.java:61) at org.apache.synapse.endpoints.IndirectEndpoint.send(IndirectEndpoint.java:54) at org.apache.synapse.endpoints.LoadbalanceEndpoint.send(LoadbalanceEndpoint.java:84) at org.apache.synapse.endpoints.LoadbalanceEndpoint.onChildEndpointFail(LoadbalanceEndpoint.java:122) at org.apache.synapse.endpoints.AbstractEndpoint.invokeNextFaultHandler(AbstractEndpoint.java:401) at org.apache.synapse.endpoints.AbstractEndpoint.onFault(AbstractEndpoint.java:286) at org.apache.synapse.endpoints.AddressEndpoint.onFault(AddressEndpoint.java:45) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:101) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) [...] at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) at org.apache.synapse.FaultHandler.handleFault(FaultHandler.java:107) […] at org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive(ProxyServiceMessageReceiver.java:181) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
[jira] Commented: (SYNAPSE-525) Option to preserve addressing headers should be available
[ https://issues.apache.org/jira/browse/SYNAPSE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700449#action_12700449 ] Andreas Veithen commented on SYNAPSE-525: - Just noticed that the cloneOptions related issue is actually the same as the one reported by Eric [1]. Since this is quite serious, I temporarily reverted the change. [1] http://markmail.org/message/2cjy73ksrly5znaz Option to preserve addressing headers should be available - Key: SYNAPSE-525 URL: https://issues.apache.org/jira/browse/SYNAPSE-525 Project: Synapse Issue Type: Bug Components: Core Affects Versions: 1.2 Environment: all env Reporter: Ruwan Linton Assignee: Ruwan Linton Fix For: 1.3 For the moment Synapse replaces all the addressing headers when sending the message out to the routed service, but there can be case where the mediation configuration should preserve the addressing headers. For example like wsa:Reply-To So this requires a switch to configure the send mediator to not to alter addressing headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Resolved: (SYNAPSE-280) Synapse doesn't preserve CDATA sections
[ https://issues.apache.org/jira/browse/SYNAPSE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen resolved SYNAPSE-280. - Resolution: Fixed The feature introduced by WSCOMMONS-461 can be used to configure Synapse to preserve CDATA sections. Added relevant documentation explaining how to set this up. Synapse doesn't preserve CDATA sections --- Key: SYNAPSE-280 URL: https://issues.apache.org/jira/browse/SYNAPSE-280 Project: Synapse Issue Type: Bug Components: Core Affects Versions: NIGHTLY Reporter: Andreas Veithen Assignee: Andreas Veithen Priority: Minor Fix For: 1.3 When a message is received by Synapse, any CDATA section is transformed into a normal text node. This issue has been discussed on the mailing list, but without getting to a conclusion: http://www.nabble.com/Interesting-problem-introduced-by-CDATA-section-to16321118.html A closer look reveals that the origin of the problem is that Woodstox by default creates parsers in coalescing mode, implying that adjacent CDATA sections and text nodes are combined and reported as a single CHARACTER event. Therefore information about CDATA sections is lost. Note that enabling coalescing by default is contrary to the StAX specifications and this is a bug in the Woodstox version used by Synapse (see http://jira.codehaus.org/browse/WSTX-140). The problem can be solved for Synapse in standalone mode by adding the following instruction to ServerManager#start: StAXUtils.getXMLInputFactory().setProperty(XMLInputFactory.IS_COALESCING, Boolean.FALSE); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Commented: (SYNAPSE-525) Option to preserve addressing headers should be available
[ https://issues.apache.org/jira/browse/SYNAPSE-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700499#action_12700499 ] Ruwan Linton commented on SYNAPSE-525: -- Sorry, for not testing all the scenarios with this change I will fix this ASAP. Thanks, Ruwan Option to preserve addressing headers should be available - Key: SYNAPSE-525 URL: https://issues.apache.org/jira/browse/SYNAPSE-525 Project: Synapse Issue Type: Bug Components: Core Affects Versions: 1.2 Environment: all env Reporter: Ruwan Linton Assignee: Ruwan Linton Fix For: 1.3 For the moment Synapse replaces all the addressing headers when sending the message out to the routed service, but there can be case where the mediation configuration should preserve the addressing headers. For example like wsa:Reply-To So this requires a switch to configure the send mediator to not to alter addressing headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Created: (SYNAPSE-534) Make logging of HTTP 500 responses configurable
Make logging of HTTP 500 responses configurable --- Key: SYNAPSE-534 URL: https://issues.apache.org/jira/browse/SYNAPSE-534 Project: Synapse Issue Type: Improvement Components: Transports Reporter: Eric Hubert Priority: Minor Attachments: warnOnHttp500.patch Currently Synapse outputs a warning for any HTTP 500 response, irrespective of the content-type. Consequently, this also applies to any SOAP fault. I would propose to generaly only log such server/service responses as a warning. Additionally I would like to make this configurable via a transport sender parameter. This parameter could be called warnOnHTTP500 and contain a delimiter separated list of content-types for which a warning shall be logged. I started implementing this, ao attached you will find a patch containing changes to HttpCoreNIOSender, ClientHandler, axis2.xml plus a short addition to the Maven sites transport documentation. The implementation was straight forward and simple but I was uncertain about how to pass the parameter from HttpCoreNIOSender to ClientHandler. I'm not sure whether my solution to use the Axis2 ConfigurationContext's properties is acceptable. So I would apreciate feedback/corrections here. If the parameter is missing, there will be no change in functionality. In order to document the change also in the default configuration I changed the axis2.xml to contain the following line: parameter name=warnOnHTTP500 locked=false*/parameter which has the same meaning as the missing parameter. An example of another valid configuration could look like this: parameter name=warnOnHTTP500 locked=falsex-application/hessian|none/parameter With this configuration a warning would only be logged for 500 responses of content-type 'x-application/hessian' or messages missing a content-type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Updated: (SYNAPSE-534) Make logging of HTTP 500 responses configurable
[ https://issues.apache.org/jira/browse/SYNAPSE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hubert updated SYNAPSE-534: Attachment: warnOnHttp500.patch Make logging of HTTP 500 responses configurable --- Key: SYNAPSE-534 URL: https://issues.apache.org/jira/browse/SYNAPSE-534 Project: Synapse Issue Type: Improvement Components: Transports Reporter: Eric Hubert Priority: Minor Attachments: warnOnHttp500.patch Currently Synapse outputs a warning for any HTTP 500 response, irrespective of the content-type. Consequently, this also applies to any SOAP fault. I would propose to generaly only log such server/service responses as a warning. Additionally I would like to make this configurable via a transport sender parameter. This parameter could be called warnOnHTTP500 and contain a delimiter separated list of content-types for which a warning shall be logged. I started implementing this, ao attached you will find a patch containing changes to HttpCoreNIOSender, ClientHandler, axis2.xml plus a short addition to the Maven sites transport documentation. The implementation was straight forward and simple but I was uncertain about how to pass the parameter from HttpCoreNIOSender to ClientHandler. I'm not sure whether my solution to use the Axis2 ConfigurationContext's properties is acceptable. So I would apreciate feedback/corrections here. If the parameter is missing, there will be no change in functionality. In order to document the change also in the default configuration I changed the axis2.xml to contain the following line: parameter name=warnOnHTTP500 locked=false*/parameter which has the same meaning as the missing parameter. An example of another valid configuration could look like this: parameter name=warnOnHTTP500 locked=falsex-application/hessian|none/parameter With this configuration a warning would only be logged for 500 responses of content-type 'x-application/hessian' or messages missing a content-type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
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:duration12/syn:duration syn:actionfault/syn:action /syn:timeout syn:markForSuspension syn:retriesBeforeSuspend3/syn:retriesBeforeSuspend syn:retryDelay500/syn:retryDelay /syn:markForSuspension syn:suspendOnFailure syn:initialDuration100/syn:initialDuration syn:progressionFactor3/syn:progressionFactor syn:maximumDuration30/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
