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

[Remy Maucherat]

Henri Gomez wrote:

    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 could try to make something like this, just tell me what you need.

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 agree

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.

Dedicated link, you know what it means say the average IT manager :

DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION => $/EUR++

If ever you came back to Lyon, I'll make you meet one of my IT manager ;-)

He's dumb ;-)
Look, you're putting together a cluster. Nothing good will come out of saving $50. Also, if you have only one Tomcat srever, you could use a crossover cable.

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)

What could we do so ?

- Create a GZIP implementation using byte array
- Use it in HTTP 1.1 stack
- Use it in JK2

As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just provide the interfaces.

Well, the idea is to be efficient, so:
- Have a ByteChunk compress(ByteChunk) method (assuming that giving it an empty chunk means it's the end of the input stream)
- Have a recycle method
- No object allocation (and esp buffers), except on init
- No need to worry about thread safety, so no syncs

But it's ok, we can have the first version use the JDK code.

> Did this ZLIB Java implementation could be what you're looking
> Remy ?
>
> http://www.jcraft.com/jzlib/index.html

Not really, it doesn't seem recyclable.

Remy


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