Link to home
Create AccountLog in
Avatar of jjacksn
jjacksn

asked on

Error retrieving stream from servlet: java.io.IOException: missing CR

i'm trying to get back a byte[] array from a servlet and getting an error.  the byte array is being written to a stream in the doPost method via this:

      MultipartRequest multiRequest = createMultiRequest(request);
      
            String accountID = getParameterFromMultipart(multiRequest, "accountID");
            String recordUID = getParameterFromMultipart(multiRequest, "recordUID");
            
            response.setContentType("application/x-download");
            response.setHeader("Content-Disposition", "attachment; filename=" + recordUID + ".data");
            
            BufferedOutputStream out = new BufferedOutputStream(response.getOutputStream());
                  
            try
            {
                  byte[] bytes = //do stuff here to get the bytes
                  out.write(bytes);
                  out.close();
            }

and then these bytes are being read back in here:


ByteArrayOutputStream bais = new ByteArrayOutputStream(chunkSize);

            int bytesRead = 0;
            bytesRead = stream.read(byteBuffer);

            while (bytesRead != -1) {
                  bais.write(byteBuffer, 0, bytesRead);
                  bytesRead = stream.read(byteBuffer);
            }
            byte[] readRecordBytes = bais.toByteArray();
            bais.close();

where the stream is retrieve from

BufferedInputStream stream = new BufferedInputStream(
                              retrieveRequest.post());

At some pont in the loop of reading teh bytes, stream.read(byteBuffer) throws an error:  java.io.IOException: missing CR.  Am I not allowed to just write bytes to the stream the way I am on the servlet?
Avatar of Mick Barry
Mick Barry
Flag of Australia image

wrong way round

               while (-1!=(bytesRead = stream.read(byteBuffer))) {
                  bais.write(byteBuffer, 0, bytesRead);
               }
Avatar of jjacksn
jjacksn

ASKER

NOTE:  I am running the servlet's on sun app server.  I cannot see this behavior when I run unit tests with the servlets deployed to localhost.  This only seems to occur when going over the wire.
What type is 'stream'?
>           bytesRead = stream.read(byteBuffer);

and get rid of that initial read.
the loop will handle reading the lot
Avatar of jjacksn

ASKER

objects, not sure what you mean?  what is wrong with teh way it is now?
Avatar of jjacksn

ASKER

CEHJ, the stream is generated from calling

BufferedInputStream stream = new BufferedInputStream(
      retrieveRequest.post());

retrieveRequest returns an InputStream, I  believe.
'stream' should be got by getInputStream on the servlet
> retrieveRequest.post()

whats that returning?

> etrieveRequest returns an InputStream, I  believe.

looks like it ractually already returns a byte array

Avatar of jjacksn

ASKER

Same issue occurs een with the different while loop.
Scrub my comment - it's a multipart.
> objects, not sure what you mean?  what is wrong with teh way it is now?

unnecessarily complicated, just need a simple loop
> looks like it ractually already returns a byte array

sorry, misread the line of code :) it does look like it returns a stream

whose multipart implementation are you using, may be worth trying it with a different one
Avatar of jjacksn

ASKER

CEHJ, not clear on what you mean.  this error is being thrown client side after the doPost method.  just checked the server logs as well, the server log is throwing an error in the write method:

ClientAbortException:  java.io.IOException: Client disconnected
        at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:409)
        at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:338)
        at org.apache.coyote.tomcat5.OutputBuffer.writeBytes(OutputBuffer.java:437)
        at org.apache.coyote.tomcat5.OutputBuffer.write(OutputBuffer.java:424)
        at org.apache.coyote.tomcat5.CoyoteOutputStream.write(CoyoteOutputStream.java:87)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
        at java.io.FilterOutputStream.write(FilterOutputStream.java:80)
Avatar of jjacksn

ASKER

using com.oreily.servlet, is there another that you would recommend?  Also, this only occurs going over the wire, i have not had any issues when testing against a server running on my local machine.
SOLUTION
Avatar of CEHJ
CEHJ
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
ASKER CERTIFIED SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
>>this error is being thrown client side after the doPost method

Can you please post the fully-qualified name of the class you're using to do the POST?
Avatar of jjacksn

ASKER

com.oreily.servlet.MultipartRequest is the thing I am using to wrap the HttpServletRequest on the server.  (note: there is no issue getting the parameters from the client to the server on the post).

to generate the request we are using our own object that I believe was downloaded from somewhere.  it wraps a native java HttpUrlConnection for multipart requests.

The post() method calls this:

    boundary();
    writeln("--");
    os.close();
    return connection.getInputStream(); //connection is an HttpUrlConnection

where boundry() is:
  private void boundary() throws IOException {
    write("--");
    write(boundary);
  }

where os is the output stream of URLConnection.getConnection();
>>to generate the request we are using our own object that I believe was downloaded from somewhere.

That's most likely the culprit
Avatar of jjacksn

ASKER

any suggestions on a good package to create them?
Jakarta HttpClient
Avatar of jjacksn

ASKER

The error is occuring even through a basic web browser, however, where my client side Http wrapper would not be in play, only the com.oreily package
Well i thought you said the error was on the client side ...
Avatar of jjacksn

ASKER

I'm not sure if it is a client side issue or a server side issue.  the server is able to properly read the parameters from the client just fine.  either the server is breaking when it is trying to write the data back or the client is breaking when it is trying to read it.  
Avatar of jjacksn

ASKER

Is there an equivelant server side library to process the multipart requests and write back?
Well if it's breaking in a browser too, it's probably the server. The O'Reilly should be ok on the server side
Avatar of jjacksn

ASKER

yeah... so... after further digging (apache works just fine for the uploads as well), the browser does properly retrieve the file... I'm going to try to rewrite the call with apache and see if it can get the bytes ok.  Thanks a lot for all the advice so far.   I'll repost if I have any more issues.
Avatar of jjacksn

ASKER

So the issue persists, but here is the odd thing.  When I'm home, on a shard wirelss router, this always uploads fine, and always breaks on the download.  When i'm in the office, it always works in both directions (my office connection is very fast).  

It does not seem to matter what size the file is, the upload always works, the download always receives 0 bytes.  This happens with both the oreily and the apache libraries.
Avatar of jjacksn

ASKER

when I try the same servlet call through a web browser, it also fails.  a file save dialog window pops open, but then another dialog pops up saying XXX could not be saved the source file could not be read.  

In all cases, when it fails, the server log says the error on the server is thrown when the servlet tries to write to the stream and it says client disconnected.  
:-)
why did u accpt that comment? I had already suggested trying it earlier, CEHJ was just copying my suggestion.
>>I had already suggested trying it earlier

Where?
Avatar of jjacksn

ASKER

ah, you're correct objects, sorry about that.  
objects> whose multipart implementation are you using, may be worth trying it with a different one

objects> give apaches implementation a try

And CEHJ made no mention of either of those comment even though it is clearly stated in the EE guidelines that credit must be given to earlier comments.
I'm happy for a split, you can accept CEHJ's comment , and make mine an assist.
>> ah, you're correct objects, sorry about that.  

Didn't see that sorry. Pretty vague anyway... ;-)
Avatar of jjacksn

ASKER

posted to moderators for split.  thanks to both of you for the help here.