You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Bryan Buchanan <br...@webbtide.com> on 2015/12/05 20:55:25 UTC

Socket Timeout

I have JavaFX app that is behaving differently on computers in my office
and at a customer site.

I've created a simple test app which has a TextField and a Button.

When the app starts, I do:

Transport transport = new TSocket(host, port);
TProtocol protocol = new TBinaryProtocol(transport);
TestApplication.Client client = new TestApplication.Client(protocol);

The app just sits there waiting for you to enter some text. When you click
the button, an RPC call is made to a remote server which reverses the
string, sends it back and it's re-displayed in the text field.

In my office, I can leave this app running all day, enter some text, click
the button, it calls the server and all is well. At the customer site,
using exactly the same version of Linux and JDK and the same remote server,
if you leave the app running for about 1/2 an hour then enter some text and
click the button, one of two things happen.

1. it aborts with a Connection timed out error:

Caused by: java.net.SocketException: Connection timed out
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
    at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
    at
org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:159)

which is fine, although I don't know why (and it's what I'm trying to track
down).

or

2. the app just hangs. When you click the button, the app freezes. In the
TestApplication.Client class the last thing I see is the message "in
reverse" below:

  public String reverse(String message) throws BJBException,
org.apache.thrift.TException
    {
      System.err.println("in reverse");
      send_reverse(message);
      System.err.println("sent message, wait for reply");
      return recv_reverse();
    }

then after a bit, the Linux Window Manager pops up and says the app is
unresponsive and do you want to kill it. It's obviously in some tight loop
somewhere in the code in libthrift-0.9.3.jar.

I'm going to create a simple "C" language client to see if the same
behaviour occurs, but I'm wondering if anyone has any hints at what I
should be looking for or changing ?

Thanks.

Re: Socket Timeout

Posted by Matt Chambers <mv...@me.com>.
I always put an auto reconnecting / load balancing wrapper around the service. 


Sent from my iPhone

> On Dec 5, 2015, at 14:55, Bryan Buchanan <br...@webbtide.com> wrote:
> 
> I have JavaFX app that is behaving differently on computers in my office
> and at a customer site.
> 
> I've created a simple test app which has a TextField and a Button.
> 
> When the app starts, I do:
> 
> Transport transport = new TSocket(host, port);
> TProtocol protocol = new TBinaryProtocol(transport);
> TestApplication.Client client = new TestApplication.Client(protocol);
> 
> The app just sits there waiting for you to enter some text. When you click
> the button, an RPC call is made to a remote server which reverses the
> string, sends it back and it's re-displayed in the text field.
> 
> In my office, I can leave this app running all day, enter some text, click
> the button, it calls the server and all is well. At the customer site,
> using exactly the same version of Linux and JDK and the same remote server,
> if you leave the app running for about 1/2 an hour then enter some text and
> click the button, one of two things happen.
> 
> 1. it aborts with a Connection timed out error:
> 
> Caused by: java.net.SocketException: Connection timed out
>    at java.net.SocketOutputStream.socketWrite0(Native Method)
>    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
>    at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
>    at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>    at
> org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:159)
> 
> which is fine, although I don't know why (and it's what I'm trying to track
> down).
> 
> or
> 
> 2. the app just hangs. When you click the button, the app freezes. In the
> TestApplication.Client class the last thing I see is the message "in
> reverse" below:
> 
>  public String reverse(String message) throws BJBException,
> org.apache.thrift.TException
>    {
>      System.err.println("in reverse");
>      send_reverse(message);
>      System.err.println("sent message, wait for reply");
>      return recv_reverse();
>    }
> 
> then after a bit, the Linux Window Manager pops up and says the app is
> unresponsive and do you want to kill it. It's obviously in some tight loop
> somewhere in the code in libthrift-0.9.3.jar.
> 
> I'm going to create a simple "C" language client to see if the same
> behaviour occurs, but I'm wondering if anyone has any hints at what I
> should be looking for or changing ?
> 
> Thanks.

Re: Socket Timeout

Posted by BCG <bg...@hushmail.com>.
On 12/05/2015 02:55 PM, Bryan Buchanan wrote:
> I have JavaFX app that is behaving differently on computers in my office
> and at a customer site.
>
> I've created a simple test app which has a TextField and a Button.
>
> When the app starts, I do:
>
> Transport transport = new TSocket(host, port);
> TProtocol protocol = new TBinaryProtocol(transport);
> TestApplication.Client client = new TestApplication.Client(protocol);
>
> The app just sits there waiting for you to enter some text. When you click
> the button, an RPC call is made to a remote server which reverses the
> string, sends it back and it's re-displayed in the text field.
>
> In my office, I can leave this app running all day, enter some text, click
> the button, it calls the server and all is well. At the customer site,
> using exactly the same version of Linux and JDK and the same remote server,
> if you leave the app running for about 1/2 an hour then enter some text and
> click the button, one of two things happen.
>
> 1. it aborts with a Connection timed out error:
>
> Caused by: java.net.SocketException: Connection timed out
>      at java.net.SocketOutputStream.socketWrite0(Native Method)
>      at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
>      at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
>      at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
>      at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
>      at
> org.apache.thrift.transport.TIOStreamTransport.flush(TIOStreamTransport.java:159)
>
> which is fine, although I don't know why (and it's what I'm trying to track
> down).
>
> or
>
> 2. the app just hangs. When you click the button, the app freezes. In the
> TestApplication.Client class the last thing I see is the message "in
> reverse" below:
>
>    public String reverse(String message) throws BJBException,
> org.apache.thrift.TException
>      {
>        System.err.println("in reverse");
>        send_reverse(message);
>        System.err.println("sent message, wait for reply");
>        return recv_reverse();
>      }
>
> then after a bit, the Linux Window Manager pops up and says the app is
> unresponsive and do you want to kill it. It's obviously in some tight loop
> somewhere in the code in libthrift-0.9.3.jar.
>
> I'm going to create a simple "C" language client to see if the same
> behaviour occurs, but I'm wondering if anyone has any hints at what I
> should be looking for or changing ?
>
> Thanks.
>
I wonder if it could just be something that your customer has set up in 
their network infrastructure... you might want to try tunneling the 
connection using SSH with keep-alive or something like that to see if it 
makes the problem go away.  It might not be a permanent solution but at 
least it is something you could try quickly that might isolate the root 
cause.

Hope that helps

Ben