synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiranya Jayathilaka (JIRA)" <>
Subject [jira] Commented: (SYNAPSE-527) Transports use TRANSPORT_NON_BLOCKING in an incorrect way
Date Thu, 25 Nov 2010 23:11:14 GMT


Hiranya Jayathilaka commented on SYNAPSE-527:

I have run into this issue recently. So I don't think it's resolved. In fact with SwiftMQ
the error can be reproduced without even preloading the JMS queue. But in any case we can
workaround the issue by removing the property from the message using the property mediator.

> Transports use TRANSPORT_NON_BLOCKING in an incorrect way
> ---------------------------------------------------------
>                 Key: SYNAPSE-527
>                 URL:
>             Project: Synapse
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 1.2
>            Reporter: Andreas Veithen
>            Assignee: Andreas Veithen
>            Priority: Critical
>             Fix For: 2.0
>         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

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:
For additional commands, e-mail:

View raw message