You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Turk <mt...@apache.org> on 2004/07/15 14:58:14 UTC
Some JK2 ideas v.2
Hi,
All (except Costin) developers has to say something, so my conclusion is
that we are not dead after all ;)
Seems that the major obstacle is the configuration, so I propose that we
forget that for a while, and make a
'generalized' environment that will sattisfy all the 'needs'.
That environment could be called APR_JAVA and it will be resposible for
os->java communication, having AJPXX, and 'JNI' as one of the possible
protocol stacks.
It will have a generic mapping mechanism (pcre enabled) for registering URI
mapings, setting communication properties, so that one could make a suport
from any container (webserver).
It will abstract the container<->java communication to the level of
'directory and file' so that one can open a connection to TC like opening a
file, or simply speaking a 'Virtual File System', so that one can either
'mount' a volume like '/servlets' or a file filter like '*.jsp'
Of course all that sounds like JK3, but ...
MT.
Re: Some JK2 ideas v.3
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
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 :)
> - 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);
In httpd-2.0 repos?
> for other servers, I think we should keep the current 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
> - 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
> - it should have good defaults (I like good defaults :) )
> - 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
> - 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
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Henri Gomez wrote:
>
>>> You must keep in mind that tomcat5 is no longer server.xml centric !
>>>
>>> It can use separate config files in different directories, if it is
>>> embedded it can use the embedor's config, etc.
>>>
>>> And httpd.conf is static - you can't modify it. We support using
>>> httpd.conf for performance-versus-flexibility or for native auth - if
>>> you want to use the apache mapper and auth instead of jk mapper and
>>> tomcat auth.
>>
>>
>>
>> Well httpd.conf is static but nothing prevent from doing :
>>
>> <Location /examples>
>> AjpWorker myworker
>> </Location>
>>
>> => All /examples goes to myworker, which could be a simple tomcat
>> or a cluster. but the idea behind is to make updates to this 'myworker'
>> from the behind, JMX or AJP13++/AJP14 link.
>
>
>
> And what if /examples context is removed ?
Well => 404
Since myworker didn't have examples webapp, the resource is missing
and unless you're in a cluster configuration, you should return a 404 error.
> Or a new context is dynamically added ?
If a new context is added, you couldn't know it at httpd.conf edit time.
Many cases here :
- You didn't map it.
- You map it to the worker but in such case you have to triple URI
mapping, one in Apache 2, another in mod_ajp, and of course a third in
tomcat, and using 3 mapping was something you asked us to avoid yesterday ;)
> What about /examples/protected/ which may need to be authenticated - if
> we really want to support "play nice with other apache modules", then we
> need to support authentication using apache modules. Then what if the
> webapp is reloaded with a different protected uri ?
/examples/protected/ should use the Apache auth as any other 'native'
Apache URL isn't it ? In such case we should exclude it from direct
mod_ajp processing, it should case later in the hooks process.
That's the main problem with jk/jk2 today, since we can be part of the
various modules chain with JkMount for example :(
>>> So IMO any jk config MUST be JMX-like.
>>
>>
>>
>> May be.
>>
>>>>
>>>>
>>>> Of course we should have somewhere in the new module the
>>>> configuration tree in whatever native format we could imagine,
>>>> apr_map maybe or apr_xml_tree if existing.
>>>
>>>
>>>
>>>
>>> File format is not important - dynamic changes and updates are the
>>> important issue.
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>> - the configuration should be in Apache's config file, rather
>>>>>>> than some complex properties file
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> +1
>>>
>>>
>>>
>>>
>>> See above.
>>>
>>> Apache config file is clearly better than any arbitrary static
>>> jk-specific config file. And it does provide close integration -
>>> including auth* using any of apache modules, and anything you can
>>> dream of in terms of apache modules.
>>>
>>> However - it is very static, and I doubt this will change soon. Even
>>> with apache2, if you change the config ( add a webapp ) you need to
>>> restart apache ( which may be interesting if multithreaded and some
>>> module is using sessions).
>>
>>
>>
>> Not necessary. Nothing prevent us from doing something like this :
>>
>> <Location /*.jsp>
>> AjpWorker myworker
>> </Location>
>>
>>
>> <Location /servlet/*>
>> AjpWorker myworker
>> </Location>
>>
>>
>> And if the mod_xxx is able to discover the webapp attached to myworker,
>> you got them redirected to the correct worker.
>
>
> And you lose the real integration into apache - which is the ability to
> use other modules.
It was a simple example, and today the real integration with apache is
pretty bad in jk/jk2, that's why I'd like to use something as simple as
EnvVars to determine if an URL should be mapped by mod_ajp.
There is way too many hooks handled by jk/jk2 today, more than complex
modules like proxy or rewrite and it could be a reason why jk/jk2 didn't
works well with Location/Directory/Alias and others Apache 2 directive...
> My point is that we have 2 use cases, one is "strong integration", where
> you want to use apache modules, and the other is "dynamic", where you
> want to deal with a server where apps are often deployed or changed.
Well we could do the both :
- strong integration using hard-coded settings in httpd.conf
- dynamic integration using a sort of AjpMount Dynamic Worker1 but
in such case you have to handle a specific URI mapping in mod_ajp.
> You just can't support both use cases with the same solution - if you
> try, it's a lose-lose situation.
I agree, that's why we should first work on strong integration, at least
for URL to worker part. Nothing prevent us for instance to be able to
update worker (direct or cluster) caracteristics dynamically, put
mapping is hardcoded.
>>> The real important feature in jk2 is the JMX emulation - I know
>>> almost nobody uses it :-).
>>
>>
>>
>> Well the code is too complex in jk2, and that's also why we need some
>> cleanups.
>
>
> I agree.
>
> However starting from scratch without having a flexible design that
> takes into account the dynamicity of tomcat is bound to result in
> another chunk of complex code ( after some time ), or something
> inflexible ( mod_webapp ? ).
mod_webapp was a good idea, which came too soon (APR mandatory before
Apache 2 release)...
>>
>>>>> Without having a common codebase and API that can be used outside
>>>>> Apache2?
>>>
>>>
>>>
>>>
>>> I like apache2, but keeping the options open is pretty important.
>>> Tomcat can be integrated in more than Web servers :-)
>>
>>
>>
>> Of course but many users and admins are confused in using jk2 with
>> Apache 2 for example. Too many way to do the same conf make jk2
>> a difficult thing and that's why many stay on jk 1.2.x
>
>
> What about 2 ways only :-) ?
>
> Again - if you can find a solution to use httpd.conf and support a
> dynamic environment without giving up integration, then I'm fine. Using
> httpd.conf file and some custom directives that don't work with other
> modules is the worse choice, you lose both integration and dynamic config.
It should be a choice, I'd like to have a strong Apache 2 integration
but with dynamic workers configuration (ie: adding worker to a cluster
worker dynamically). Apache 2 knows that it should work with a worker,
but mod_ajp could change this worker from direct, to cluster and even
change cluter caracteristics.
>>
>>> If you have a good infrastructure ( library ) for dynamic config and
>>> request forwarding - why not keep it reusable for other applications,
>>> even for things besides tomcat.
>>
>>
>>
>> Well if other application want to access an embedded tomcat, they could
>> use JNI or direct Java calls ?
>
>
> In most cases, other apps need to use TCP/unix sockets and jk protocol (
> I'm talking about native apps ). JNI is far too complicated, especially
> from single-threaded apps.
yes the ajp library could be used outside Apache 2, but may need Apache
2 to be built...
>>
>>> Having a closeley integrated variant ( using this library ) is a
>>> great idea, and it would be even better if this could be bundled with
>>> apache.
>>
>>
>>
>> Of course that's the idea, having a resonable module which could came
>> with Apache 2.x distributions, following the same code standards (ie
>> using apr_/ap_) and also the same documentation format (the HTTPD 2.0
>> documentation is really clear).
>
>
> +1 - as long as the code has a good architecture that takes jmx in
> account, and uses a modular approach.
>
> ( this means - parts of it could be reused )
>
>
>>
>>>> We should discuss what will be in the API, some will be only APR
>>>> dependant, but of course many will be dependant of Apache 2.x, for
>>>> examples Apache requests.
>>>>
>>>> But we could see simple call, like :
>>>>
>>>> int xxx_forward_simple_request(
>>>> xxx_worker_t *,
>>>> apr_pool_t * req_uri,
>>>> apr_pool_t * reply_data);
>>>>
>>>> int xxx_forward_simple_post_request(
>>>> xxx_worker_t *,
>>>> apr_pool_t * req_uri,
>>>> apr_pool_t * post_data,
>>>> apr_pool_t * reply_data);
>>>>
>>>> int xxx_forward_full_request(
>>>> xxx_worker_t *,
>>>> apr_pool_t * req_uri,
>>>> apr_table_t * headers,
>>>> apr_pool_t * post_data,
>>>> apr_pool_t * reply_data);
>>>>
>>>>
>>>>
>>>>
>>>>> In that case why not write only proxy_coyote for mod_proxy?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Since it will be nice to be able to be warned in mod_xxx
>>>> from real-time topology updates, ie application down on one
>>>> tomcat, new application on another tomcat, cluster updates...
>>>
>>>
>>>
>>>
>>> This may be a good feature for mod_proxy as well BTW :-)
>>
>>
>>
>> mod_proxy didn't support clustering :(
>>
>>>>
>>>>>>> - I think the protocol should be an extension of AJP/1.3
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it
>>>>>> could be a good candidate. In my idea we should start to write an
>>>>>> APR based
>>>>>> AJP/1.4 library, which could be first used outside Apache 2 server
>>>>>> for test and benchs purposes.
>>>>>>
>>>>>
>>>>>
>>>>> +1, but in contradiction with previous :).
>>>>> I would also like to see the gzip like extension to AJP/xx for
>>>>> lowering the
>>>>> data transfer.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It was proposed some times ago together with some light crypto to
>>>> secure
>>>> apache - tomcat link when you're not in a secure network. All of
>>>> these could be made optional in protocol negociation side of AJP/14...
>>>
>>>
>>>
>>>
>>> It's all nice, but I don't see it as the biggest priority and it may
>>> be better implemented after everything else settles down ( otherwise
>>> the extra code would make changes harder ).
>>
>>
>>
>> Of course, negociation is one thing, implementation is another.
>
>
> :-)
>
>>
>>> It seems close apache2 integration is a pretty big change
>>
>>
>>
>> Yes, a total rewrite of the existing code, no more jk, no more jk2, but
>> cut/paste, redesign and rewrite.
>
>
> Ok, but it should start with "design" ( or even better - agreement on
> requirements before design !)
We're discussing that right now :)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
>> You must keep in mind that tomcat5 is no longer server.xml centric !
>>
>> It can use separate config files in different directories, if it is
>> embedded it can use the embedor's config, etc.
>>
>> And httpd.conf is static - you can't modify it. We support using
>> httpd.conf for performance-versus-flexibility or for native auth - if
>> you want to use the apache mapper and auth instead of jk mapper and
>> tomcat auth.
>
>
> Well httpd.conf is static but nothing prevent from doing :
>
> <Location /examples>
> AjpWorker myworker
> </Location>
>
> => All /examples goes to myworker, which could be a simple tomcat
> or a cluster. but the idea behind is to make updates to this 'myworker'
> from the behind, JMX or AJP13++/AJP14 link.
And what if /examples context is removed ?
Or a new context is dynamically added ?
What about /examples/protected/ which may need to be authenticated - if
we really want to support "play nice with other apache modules", then we
need to support authentication using apache modules. Then what if the
webapp is reloaded with a different protected uri ?
>
>
>> So IMO any jk config MUST be JMX-like.
>
>
> May be.
>
>>>
>>>
>>> Of course we should have somewhere in the new module the
>>> configuration tree in whatever native format we could imagine,
>>> apr_map maybe or apr_xml_tree if existing.
>>
>>
>>
>> File format is not important - dynamic changes and updates are the
>> important issue.
>>
>>
>>
>>>
>>>>
>>>>>> - the configuration should be in Apache's config file, rather than
>>>>>> some complex properties file
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> +1
>>
>>
>>
>> See above.
>>
>> Apache config file is clearly better than any arbitrary static
>> jk-specific config file. And it does provide close integration -
>> including auth* using any of apache modules, and anything you can
>> dream of in terms of apache modules.
>>
>> However - it is very static, and I doubt this will change soon. Even
>> with apache2, if you change the config ( add a webapp ) you need to
>> restart apache ( which may be interesting if multithreaded and some
>> module is using sessions).
>
>
> Not necessary. Nothing prevent us from doing something like this :
>
> <Location /*.jsp>
> AjpWorker myworker
> </Location>
>
>
> <Location /servlet/*>
> AjpWorker myworker
> </Location>
>
>
> And if the mod_xxx is able to discover the webapp attached to myworker,
> you got them redirected to the correct worker.
And you lose the real integration into apache - which is the ability to
use other modules.
My point is that we have 2 use cases, one is "strong integration", where
you want to use apache modules, and the other is "dynamic", where you
want to deal with a server where apps are often deployed or changed.
You just can't support both use cases with the same solution - if you
try, it's a lose-lose situation.
>
>> The real important feature in jk2 is the JMX emulation - I know almost
>> nobody uses it :-).
>
>
> Well the code is too complex in jk2, and that's also why we need some
> cleanups.
I agree.
However starting from scratch without having a flexible design that
takes into account the dynamicity of tomcat is bound to result in
another chunk of complex code ( after some time ), or something
inflexible ( mod_webapp ? ).
>
>
>>>> Without having a common codebase and API that can be used outside
>>>> Apache2?
>>
>>
>>
>> I like apache2, but keeping the options open is pretty important.
>> Tomcat can be integrated in more than Web servers :-)
>
>
> Of course but many users and admins are confused in using jk2 with
> Apache 2 for example. Too many way to do the same conf make jk2
> a difficult thing and that's why many stay on jk 1.2.x
What about 2 ways only :-) ?
Again - if you can find a solution to use httpd.conf and support a
dynamic environment without giving up integration, then I'm fine. Using
httpd.conf file and some custom directives that don't work with other
modules is the worse choice, you lose both integration and dynamic config.
>
>> If you have a good infrastructure ( library ) for dynamic config and
>> request forwarding - why not keep it reusable for other applications,
>> even for things besides tomcat.
>
>
> Well if other application want to access an embedded tomcat, they could
> use JNI or direct Java calls ?
In most cases, other apps need to use TCP/unix sockets and jk protocol (
I'm talking about native apps ). JNI is far too complicated,
especially from single-threaded apps.
>
>> Having a closeley integrated variant ( using this library ) is a great
>> idea, and it would be even better if this could be bundled with apache.
>
>
> Of course that's the idea, having a resonable module which could came
> with Apache 2.x distributions, following the same code standards (ie
> using apr_/ap_) and also the same documentation format (the HTTPD 2.0
> documentation is really clear).
+1 - as long as the code has a good architecture that takes jmx in
account, and uses a modular approach.
( this means - parts of it could be reused )
>
>>> We should discuss what will be in the API, some will be only APR
>>> dependant, but of course many will be dependant of Apache 2.x, for
>>> examples Apache requests.
>>>
>>> But we could see simple call, like :
>>>
>>> int xxx_forward_simple_request(
>>> xxx_worker_t *,
>>> apr_pool_t * req_uri,
>>> apr_pool_t * reply_data);
>>>
>>> int xxx_forward_simple_post_request(
>>> xxx_worker_t *,
>>> apr_pool_t * req_uri,
>>> apr_pool_t * post_data,
>>> apr_pool_t * reply_data);
>>>
>>> int xxx_forward_full_request(
>>> xxx_worker_t *,
>>> apr_pool_t * req_uri,
>>> apr_table_t * headers,
>>> apr_pool_t * post_data,
>>> apr_pool_t * reply_data);
>>>
>>>
>>>
>>>
>>>> In that case why not write only proxy_coyote for mod_proxy?
>>>
>>>
>>>
>>>
>>> Since it will be nice to be able to be warned in mod_xxx
>>> from real-time topology updates, ie application down on one
>>> tomcat, new application on another tomcat, cluster updates...
>>
>>
>>
>> This may be a good feature for mod_proxy as well BTW :-)
>
>
> mod_proxy didn't support clustering :(
>
>>>
>>>>>> - I think the protocol should be an extension of AJP/1.3
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could
>>>>> be a good candidate. In my idea we should start to write an APR based
>>>>> AJP/1.4 library, which could be first used outside Apache 2 server
>>>>> for test and benchs purposes.
>>>>>
>>>>
>>>>
>>>> +1, but in contradiction with previous :).
>>>> I would also like to see the gzip like extension to AJP/xx for
>>>> lowering the
>>>> data transfer.
>>>
>>>
>>>
>>>
>>> It was proposed some times ago together with some light crypto to secure
>>> apache - tomcat link when you're not in a secure network. All of
>>> these could be made optional in protocol negociation side of AJP/14...
>>
>>
>>
>> It's all nice, but I don't see it as the biggest priority and it may
>> be better implemented after everything else settles down ( otherwise
>> the extra code would make changes harder ).
>
>
> Of course, negociation is one thing, implementation is another.
:-)
>
>> It seems close apache2 integration is a pretty big change
>
>
> Yes, a total rewrite of the existing code, no more jk, no more jk2, but
> cut/paste, redesign and rewrite.
Ok, but it should start with "design" ( or even better - agreement on
requirements before design !)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
>>>>
>>>> We should first determine if Apache2 will have to monitor a
>>>> service/system links to the various tomcats (in cluster
>>>> configuration) to learn about real-time topology.
>>>>
>>>
>>>
>>> In fact, that is why I've pursued the .xml config over the current one.
>>> The main idea is to _internally_ have config tree (right now we don't
>>> have
>>> that).
>>> So that internal configuration tree will be populated either using
>>> directives in the native httpd.conf or reading server.xml stream from
>>> TC or
>>> from file.
>
>
>
> You must keep in mind that tomcat5 is no longer server.xml centric !
>
> It can use separate config files in different directories, if it is
> embedded it can use the embedor's config, etc.
>
> And httpd.conf is static - you can't modify it. We support using
> httpd.conf for performance-versus-flexibility or for native auth - if
> you want to use the apache mapper and auth instead of jk mapper and
> tomcat auth.
Well httpd.conf is static but nothing prevent from doing :
<Location /examples>
AjpWorker myworker
</Location>
=> All /examples goes to myworker, which could be a simple tomcat
or a cluster. but the idea behind is to make updates to this 'myworker'
from the behind, JMX or AJP13++/AJP14 link.
> So IMO any jk config MUST be JMX-like.
May be.
>>
>>
>> Of course we should have somewhere in the new module the configuration
>> tree in whatever native format we could imagine, apr_map maybe or
>> apr_xml_tree if existing.
>
>
> File format is not important - dynamic changes and updates are the
> important issue.
>
>
>
>>
>>>
>>>>> - the configuration should be in Apache's config file, rather than
>>>>> some complex properties file
>>>>
>>>>
>>>>
>>>> +1
>
>
> See above.
>
> Apache config file is clearly better than any arbitrary static
> jk-specific config file. And it does provide close integration -
> including auth* using any of apache modules, and anything you can dream
> of in terms of apache modules.
>
> However - it is very static, and I doubt this will change soon. Even
> with apache2, if you change the config ( add a webapp ) you need to
> restart apache ( which may be interesting if multithreaded and some
> module is using sessions).
Not necessary. Nothing prevent us from doing something like this :
<Location /*.jsp>
AjpWorker myworker
</Location>
<Location /servlet/*>
AjpWorker myworker
</Location>
And if the mod_xxx is able to discover the webapp attached to myworker,
you got them redirected to the correct worker.
> The real important feature in jk2 is the JMX emulation - I know almost
> nobody uses it :-).
Well the code is too complex in jk2, and that's also why we need some
cleanups.
>>> Without having a common codebase and API that can be used outside
>>> Apache2?
>
>
> I like apache2, but keeping the options open is pretty important. Tomcat
> can be integrated in more than Web servers :-)
Of course but many users and admins are confused in using jk2 with
Apache 2 for example. Too many way to do the same conf make jk2
a difficult thing and that's why many stay on jk 1.2.x
> If you have a good infrastructure ( library ) for dynamic config and
> request forwarding - why not keep it reusable for other applications,
> even for things besides tomcat.
Well if other application want to access an embedded tomcat, they could
use JNI or direct Java calls ?
> Having a closeley integrated variant ( using this library ) is a great
> idea, and it would be even better if this could be bundled with apache.
Of course that's the idea, having a resonable module which could came
with Apache 2.x distributions, following the same code standards (ie
using apr_/ap_) and also the same documentation format (the HTTPD 2.0
documentation is really clear).
>> We should discuss what will be in the API, some will be only APR
>> dependant, but of course many will be dependant of Apache 2.x, for
>> examples Apache requests.
>>
>> But we could see simple call, like :
>>
>> int xxx_forward_simple_request(
>> xxx_worker_t *,
>> apr_pool_t * req_uri,
>> apr_pool_t * reply_data);
>>
>> int xxx_forward_simple_post_request(
>> xxx_worker_t *,
>> apr_pool_t * req_uri,
>> apr_pool_t * post_data,
>> apr_pool_t * reply_data);
>>
>> int xxx_forward_full_request(
>> xxx_worker_t *,
>> apr_pool_t * req_uri,
>> apr_table_t * headers,
>> apr_pool_t * post_data,
>> apr_pool_t * reply_data);
>>
>>
>>
>>
>>> In that case why not write only proxy_coyote for mod_proxy?
>>
>>
>>
>> Since it will be nice to be able to be warned in mod_xxx
>> from real-time topology updates, ie application down on one
>> tomcat, new application on another tomcat, cluster updates...
>
>
> This may be a good feature for mod_proxy as well BTW :-)
mod_proxy didn't support clustering :(
>>
>>>>> - I think the protocol should be an extension of AJP/1.3
>>>>
>>>>
>>>>
>>>> I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could
>>>> be a good candidate. In my idea we should start to write an APR based
>>>> AJP/1.4 library, which could be first used outside Apache 2 server
>>>> for test and benchs purposes.
>>>>
>>>
>>>
>>> +1, but in contradiction with previous :).
>>> I would also like to see the gzip like extension to AJP/xx for
>>> lowering the
>>> data transfer.
>>
>>
>>
>> It was proposed some times ago together with some light crypto to secure
>> apache - tomcat link when you're not in a secure network. All of these
>> could be made optional in protocol negociation side of AJP/14...
>
>
> It's all nice, but I don't see it as the biggest priority and it may be
> better implemented after everything else settles down ( otherwise the
> extra code would make changes harder ).
Of course, negociation is one thing, implementation is another.
> It seems close apache2 integration is a pretty big change
Yes, a total rewrite of the existing code, no more jk, no more jk2, but
cut/paste, redesign and rewrite.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
>>>
>>> We should first determine if Apache2 will have to monitor a
>>> service/system links to the various tomcats (in cluster
>>> configuration) to learn about real-time topology.
>>>
>>
>>
>> In fact, that is why I've pursued the .xml config over the current one.
>> The main idea is to _internally_ have config tree (right now we don't
>> have
>> that).
>> So that internal configuration tree will be populated either using
>> directives in the native httpd.conf or reading server.xml stream from
>> TC or
>> from file.
You must keep in mind that tomcat5 is no longer server.xml centric !
It can use separate config files in different directories, if it is
embedded it can use the embedor's config, etc.
And httpd.conf is static - you can't modify it. We support using
httpd.conf for performance-versus-flexibility or for native auth - if
you want to use the apache mapper and auth instead of jk mapper and
tomcat auth.
So IMO any jk config MUST be JMX-like.
>
>
> Of course we should have somewhere in the new module the configuration
> tree in whatever native format we could imagine, apr_map maybe or
> apr_xml_tree if existing.
File format is not important - dynamic changes and updates are the
important issue.
>
>>
>>>> - the configuration should be in Apache's config file, rather than
>>>> some complex properties file
>>>
>>>
>>> +1
See above.
Apache config file is clearly better than any arbitrary static
jk-specific config file. And it does provide close integration -
including auth* using any of apache modules, and anything you can dream
of in terms of apache modules.
However - it is very static, and I doubt this will change soon. Even
with apache2, if you change the config ( add a webapp ) you need to
restart apache ( which may be interesting if multithreaded and some
module is using sessions).
The real important feature in jk2 is the JMX emulation - I know almost
nobody uses it :-).
>>>
>>
>>
>> The general idea is to connect to TC and get the URI/VHOST topology,
>> but we
>> still need the 'intervene' directives for connector specific ones.
>> How to make them simpler to use the JK and JK2?
>>
>> Perhaps using something like:
>>
>> <CoyoteWorker workerA>
>> ...directives
>>
>> </CoyoteWorker>
>
>
> I agreed for this on worker configuration in httpd.conf.
>
>> And then:
>>
>> <Files *.jsp>
>> CoyoteUsesWorker workerA
>> </Files>
>
>
> ok.
>
> We should also be able to handle :
>
> <Location /myspecialurl>
> CoyoteUsesWorker workerA
> </Files>
>
> Something very familiar to Apache admins.
+1 ( it's actually already working AFAIK - or it used to be ).
>>>> - it should work well with other modules (I guess if somehow it is
>>>> accepted into the Apache codebase, it will be required)
>>>
>>>
>>> That's why we should focus on Apache 2 only module.
>>>
>>
>>
>> Not sure I'm in favor of that (unless you meant dropping 1.3 module by
>> that).
>
>
> Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
> could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
> No more code complexity to handle all the web-servers around,
> we should focus on Apache 2.x.
>
> For example majors Linux distributions are now using Apache 2 instead of
> Apache 1.3. So Apache 2.x will be more and more used.
>
>> Without having a common codebase and API that can be used outside
>> Apache2?
I like apache2, but keeping the options open is pretty important. Tomcat
can be integrated in more than Web servers :-)
If you have a good infrastructure ( library ) for dynamic config and
request forwarding - why not keep it reusable for other applications,
even for things besides tomcat.
Having a closeley integrated variant ( using this library ) is a great
idea, and it would be even better if this could be bundled with apache.
>
> We should discuss what will be in the API, some will be only APR
> dependant, but of course many will be dependant of Apache 2.x, for
> examples Apache requests.
>
> But we could see simple call, like :
>
> int xxx_forward_simple_request(
> xxx_worker_t *,
> apr_pool_t * req_uri,
> apr_pool_t * reply_data);
>
> int xxx_forward_simple_post_request(
> xxx_worker_t *,
> apr_pool_t * req_uri,
> apr_pool_t * post_data,
> apr_pool_t * reply_data);
>
> int xxx_forward_full_request(
> xxx_worker_t *,
> apr_pool_t * req_uri,
> apr_table_t * headers,
> apr_pool_t * post_data,
> apr_pool_t * reply_data);
>
>
>
>
>> In that case why not write only proxy_coyote for mod_proxy?
>
>
> Since it will be nice to be able to be warned in mod_xxx
> from real-time topology updates, ie application down on one
> tomcat, new application on another tomcat, cluster updates...
This may be a good feature for mod_proxy as well BTW :-)
>
>>>> - I think the protocol should be an extension of AJP/1.3
>>>
>>>
>>> I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could
>>> be a good candidate. In my idea we should start to write an APR based
>>> AJP/1.4 library, which could be first used outside Apache 2 server
>>> for test and benchs purposes.
>>>
>>
>>
>> +1, but in contradiction with previous :).
>> I would also like to see the gzip like extension to AJP/xx for
>> lowering the
>> data transfer.
>
>
> It was proposed some times ago together with some light crypto to secure
> apache - tomcat link when you're not in a secure network. All of these
> could be made optional in protocol negociation side of AJP/14...
It's all nice, but I don't see it as the biggest priority and it may be
better implemented after everything else settles down ( otherwise the
extra code would make changes harder ).
It seems close apache2 integration is a pretty big change
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>Well I'd like to see jk 1.2.x continuing its slow maintenance
>>cycle since it's the most used module for now.
>>
>>And start from scratch the new mod_coyote.
>>
>>
>>>Ok, but let's try to make the code 'reusable', protocol and basic
>>>config tree should be in a separate files, so that we can
>>
>>aventually
>>
>>>make something simmilar for other web servers if there will
>>
>>be enough
>>
>>>interest, or make a generic 'apr/apr-util' like library, so
>>
>>everything
>>
>>>that uses 'ap_xxx' calls should go in mod_coyote.
>>
>>Well if we want mod_coyote included in Apache 2.x tree, we
>>shouldn't have too much files. Also I'd like to avoid too
>>many wrapper calls functions.
>>
>
>
> protocol, transport, config, log, utils and mod. (cca 6 files + 2 includes).
Seems reasonable.
> So, what cannot be build without ap_api should go to mod_ file itself.
> Also all the config should be API based (not directly setting elements).
Example please ?
> The main purpose is to able to 'reuse' the code, but not directly, so that
> it's core
> parts like config, protocol and transport can be ported to other servers,
> with
> 'reasonably' low efforts.
Ok.
> By that I mean that if we need to read from the server we use the high-level
> function that will do that, (probably wrapping few ap_xxx calls).
>
> It's only a matter of 'strategy' used :).
Of course.
Also having a ajp style library could help us make so AJP based stress
tests applications, a little like ApacheBench.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> Well I'd like to see jk 1.2.x continuing its slow maintenance
> cycle since it's the most used module for now.
>
> And start from scratch the new mod_coyote.
>
> > Ok, but let's try to make the code 'reusable', protocol and basic
> > config tree should be in a separate files, so that we can
> aventually
> > make something simmilar for other web servers if there will
> be enough
> > interest, or make a generic 'apr/apr-util' like library, so
> everything
> > that uses 'ap_xxx' calls should go in mod_coyote.
>
> Well if we want mod_coyote included in Apache 2.x tree, we
> shouldn't have too much files. Also I'd like to avoid too
> many wrapper calls functions.
>
protocol, transport, config, log, utils and mod. (cca 6 files + 2 includes).
So, what cannot be build without ap_api should go to mod_ file itself.
Also all the config should be API based (not directly setting elements).
The main purpose is to able to 'reuse' the code, but not directly, so that
it's core
parts like config, protocol and transport can be ported to other servers,
with
'reasonably' low efforts.
By that I mean that if we need to read from the server we use the high-level
function that will do that, (probably wrapping few ap_xxx calls).
It's only a matter of 'strategy' used :).
MT.
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>
>>>For example majors Linux distributions are now using Apache
>>
>>2 instead
>>
>>>of Apache 1.3. So Apache 2.x will be more and more used.
>>
>>When not running inside Apache, there are tons of things when
>>cannot use, including configuration. So the best is indeed to
>>keep JK around for supporting other servers. One of the big
>>problems is that it would be best to keep developing either
>>jk 1.2.x or jk 2.0.x, but not both ;)
Well I'd like to see jk 1.2.x continuing its slow maintenance cycle
since it's the most used module for now.
And start from scratch the new mod_coyote.
> Ok, but let's try to make the code 'reusable', protocol and basic config
> tree should be in a separate files, so that we can aventually make something
> simmilar for other web servers if there will be enough interest, or make a
> generic 'apr/apr-util' like library, so everything that uses 'ap_xxx' calls
> should go in mod_coyote.
Well if we want mod_coyote included in Apache 2.x tree, we shouldn't
have too much files. Also I'd like to avoid too many wrapper calls
functions.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Henri Gomez wrote:
>
>> Second reference to mod_coyote ?
>>
>> Should we retains this one ?
>
>
> Maybe ;)
> We have two connectors planned. This one will use AJP, while the other
> would use JNI, so we need two, different, non confusing names. So naming
> this mod_jk3 would be bad, just like naming the two mod_coyote1 and
> mod_coyote2.
>
> So when will we get all these new shiny toys ? :)
Well we should first discuss for :
- a name :)
- what features will be mandatory in the initial release.
- library/modules repartition
You speak about AJP and JNI, so I suggest 2 differents projets :
mod_ajp
mod_jni
Both will be Apache 2.x modules to link an Apache web-server with
tomcat(s) using AJP 1.3++ (AJP 1.4) protocol (mod_ajp) or JNI
connectiviy (mod_jni).
I could works on mod_ajp, taking the best parts of jk/jk2, and putting
the basic bricks in an ajp library. Of course we'll need to see how to
make this ajp library with real world, for instance I think we could
follow the Mladen idea, ie having a configuration structure (tree)
located in memory and updated via call to the API :
ajp_config_t * create_ajp_config();
int add_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk);
int remove_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk);
int update_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk);
int destroy_ajp_config(ajp_config_t * conf);
Ad minima we should have workers in the configuration.
To remove the work to rewrite the URI to worker part,
we could start with a mapping using Apache 2 directive
ie Location/EnvVars/Files...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> Second reference to mod_coyote ?
>
> Should we retains this one ?
Maybe ;)
We have two connectors planned. This one will use AJP, while the other
would use JNI, so we need two, different, non confusing names. So naming
this mod_jk3 would be bad, just like naming the two mod_coyote1 and
mod_coyote2.
So when will we get all these new shiny toys ? :)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>
>>>For example majors Linux distributions are now using Apache
>>
>>2 instead
>>
>>>of Apache 1.3. So Apache 2.x will be more and more used.
>>
>>When not running inside Apache, there are tons of things when
>>cannot use, including configuration. So the best is indeed to
>>keep JK around for supporting other servers. One of the big
>>problems is that it would be best to keep developing either
>>jk 1.2.x or jk 2.0.x, but not both ;)
>>
>
>
> Ok, but let's try to make the code 'reusable', protocol and basic config
> tree should be in a separate files, so that we can aventually make something
> simmilar for other web servers if there will be enough interest, or make a
> generic 'apr/apr-util' like library, so everything that uses 'ap_xxx' calls
> should go in mod_coyote.
Second reference to mod_coyote ?
Should we retains this one ?
Remy :;)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Remy Maucherat
>
> > For example majors Linux distributions are now using Apache
> 2 instead
> > of Apache 1.3. So Apache 2.x will be more and more used.
>
> When not running inside Apache, there are tons of things when
> cannot use, including configuration. So the best is indeed to
> keep JK around for supporting other servers. One of the big
> problems is that it would be best to keep developing either
> jk 1.2.x or jk 2.0.x, but not both ;)
>
Ok, but let's try to make the code 'reusable', protocol and basic config
tree should be in a separate files, so that we can aventually make something
simmilar for other web servers if there will be enough interest, or make a
generic 'apr/apr-util' like library, so everything that uses 'ap_xxx' calls
should go in mod_coyote.
MT.
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Some JK2 ideas v.3
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
> Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
> could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
> No more code complexity to handle all the web-servers around,
> we should focus on Apache 2.x.
Yes. A lot of the complexity is to allow running with many servers,
having custom configuration, etc. Apache 2 is now (finally) getting
significant deployments numbers, and is bundled in many distributions,
so adding special support for it makes sense (as long as we can
distribute our module in their codebase, otherwise it's less interesting).
> For example majors Linux distributions are now using Apache 2 instead
> of Apache 1.3. So Apache 2.x will be more and more used.
When not running inside Apache, there are tons of things when cannot
use, including configuration. So the best is indeed to keep JK around
for supporting other servers. One of the big problems is that it would
be best to keep developing either jk 1.2.x or jk 2.0.x, but not both ;)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>We should first determine if Apache2 will have to monitor a
>>service/system links to the various tomcats (in cluster
>>configuration) to learn about real-time topology.
>>
>
>
> In fact, that is why I've pursued the .xml config over the current one.
> The main idea is to _internally_ have config tree (right now we don't have
> that).
> So that internal configuration tree will be populated either using
> directives in the native httpd.conf or reading server.xml stream from TC or
> from file.
Of course we should have somewhere in the new module the configuration
tree in whatever native format we could imagine, apr_map maybe or
apr_xml_tree if existing.
>
>>>- the configuration should be in Apache's config file, rather than
>>>some complex properties file
>>
>>+1
>>
>
>
> The general idea is to connect to TC and get the URI/VHOST topology, but we
> still need the 'intervene' directives for connector specific ones.
> How to make them simpler to use the JK and JK2?
>
> Perhaps using something like:
>
> <CoyoteWorker workerA>
> ...directives
>
> </CoyoteWorker>
I agreed for this on worker configuration in httpd.conf.
> And then:
>
> <Files *.jsp>
> CoyoteUsesWorker workerA
> </Files>
ok.
We should also be able to handle :
<Location /myspecialurl>
CoyoteUsesWorker workerA
</Files>
Something very familiar to Apache admins.
>>>- it should work well with other modules (I guess if somehow it is
>>>accepted into the Apache codebase, it will be required)
>>
>>That's why we should focus on Apache 2 only module.
>>
>
>
> Not sure I'm in favor of that (unless you meant dropping 1.3 module by
> that).
Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
No more code complexity to handle all the web-servers around,
we should focus on Apache 2.x.
For example majors Linux distributions are now using Apache 2 instead of
Apache 1.3. So Apache 2.x will be more and more used.
> Without having a common codebase and API that can be used outside Apache2?
We should discuss what will be in the API, some will be only APR
dependant, but of course many will be dependant of Apache 2.x, for
examples Apache requests.
But we could see simple call, like :
int xxx_forward_simple_request(
xxx_worker_t *,
apr_pool_t * req_uri,
apr_pool_t * reply_data);
int xxx_forward_simple_post_request(
xxx_worker_t *,
apr_pool_t * req_uri,
apr_pool_t * post_data,
apr_pool_t * reply_data);
int xxx_forward_full_request(
xxx_worker_t *,
apr_pool_t * req_uri,
apr_table_t * headers,
apr_pool_t * post_data,
apr_pool_t * reply_data);
> In that case why not write only proxy_coyote for mod_proxy?
Since it will be nice to be able to be warned in mod_xxx
from real-time topology updates, ie application down on one
tomcat, new application on another tomcat, cluster updates...
>>>- I think the protocol should be an extension of AJP/1.3
>>
>>I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it
>>could be a good candidate. In my idea we should start to
>>write an APR based
>>AJP/1.4 library, which could be first used outside Apache 2
>>server for test and benchs purposes.
>>
>
>
> +1, but in contradiction with previous :).
> I would also like to see the gzip like extension to AJP/xx for lowering the
> data transfer.
It was proposed some times ago together with some light crypto to secure
apache - tomcat link when you're not in a secure network. All of these
could be made optional in protocol negociation side of AJP/14...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> We should first determine if Apache2 will have to monitor a
> service/system links to the various tomcats (in cluster
> configuration) to learn about real-time topology.
>
In fact, that is why I've pursued the .xml config over the current one.
The main idea is to _internally_ have config tree (right now we don't have
that).
So that internal configuration tree will be populated either using
directives in the native httpd.conf or reading server.xml stream from TC or
from file.
>
> > - the configuration should be in Apache's config file, rather than
> > some complex properties file
>
> +1
>
The general idea is to connect to TC and get the URI/VHOST topology, but we
still need the 'intervene' directives for connector specific ones.
How to make them simpler to use the JK and JK2?
Perhaps using something like:
<CoyoteWorker workerA>
...directives
</CoyoteWorker>
And then:
<Files *.jsp>
CoyoteUsesWorker workerA
</Files>
> > - it should work well with other modules (I guess if somehow it is
> > accepted into the Apache codebase, it will be required)
>
> That's why we should focus on Apache 2 only module.
>
Not sure I'm in favor of that (unless you meant dropping 1.3 module by
that).
Without having a common codebase and API that can be used outside Apache2?
In that case why not write only proxy_coyote for mod_proxy?
> > - I think the protocol should be an extension of AJP/1.3
>
> I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it
> could be a good candidate. In my idea we should start to
> write an APR based
> AJP/1.4 library, which could be first used outside Apache 2
> server for test and benchs purposes.
>
+1, but in contradiction with previous :).
I would also like to see the gzip like extension to AJP/xx for lowering the
data transfer.
MT.
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
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
Of course.
> - it should have a name which doesn't confuse folks :)
mod_whatever, I was thinking for something like mod_coyote or mod_jtc.
> - 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
> - it should try to optimize keepalive if possible for performance
No idea, should take a look more in Apache 2.x :)
> - it should support quality of service (messages to notify that a webapp
> is being serviced on one node, etc)
Simple extensions to ajp13 / ajp14.
We should first determine if Apache2 will have to monitor a
service/system links to the various tomcats (in cluster configuration)
to learn about real-time topology.
> - (nice to have) it should be possible to configure the cluster dynamically
See previous comment.
> - 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)
oki
> - the configuration should be in Apache's config file, rather than some
> complex properties file
+1
> - it should have good defaults (I like good defaults :) )
Well we should at least know a default worker.
> - it should work well with other modules (I guess if somehow it is
> accepted into the Apache codebase, it will be required)
That's why we should focus on Apache 2 only module.
> - I think the protocol should be an extension of AJP/1.3
I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could be
a good candidate. In my idea we should start to write an APR based
AJP/1.4 library, which could be first used outside Apache 2 server
for test and benchs purposes.
Also we should start with something working with both TC 3.3.x, 4.1.x
and 5.x.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> 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
>
>
> +1
>
>> - 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 ).
Well AJP/1.3 exist on TC 3.3.x, 4.1.x and 5.x.
Adding some Ajp/1.3++ features is just evolution, not a complete rewrite
like an XDR based coyote connector.
>> - 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.
Many and add minima that HTTPD 2.0 didn't require JNI. Frankly I'd
prefer to see JNI in a mod_java project instead...
> 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"
JNI stuff could goes in mod_jni/mod_java, less complexity, no
users/admins questions about auto-configuring/compiling/setup...
=> Better acceptation by Apache 2.x admins for the mod_ajp module
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
>> The AJP13 protocol will have to be enhanced (or better enabled) to use
>> the
>> 'Service channel' and 'Data Filter'. It is not necessary to define all
>> Service channel modes like server topology, or server readiness,
>> neither to
>> define all the Data Filter modes like cryptography or compression. I was
>> thinking of something like 'extensions' to the protocol, meaning that one
>> can extend the protocol to some desired level.
> Yes.
>
> My initial idea for AJP/1.4 wass to mix on the same wire request
> forwaring which is the core functionnality of AJP/1.3 with system
> messaging.
>
> - Service channel is a channel to send/received update between Apache
> and Tomcats :
>
> - Negociation between Apache and Tomcat.
>
> * Should we use an authentification scheme between Apache and
> Tomcat (ajp1.3 make that Tomcat trust any Web server
> caming via AJP13).
>
> * Should we compress the requests/replies
>
> * Should we crypt the requests/replies.
>
> - Web Applications state updates :
>
> * a Web Application is added
>
> * a Web Application is removed
>
>
> - Updates in cluster configurations :
>
> * worker1 was handling 25% of total load, now it could handle
> 35%.
>
> * worker2 in cluster is down for maintenance....
>
> * Apache 2 could use worker3 for this cluster, it could reach it
> at IP/PORT....
This sound like a lot of features. I'm sure others will be added to the
list by other people. That is my concern - it seems the assumption is
this will be a very simple module, so there is no need for modularity or
a flexible design. On the other side, just like in all other "it's
going to be very simple" cases, features will keep piling.
It's one thing to have just apache2 module and ajp13 ( and nothing
more), another thing to have all the above.
The real problem is:
1. figuring the list of features.
- I agree multiple protocols ( incl jni) and multiple servers should be
droped.
- We seem to agree on having "cluster reconfiguration" feature.
- I'm not sure if we agree or not on dynamic add/remove of webapps.
- It seems I'm alone in wanting monitoring and finer reconfiguration.
- we agree on strong integration with the server
- I'm not sure about about the "add/remove" of webapps versus "strong
integration" - I haven't seen any answer on how they can work togheter,
it seems Mladen solves this by removing "add remove webapps", which IMO
is bad. I just don't know how you can have both at the same time - the
only solution I found so far is to have 2 operating modes.
2. design. It seems a lot of people believe this will stay "simple" and
there is no need for a flexible design (i.e. components, etc ). If it
is a clear understanding that the feature list will be frozen - i.e. if
you want more features, you'll need to write a new module from scratch
and not reuse anything from this - then it may work, but I never seen
this happening in open source.
If C-Mbeans are too complicated - then maybe we can use GObject ( from
gnome ) or XPCom components ( from mozilla ) ( or some subset of it).
But please, don't start another "simple" project that in a year will
have to be rewritten. Object oriented programming does have some value:-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>Ideally since we could have a cluster of Apache WebServer
>>linked to a cluster of Tomcat ServletEngines, and that member
>>could enter or exit these 2 clusters we should have something
>>using Multicast (ideally a native JavaGroups) for both side.
>>
>
>
> Wow, you've push it to the limit :)
>
>
>>With such the configuration in both Web and Tomcat clusters
>>will be to enter a Service Channel where all members will get
>>all the services messages and handle them accordingly ?
>>
>>What about multicast support in APR ?
>>
>
>
> Each node would need both server and client listeners, so they can exchange
> service messages.
>
> But I'm not sure that I wish to see that in the core itself. It brings an
> extra complexity that is needed in 'not-an-everyday usage'.
> Something like should either be a different project or at least manageable
> at compile time.
No this settings will be for mod_ajp 2.x :)
We should focus now on mod_ajp 1.0 ....
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> Ideally since we could have a cluster of Apache WebServer
> linked to a cluster of Tomcat ServletEngines, and that member
> could enter or exit these 2 clusters we should have something
> using Multicast (ideally a native JavaGroups) for both side.
>
Wow, you've push it to the limit :)
> With such the configuration in both Web and Tomcat clusters
> will be to enter a Service Channel where all members will get
> all the services messages and handle them accordingly ?
>
> What about multicast support in APR ?
>
Each node would need both server and client listeners, so they can exchange
service messages.
But I'm not sure that I wish to see that in the core itself. It brings an
extra complexity that is needed in 'not-an-everyday usage'.
Something like should either be a different project or at least manageable
at compile time.
MT.
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Henri Gomez wrote:
> Mladen Turk wrote:
>
>> The AJP13 protocol will have to be enhanced (or better enabled) to use
>> the
>> 'Service channel' and 'Data Filter'. It is not necessary to define all
>> Service channel modes like server topology, or server readiness,
>> neither to
>> define all the Data Filter modes like cryptography or compression. I was
>> thinking of something like 'extensions' to the protocol, meaning that one
>> can extend the protocol to some desired level.
>
>
> Yes.
>
> My initial idea for AJP/1.4 wass to mix on the same wire request
> forwaring which is the core functionnality of AJP/1.3 with system
> messaging.
>
> - Service channel is a channel to send/received update between Apache
> and Tomcats :
>
> - Negociation between Apache and Tomcat.
>
> * Should we use an authentification scheme between Apache and
> Tomcat (ajp1.3 make that Tomcat trust any Web server
> caming via AJP13).
>
> * Should we compress the requests/replies
>
> * Should we crypt the requests/replies.
>
> - Web Applications state updates :
>
> * a Web Application is added
>
> * a Web Application is removed
>
>
> - Updates in cluster configurations :
>
> * worker1 was handling 25% of total load, now it could handle
> 35%.
>
> * worker2 in cluster is down for maintenance....
>
> * Apache 2 could use worker3 for this cluster, it could reach it
> at IP/PORT....
Ideally since we could have a cluster of Apache WebServer linked to a
cluster of Tomcat ServletEngines, and that member could enter or exit
these 2 clusters we should have something using Multicast (ideally a
native JavaGroups) for both side.
With such the configuration in both Web and Tomcat clusters will be
to enter a Service Channel where all members will get all the services
messages and handle them accordingly ?
What about multicast support in APR ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
>> The AJP13 protocol will have to be enhanced (or better enabled) to use
>> the
>> 'Service channel' and 'Data Filter'. It is not necessary to define all
>> Service channel modes like server topology, or server readiness,
>> neither to
>> define all the Data Filter modes like cryptography or compression. I was
>> thinking of something like 'extensions' to the protocol, meaning that one
>> can extend the protocol to some desired level.
> Yes.
>
> My initial idea for AJP/1.4 wass to mix on the same wire request
> forwaring which is the core functionnality of AJP/1.3 with system
> messaging.
>
> - Service channel is a channel to send/received update between Apache
> and Tomcats :
>
> - Negociation between Apache and Tomcat.
>
> * Should we use an authentification scheme between Apache and
> Tomcat (ajp1.3 make that Tomcat trust any Web server
> caming via AJP13).
>
> * Should we compress the requests/replies
>
> * Should we crypt the requests/replies.
>
> - Web Applications state updates :
>
> * a Web Application is added
>
> * a Web Application is removed
>
>
> - Updates in cluster configurations :
>
> * worker1 was handling 25% of total load, now it could handle
> 35%.
>
> * worker2 in cluster is down for maintenance....
>
> * Apache 2 could use worker3 for this cluster, it could reach it
> at IP/PORT....
This sound like a lot of features. I'm sure others will be added to the
list by other people. That is my concern - it seems the assumption is
this will be a very simple module, so there is no need for modularity or
a flexible design. On the other side, just like in all other "it's
going to be very simple" cases, features will keep piling.
It's one thing to have just apache2 module and ajp13 ( and nothing
more), another thing to have all the above.
The real problem is:
1. figuring the list of features.
- I agree multiple protocols ( incl jni) and multiple servers should be
droped.
- We seem to agree on having "cluster reconfiguration" feature.
- I'm not sure if we agree or not on dynamic add/remove of webapps.
- It seems I'm alone in wanting monitoring and finer reconfiguration.
- we agree on strong integration with the server
- I'm not sure about about the "add/remove" of webapps versus "strong
integration" - I haven't seen any answer on how they can work togheter,
it seems Mladen solves this by removing "add remove webapps", which IMO
is bad. I just don't know how you can have both at the same time - the
only solution I found so far is to have 2 operating modes.
2. design. It seems a lot of people believe this will stay "simple" and
there is no need for a flexible design (i.e. components, etc ). If it
is a clear understanding that the feature list will be frozen - i.e. if
you want more features, you'll need to write a new module from scratch
and not reuse anything from this - then it may work, but I never seen
this happening in open source.
If C-Mbeans are too complicated - then maybe we can use GObject ( from
gnome ) or XPCom components ( from mozilla ) ( or some subset of it).
But please, don't start another "simple" project that in a year will
have to be rewritten. Object oriented programming does have some value:-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>>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"
>>
>>
>>All that is cool, but what you propose looks a lot like JK 2
>>(JMX dynamic features, support for many webservers, etc), and
>>we know that almost no developer understands it anymore. This
>>clashes head on with the "it has to be simple" requirement:
>>how do you expect the issue to be solved ?
>>
>>This is the point about dropping server portability, among
>>other things.
>>Sorry to say it aloud, but for new developments I don't care
>>about IIS (it should die) nor Apache 1.3, which are the two
>>other servers that matter. To support these, we have mod_jk
>>1.2 (and too bad if people don't get the extra features).
>>
>
>
> I agree with you.
> We've tried to hard to mix a bunch of different concepts together.
> At some time the JNI even worked, but only on single-child servers (Apache2
> on Win32 and IIS).
>
> IMO we should focus on the 'APR/APR-UTIL' based protocol and TCP/IP
> transport for now, with in memory config dynamically updatable via API
> calls, using as little as possible specific 'ap_xxx' calls. I like the
> Henri's idea to have a little lib and a small app like ab, to test the
> protocol, and all core functionality. It would be a tremendous achievement
> to be able to effectively test the core module functionality without server
> itself. It would give a common playground for protocol testing, auto-config,
> etc...
>
> The JNI is totally different, cause you can have only one VM per Apache2
> instance, but you can have 100+ forked childs each trying to load it's own
> VM, so the inprocess TC instance has a very limited usability, and is very
> server specific.
>
> IIS is also something different, and if one wish to write the good extension
> it has to be done in a different way.
> Still, some core functionality can be reused, but not making some 'common'
> code, but rather making common codebase, that some inexperienced (in a
> JK/JK2 sense) developer will be able to cope with.
>
> I agree with Costin that the JMX is a great stuff, but not if we wish to
> build a simple and _reliable_ module with finite (or static like Costin
> said) set of functionality.
>
> The AJP13 protocol will have to be enhanced (or better enabled) to use the
> 'Service channel' and 'Data Filter'. It is not necessary to define all
> Service channel modes like server topology, or server readiness, neither to
> define all the Data Filter modes like cryptography or compression. I was
> thinking of something like 'extensions' to the protocol, meaning that one
> can extend the protocol to some desired level.
Yes.
My initial idea for AJP/1.4 wass to mix on the same wire request
forwaring which is the core functionnality of AJP/1.3 with system messaging.
- Service channel is a channel to send/received update between Apache
and Tomcats :
- Negociation between Apache and Tomcat.
* Should we use an authentification scheme between Apache and
Tomcat (ajp1.3 make that Tomcat trust any Web server
caming via AJP13).
* Should we compress the requests/replies
* Should we crypt the requests/replies.
- Web Applications state updates :
* a Web Application is added
* a Web Application is removed
- Updates in cluster configurations :
* worker1 was handling 25% of total load, now it could handle
35%.
* worker2 in cluster is down for maintenance....
* Apache 2 could use worker3 for this cluster, it could reach it
at IP/PORT....
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Remy Maucherat
> >
> > 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"
>
>
> All that is cool, but what you propose looks a lot like JK 2
> (JMX dynamic features, support for many webservers, etc), and
> we know that almost no developer understands it anymore. This
> clashes head on with the "it has to be simple" requirement:
> how do you expect the issue to be solved ?
>
> This is the point about dropping server portability, among
> other things.
> Sorry to say it aloud, but for new developments I don't care
> about IIS (it should die) nor Apache 1.3, which are the two
> other servers that matter. To support these, we have mod_jk
> 1.2 (and too bad if people don't get the extra features).
>
I agree with you.
We've tried to hard to mix a bunch of different concepts together.
At some time the JNI even worked, but only on single-child servers (Apache2
on Win32 and IIS).
IMO we should focus on the 'APR/APR-UTIL' based protocol and TCP/IP
transport for now, with in memory config dynamically updatable via API
calls, using as little as possible specific 'ap_xxx' calls. I like the
Henri's idea to have a little lib and a small app like ab, to test the
protocol, and all core functionality. It would be a tremendous achievement
to be able to effectively test the core module functionality without server
itself. It would give a common playground for protocol testing, auto-config,
etc...
The JNI is totally different, cause you can have only one VM per Apache2
instance, but you can have 100+ forked childs each trying to load it's own
VM, so the inprocess TC instance has a very limited usability, and is very
server specific.
IIS is also something different, and if one wish to write the good extension
it has to be done in a different way.
Still, some core functionality can be reused, but not making some 'common'
code, but rather making common codebase, that some inexperienced (in a
JK/JK2 sense) developer will be able to cope with.
I agree with Costin that the JMX is a great stuff, but not if we wish to
build a simple and _reliable_ module with finite (or static like Costin
said) set of functionality.
The AJP13 protocol will have to be enhanced (or better enabled) to use the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness, neither to
define all the Data Filter modes like cryptography or compression. I was
thinking of something like 'extensions' to the protocol, meaning that one
can extend the protocol to some desired level.
MT.
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Remy Maucherat wrote:
>>
>>>
>>> I think you're mixing the Java side with the native side. I think the
>>> Java side should obviously use JMX to monitor what's going on with
>>> Tomcat. However, the native side will just recieve proprietary messages.
>>> We have to keep the native side as small and simple as possible to
>>> get into the HTTPD codebase.
>>
>>
>>
>> No, I'm only talking about the C side. Let's call it C-JMX.
>>
>> Instead of yet-another "small and simple" connector that grows out of
>> control, it may be better to learn a lesson from java and apply it in C.
>> Jk and Jk2 ( and mod_jserv ) all started "small and simple", then got
>> more and more features and fixes.
>>
>> If we start with "just add custom proprietary messages for every
>> feature we want to implement" - the code will soon become very
>> complex. Most of the messages are not in the critical path, so using a
>> JMX model of get/set/event is reasonable.
>>
>> Monitoring and controlling the native code from java is IMO quite
>> usefull and important by itself. Even Apache supports limited
>> monitoring ( SNMP, mod_status, etc ).
>
>
> Ok. We'll see if I'm more convinced when you show your code ;) For now,
> I'm siding with Henri and his proposed solution.
I'd like to heard some Apache 2 specialists here, may be some core HTTPD
developpers since after all we're discussing an Apache 2.x module.
I'll send an invitation to them in httpd-dev...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
> But we don't wish to write something modular and unlimitedly extendable.
> Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
> Having that in mind, we have APR, and 'almost' a finite set of requirements,
> without the need to 'think modular' or 'think cross-webserver'.
I understand this, and it is a good idea. I'm ok to drop "multi server"
and "multiple protocols" or "extensible" and "jni".
The only point I strongly disagree is droping the "monitoring" and
"runtime re-configuration". Tomcat is a dynamic server, people are using
it to deploy and modify webapps all the time - editing httpd.conf and
restarting the server on each change is not the right solution.
> Also making any additional 'features' to the connector (like 'discovery'
> etc.) would have to be made as such, and enabled during compile time, so
> that the basic functionality remains as is. This means that we don't compile
> everything and then use the config to either enable or disable features, but
> rather make something like 'mpm concept' selectable at compile time.
Well, I also disagree with this :-), enabling/disabling discovery or
other features should be done at runtime. I don't like too many
./configure options.
>>Seriously - if you take away the JMX and support for other
>>servers - why not just use mod_jserv ?
>
>
> No one prevents you of making mod_jmx that will allow entire Apache2 to be
> maintainable trough JMX console, not only our module :).
Unfortunately - adding monitoring and runtime reconfiguration requires a
certain design. Some parts of apache can be monitored, but not much (
certainly not the modules - unless you hack something and look in their
private data structures ). Reconfiguration is even harder without having
it in the design.
As I said, what you describe - basic protocol only and only apache - is
already available in mod_jserv, it just needs porting to apache2. Why
would you want to write another module doing the same thing ?
> If you wish to write a good Apache2 module or IIS filter, they have to be
> different projects. Also being usable from admins point of view requires
> that the apache module is configurable trough httpd.conf, and IIS trough
> GUI. None of them uses JMX to configure the webserver thought.
None of the web servers support the dynamic webapp adding or clustering
and all the feture that tomcat supports. I think monitoring and
reconfiguration is a must feature for a servlet container, and that also
means the web server connector should have basic support for it.
> Think that the main problem is that we don't understand the JK2 code any
> more, and that the modularity combined with crosswebserver became an
> obstacle rather then a feature.
No problem, drop both ( and multiple protocol as well ). But don't drop
features that actually matter.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
> Costin Manolache wrote
>
>>I can understand the jk2 "object oriented C" is considered
>>too complex.
>
>
> True.
>
>
>>But I certainly can't agree on a design that is not modular
>>and doesn't support this basic requirement. We already have
>>mod_jserv and mod_webapp
>> - and a long history of "rewrite from scratch to make it simpler"
>>turning into far more complex code.
>>
>
>
> But we don't wish to write something modular and unlimitedly extendable.
> Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
> Having that in mind, we have APR, and 'almost' a finite set of requirements,
> without the need to 'think modular' or 'think cross-webserver'.
> Lot of the code would be reusable, but it would mean that making a mod_jni
> connector would mean to make a completely different project without some
> common directory holding shareable code.
>
> Also making any additional 'features' to the connector (like 'discovery'
> etc.) would have to be made as such, and enabled during compile time, so
> that the basic functionality remains as is. This means that we don't compile
> everything and then use the config to either enable or disable features, but
> rather make something like 'mpm concept' selectable at compile time.
>
>
>>Seriously - if you take away the JMX and support for other
>>servers - why not just use mod_jserv ?
>
>
> No one prevents you of making mod_jmx that will allow entire Apache2 to be
> maintainable trough JMX console, not only our module :).
A great idea, but probably something which should be a whole new module,
mod_jmx or mod_cmx (C Management Extension). I'm sure the HTTPD team
will be more than pleased to discuss this.
> Regarding other servers you meant IIS (other are less then couple of
> percent) probably (apache13 users can use jk). I would like to make the
> 'real' IIS6 filter that will go in the NT kernel's http.sys, have dynamic
> thread pool and MMC snap-in, but that is something completely different. Few
> things like config tree, ajp protocol and transport can be reused cause now
> we have the APR that generalizes the OS layer.
> If you wish to write a good Apache2 module or IIS filter, they have to be
> different projects. Also being usable from admins point of view requires
> that the apache module is configurable trough httpd.conf, and IIS trough
> GUI. None of them uses JMX to configure the webserver thought.
>
> I have on my dash-board for a long time a project that will make a TC as a
> main web server, having Apache as a 'slave' for additional PHP and Perl
> support, but that also is something completely different and questionably
> usable.
>
>
>>After all mod_jk and
>>jk2 got complex because of additional requirements and
>>features that we wanted to implement - if we drop them then
>>we can just go back and use mod_jserv.
>>
>
>
> Think that the main problem is that we don't understand the JK2 code any
> more, and that the modularity combined with crosswebserver became an
> obstacle rather then a feature.
Yes, that's a perfect resume of the current situation.
I don't have problem with writing clean C to make something
JMX/CMXizable but it appears to add some complexity.
Just take a look at the actual code in jk2 :(
...
int JK_METHOD jk2_channel_setAttribute(jk_env_t *env,
jk_bean_t *mbean,
char *name, void *valueP)
{
jk_channel_t *ch = (jk_channel_t *)mbean->object;
char *value = valueP;
if (strcmp("debug", name) == 0) {
ch->mbean->debug = atoi(value);
}
else if (strcmp("disabled", name) == 0) {
ch->mbean->disabled = atoi(value);
if (ch->worker != NULL)
ch->worker->mbean->disabled = ch->mbean->disabled;
}
else {
if (ch->worker != NULL) {
return ch->worker->mbean->setAttribute(env, ch->worker->mbean,
name, valueP);
}
return JK_ERR;
}
return JK_OK;
}
...
The problem with C is there is no introspection helper so we have
to do many things by hand and it tend to 'offuscate' the real code.
I'd rather like simple C way:
int ajp_channel_setDebug(jk_channel_t * channel, int debuglevel);
int ajp_channel_setState(jk_channel_t * channel, int state);
int ajp_channel_open(jk_channel_t * channel);
int ajp_channel_close(jk_channel_t * channel);
int ajp_channel_read(jk_channel_t * channel, apr_pool_t * buf);
int ajp_channel_write(jk_channel_t * channel, apr_pool_t * buf);
int ajp_channel_hasInput(jk_channel_t * channel);
That's one of the reason I suggested a specific Apache 2.x module,
to follow the HTTPD dev team habbits which are still plain C.
May be a pre-requisite to go farther will be to discuss with them
what should be a CBean ?
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
Costin Manolache wrote
>
> I can understand the jk2 "object oriented C" is considered
> too complex.
True.
> But I certainly can't agree on a design that is not modular
> and doesn't support this basic requirement. We already have
> mod_jserv and mod_webapp
> - and a long history of "rewrite from scratch to make it simpler"
> turning into far more complex code.
>
But we don't wish to write something modular and unlimitedly extendable.
Just the load-balancing-ajp13+ over tcp/ip connector, for Apache2.
Having that in mind, we have APR, and 'almost' a finite set of requirements,
without the need to 'think modular' or 'think cross-webserver'.
Lot of the code would be reusable, but it would mean that making a mod_jni
connector would mean to make a completely different project without some
common directory holding shareable code.
Also making any additional 'features' to the connector (like 'discovery'
etc.) would have to be made as such, and enabled during compile time, so
that the basic functionality remains as is. This means that we don't compile
everything and then use the config to either enable or disable features, but
rather make something like 'mpm concept' selectable at compile time.
> Seriously - if you take away the JMX and support for other
> servers - why not just use mod_jserv ?
No one prevents you of making mod_jmx that will allow entire Apache2 to be
maintainable trough JMX console, not only our module :).
Regarding other servers you meant IIS (other are less then couple of
percent) probably (apache13 users can use jk). I would like to make the
'real' IIS6 filter that will go in the NT kernel's http.sys, have dynamic
thread pool and MMC snap-in, but that is something completely different. Few
things like config tree, ajp protocol and transport can be reused cause now
we have the APR that generalizes the OS layer.
If you wish to write a good Apache2 module or IIS filter, they have to be
different projects. Also being usable from admins point of view requires
that the apache module is configurable trough httpd.conf, and IIS trough
GUI. None of them uses JMX to configure the webserver thought.
I have on my dash-board for a long time a project that will make a TC as a
main web server, having Apache as a 'slave' for additional PHP and Perl
support, but that also is something completely different and questionably
usable.
> After all mod_jk and
> jk2 got complex because of additional requirements and
> features that we wanted to implement - if we drop them then
> we can just go back and use mod_jserv.
>
Think that the main problem is that we don't understand the JK2 code any
more, and that the modularity combined with crosswebserver became an
obstacle rather then a feature.
MT.
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>>
>> Monitoring and controlling the native code from java is IMO quite
>> usefull and important by itself. Even Apache supports limited
>> monitoring ( SNMP, mod_status, etc ).
>
>
> Ok. We'll see if I'm more convinced when you show your code ;) For now,
> I'm siding with Henri and his proposed solution.
Which proposed solution ? To drop "dynamic monitoring and
reconfiguration" from requirements ?
So far I haven't even seen a final list of requirements for this new
connector, and no design. We only have some ideas - most of them mapping
to the drop of some requirements ( which is fine ). It is also clear we
don't have any clear decision on how to solve the conflicting
requirements. Henri is talking about some "discovery" requirement, and
some other people talked about "discovery" for the cluster - how does
this interact with the other requirement of "use httpd.conf and play
nice with other modules" ?
Regarding "show me code" - I don't have to write a complex pice of code
to prove my point. KDE DCOP ( and to a lesser extent, Gnome ) are good
example of components that allow control from outside. We don't need
something as complex ( well, dcop is not very complex, only the
qt-depenent dispatching ).
I can understand the jk2 "object oriented C" is considered too complex.
But I certainly can't agree on a design that is not modular and doesn't
support this basic requirement. We already have mod_jserv and mod_webapp
- and a long history of "rewrite from scratch to make it simpler"
turning into far more complex code.
Seriously - if you take away the JMX and support for other servers - why
not just use mod_jserv ? After all mod_jk and jk2 got complex because of
additional requirements and features that we wanted to implement - if we
drop them then we can just go back and use mod_jserv.
In any case - I haven't been very active lately, and my current interest
is on the java side, so I can't vote -1. But it would really be bad if
this will start without even having an agreed list of requirements, and
a design that is based on the requirements and takes into account the
future ( "simple" is a nice word, but if it is not based on a sound
design it's just a matter of time until it becomes unmaintainable
complex ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>>
>> I think you're mixing the Java side with the native side. I think the
>> Java side should obviously use JMX to monitor what's going on with
>> Tomcat. However, the native side will just recieve proprietary messages.
>> We have to keep the native side as small and simple as possible to
>> get into the HTTPD codebase.
>
>
> No, I'm only talking about the C side. Let's call it C-JMX.
>
> Instead of yet-another "small and simple" connector that grows out of
> control, it may be better to learn a lesson from java and apply it in C.
> Jk and Jk2 ( and mod_jserv ) all started "small and simple", then got
> more and more features and fixes.
>
> If we start with "just add custom proprietary messages for every
> feature we want to implement" - the code will soon become very
> complex. Most of the messages are not in the critical path, so using a
> JMX model of get/set/event is reasonable.
>
> Monitoring and controlling the native code from java is IMO quite
> usefull and important by itself. Even Apache supports limited
> monitoring ( SNMP, mod_status, etc ).
Ok. We'll see if I'm more convinced when you show your code ;) For now,
I'm siding with Henri and his proposed solution.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
>
> I think you're mixing the Java side with the native side. I think the
> Java side should obviously use JMX to monitor what's going on with
> Tomcat. However, the native side will just recieve proprietary messages.
> We have to keep the native side as small and simple as possible to get
> into the HTTPD codebase.
No, I'm only talking about the C side. Let's call it C-JMX.
Instead of yet-another "small and simple" connector that grows out of
control, it may be better to learn a lesson from java and apply it in C.
Jk and Jk2 ( and mod_jserv ) all started "small and simple", then got
more and more features and fixes.
If we start with "just add custom proprietary messages for every feature
we want to implement" - the code will soon become very complex. Most of
the messages are not in the critical path, so using a JMX model of
get/set/event is reasonable.
Monitoring and controlling the native code from java is IMO quite
usefull and important by itself. Even Apache supports limited monitoring
( SNMP, mod_status, etc ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>> Costin Manolache wrote:
>>
>>> 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"
>>
>>
>>
>>
>> All that is cool, but what you propose looks a lot like JK 2 (JMX
>> dynamic features, support for many webservers, etc), and we know that
>> almost no developer understands it anymore. This clashes head on with
>> the "it has to be simple" requirement: how do you expect the issue to
>> be solved ?
>
>
>
> JMX seems to simplify tomcat5 pretty well, and I think it would be a
> big lost if we would say 'let's simplify tomcat5 and remove jmx'.
>
> If you don't have the ability to deal with the changes in the cluster
> and the added/removed webapps - why bother, just use mod_proxy and
> you're done. Why write a special connector if it wouldn't take
> advantage of almost any tomcat benefit ?
>
> Regarding multiple servers - if JMX, then the code will probably have
> some modularity that would allow this anyway.
>
> One thing is clear - if you start with the idea "let's not have JMX,
> may be will add it later", it'll be impossible to do it. That's what
> we tried in jk2, and it's not very nice. If you start with a dynamic
> design - and take into account the implications on config, code
> structure, etc - then it may be a bit more complex that the "simplest
> connector", however you'll have a good base for future changes.
>
>
>>
>> This is the point about dropping server portability, among other
>> things. Sorry to say it aloud, but for new developments I don't care
>> about IIS (it should die) nor Apache 1.3, which are the two other
>> servers that matter. To support these, we have mod_jk 1.2 (and too
>> bad if people don't get the extra features).
>
>
> One of the things I'm very interested in is getting tomcat "connected"
> with other, non-web server applications. I realize this is crazy and
> most people don't need such a thing - but we all have crazy ideas, and
> it happens that having a generic support that works for IIS or iPlanet
> will also allow other kinds of connectors.
>
> If JMX is used, then it'll require modularity which will then allow
> other connectors based on the same components.
>
> I'm +1 on dropping IIS and apache1.3 BTW.
I think you're mixing the Java side with the native side. I think the
Java side should obviously use JMX to monitor what's going on with
Tomcat. However, the native side will just recieve proprietary messages.
We have to keep the native side as small and simple as possible to get
into the HTTPD codebase.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>> Costin Manolache wrote:
>>
>>> 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"
>>
>>
>>
>>
>> All that is cool, but what you propose looks a lot like JK 2 (JMX
>> dynamic features, support for many webservers, etc), and we know that
>> almost no developer understands it anymore. This clashes head on with
>> the "it has to be simple" requirement: how do you expect the issue to
>> be solved ?
>
>
>
> JMX seems to simplify tomcat5 pretty well, and I think it would be a big
> lost if we would say 'let's simplify tomcat5 and remove jmx'.
>
> If you don't have the ability to deal with the changes in the cluster
> and the added/removed webapps - why bother, just use mod_proxy and
> you're done. Why write a special connector if it wouldn't take
> advantage of almost any tomcat benefit ?
>
> Regarding multiple servers - if JMX, then the code will probably have
> some modularity that would allow this anyway.
>
> One thing is clear - if you start with the idea "let's not have JMX, may
> be will add it later", it'll be impossible to do it. That's what we
> tried in jk2, and it's not very nice. If you start with a dynamic design
> - and take into account the implications on config, code structure, etc
> - then it may be a bit more complex that the "simplest connector",
> however you'll have a good base for future changes.
Well JK2 inherited too many things from the past and add too many
features to be used today.
I'd rather prefer a pragmatic approach :
- step 1: rewrite mod_ajp module with simplicity and Apache 2.x admin
habbits in mind, with simple real worker. Decent documentation about
this first version.
- step 2: add load-balancing support in using ajp/network and
also good documentation about it.
- step 3: add JMX-like features by handling special URL (ajp-handler
or via AJP/1.3 and provide a good JMX support console for it.
>> This is the point about dropping server portability, among other
>> things. Sorry to say it aloud, but for new developments I don't care
>> about IIS (it should die) nor Apache 1.3, which are the two other
>> servers that matter. To support these, we have mod_jk 1.2 (and too bad
>> if people don't get the extra features).
>
>
>
>
> One of the things I'm very interested in is getting tomcat "connected"
> with other, non-web server applications. I realize this is crazy and
> most people don't need such a thing - but we all have crazy ideas, and
> it happens that having a generic support that works for IIS or iPlanet
> will also allow other kinds of connectors.
Don't use mod_ajp for this, but use the ajp library with custom code.
> If JMX is used, then it'll require modularity which will then allow
> other connectors based on the same components.
JMX is great but a good console will be required...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> 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"
>
>
>
> All that is cool, but what you propose looks a lot like JK 2 (JMX
> dynamic features, support for many webservers, etc), and we know that
> almost no developer understands it anymore. This clashes head on with
> the "it has to be simple" requirement: how do you expect the issue to be
> solved ?
JMX seems to simplify tomcat5 pretty well, and I think it would be a big
lost if we would say 'let's simplify tomcat5 and remove jmx'.
If you don't have the ability to deal with the changes in the cluster
and the added/removed webapps - why bother, just use mod_proxy and
you're done. Why write a special connector if it wouldn't take
advantage of almost any tomcat benefit ?
Regarding multiple servers - if JMX, then the code will probably have
some modularity that would allow this anyway.
One thing is clear - if you start with the idea "let's not have JMX, may
be will add it later", it'll be impossible to do it. That's what we
tried in jk2, and it's not very nice. If you start with a dynamic design
- and take into account the implications on config, code structure,
etc - then it may be a bit more complex that the "simplest connector",
however you'll have a good base for future changes.
>
> This is the point about dropping server portability, among other things.
> Sorry to say it aloud, but for new developments I don't care about IIS
> (it should die) nor Apache 1.3, which are the two other servers that
> matter. To support these, we have mod_jk 1.2 (and too bad if people
> don't get the extra features).
One of the things I'm very interested in is getting tomcat "connected"
with other, non-web server applications. I realize this is crazy and
most people don't need such a thing - but we all have crazy ideas, and
it happens that having a generic support that works for IIS or iPlanet
will also allow other kinds of connectors.
If JMX is used, then it'll require modularity which will then allow
other connectors based on the same components.
I'm +1 on dropping IIS and apache1.3 BTW.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> 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"
All that is cool, but what you propose looks a lot like JK 2 (JMX
dynamic features, support for many webservers, etc), and we know that
almost no developer understands it anymore. This clashes head on with
the "it has to be simple" requirement: how do you expect the issue to be
solved ?
This is the point about dropping server portability, among other things.
Sorry to say it aloud, but for new developments I don't care about IIS
(it should die) nor Apache 1.3, which are the two other servers that
matter. To support these, we have mod_jk 1.2 (and too bad if people
don't get the extra features).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Costin Manolache <cm...@yahoo.com>.
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
+1
> - 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"
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Tim Funk <fu...@joedog.org>.
How about mod_tomcat?
-Tim
Mladen Turk wrote:
>>-----Original Message-----
>>From: Remy Maucherat
>>
>
>>- it should have a name which doesn't confuse folks :)
>
>
> APR_JAVA as static core lib + mod_javalink?
>
> For example I wish to make a WIN2003 http.sys kernel module.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.3
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>
>>- it should be simpler than JK 1 or 2
>
>
> That's the general idea
>
>
>>- it should have a name which doesn't confuse folks :)
>
>
> APR_JAVA as static core lib + mod_javalink?
>
> For example I wish to make a WIN2003 http.sys kernel module.
>
>
>>- 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
>
>
> As said in the initial post. The JNI has to be a separate project, as well
> as any other 'bizarre' communication rather then TCP/IP
Agreed for JNI for jk, I'd rather like to see a return of the old
mod_java. TCP/IP and Unix socket could share about 95% of code but
we could start with TCP/IP only.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.3
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Remy Maucherat
>
>
> - it should be simpler than JK 1 or 2
That's the general idea
> - it should have a name which doesn't confuse folks :)
APR_JAVA as static core lib + mod_javalink?
For example I wish to make a WIN2003 http.sys kernel module.
> - 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
As said in the initial post. The JNI has to be a separate project, as well
as any other 'bizarre' communication rather then TCP/IP
MT.
Some JK2 ideas v.3
Posted by Remy Maucherat <re...@apache.org>.
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 :)
- 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
- 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
- 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
- it should have good defaults (I like good defaults :) )
- 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
- 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
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Costin Manolache <cm...@yahoo.com>.
Henri Gomez wrote:
> Costin Manolache wrote:
>
>> Mladen Turk wrote:
>>
>>> Hi,
>>>
>>> All (except Costin) developers has to say something, so my conclusion is
>>> that we are not dead after all ;)
>>
>>
>>
>> I'm alive as well, and I have something to say - I spent last few
>> weekends playing with coyote and tomcat, probably in few weeks I'll
>> have something working and I'll get back.
>>
>>
>>
>>>
>>> Seems that the major obstacle is the configuration, so I propose that we
>>> forget that for a while, and make a
>>> 'generalized' environment that will sattisfy all the 'needs'.
>>> That environment could be called APR_JAVA and it will be resposible for
>>> os->java communication, having AJPXX, and 'JNI' as one of the possible
>>> protocol stacks.
>>
>>
>>
>>
>>> It will have a generic mapping mechanism (pcre enabled) for
>>> registering URI
>>> mapings, setting communication properties, so that one could make a
>>> suport
>>> from any container (webserver).
>>
>>
>>
>> URI mapping is already duplicated in the web server and catalina,
>> please not a third mapper :-)
>
>
> Of course, and we could start with a simple mapper using Location/EnvVar.
If we don't use Location - then even if httpd.conf is used, it'll still
be a different config file, just it'll be inside httpd.conf :-).
Location is what allows it to play with other apache modules and look
natural to apache admins.
>>> It will abstract the container<->java communication to the level of
>>> 'directory and file' so that one can open a connection to TC like
>>> opening a
>>> file, or simply speaking a 'Virtual File System', so that one can either
>>> 'mount' a volume like '/servlets' or a file filter like '*.jsp'
>>
>>
>>
>> Depends on what you want :-). Request forwarding from server and
>> tomcat works reasonably well, it's the other stuff that is hard, and
>> it doesn't map so well to "VFS" model ( auth, conf, etc ).
>
>
> Request forwarding is still the main feature, but we'd like to some
> dynamic topology (webapp discovery, cluster state updates...)
+1
Request forwarding is quite simple - and well understood. The other kind
of communication is the problem. Again, since most of it is off-line (
not in critical path ), a simplified get/set/event model ( JMX-like :-)
might be a good choice ( instead of a special packet type for each use
case - webapp discovery, cluster, etc ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> Mladen Turk wrote:
>
>> Hi,
>>
>> All (except Costin) developers has to say something, so my conclusion is
>> that we are not dead after all ;)
>
>
> I'm alive as well, and I have something to say - I spent last few
> weekends playing with coyote and tomcat, probably in few weeks I'll have
> something working and I'll get back.
>
>
>
>>
>> Seems that the major obstacle is the configuration, so I propose that we
>> forget that for a while, and make a
>> 'generalized' environment that will sattisfy all the 'needs'.
>> That environment could be called APR_JAVA and it will be resposible for
>> os->java communication, having AJPXX, and 'JNI' as one of the possible
>> protocol stacks.
>
>
>
>> It will have a generic mapping mechanism (pcre enabled) for
>> registering URI
>> mapings, setting communication properties, so that one could make a
>> suport
>> from any container (webserver).
>
>
> URI mapping is already duplicated in the web server and catalina, please
> not a third mapper :-)
Of course, and we could start with a simple mapper using Location/EnvVar.
>> It will abstract the container<->java communication to the level of
>> 'directory and file' so that one can open a connection to TC like
>> opening a
>> file, or simply speaking a 'Virtual File System', so that one can either
>> 'mount' a volume like '/servlets' or a file filter like '*.jsp'
>
>
> Depends on what you want :-). Request forwarding from server and tomcat
> works reasonably well, it's the other stuff that is hard, and it doesn't
> map so well to "VFS" model ( auth, conf, etc ).
Request forwarding is still the main feature, but we'd like to some
dynamic topology (webapp discovery, cluster state updates...)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> Mladen Turk wrote:
>>
>>> Hi,
>>>
>>> All (except Costin) developers has to say something, so my conclusion is
>>> that we are not dead after all ;)
>>
>>
>>
>> I'm alive as well, and I have something to say - I spent last few
>> weekends playing with coyote and tomcat, probably in few weeks I'll
>> have something working and I'll get back.
>
>
> This is cryptic, and encourages unreasonable expectations ;)
Well, the important thing for me is that I'm starting to write (tomcat)
code and to get some time. I still have very little free time - and some
of the code may be quite controversial, so I want to have a good
prototype ( and make sure it is indeed a good idea ). I'm trying 3
things at once, at least one should be usefull.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Mladen Turk wrote:
>
>> Hi,
>>
>> All (except Costin) developers has to say something, so my conclusion is
>> that we are not dead after all ;)
>
>
> I'm alive as well, and I have something to say - I spent last few
> weekends playing with coyote and tomcat, probably in few weeks I'll
> have something working and I'll get back.
This is cryptic, and encourages unreasonable expectations ;)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Costin Manolache <cm...@yahoo.com>.
Mladen Turk wrote:
> Hi,
>
> All (except Costin) developers has to say something, so my conclusion is
> that we are not dead after all ;)
I'm alive as well, and I have something to say - I spent last few
weekends playing with coyote and tomcat, probably in few weeks I'll have
something working and I'll get back.
>
> Seems that the major obstacle is the configuration, so I propose that we
> forget that for a while, and make a
> 'generalized' environment that will sattisfy all the 'needs'.
> That environment could be called APR_JAVA and it will be resposible for
> os->java communication, having AJPXX, and 'JNI' as one of the possible
> protocol stacks.
> It will have a generic mapping mechanism (pcre enabled) for registering URI
> mapings, setting communication properties, so that one could make a suport
> from any container (webserver).
URI mapping is already duplicated in the web server and catalina, please
not a third mapper :-)
> It will abstract the container<->java communication to the level of
> 'directory and file' so that one can open a connection to TC like opening a
> file, or simply speaking a 'Virtual File System', so that one can either
> 'mount' a volume like '/servlets' or a file filter like '*.jsp'
Depends on what you want :-). Request forwarding from server and tomcat
works reasonably well, it's the other stuff that is hard, and it doesn't
map so well to "VFS" model ( auth, conf, etc ).
Costin
>
>
> Of course all that sounds like JK3, but ...
>
>
> MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Tim Funk wrote:
> If this is all wishlists .. it'd be nice if we could set the worker and
> handler via mod_rewrite.
>
> Intead of
> JkMount /*.jsp loadbalancer
> Say:
> RewriteCond %{REQUEST_URI} *\.jsp
> RewriteRule ^(.+)$ $1 [T=jk,E=worker:loaderbalance]
>
> [If my syntax above is correct]
Rewrite rewrite the URL but doesn't process the request (it doesn't not read the
file corresponding to the URL).
>
>
> -Tim
>
> Mladen Turk wrote:
>
>>
>>
>>
>>> -----Original Message-----
>>> From: Henri Gomez
>>>
>>>> Of course all that sounds like JK3, but ...
>>>
>>>
>>> Did you see my post about a simpler module specific for now to Apache
>>> 2.x (2.0/2.1), may be something which could be included in standard
>>> Apache 2.x distribution which will save us hours on explaining how to
>>> build mod_jk/mod_jk2....
>>>
>>
>>
>> Yes, I did. I read all the replys wery carefully.
>> Did you understand mine?
>>
>> What I propose is: 'imagine a TC as a virtual file system'
>> So, you can 'apr_vfopen(TC/sever, ....)' like opening a file.
>>
>> You could for examle:
>>
>> Jk3Mount /*.jsp
>>
>> and have smewhere something like:
>>
>> <mapping "*.jsp">
>> <server name="1.2.3.1" factor="10%" />
>> </mapping>
>> or:
>>
>> <mapping "*.jsp">
>> <balance>
>> <server name="1.2.3.1" factor="10%" />
>> <server name="1.2.3.2" factor="20%" />
>> <server name="1.2.3.3" factor="auto" />
>> <server name="1.2.3.4" factor="failover" /> </balance>
>> </mapping>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Henri Gomez <hg...@apache.org>.
Tim Funk wrote:
> If this is all wishlists .. it'd be nice if we could set the worker and
> handler via mod_rewrite.
>
> Intead of
> JkMount /*.jsp loadbalancer
> Say:
> RewriteCond %{REQUEST_URI} *\.jsp
> RewriteRule ^(.+)$ $1 [T=jk,E=worker:loaderbalance]
>
> [If my syntax above is correct]
I was thinking something similar
SetEnvIf Request_URI "/*.jsp" worker:loaderbalance
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Tim Funk <fu...@joedog.org>.
If this is all wishlists .. it'd be nice if we could set the worker and
handler via mod_rewrite.
Intead of
JkMount /*.jsp loadbalancer
Say:
RewriteCond %{REQUEST_URI} *\.jsp
RewriteRule ^(.+)$ $1 [T=jk,E=worker:loaderbalance]
[If my syntax above is correct]
-Tim
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>>Of course all that sounds like JK3, but ...
>>
>>Did you see my post about a simpler module specific for now
>>to Apache 2.x (2.0/2.1), may be something which could be
>>included in standard Apache 2.x distribution which will save
>>us hours on explaining how to build mod_jk/mod_jk2....
>>
>
>
> Yes, I did. I read all the replys wery carefully.
> Did you understand mine?
>
> What I propose is: 'imagine a TC as a virtual file system'
> So, you can 'apr_vfopen(TC/sever, ....)' like opening a file.
>
> You could for examle:
>
> Jk3Mount /*.jsp
>
> and have smewhere something like:
>
> <mapping "*.jsp">
> <server name="1.2.3.1" factor="10%" />
> </mapping>
>
> or:
>
> <mapping "*.jsp">
> <balance>
> <server name="1.2.3.1" factor="10%" />
> <server name="1.2.3.2" factor="20%" />
> <server name="1.2.3.3" factor="auto" />
> <server name="1.2.3.4" factor="failover" />
> </balance>
> </mapping>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Both approaches have their advantages....
>
> Just don't loose the multi-file configuration flexibility given by
> JkUriSet.
Gack, I meant "lose". I did one of my own pet-peeve typos....
> Also, having either XML-based configuration *or* pure .conf
> configuration would be more easily understood than the current
> workers2.properties details.
>
> Mladen Turk wrote:
>
>>> -----Original Message-----
>>> From: Henri Gomez
>>>
>>>
>>>> Of course all that sounds like JK3, but ...
>>>>
>>>
>>> Did you see my post about a simpler module specific for now to
>>> Apache 2.x (2.0/2.1), may be something which could be included in
>>> standard Apache 2.x distribution which will save us hours on
>>> explaining how to build mod_jk/mod_jk2....
>>>
>>
>> Yes, I did. I read all the replys wery carefully.
>> Did you understand mine?
>>
>> What I propose is: 'imagine a TC as a virtual file system'
>> So, you can 'apr_vfopen(TC/sever, ....)' like opening a file.
>>
>> You could for examle:
>>
>> Jk3Mount /*.jsp
>>
>> and have smewhere something like:
>>
>> <mapping "*.jsp">
>> <server name="1.2.3.1" factor="10%" />
>> </mapping>
>> or:
>>
>> <mapping "*.jsp">
>> <balance>
>> <server name="1.2.3.1" factor="10%" />
>> <server name="1.2.3.2" factor="20%" />
>> <server name="1.2.3.3" factor="auto" />
>> <server name="1.2.3.4" factor="failover" /> </balance>
>> </mapping>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Some JK2 ideas v.2
Posted by Jess Holle <je...@ptc.com>.
Both approaches have their advantages....
Just don't loose the multi-file configuration flexibility given by JkUriSet.
Also, having either XML-based configuration *or* pure .conf
configuration would be more easily understood than the current
workers2.properties details.
Mladen Turk wrote:
>>-----Original Message-----
>>From: Henri Gomez
>>
>>
>>>Of course all that sounds like JK3, but ...
>>>
>>>
>>Did you see my post about a simpler module specific for now
>>to Apache 2.x (2.0/2.1), may be something which could be
>>included in standard Apache 2.x distribution which will save
>>us hours on explaining how to build mod_jk/mod_jk2....
>>
>>
>Yes, I did. I read all the replys wery carefully.
>Did you understand mine?
>
>What I propose is: 'imagine a TC as a virtual file system'
>So, you can 'apr_vfopen(TC/sever, ....)' like opening a file.
>
>You could for examle:
>
>Jk3Mount /*.jsp
>
>and have smewhere something like:
>
><mapping "*.jsp">
> <server name="1.2.3.1" factor="10%" />
></mapping>
>
>or:
>
><mapping "*.jsp">
> <balance>
> <server name="1.2.3.1" factor="10%" />
> <server name="1.2.3.2" factor="20%" />
> <server name="1.2.3.3" factor="auto" />
> <server name="1.2.3.4" factor="failover" />
> </balance>
></mapping>
>
>
Re: Some JK2 ideas v.2
Posted by Andy Armstrong <an...@hexten.net>.
Henri Gomez wrote:
> Well I'd like to see the JK3 or whatever will name the new module to be
> much more simpler and with less code.
+1 to that. It really has the feel of something that's more complex than
it should be at the moment.
--
Andy Armstrong
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.2
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
>
> Well I'd like to see the JK3 or whatever will name the new
> module to be much more simpler and with less code.
>
Bingo!
I'm trying over and over again to 'push' something like 'zero-config', not
depandant of any current container.
Just imagine a JK2+ as a 'virtual file system' with xml config for something
like 'fstab' named xxxconfig.xml.
Everthing else should be left to the container implementation.
So let's make something simple as apj_mount_uri(HOST, PORT, URI) that will
just register the uri.
Also I can live with something like apj_config_set("path/to/the/property",
"value"), so that all the config can came from the container itself.
But, the 'native file' config has to be XML (so that one can read the
server.xml directly or from the net), and there has to be no 'default
behaviour assumptions' unless specified as something like 'inherit
properties'.
So if someone wishes to make a apache module it will have to call
apj_mount_uri and few apj_config_set's, meaning that the all the 'high
level' directives will have to go in the module itself.
The major goal is to make something that could communicate to TC from
something simple as console app, or a web server.
For example:
int main()
{
f = apj_fopen("someserver:port/uri", "r;JSESSIONID=XX; and other
http vars");
while(apj_fread)... read the content from the file
}
Or
int main()
{
f = apj_fopen("someserver:port/uri", "w;HTTP_VARS..");
apj_write(f, the_post_data);
while (apj_read) ...
}
MT.
> For instance even jk2 inherited many code from jk and since
> jk was designed to be WebServer independant we couldn't use
> the full APIs of APR and Apache.
>
> That's why I think we should rewrite the jk/jk2 successor
> with Apache 2.x (2.0/2.1) in mind, using all the power of
> Apache HTTPD directive, including mapping discovery and so on.
>
> Ultimatly if we could produce a smaller module, we could then
> try to convince Apache 2 team to include it in Apache 2 distribution.
>
> > <mapping "*.jsp">
> > <balance>
> > <server name="1.2.3.1" factor="10%" />
> > <server name="1.2.3.2" factor="20%" />
> > <server name="1.2.3.3" factor="auto" />
> > <server name="1.2.3.4" factor="failover" />
> > </balance>
> > </mapping>
>
> I like the balanced worker definition but for an httpd.conf
> which more easy for Apache Admins, shouldn't it be :
>
> <WorkerDef>
> WorkerType ajp13
> WorkerName myworker1
> WorkerHost 1.2.3.1
> WorketPort 8009
> </WorkerDef>
>
> <WorkerDef>
> WorkerType ajp13
> WorkerName myworker2
> WorkerHost 1.2.3.2
> WorketPort 8009
> </WorkerDef>
>
> <WorkerDef>
> WorkerType ajp13
> WorkerName myworker3
> WorkerHost 1.2.3.3
> WorketPort 8009
> </WorkerDef>
>
> <WorkerDef>
> WorkerType ajp13
> WorkerName myworker4
> WorkerHost 1.2.3.4
> WorketPort 8009
> </WorkerDef>
>
> <WorkerDef>
> WorkerType lb
> WorkerName balanced
> WorkerEntry myworker1 10%
> WorkerEntry myworker2 20%
> WorkerEntry myworker3 auto
> WorkerEntry myworker4 failover
> </WorkerDef>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Some JK2 ideas v.2
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>
>
>>-----Original Message-----
>>From: Henri Gomez
>>
>>>Of course all that sounds like JK3, but ...
>>
>>Did you see my post about a simpler module specific for now
>>to Apache 2.x (2.0/2.1), may be something which could be
>>included in standard Apache 2.x distribution which will save
>>us hours on explaining how to build mod_jk/mod_jk2....
>>
>
>
> Yes, I did. I read all the replys wery carefully.
> Did you understand mine?
>
> What I propose is: 'imagine a TC as a virtual file system'
> So, you can 'apr_vfopen(TC/sever, ....)' like opening a file.
>
> You could for examle:
>
> Jk3Mount /*.jsp
>
> and have smewhere something like:
>
> <mapping "*.jsp">
> <server name="1.2.3.1" factor="10%" />
> </mapping>
>
> or:
Well I'd like to see the JK3 or whatever will name the new module to be
much more simpler and with less code.
For instance even jk2 inherited many code from jk and since jk was
designed to be WebServer independant we couldn't use the full APIs
of APR and Apache.
That's why I think we should rewrite the jk/jk2 successor with Apache
2.x (2.0/2.1) in mind, using all the power of Apache HTTPD directive,
including mapping discovery and so on.
Ultimatly if we could produce a smaller module, we could then try to
convince Apache 2 team to include it in Apache 2 distribution.
> <mapping "*.jsp">
> <balance>
> <server name="1.2.3.1" factor="10%" />
> <server name="1.2.3.2" factor="20%" />
> <server name="1.2.3.3" factor="auto" />
> <server name="1.2.3.4" factor="failover" />
> </balance>
> </mapping>
I like the balanced worker definition but for an httpd.conf
which more easy for Apache Admins, shouldn't it be :
<WorkerDef>
WorkerType ajp13
WorkerName myworker1
WorkerHost 1.2.3.1
WorketPort 8009
</WorkerDef>
<WorkerDef>
WorkerType ajp13
WorkerName myworker2
WorkerHost 1.2.3.2
WorketPort 8009
</WorkerDef>
<WorkerDef>
WorkerType ajp13
WorkerName myworker3
WorkerHost 1.2.3.3
WorketPort 8009
</WorkerDef>
<WorkerDef>
WorkerType ajp13
WorkerName myworker4
WorkerHost 1.2.3.4
WorketPort 8009
</WorkerDef>
<WorkerDef>
WorkerType lb
WorkerName balanced
WorkerEntry myworker1 10%
WorkerEntry myworker2 20%
WorkerEntry myworker3 auto
WorkerEntry myworker4 failover
</WorkerDef>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
RE: Some JK2 ideas v.2
Posted by Mladen Turk <mt...@apache.org>.
> -----Original Message-----
> From: Henri Gomez
> >
> > Of course all that sounds like JK3, but ...
>
> Did you see my post about a simpler module specific for now
> to Apache 2.x (2.0/2.1), may be something which could be
> included in standard Apache 2.x distribution which will save
> us hours on explaining how to build mod_jk/mod_jk2....
>
Yes, I did. I read all the replys wery carefully.
Did you understand mine?
What I propose is: 'imagine a TC as a virtual file system'
So, you can 'apr_vfopen(TC/sever, ....)' like opening a file.
You could for examle:
Jk3Mount /*.jsp
and have smewhere something like:
<mapping "*.jsp">
<server name="1.2.3.1" factor="10%" />
</mapping>
or:
<mapping "*.jsp">
<balance>
<server name="1.2.3.1" factor="10%" />
<server name="1.2.3.2" factor="20%" />
<server name="1.2.3.3" factor="auto" />
<server name="1.2.3.4" factor="failover" />
</balance>
</mapping>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
Re: Some JK2 ideas v.2
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
> Hi,
>
> All (except Costin) developers has to say something, so my conclusion is
> that we are not dead after all ;)
>
> Seems that the major obstacle is the configuration, so I propose that we
> forget that for a while, and make a
> 'generalized' environment that will sattisfy all the 'needs'.
> That environment could be called APR_JAVA and it will be resposible for
> os->java communication, having AJPXX, and 'JNI' as one of the possible
> protocol stacks.
> It will have a generic mapping mechanism (pcre enabled) for registering URI
> mapings, setting communication properties, so that one could make a suport
> from any container (webserver).
> It will abstract the container<->java communication to the level of
> 'directory and file' so that one can open a connection to TC like opening a
> file, or simply speaking a 'Virtual File System', so that one can either
> 'mount' a volume like '/servlets' or a file filter like '*.jsp'
>
>
> Of course all that sounds like JK3, but ...
Did you see my post about a simpler module specific for now
to Apache 2.x (2.0/2.1), may be something which could be
included in standard Apache 2.x distribution which will save
us hours on explaining how to build mod_jk/mod_jk2....
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org