TCP Timeout Config Problem

Details

  • Similar Issues:
    None

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

relates to

Bug - A problem which impairs or prevents the functions of the product. MULE-645 MuleClient.send doesn´t respect the specified timeout

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: