• Post Reply Bookmark Topic Watch Topic
  • New Topic

ZipOutputStream remaining bits

 
sam wootton
Ranch Hand
Posts: 94
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ZipOutputStream remaining bits

Hi,

Thanks in advance for any help / advice. Its very much appreciated.

I have a ZipOutputStream in a Servlet, that creates a zip file with some files in it:

zipOutputStream.putNextEntry(new ZipEntry(tmpFileName));

I then send this back to the client with a ServletOutputStream:



This works fine, and looks like:



I set the content length of the response to this response.setHeader("File-size", ""+tmpZip.length()).

The problem is that when i read this from the client:



Im always around 700 bits short! e.g.



// ends

And hence:



... never gets called.

I never had this problem when i was using non zip stream, it always matched client > server. But now the bits read dont quite get to the zip file size.

I guess its more the 'reading' of the stream from the client that is the problem, than the writing of the stream on the server???

Best regards, snapple
 
Rob Spoor
Sheriff
Posts: 20819
68
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sam wootton wrote:response.setHeader("File-size", ""+tmpZip.length()).

Shouldn't you use response.setContentLength(tmpZip.length()) instead? Content-Length is the proper header, and this method will set it for you.



Im always around 700 bits short! e.g.


Are you sure? You print out the old number of bytes, before you add anything to it. Move that println statement two lines down, after you've increased bytesTotal. See if they match then.

I'm not saying this will solve your problem, but it may help you troubleshoot the issue.
 
sam wootton
Ranch Hand
Posts: 94
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rob Spoor,

Thanks for your response.

Move that println statement two lines down, after you've increased bytesTotal. See if they match then


... well thats embarrassing! I didnt see that at all. You are correct, they matched:

3220480 'v' 3226380
3221504 'v' 3226380
3222528 'v' 3226380
3223552 'v' 3226380
3224576 'v' 3226380
3225600 'v' 3226380
3226380 'v' 3226380

I was already setting content length to file size, just didnt post it :]

Many thanks!

Best regards, snapple
 
Rob Spoor
Sheriff
Posts: 20819
68
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does this mean that your closing code does get called now? Because if so, then it should have been called from the start. After all, the value of bytesTotal doesn't change by that fix, only the value you're printing.
 
sam wootton
Ranch Hand
Posts: 94
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Rob Spoor,

Basically this is what is happening:

'target' is my end number of bytes i expect to read:

if 'target' = accumulative compressed size of each zip entry then: bytes read never reach target (target is double that of bytes read, 3312776.0 'v' 6452628.0 = 51%).

if 'target' = file length() of total zip file then: bytes read go over (just) the target (target is slightly too high 3258630.0 'v' 3226400.0 = 100%).

.. where bytes read is on the left of 'v' and target is on the right.

Best regards, snapple
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!