• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

ZipOutputStream remaining bits

 
Ranch Hand
Posts: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Marshal
Posts: 22401
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Marshal
Posts: 22401
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 105
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Heroic work plunger man. Please allow me to introduce you to this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic