P4
FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
windows 2000
EXTRA RELEVANT SYSTEM CONFIGURATION :
A DESCRIPTION OF THE PROBLEM :
The core symptom was a tomcat serverlet to implement file upload, which failed intermittantly with various low level errors, such as "arrayIndexOutofBounds" and "streamcorrupted" in the bowels of the TCP buffering code.
The serverlet was being fed by a process which carefully interleaved output to ObjectOutputStream / flush / raw write to underlying stream, with corresponding careful interleaving of reads in the receiving process.
Switching the I/O to all go through the ObjectOutputSteam/ObjectInputStream fixed the problem.
It's not obvious that this should be considered a bug in java - but it is obvious that even if this is supposed to work, it would have to be done very carefully - not a robust coding style.
So my request is, either treat it as a bug in java and make it work, or treat is as a bug in the client program, and make it illegal. It could be made illegal, for example, buy detecting and forbidding i/o to a low level stream once i/o has been done using a layered steam and vice-versa.
In it's present state, user programs are buggy in very subtle ways that are practically impossible to diagonse.
I can, if desired, supply the actual sender and receiver code "before"
and "after", but it would be fairly difficult to construct a simple test case
for you.
My working hypothesis is that both of the nested stream structures have optimizations/shortcuts to get to the actual data stream coming from TCP, and that under the right circumstances, these shortcuts are tripping up.
My thought is that even if this technique worked, alternating I/O from a stream and another stream that encapsulates it would be very easy to do incorrectly.
I would be perfectly happy with an ENFORCED restriction, that after you have built an encapsulation of a stream, you are no longer allowed to do operate directly on the underlying stream. This would be very easy to implement, and would result in more reliable program
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Easy to reproduce when tomcat was concurrently serving two clients, even though theoretically there was no interaction between the clients. Set tomcat running the serverlet in the "andromeda" folder.
open the html page which presents an upload applet. Select a batch of 20 images or so. Open another browser window and do likewise. Start both applets uploading simultaneously.
If you run the applets one at a time, no errors should occur. If you run the "good" version of the serverlet, instead of the
"bad" version, no errors should occur.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
"ArrayIndexOutOfBounds"
"StreamCorrupted"
REPRODUCIBILITY :
This bug can be reproduced often.
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
windows 2000
EXTRA RELEVANT SYSTEM CONFIGURATION :
A DESCRIPTION OF THE PROBLEM :
The core symptom was a tomcat serverlet to implement file upload, which failed intermittantly with various low level errors, such as "arrayIndexOutofBounds" and "streamcorrupted" in the bowels of the TCP buffering code.
The serverlet was being fed by a process which carefully interleaved output to ObjectOutputStream / flush / raw write to underlying stream, with corresponding careful interleaving of reads in the receiving process.
Switching the I/O to all go through the ObjectOutputSteam/ObjectInputStream fixed the problem.
It's not obvious that this should be considered a bug in java - but it is obvious that even if this is supposed to work, it would have to be done very carefully - not a robust coding style.
So my request is, either treat it as a bug in java and make it work, or treat is as a bug in the client program, and make it illegal. It could be made illegal, for example, buy detecting and forbidding i/o to a low level stream once i/o has been done using a layered steam and vice-versa.
In it's present state, user programs are buggy in very subtle ways that are practically impossible to diagonse.
I can, if desired, supply the actual sender and receiver code "before"
and "after", but it would be fairly difficult to construct a simple test case
for you.
My working hypothesis is that both of the nested stream structures have optimizations/shortcuts to get to the actual data stream coming from TCP, and that under the right circumstances, these shortcuts are tripping up.
My thought is that even if this technique worked, alternating I/O from a stream and another stream that encapsulates it would be very easy to do incorrectly.
I would be perfectly happy with an ENFORCED restriction, that after you have built an encapsulation of a stream, you are no longer allowed to do operate directly on the underlying stream. This would be very easy to implement, and would result in more reliable program
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Easy to reproduce when tomcat was concurrently serving two clients, even though theoretically there was no interaction between the clients. Set tomcat running the serverlet in the "andromeda" folder.
open the html page which presents an upload applet. Select a batch of 20 images or so. Open another browser window and do likewise. Start both applets uploading simultaneously.
If you run the applets one at a time, no errors should occur. If you run the "good" version of the serverlet, instead of the
"bad" version, no errors should occur.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
"ArrayIndexOutOfBounds"
"StreamCorrupted"
REPRODUCIBILITY :
This bug can be reproduced often.