Unified I/O could be helpful - http://uio.imagero.com
It's free and open source.

Andrey

I'm not sure what you mean by this. I can think of 3 possible meaning, but each
one has different answers...

1) You have a large lump of gzipped data and you want to read that
incrementally across a network, i.e. without holding the whole thing in memory
at the same time.  That's easy because GZipInputStream is inherently
incremental.

2) You have a server of some sort which provides a sequence of  32K chunks of
data, each of which has been independently gzipped.  Again that is easy -- just
de-gzip each chunk independently and assemble the results.

3) You have an awkwardly designed system which passes out chunks extracted from
a single gzipped file, but doesn't do so as an uninterrupted stream.  Perhaps
some sort of web-service where you keep sending HTTP requests "give me the next
chunk".  If so then your first thought should be "how can I fix the design?".
Assuming that you are unable to do so, and since you clearly have too much data
for a simple hack/workaround to suffice, you will have to create a custom
implementation of ReadStream.  That implementation would satisfy read()
requests by checking an internal buffer to see if it already had enough data
stored and, if not, then it would refill the buffer by issuing a network
request to your server for the next 32K chunk.  You would create an instance of
that class and pass it to the GZipInputStream constructor.  You might find that
quite difficult if other parts of your application need to talk to the server
at the same time, or if the protocol for talking to the server is more
complicated than I'm assuming here.

   -- chris