Details

    • Similar Issues:
      MULE-1981Tcp synchronous and remoteSync problem
      MULE-6326TCP timeouts are not working
      MULE-1741Tcp Streaming Testcases failig after merge
      MULE-7144Differentiate TCP connection timeout from responseTimeout
      MULE-2519TCP Provider Problem When High Concurrent
      MULE-2563TCP Provider Problem When High Concurrent
      MULE-6539Provide a way to disable transport timeouts so a debugging session is not interrupted
      MULE-2799Problems with ACEGI config
      MULE-1807Tcp endpoint does not start under Spring
      MULE-112Tcp connector not closing all threads when disposing

      Description

      Hello,

      We're trying to use MuleClient to send a synchronous request to a tcp endpoint. We initialize mule client with a config file like this;

      <connector name="tcpConnector"
      className="org.mule.providers.tcp.TcpConnector">
      <properties>
      <property name="timeout" value="60000" />
      <property name="tcpProtocolClassName"
      value="org.mule.providers.tcp.protocols.LengthProtocol"
      />
      </properties>
      </connector>
      <model name="client"/>

      And the server like this;

      <connector name="tcpConnector"
      className="org.mule.providers.tcp.TcpConnector">
      <properties>
      <property name="timeout" value="60000" />
      <property name="tcpProtocolClassName"
      value="org.mule.providers.tcp.protocols.LengthProtocol"
      />
      </properties>
      </connector>

      <model name="TestServer">
      <mule-descriptor name="TestServiceUMO"
      implementation="TestReceiver">
      <inbound-router>
      <endpoint synchronous="true" remoteSync="true"
      remoteSyncTimeout="60000"
      address="tcp://localhost:9000"
      transformers="BytesToString" />
      <interceptor className="default" />
      </mule-descriptor>
      </model>

      No matter what we specify for any of the timeout values. The client allways times out after 10 seconds. I have traced through the code and it appears that the 60 second timeout specified on the connector is being set properly. However when TcpMessageDispatcher executes the following

      byte[] result = receive(socket,
      event.getEndpoint().getRemoteSyncTimeout());
      (around Line 115)

      The MuleEndpoint.getRemoteSyncTimeout() is always returning 10000.

      I've also noticed that useRemoteSync() for TcpMessageDispatcher appears to always be enabled.

      Can someone have a look?

      Thanks for your help.

      Mark

        Issue Links

          Activity

          Hide
          Ross Mason added a comment -

          Hi Mark,

          I can see the the problem. Have tried specifying the time out on your client call, i.e.

          ... client.send("tcp://localhost:1234", "data", null, 60000);

          That should work.
          Also, the useRemoteSync is always set to true when making 'send' calls from the client, otherwise you wouldn't get a response back from the TcpMessageDispatcher.

          Cheers,
          Ross

          Show
          Ross Mason added a comment - Hi Mark, I can see the the problem. Have tried specifying the time out on your client call, i.e. ... client.send("tcp://localhost:1234", "data", null, 60000); That should work. Also, the useRemoteSync is always set to true when making 'send' calls from the client, otherwise you wouldn't get a response back from the TcpMessageDispatcher. Cheers, Ross
          Hide
          Mark Koch added a comment -

          Hi Ross,

          Thanks for having a look.

          I've tried setting the timeout using the method arg to MuleCliend.send(). However, this doesn't have an affect. I don;t believe getRemoteSyncTimeout() ( which is always called ) has any notion of the timeout being passed via the send() call.

          Unless I'm out of date, I believe this means that for the current nightly build all TCP endpoints will always have the DEFAULT_TIMEOUT of 10000 ms.

          Mark

          Show
          Mark Koch added a comment - Hi Ross, Thanks for having a look. I've tried setting the timeout using the method arg to MuleCliend.send(). However, this doesn't have an affect. I don;t believe getRemoteSyncTimeout() ( which is always called ) has any notion of the timeout being passed via the send() call. Unless I'm out of date, I believe this means that for the current nightly build all TCP endpoints will always have the DEFAULT_TIMEOUT of 10000 ms. Mark
          Hide
          Mark Koch added a comment -

          This has been for a while. There must not be many users using tcp sych. I've hacked a solution to 1.1 but would like to move to 1.2/1.3. Can you take another look at this issue?

          Show
          Mark Koch added a comment - This has been for a while. There must not be many users using tcp sych. I've hacked a solution to 1.1 but would like to move to 1.2/1.3. Can you take another look at this issue?
          Hide
          Mark Koch added a comment -

          Hi Ross,

          Hi Ross,

          I'm finally up and running on 1.3-SNAPSHOT. The TCP timeout fix you made appears to be functional, server returns expected results. However, I'm seeing a strange exception in the log. About 60 seconds after any synchronous TCP request is processed, I see the following in the server log;

          21 Feb 2006 16:56:25,408 ERROR org.mule.impl.DefaultExceptionStrategy 233 - Caught exception in Exception Strategy: Read timed out
          java.net.SocketTimeoutException: Read timed out
          at java.net.SocketInputStream.socketRead0(Native Method)
          at java.net.SocketInputStream.read(SocketInputStream.java:129)
          at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
          at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
          at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
          at java.io.DataInputStream.read(DataInputStream.java:224)
          at java.io.DataInputStream.read(DataInputStream.java:170)
          at org.mule.providers.tcp.protocols.LengthProtocol.read(LengthProtocol.java:49)
          at org.mule.providers.tcp.TcpMessageReceiver$TcpWorker.run(TcpMessageReceiver.java:230)
          at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
          at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:643)
          at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:668)
          at java.lang.Thread.run(Thread.java:534)

          As you can see from the stack, I'm using the Length protocol. Here's my basic UMO config;

          <mule-descriptor name="ConfigServiceUMO" implementation="configController">
          <inbound-router>
          <endpoint synchronous="true" address="$

          {ew.esb.service.config.queue.tcp}

          " transformers="BytesToString XmlToObject" responseTransformers="ObjectToXml"></endpoint>
          </inbound-router>
          <interceptor className="default" />
          </mule-descriptor>

          I've played around with setting the remoteSync params ( I admit, I have no idea what they're for ) but this appears to have no effect. Is there something I'm missing that would cause the server to continue reading from the TCP socket?

          Thanks,
          Mark

          Show
          Mark Koch added a comment - Hi Ross, Hi Ross, I'm finally up and running on 1.3-SNAPSHOT. The TCP timeout fix you made appears to be functional, server returns expected results. However, I'm seeing a strange exception in the log. About 60 seconds after any synchronous TCP request is processed, I see the following in the server log; 21 Feb 2006 16:56:25,408 ERROR org.mule.impl.DefaultExceptionStrategy 233 - Caught exception in Exception Strategy: Read timed out java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at java.io.BufferedInputStream.read1(BufferedInputStream.java:222) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) at java.io.DataInputStream.read(DataInputStream.java:224) at java.io.DataInputStream.read(DataInputStream.java:170) at org.mule.providers.tcp.protocols.LengthProtocol.read(LengthProtocol.java:49) at org.mule.providers.tcp.TcpMessageReceiver$TcpWorker.run(TcpMessageReceiver.java:230) at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:643) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:668) at java.lang.Thread.run(Thread.java:534) As you can see from the stack, I'm using the Length protocol. Here's my basic UMO config; <mule-descriptor name="ConfigServiceUMO" implementation="configController"> <inbound-router> <endpoint synchronous="true" address="$ {ew.esb.service.config.queue.tcp} " transformers="BytesToString XmlToObject" responseTransformers="ObjectToXml"></endpoint> </inbound-router> <interceptor className="default" /> </mule-descriptor> I've played around with setting the remoteSync params ( I admit, I have no idea what they're for ) but this appears to have no effect. Is there something I'm missing that would cause the server to continue reading from the TCP socket? Thanks, Mark
          Hide
          Ross Mason added a comment -

          Hi Mark, Is this issue still open for you?

          Show
          Ross Mason added a comment - Hi Mark, Is this issue still open for you?
          Hide
          Holger Hoffstaette added a comment -

          Most likely caused by a bug related to socket state management.

          Show
          Holger Hoffstaette added a comment - Most likely caused by a bug related to socket state management.

            People

            • Assignee:
              Holger Hoffstaette
              Reporter:
              Mark Koch
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development