java.net.SocketTimeoutException: Read timed out

[Vino Adriano]

Hi,
I have an ISO8583 client build with pos, I created a request listener
on the mux of a channel that connected to a ISO 8583 server. The
process is the server send a 200 message to client request listener
and the client compute the message and then response it with
210.nEverything is running well if the precessing time is fast, but if
it goes slow (around 30-40 second), before the client response the
server with 210, I always get this error:

<log realm="request-listener" at="Wed May 26 14:41:43 WIT 2010.240">
<error>
java.net.SocketTimeoutException: Read timed out
</error>
</log>

This error makes the client not able to continue the process (there is
no response process after this error).

The problem is I don't know who did the timeout (the client or the
server), on the client configuration (the channel and the mux) there
is no timeout specified. So my suspicious is that the server did the
timeout which make the client not able to response, but I asked the
developer on the server side and they said that they do not have any
timeout (after server send 200 to client, server will wait unlimited
time until client response the 210), is this possible that the server
can wait unlimitted time?
Or is there any default timeout on my channel or mux configuration on
the client which did the timeout?

This is the configuration on the client:
- Channel
<channel-adaptor name="client-channel"
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
packager="org.jpos.iso.packager.GenericPackager">
<property name="packager-config" value="cfg/iso87ascii.xml" />
<property name="host" value="xxx.xxx.xxx.xxx" />
<property name="port" value="15000" />
</channel>
<in>client-send</in>
<out>client-receive</out>
<reconnect-delay>10000</reconnect-delay>
<keep-alive>true</keep-alive>
</channel-adaptor>

-MUX
<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-mux">
<in>client-receive</in>
<out>client-send</out>
<unhandled>client-unhandled</unhandled>
<request-listener class="com.jpos.listener.clientListener"
logger="Q2">
</request-listener>
</mux>

I really appreciate your help

[Mark Salter]

On 26/05/2010 10:17, Vino Adriano wrote:
> I have an ISO8583 client build with pos, I created a request listener
> on the mux of a channel that connected to a ISO 8583 server. The
> process is the server send a 200 message to client request listener
> and the client compute the message and then response it with
> 210.nEverything is running well if the precessing time is fast, but if
> it goes slow (around 30-40 second), before the client response the
> server with 210, I always get this error:
>
> <log realm="request-listener" at="Wed May 26 14:41:43 WIT 2010.240">
> <error>
> java.net.SocketTimeoutException: Read timed out
> </error>
> </log>

How long do you want to wait before giving up? I ask as I assume you
have a user/client waiting for your response. More than 30 seconds
sounds like a long time to wait, but I wondered what you acceptable wait
time was.

>
> This error makes the client not able to continue the process (there is
> no response process after this error).
>
> The problem is I don't know who did the timeout (the client or the
> server), on the client configuration (the channel and the mux) there
> is no timeout specified. So my suspicious is that the server did the
> timeout which make the client not able to response, but I asked the
> developer on the server side and they said that they do not have any
> timeout (after server send 200 to client, server will wait unlimited
> time until client response the 210), is this possible that the server
> can wait unlimitted time?
> Or is there any default timeout on my channel or mux configuration on
> the client which did the timeout?

Your operating system may be using a default value as you are not giving
one to the Channel to use. It's default time used may well be in the
order you observe.

What operating system are you running your setup on?

>
> This is the configuration on the client:
> - Channel
> <channel-adaptor name="client-channel"
> class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
> <channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
> packager="org.jpos.iso.packager.GenericPackager">
> <property name="packager-config" value="cfg/iso87ascii.xml" />
> <property name="host" value="xxx.xxx.xxx.xxx" />
> <property name="port" value="15000" />
> </channel>
> <in>client-send</in>
> <out>client-receive</out>
> <reconnect-delay>10000</reconnect-delay>
> <keep-alive>true</keep-alive>
> </channel-adaptor>
>

Channel has a timeout property that the guide tells us:-

"socketlevel timeout in millis. The channel is con-
sidered invalid if no messages are received after the
given timeout. Defaults to no timeout but it's strongly
recommended to set one."

Perhaps you could add a timeout value on your channel?

From your question, you appear to be happy to wait 'forever'. A value
of 0 looks a way to achieve this, but I would hope this is something you
could avoid - it seems unlikely to be what you need?

--
Mark

[Mark Salter]

On 26/05/2010 11:33, Mark Salter wrote:

> Perhaps you could add a timeout value on your channel?
>

Hmmm, the default value that will be use if a timeout property is not
given *is* 0, so now I am having to think.

There was discussion on this a while back, I wonder if a search will
give us anything?

--
Mark

[Vino Adriano]

Hi Mark, thank you very much for your fast response.
By reading your response I assume that in your opinion that the side
who did the timeout is on the client side?

On May 26, 5:33 pm, Mark Salter <marksal...@talktalk.net> wrote:
> How long do you want to wait before giving up?  I ask as I assume you
> have a user/client waiting for your response. More than 30 seconds
> sounds like a long time to wait, but I wondered what you acceptable wait
> time was.

The process on the client side sometimes takes up to 60 second, so the
server must at least wait for 60 second for the response.

>
> Your operating system may be using a default value as you are not giving
> one to the Channel to use.  It's default time used may well be in the
> order you observe.
>
> What operating system are you running your setup on?
>

The operating system of the Client side is Centos 5, I don't know the
os on the server side.

>
> Channel has a timeout property that the guide tells us:-
>
> "socketlevel timeout in millis.  The channel is con-
> sidered invalid if no messages are received after the
> given timeout.  Defaults to no timeout but it's strongly
> recommended to set one."
>
> Perhaps you could add a timeout value on your channel?

Can I do this to channel configuration so the channel will have 60
second timeout on socket level?

<channel-adaptor name="client-channel"
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
packager="org.jpos.iso.packager.GenericPackager">
<property name="packager-config" value="cfg/
iso87ascii.xml" />
<property name="host" value="xxx.xxx.xxx.xxx" />
<property name="port" value="15000" />
</channel>
<in>client-send</in>
<out>client-receive</out>
<reconnect-delay>10000</reconnect-delay>
<keep-alive>true</keep-alive>

<timeout>60000</timeout>
</channel-adaptor>

>
> From your question, you appear to be happy to wait 'forever'.  A value
> of 0 looks a way to achieve this, but I would hope this is something you
> could avoid - it seems unlikely to be what you need?

I only do the client side, but this client is also receive a request
(200) from server and then the client compute things. so the server is
the one who wait the response from me (client).

> --
> Mark

Thank you very much Mark, I really appreciate your help.

[Mark Salter]

On 26/05/2010 12:38, Vino Adriano wrote:
> Hi Mark, thank you very much for your fast response.
> By reading your response I assume that in your opinion that the side
> who did the timeout is on the client side?

I was happy to accept the detail you provided that the timeout was
happening on your side - your read (of the slow response) is timing out.

>
> On May 26, 5:33 pm, Mark Salter <marksal...@talktalk.net> wrote:
>> How long do you want to wait before giving up? I ask as I assume you
>> have a user/client waiting for your response. More than 30 seconds
>> sounds like a long time to wait, but I wondered what you acceptable wait
>> time was.
>
> The process on the client side sometimes takes up to 60 second, so the
> server must at least wait for 60 second for the response.

Wow that is a long time - just my view. Systems I work with strive for
60 millisecond response times (or less) 8).

<joke>
What are they doing that takes so long - phoning the account holder?
</joke>

Including the timeout as indicated below is hopefully going to help.
However, if 60 seconds is the observed peak duration, then perhaps a
timeout value of slightly more than 60000 is desirable.

>>
>> Channel has a timeout property that the guide tells us:-
>>
>> "socketlevel timeout in millis. The channel is con-
>> sidered invalid if no messages are received after the
>> given timeout. Defaults to no timeout but it's strongly
>> recommended to set one."
>>
>> Perhaps you could add a timeout value on your channel?
>
> Can I do this to channel configuration so the channel will have 60
> second timeout on socket level?
>
> <channel-adaptor name="client-channel"
> class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
> <channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
> packager="org.jpos.iso.packager.GenericPackager">
> <property name="packager-config" value="cfg/
> iso87ascii.xml" />
> <property name="host" value="xxx.xxx.xxx.xxx" />
> <property name="port" value="15000" />
> </channel>
> <in>client-send</in>
> <out>client-receive</out>
> <reconnect-delay>10000</reconnect-delay>
> <keep-alive>true</keep-alive>
> <timeout>60000</timeout>
> </channel-adaptor>
>

Not quite, the property is part of the channel, not the adaptor, so :-

<channel-adaptor name="client-channel"
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2">
<channel class="org.jpos.iso.channel.NACChannel" logger="Q2"
packager="org.jpos.iso.packager.GenericPackager">
<property name="packager-config"

value="cfg/iso87ascii.xml" />

<property name="host" value="xxx.xxx.xxx.xxx" />
<property name="port" value="15000" />

<property name="timeout" value="60000" />

</channel>
<in>client-send</in>
<out>client-receive</out>
<reconnect-delay>10000</reconnect-delay>
<keep-alive>true</keep-alive>

</channel-adaptor>

--
Mark

[Vino Adriano]

Ok... I will try adding the <timeout> property on the channel.

I agree with you that 60 second is very long time, but that is
necessary because this client app is a bridge between 2 iso8583
server, so after 1 server hit a request the client must forward the
message to another server. The average response time is 2-3 second
(still very long compared to your standard) but sometimes it can be
more than 30-40 second, that is why I put the timeout ot 60second.

Thank you very much Mark, I will back again with the result.

[Alejandro Revilla]

For the records, in order to add the timeout property, you need to place something like this:

 <property name="timeout" value="xxxxx" />

inside your <channel>....</channel> fragment.

I'd try a netstat and watch for the Send-Q and Recv-Q, you could get a timeout on the socket if the underlying network doesn't manage to deliver a packet (you'd see values greater than zero on your Send-Q).

I had dozens of discussions with the-other-end-guy claiming that they reply in say 1s, and that's probably true, but may be the former request reached the remote host 30 seconds later, or the response packet took 30 seconds to come back due to network congestion/retransmissions (that's the rule not the exception on some GPRS networks).

--
You received this message because you are subscribed to the  "jPOS Users" group.
Please see http://jpos.org/wiki/JPOS_Mailing_List_Readme_first
To post to this group, send email to jpos-...@googlegroups.com
To unsubscribe, send email to jpos-users+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jpos-users