tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Some JK2 ideas v.3
Date Mon, 19 Jul 2004 15:27:39 GMT
Remy Maucherat wrote:

> My turn :)
> Sorry, I won't help code it (well, maybe a little for the Java part); so 
> I don't know if I have a say in any decision, but I though I should 
> participate as well.
> - it should be simpler than JK 1 or 2


> - it should have a name which doesn't confuse folks :)

mod_tomcat would be good.

> - Apache 2.x specific using APR (with the goal being the inclusion in 
> the Apache distribution as a default module: no more compilation 
> problems, etc); for other servers, I think we should keep the current JK

That's good if it means "generic library plust apache2 specific code", 
but it's really bad if it means all new functionality will only work in 
apache2 and for all other servers ( and no-server use cases ) we'll be 
stuck with jk.

> - it should try to optimize keepalive if possible for performance
> - it should support quality of service (messages to notify that a webapp 
> is being serviced on one node, etc)
> - (nice to have) it should be possible to configure the cluster dynamically

I would upgrade this to MUST have, not only for cluster but also 
webapps. Tomcat5 is pretty dynamic. If this is missing - why bother ?

> - there should be a clear documentation for which connector to use (I'm 
> not talking about specific needs, but general case: one server -> 
> standalone HTTP/1.1, cluster -> mod_newthing)
> - the configuration should be in Apache's config file, rather than some 
> complex properties file

-0 - apache config file is the best choice for 'close integration', but 
it can't be used in a JMX-like dynamic environment.

There are use cases where you want one, but the other is as important.

> - it should have good defaults (I like good defaults :) )

Big +1.

> - it should work well with other modules (I guess if somehow it is 
> accepted into the Apache codebase, it will be required)
> - I think the protocol should be an extension of AJP/1.3

+1 - or a standard, existing protocol. No new arbitrary protocols. ( XDR 
  subset remains my favorite ).

> - No JNI in this module IMO: I think it would be better to have another 
> separate module dedicated to JNI (and trying to use, for example, the in 
> memory protocol handler or similar techniques) if there's interest, 
> rather than add complexity to this module, which has very different needs

What complexity does JNI add to jk2 ? There are separate files, using 
the same protocol.

The real important lesson in Jk2 is that JNI works faster and better if 
it is not used to pass objects.

The only 2 JNI models that actually work are jk2 "protocol marshalling, 
pass only byte[]" and eclipse swt "small simple calls with mostly int 
and byte[] params"


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message