Very interesting thread.
What's the needs in server / tc communications ?
- new apis
- new communication layer
ajp is a not so bad protocol but the jk impl mix comm & marsh/unmarsh
& api.
we could find a persistant communication layer (openwire from
activemq ?)
we could define a set of apis (getLoad, forwardRequest)
Then we should be able to glue both to a servlet engine like tomcat.
Could we assemble existing components and attract external people ? I
hope so, that was the idea behind my original post on this thread.
I'm pretty sure we could collects ideas and needs here and after have
a general idea of what should be done, how and where.
Incubator is a good idea, so it won't just be (seen) as a new tomcat
sub project or a nth attempt to rewrite mod_jk.
Also it could be used by other servlet engines, more brains, more ideas.
Openess is the key.
Le 4 avr. 09 à 19:15, Costin Manolache <cos...@gmail.com> a écrit :
On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk <mt...@apache.org> wrote:
Costin Manolache wrote:
On Sat, Apr 4, 2009 at 9:03 AM, David Jencks
<david_jen...@yahoo.com>
wrote:
My understanding of 'what we talk about' is what to do with mod_jk -
deprecate/remove old code, add few features
to better match current tomcat ( and current requirements - larger
clusters,
etc ). It seems there is some agreement that
current AJP protocol won't work, but bigger disagreement on
weather to
just
do nothing at all ( i.e. just maintain current
code ), or do some small addition to AJP, use HTTP, etc.
I got the impression that majority of people here
wish to maintain the mod_jk. Rainer wishes to add few
things in new 1.3 branch which is fine with me.
The rest like Jean-Frederic said 'Won't happen'
which I read, there is no man power here that
would do something new.
I agree there is no man power to implement a new protocol.
But if we just use one - openwire or something similar - it may be
much easier.
Adding the dependency and getting it to build should be few hours/
days,
then adding various handlers can be done very incrementally.
If I read correctly Rainer's list, some improvements will be easier
if he
had a better/more extensible communication mechanism, load balancing
in
particular.
I don't have a lot of time - certainly not for a new connector/
branch/etc,
but
I and others may find few hours if it would be easier -
and I think a more extensible communication would do that. Changing
existing
code - without breaking backward compat - is pretty hard.
I would love to make 'something new', but it
obviously won't happen under Tomcat umbrella.
Why not ? It seems well in scope.
Costin
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
