Output Stream will not write unless in debug mode
Hey all,
I'm debugging a client application I have just written. Basically, my client is a communication agent that translates data from one connection into a format recognized by another connection and vice/versa.
I have an OutputStream defined the following way:
private OutputStream __Output;
It's instantiated with this line of code (where __Connection is a socket already instantiated properly):
__Output = __Connection.getOutputStream();
And then I try to write to it this way:
__Output.write(_response.getBytes());
Here's the funny thing, this call to write works if I'm using debug mode of the IDE, using the IDE's debugger and I have a breakpoint on the line and then hit F8 to step over. If I'm in debug mode and just decide to continue after I've investigated what I need to, it seems the write method is just ignored. Similarly, if I run the project from the IDE it will not work.
Has anyone experienced this problem before? Does anyone have any insight into what is occurring?
Thanks,
Josh
# 1
If a program works in debug mode but not otherwise, the following IMHO could be one reason:
In debug mode there will be a time lag between operations (especially when an operation is suspended on a breakpoint). Perhaps a sleep is required to wait for an operation to complete at runtime, which becomes available during debug without asking for it.
To debug an application that runs fine in debug mode, you may want to fall back on System.out.println statements scattered through the code to track the problem, instead of the debugger.
Can u try replacing "__Output.write(_response.getBytes());" with
try
{
__Output.write(_response.getBytes());
}
catch (Throwable e)
{
e.printStackTrace() ;
}
to see if there are any messages?
# 2
Hi KarthikR,
I do have the code within a try catch, I just didn't show it in the code sample provided. I just noticed something even stranger. If I monitor the application my client is writing to, the connection just goes offline. It appears to go offline right before the write call. If I breakpoint on the write line and step over it, it does not go offline and the message is sent and received properly.
I will admit I'm a .NET and a VB6 developer. I'm stuck on a Java project and I can program in Java, but I'm not well versed on its guts. Do you have any more suggestions?
Thanks,
Josh
# 3
Sorry, I forgot to say I added the print trace in the catch and the code never hits the catch block.Josh
# 4
Is it possible to post a more complete code snippet?
# 5
Sure..The WriteErrorToConn method is a member of object WorkerThread. Class WorkerThread extends class Thread. I'm using the new java.util.concurrent stuff to do threading. I'm using a FixedThreadPool of size 25. When a ServerSocket object accepts a connection, I construct WorkerThread with the Socket object and then pass it to the Thread Pool through the execute method.
private void WriteErrorToConn()
{
char _terminator[] = new char[1]; //message terminator char array
_terminator[0] = 4;//message terminator value
String _terminatorAsString = new String(_terminator); //terminator as a string value
String _error = IConstants.ERROR_TO_CONN + _terminatorAsString;
try
{
__Output.write(_error.getBytes());
}
catch (Throwable e)
{
e.printStackTrace();
}
}
Here's how I define the OutputStream object:
[/code]
private OutputStream __Output;
Here's how I get the OutputStream object, it's done during construction:
[code]
__Output = __Connection.getOutputStream();
__Connection object is passed in as a parameter when constructing Object WorkerThread and is retrieved when a ServerSocket accepts a connection.
Thanks,
Josh
# 6
Can u try explicitly calling flush? _output.write(...) ;_output.flush() ;
# 7
Yeah I did that earlier today. I now call flush( ) after a get the OutputStream from the Socket object and after I invoke the write method. Still no luck.
I created another project and it works from the IDE. I'm stumped. I took the code from this project and only kept the comms stuff, pretty much a passthrough client, and it works. So I figured I would see what happens if I run the application explicitly through javaw and I must be a moron because I keep getting that my Main.class is not found eventhough the Main.class path is in my classpath system variable.
I don't understand what is going on. My brain is starting to spin now.
Josh
# 8
I got it to work, but I have no clue how it did. Let me rephrase, I know what I added that made it work, but as far as the intricacies of Java, I don't know why this change allowed it to work.
I had to place all explicit and implicit calls to __Output.write(...) in the following try, catch block:
try {
} catch (InterruptedIOException _ieexc)
{
...
}
I'm really confused because this logic was enclosed with a catch for a General Exception, which means if a timeout would have occurred it would have been caught there. Why this specific exception must be caught to allow the message to write without stepping over the line of code in debug mode, has to be a bug with Java version 5. Should I try to reproduce this in a new project and report the problem to Sun or not?
Josh
# 9
If catching a higher-level exception results in a different behaviour than catching a lower-level exception, it is indeed strange. It would be a nice idea to distill this into a simple test program and file a bug with java folks to see if it is indeed a bug in jdk5...
btw, pl. ref:
http://java.sun.com/developer/technicalArticles/Networking/timeouts/index.html
# 10
I've lied. It's doing it again. Even with the exception in there. It started around 1pm today and no changes were made to the code. I'm just running through unit tests and sure enough, it blew up.
I'm wondering if it is a timing issue. I've tried adding a sleep(1000) but that didn't seem to help.
Is this problem something new to you?
J.
# 11
I myself have not come across this issue before; also, since this seems to be a jdk related issue, you may want to post this question on java forums (say, http://forum.java.sun.com/forum.jspa?forumID=31)...
btw, have you tried out the following, just to eliminate these possibilities:
- 'System.out.println(_error.getBytes())' to see if _error actually has something...
- get the stream '__Output = __Connection.getOutputStream();' just prior to writing instead of the in the constructor, to make sure the connection and the outputstream are valid at the time being used...
# 12
Yeah I tried both of those. I even tried storing to a byte array before calling out and ensuring everything was in there.
I think I have figured out the problem and does involve the threading. I think the thread is terminated before the message is written. I put a sleep(10000) in between the write and the flush and it worked. I'm gonna dabble with it some more.
Thanks for your help!
Josh
