You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2009/03/29 17:33:51 UTC
[jira] Created: (SYNAPSE-527) Transports use TRANSPORT_NON_BLOCKING
in an incorrect way
Transports use TRANSPORT_NON_BLOCKING in an incorrect way
---------------------------------------------------------
Key: SYNAPSE-527
URL: https://issues.apache.org/jira/browse/SYNAPSE-527
Project: Synapse
Issue Type: Bug
Components: Transports
Affects Versions: 1.2
Reporter: Andreas Veithen
Priority: Minor
The TRANSPORT_NON_BLOCKING property is set on the message contexts for incoming messages by ServerWorker#createMessageContext (NIO HTTP transport) and AbstractTransportListener#createMessageContext. When the message is sent out, Synapse copies this property over to the message context for the outgoing message. This in turn has an impact on the threading behavior when the message is sent: depending on the value of TRANSPORT_NON_BLOCKING, the <send> mediator (more precisely the OperationClient) will invoke the outgoing transport in a separate thread. It is not clear why the transport that handles the incoming request should determine the threading behavior of the transport that sends the outgoing request to the target service.
See also http://markmail.org/message/6iuslkueny24po73
--
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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-527) Transports use
TRANSPORT_NON_BLOCKING in an incorrect way
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693589#action_12693589 ]
Asankha C. Perera commented on SYNAPSE-527:
-------------------------------------------
I opened AXIS2-4196 [AxisEngine meddles with concerns of the transports, and creates a thread when sending out a message] a couple of months back to fix this in Axis2. Although this is one of the core classes of Axis2, a full review and fix is needed and the TransportNonBlockingInvocationWorker removed. Another critical issue is the Axis2 definition of a client and server side.. With Synapse, we are both, and this causes a lot of issues too
> Transports use TRANSPORT_NON_BLOCKING in an incorrect way
> ---------------------------------------------------------
>
> Key: SYNAPSE-527
> URL: https://issues.apache.org/jira/browse/SYNAPSE-527
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Priority: Minor
>
> The TRANSPORT_NON_BLOCKING property is set on the message contexts for incoming messages by ServerWorker#createMessageContext (NIO HTTP transport) and AbstractTransportListener#createMessageContext. When the message is sent out, Synapse copies this property over to the message context for the outgoing message. This in turn has an impact on the threading behavior when the message is sent: depending on the value of TRANSPORT_NON_BLOCKING, the <send> mediator (more precisely the OperationClient) will invoke the outgoing transport in a separate thread. It is not clear why the transport that handles the incoming request should determine the threading behavior of the transport that sends the outgoing request to the target service.
> See also http://markmail.org/message/6iuslkueny24po73
--
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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-527) Transports use TRANSPORT_NON_BLOCKING
in an incorrect way
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen updated SYNAPSE-527:
------------------------------------
Priority: Critical (was: Minor)
Fix Version/s: 1.3
Increasing the priority to critical because this issue may cause data loss and crash Synapse.
This happens in the following scenario:
- Modify sample 250 to forward using JMS instead of HTTP.
- Preload the queue of the proxy service with a large number of messages: ant jmsclient -Djms_type=pox -Djms_dest=dynamicQueues/StockQuoteProxy -Djms_payload=MSFT -Djms_msgcount=10000
- Start Synapse
On Mac OS X, the result is that Synapse will successfully process a certain number of messages (of order 1000), but then starts to trigger errors "Can't create thread: 5" and later fails with an out of memory error. The result is that messages are lost.
The workaround is to add the following mediator to the inSequence:
<property action="remove" name="transportNonBlocking" scope="axis2"/>
In that case, Synapse will gently forward all the messages.
> Transports use TRANSPORT_NON_BLOCKING in an incorrect way
> ---------------------------------------------------------
>
> Key: SYNAPSE-527
> URL: https://issues.apache.org/jira/browse/SYNAPSE-527
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Priority: Critical
> Fix For: 1.3
>
>
> The TRANSPORT_NON_BLOCKING property is set on the message contexts for incoming messages by ServerWorker#createMessageContext (NIO HTTP transport) and AbstractTransportListener#createMessageContext. When the message is sent out, Synapse copies this property over to the message context for the outgoing message. This in turn has an impact on the threading behavior when the message is sent: depending on the value of TRANSPORT_NON_BLOCKING, the <send> mediator (more precisely the OperationClient) will invoke the outgoing transport in a separate thread. It is not clear why the transport that handles the incoming request should determine the threading behavior of the transport that sends the outgoing request to the target service.
> See also http://markmail.org/message/6iuslkueny24po73
--
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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-527) Transports use TRANSPORT_NON_BLOCKING
in an incorrect way
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen updated SYNAPSE-527:
------------------------------------
Attachment: synapse_sample_250.xml
> Transports use TRANSPORT_NON_BLOCKING in an incorrect way
> ---------------------------------------------------------
>
> Key: SYNAPSE-527
> URL: https://issues.apache.org/jira/browse/SYNAPSE-527
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Priority: Critical
> Fix For: 1.3
>
> Attachments: synapse_sample_250.xml
>
>
> The TRANSPORT_NON_BLOCKING property is set on the message contexts for incoming messages by ServerWorker#createMessageContext (NIO HTTP transport) and AbstractTransportListener#createMessageContext. When the message is sent out, Synapse copies this property over to the message context for the outgoing message. This in turn has an impact on the threading behavior when the message is sent: depending on the value of TRANSPORT_NON_BLOCKING, the <send> mediator (more precisely the OperationClient) will invoke the outgoing transport in a separate thread. It is not clear why the transport that handles the incoming request should determine the threading behavior of the transport that sends the outgoing request to the target service.
> See also http://markmail.org/message/6iuslkueny24po73
--
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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-527) Transports use
TRANSPORT_NON_BLOCKING in an incorrect way
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845307#action_12845307 ]
Amila Chinthaka Suriarachchi commented on SYNAPSE-527:
------------------------------------------------------
Has this issue solved by now?
Currently Axis2 sets TRANSPORT_NON_BLOCKING only at here.
//if we don't do this , this guy will wait till it gets HTTP 202 in the HTTP case
mc.setProperty(MessageContext.TRANSPORT_NON_BLOCKING, Boolean.TRUE);
mc.getConfigurationContext().registerOperationContext(mc.getMessageID(), oc);
in OutInAxisOperation which I believe don't get executed by synapse code.
> Transports use TRANSPORT_NON_BLOCKING in an incorrect way
> ---------------------------------------------------------
>
> Key: SYNAPSE-527
> URL: https://issues.apache.org/jira/browse/SYNAPSE-527
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Priority: Critical
> Fix For: 1.3
>
> Attachments: synapse_sample_250.xml
>
>
> The TRANSPORT_NON_BLOCKING property is set on the message contexts for incoming messages by ServerWorker#createMessageContext (NIO HTTP transport) and AbstractTransportListener#createMessageContext. When the message is sent out, Synapse copies this property over to the message context for the outgoing message. This in turn has an impact on the threading behavior when the message is sent: depending on the value of TRANSPORT_NON_BLOCKING, the <send> mediator (more precisely the OperationClient) will invoke the outgoing transport in a separate thread. It is not clear why the transport that handles the incoming request should determine the threading behavior of the transport that sends the outgoing request to the target service.
> See also http://markmail.org/message/6iuslkueny24po73
--
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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org