PrintWriter & Sockets

[rajatag]

Hi,

Here's a strange problem I'm facing:

1. I am connecting to a server as follows:
=======
Socket socket = null;
PrintWriter output;
socket = new Socket(server, port);
output = new PrintWriter(socket.getOutputStream(), true);
=======

2. To write data to the socket, I use the following:
=======
public boolean SendRequest(String req) {
try {
output.println(req);
// auto flush is already enabled when creating
PrintWriter so not required here.
System.out.println(req);
} catch (Exception e) {
e.printStackTrace();
return false;
}
return true;
}
=======

I am writing data to the socket at regular intervals of 15 minutes.
After sometime, the data does not get written to the socket any more
EVEN THOUGH it does appear in the System.out.println() line just after
the output.println() line.

It's a very odd problem and hope someone can help me through with
this.

Thanks!
Rajat

 

[Gordon Beaton]

I am writing data to the socket at regular intervals of 15 minutes.
After sometime, the data does not get written to the socket any more
EVEN THOUGH it does appear in the System.out.println() line just
after the output.println() line.

How did you determine that the data does not get written to the
Socket?

What does the corresponding server code look like?

/gordon

 

[rajatag]

If the data gets written to the server, then the server would react to
it, but it does not do anything.

The server side is a non-blocking implementation however, the code is
really large. Which portion should I paste? I doubt there is a problem
on the server as it operates normally with over a hundred clients at
the same time.

Regards,

 

[Gordon Beaton]

If the data gets written to the server, then the server would react
to it, but it does not do anything.

The server's failure to react only indicates that it failed to react.
It could be due to an error at the server itself, at the client, or
somewhere in between. Taken by itself, there is nothing that stands
out in the code you posted.

The server side is a non-blocking implementation however, the code
is really large. Which portion should I paste? I doubt there is a
problem on the server as it operates normally with over a hundred
clients at the same time.

Do you mean that none of the other clients have this problem?

Is this client somehow different from the others?

I strongly suggest that you use a tool like Wireshark (previously
Ethereal) to monitor the actual network traffic generated by the
failing client. This will give you a much better idea of where the
problem might be occurring.

/gordon

 

[Thomas Fritsch]

1. I am connecting to a server as follows:
=======
Socket socket = null;
PrintWriter output;
socket = new Socket(server, port);
output = new PrintWriter(socket.getOutputStream(), true);
=======

2. To write data to the socket, I use the following:
=======
public boolean SendRequest(String req) {
try {
output.println(req);
// auto flush is already enabled when creating
// PrintWriter so not required here.

Quoted from the API doc of PrintWriter:
Methods in this class never throw I/O exceptions.
The client may inquire as to whether any errors have
occurred by invoking checkError().
Hence, the fact, that your catch clause below is never called, doesn't
necessarily mean that the data was successfully sent.
Therefore I strongly recommend to insert something like this:
if (output.checkError())
throw new IOException("something bad happened");

 

[rajatag]

necessarily mean that the data was successfully sent.
Therefore I strongly recommend to insert something like this:
if (output.checkError())
throw new IOException("something bad happened");

The above helped solve the problem. The timer was causing some issues
with the socket and we were able to determine the same using
output.checkError();

Thanks for your support!

Regards,
Rajat

 

[nukleus]

I wouldn't even throw IOException
because there could be NUMEROUS conditions,
such as unable to open files, can not connect,
lost connection, stream lost, file does not exist,
file has wrong access permisions, etc.

All of these are COMPLETELY different conditions
and need to be handled in the most appropriate place
with fine enough granularity for the entire app to
be able to handle and recover from ANY condition
imaginable.

Instead, you create ConnectionLostException, extending
SocketException, where you handle several types of
those kinds of errors.

Or, InalidParameter exception, or FileNotFoundException,
or ServerDeniedAccessException, or AuthorizationRequiredException
and things like that.

In this case, you should be able to handle just about
any error condition imaginable and recover from it
in the most graceful manner instead of restarting the
whole thing from top or requiring user to reboot.

:--}

The above helped solve the problem. The timer was causing some issues
with the socket and we were able to determine the same using
output.checkError();

Just use TimeOutException and try to retry to reconnect
and redo it on the LOWEST level possible instead of letting
the higher levels handle that exception, in which case,
they'd have to retry the whole operation from the top.

I am handling this exact error condition just perfectly
to the point where you can unplug the network cable
and it stays on the lowest possible level retrying it.

Works like a champ. You can not possibly do it better.
Not possible, even in principle.

 

[Esmond Pitt]

I wouldn't even throw IOException

The problem is that PrintWriter won't tell you what the actual exception
was, except that by definition of the methods implemented it must have
been an IOException or a subclass.

Really you shouldn't use PrintWriter or PrintStream over the network at
all, you're just asking for untraceable trouble.