sql server - Timeout when connecting through a TCP-Connector -

i route traffic through mule mssql database. database runs on url "internalserverurl" on port 1433.

mule shall act tcp-server/proxy , re-route incoming tcp traffic on 1433 address @ "internalserverurl" on port 1433, handle response , return back.

example code:

<?xml version="1.0" encoding="utf-8"?>  <mule xmlns:tcp="http://www.mulesoft.org/schema/mule/tcp" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="ce-3.3.1" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation=" http://www.mulesoft.org/schema/mule/tcp http://www.mulesoft.org/schema/mule/tcp/current/mule-tcp.xsd  http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd  http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd ">     <tcp:connector name="tcp_c_l" validateconnections="false" receivebuffersize="102400" sendbuffersize="102400" doc:name="tcp connector">     <tcp:streaming-protocol/>     </tcp:connector>     <tcp:connector name="tcp_c_81" validateconnections="false" receivebuffersize="102400" sendbuffersize="102400" doc:name="tcp connector">     <tcp:streaming-protocol/>     </tcp:connector>     <flow name="incomingendpoint" doc:name="incomingendpoint">         <tcp:inbound-endpoint exchange-pattern="request-response" responsetimeout="10000" doc:name="tcp-proxy" host="localhost" port="1433" connector-ref="tcp_c_l" />         <tcp:outbound-endpoint exchange-pattern="request-response" host="internalserverurl" port="1433" responsetimeout="10000" doc:name="tcp" connector-ref="tcp_c_81" />     </flow> </mule> 

if run code mule application starts fine, can connect via jdbc port 1433 thorugh localhost. db connection not successful. mule throw socket exception:

exception stack is: 1. socket closed (java.net.socketexception)   java.net.socket:864 (null) 2. failed route event via endpoint: defaultoutboundendpoint{endpointuri=tcp://internalserverurl:1433, connector=tcpconnector {   name=tcp_c_81   lifecycle=start   this=7ffba3f9   numberofconcurrenttransactedreceivers=4   createmultipletransactedreceivers=true   connected=true   supportedprotocols=[tcp]   serviceoverrides=<none> } ,  name='endpoint.tcp.internalserverurl.1433', mep=request_response, properties={}, transactionconfig=transaction{factory=null, action=indifferent, timeout=0}, deleteunacceptedmessages=false, initialstate=started, responsetimeout=10000, endpointencoding=utf-8, disabletransporttransformer=false}. message payload of type: tcpmessagereceiver$tcpworker$1 (org.mule.api.transport.dispatchexception)   org.mule.transport.abstractmessagedispatcher:109 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/transport/dispatchexception.html) 

why there socket timeout ? when jdbc connection directly (from same machine runs mule application) connection fine.

if use

<tcp:direct-protocol payloadonly="true"/> 

instead of

<tcp:streaming-protocol/> 

then can see tcp packet incoming on mssql server, sql server log message like: 08/18/2014 12:16:41,logon,unknown,the login packet used open connection structurally invalid; connection has been closed. please contact vendor of client library. [client: 10.2.60.169] 08/18/2014 12:16:41,logon,unknown,error: 17832 severity: 20 state: 2.

thanks, sebastian

take @ tcp connector protocol table: http://www.mulesoft.org/documentation/display/current/tcp+transport+reference#tcptransportreference-protocoltables

the streaming-protocol has read property:

all bytes sent until socket closed

if client doesn't disconnect, mule keep reading ever protocol.

keep in mind mule message-oriented middleware: if want tcp bridge work, need use protocol compatible mssql protocol.

this means protocol must recognize whatever character or sequence of characters used sql client mark end of request, mule can cut message out of bytes received far route down flow.

it's possible none of provided protocols allow this, meaning have create own protocol...