Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / February 2007

Tip: Looking for answers? Try searching our database.

PrintWriter & Sockets

Thread view: 
rajatag - 07 Feb 2007 12:28 GMT
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 - 07 Feb 2007 13:06 GMT
> 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

Signature

[ don't email me support questions or followups ]
g o r d o n  +  n e w s  @  b a l d e r 1 3 . s e

rajatag - 07 Feb 2007 13:22 GMT
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 - 07 Feb 2007 13:35 GMT
> 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

Signature

[ don't email me support questions or followups ]
g o r d o n  +  n e w s  @  b a l d e r 1 3 . s e

Thomas Fritsch - 07 Feb 2007 14:17 GMT
> 1. I am connecting to a server as follows:
> =======
[quoted text clipped - 11 lines]
>       // 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");
>       System.out.println(req);
>     } catch (Exception e) {
[quoted text clipped - 9 lines]
> EVEN THOUGH it does appear in the System.out.println() line just after
> the output.println() line.

Signature

Thomas

rajatag - 08 Feb 2007 06:44 GMT
On Feb 7, 7:17 pm, Thomas Fritsch <i.dont.like.s...@invalid.com>
wrote:
> 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 - 08 Feb 2007 15:20 GMT
>On Feb 7, 7:17 pm, Thomas Fritsch <i.dont.like.s...@invalid.com>
>wrote:
>> 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");

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.

>Thanks for your support!
>
>Regards,
>Rajat
Esmond Pitt - 09 Feb 2007 00:09 GMT
> 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.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.