Re: gzip-encoding in TC 4.1.x/5.x

[Remy Maucherat]

Henri Gomez wrote:

            I was planning to add the feature as filters in Coyote
            HTTP/1.1, but never did, because I wasn't able to find
            efficient compression code. I suppose something could be put
            together using the JDK compression IS and OS in the meantime.




        GZIPOutputstream is quit fast today.



    I think I'll disagree whenever I'll try it.


C'est le jeu ;)

Ideally, I'd like a ByteChunk compress(ByteChunk) with nice recycle methods so that no object even gets allocated.

Right, but I'm currently playing with stuff which read/write
large files, and reading/writing with GZIPxxxxstream make the
program 4* faster !

One of the problems is that the compressed streams from the JDK are not recyclable, cause a lot of possibly synced method calls, and so on. Plus, it's kinda ugly to fit the OS and IS models into the Coyote HTTP/1.1 filter model.

Does anyone know about compression code which would use byte arrays on input/output ?

I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.

You can't do it, unless the code is in the adapter, and that's bad design (it's a protocol feature, so it should be in the protocol hanlder).

Couldn't the compression goes in filter, like Amy does sometimes ago ?

You can use it there if you want. However, transfer encoding is a protocol feature. So it seems logical to handle this at the protocol layer (for example, chunked is a transfer encoding, and also hanlded at the protocol handler level). Plus you get a nice server wide configuration on the native webserver, rather than individual settings depending on where the resource is served from. It just seems much cleaner.

I don't quite see the Apache <-> Tomcat link being bandwidth constrained except in very specific situations. In loopback, it uses special optimized processing, and if there are separate boxes for Apache and Tomcat, then they should IMO use a dedicated network link.

I don't see what you can do to improve Amy's filter performance, as it has to:
- be thread safe
- use inefficient methods from the servlet API (which create garbage, etc)

Remy


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>