You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2003/01/27 18:18:49 UTC
[5.0] New mapper
(This question is for Costin)
As I've mentioned before, I'm writing a new mapper to replace the
current 5.0 request mapper, which is a major performance problem right now.
The implementation goes well enough (I'll likely commit something today
or tomorrow; in the end, there are no fancy algorithms involved), but
there's the problem of keeping the mapper structure in sync with
Catalina's structure.
To do that, I was planning to use a simple MBean registration listener
(as all the components we're interested in register with JMX) with the
MBean server. (I can only see a way of doing that using JMX 1.2)
So, is it ok to do that ? Is there a better way (I don't want to use the
Catalina listeners, obviously) ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Speaking of which, I'm missing a registration for the hosts (I don't
> know if it's defined in JSR 77).
> Could we add some custom attributes on the object name for wrapper
> (giving the mapping), as well as the host registration, and still comply
> with the spec (I'd say yes, but ...) ?
Sure. JSR77 is very thin - way too thin.
It doesn't forbid container-specific objects - but leves the naming open.
The only issue - we need to get rid of the Listeners and move the JMX
registration in the core objects.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
> If the question is about using JMX1.2 - it was alredy proposed, and it
> seems nobody objected ( but nobody did it either ). If you want to do
> that - all you need is update the mbean descriptors, and change all the
> arrays to use the JNI names ( [Ljava.lang.String; instead of
> java.lang.String[] ). And of course - fix download to get jmxri instead
> of mx4j.
>
> When MX4J implements 1.2, we'll switch back.
> I'm using JMXRI1.2 - and so far it works very nice.
>
> Regarding the registration listener: there are 2 issues you need to
> be carefull. First, it would be good if the code is independent of
> the load order - i.e. listen for notifications but also do a query for
> the existing objects. You can do that using JMX query, or by
> using the attributes. After you take care of the existing mappings,
> you can start listening for registration - you can do both with plain
> JMX1.1.
Speaking of which, I'm missing a registration for the hosts (I don't
know if it's defined in JSR 77).
Could we add some custom attributes on the object name for wrapper
(giving the mapping), as well as the host registration, and still comply
with the spec (I'd say yes, but ...) ?
Thanks,
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> If the question is about using JMX1.2 - it was alredy proposed, and it
>> seems nobody objected ( but nobody did it either ). If you want to do
>> that - all you need is update the mbean descriptors, and change all the
>> arrays to use the JNI names ( [Ljava.lang.String; instead of
>> java.lang.String[] ). And of course - fix download to get jmxri instead
>> of mx4j.
>
> BTW, would it be possible to add a feature in the modeler to autodetec
> the JMX version, and do that transparently ?
The big problem with JMX1.1 is the lack of (declarative) security. That
makes it history - the only reason to support it is the lack of 1.2 support
in the current mx4j.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> If the question is about using JMX1.2 - it was alredy proposed, and it
> seems nobody objected ( but nobody did it either ). If you want to do
> that - all you need is update the mbean descriptors, and change all the
> arrays to use the JNI names ( [Ljava.lang.String; instead of
> java.lang.String[] ). And of course - fix download to get jmxri instead
> of mx4j.
BTW, would it be possible to add a feature in the modeler to autodetec
the JMX version, and do that transparently ?
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>
>>> BTW - I assume you read the discussion on authorization - the problem
>>> is the same ( mapping requests URIs to constraints ), it would be good
>>> if we can reuse some code.
>>
>>
>> The mapping code is generic. I was thinking about having the mapper do
>> the constraint mappings (as it's the same operation) also.
>
> Oops, I just remembered the mapping rules are not the same (for the
> constraints, it's the first match according to the order defined in
> web.xml).
Yes, don't you love the spec :-) ?
It'll be very fun to watch JSR115 and the Policy - since that's a best
match too ( like all web servers in the world ). Will they break the servlet
spec or the java security spec ? Or both ( and invent their own rules ) ?
Anyway - people who use web servers for authentication are usually aware
and don't mix server auth with servlet auth ( or so I hope... - otherwise
we would have had far more security reports ). Hopefully the Policy based
authorization will be adopted - and the broken servlet authorization
deprecated...
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
>> BTW - I assume you read the discussion on authorization - the problem
>> is the same ( mapping requests URIs to constraints ), it would be good if
>> we can reuse some code.
>
>
> The mapping code is generic. I was thinking about having the mapper do
> the constraint mappings (as it's the same operation) also.
Oops, I just remembered the mapping rules are not the same (for the
constraints, it's the first match according to the order defined in
web.xml).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>Costin Manolache wrote:
>>
>>>Remy Maucherat wrote:
>>
>>>Cast the notification to MBeanServerNotification :-)
>>
>>Ok, it sort of works now.
>>
>>The remaining problems:
>>- some attributes need to send JMX notifications (welcome files,
>>mappings, etc) so the mapper can be updated
>>- the Host handling is not dynamic
>>- some operations need also be propagated (removal of a component)
>
>
> What if we simplify this by exposing the mappings, welcome files, etc
> as JMX attributes of context ?
That sounds doable.
> Of course, we won't save the web.xml if someone adds a mapping ( yet :-),
> but you'll only need to listen for context add/remove notifications.
Well, the MBean is never unregistered at the moment, so it's quite
limited ;-)
> And the jmx console would provide more usefull informations.
>
> The methods and info is already there - we just need to expose them.
>
> BTW - I assume you read the discussion on authorization - the problem
> is the same ( mapping requests URIs to constraints ), it would be good if
> we can reuse some code.
The mapping code is generic. I was thinking about having the mapper do
the constraint mappings (as it's the same operation) also.
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>
>> Cast the notification to MBeanServerNotification :-)
>
> Ok, it sort of works now.
>
> The remaining problems:
> - some attributes need to send JMX notifications (welcome files,
> mappings, etc) so the mapper can be updated
> - the Host handling is not dynamic
> - some operations need also be propagated (removal of a component)
What if we simplify this by exposing the mappings, welcome files, etc
as JMX attributes of context ?
Of course, we won't save the web.xml if someone adds a mapping ( yet :-),
but you'll only need to listen for context add/remove notifications.
And the jmx console would provide more usefull informations.
The methods and info is already there - we just need to expose them.
BTW - I assume you read the discussion on authorization - the problem
is the same ( mapping requests URIs to constraints ), it would be good if
we can reuse some code.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
> Cast the notification to MBeanServerNotification :-)
Ok, it sort of works now.
The remaining problems:
- some attributes need to send JMX notifications (welcome files,
mappings, etc) so the mapper can be updated
- the Host handling is not dynamic
- some operations need also be propagated (removal of a component)
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>> Remy Maucherat wrote:
>>
>>
>>>The mapper has a currently unused dependency on JNDI, and I plan to put
>>>it in the org.apache.tomcat.util.http.mapper package.
>>
>>
>> JNDI deps are fine - dependencies on org.apache.naming are not very good
>> ( since tomcat can be used in an app that uses a different naming impl ).
>
> Well, I'm still unsure about physical welcome files. On the plus side,
> it would be considerably faster to do that in the mapper.
>
>>>How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
>>>obvious, but I think I missed it in 1.1. The static queries are of
>>>course similar.
>>
>>
>> It's the same - register a listener on the MBeanServerDelegate.
>
> I tried that, and get a lot of nice notifications about registration,
> but how do I get the ObjectName of the MBean which caused the
> notification (the source of the Notification is the server delegate,
> which doesn't help). ?
Cast the notification to MBeanServerNotification :-)
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
>>The mapper has a currently unused dependency on JNDI, and I plan to put
>>it in the org.apache.tomcat.util.http.mapper package.
>
>
> JNDI deps are fine - dependencies on org.apache.naming are not very good
> ( since tomcat can be used in an app that uses a different naming impl ).
Well, I'm still unsure about physical welcome files. On the plus side,
it would be considerably faster to do that in the mapper.
>>How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
>>obvious, but I think I missed it in 1.1. The static queries are of
>>course similar.
>
>
> It's the same - register a listener on the MBeanServerDelegate.
I tried that, and get a lot of nice notifications about registration,
but how do I get the ObjectName of the MBean which caused the
notification (the source of the Notification is the server delegate,
which doesn't help). ?
Help :-P
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> The mapper has a currently unused dependency on JNDI, and I plan to put
> it in the org.apache.tomcat.util.http.mapper package.
JNDI deps are fine - dependencies on org.apache.naming are not very good
( since tomcat can be used in an app that uses a different naming impl ).
> How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
> obvious, but I think I missed it in 1.1. The static queries are of
> course similar.
It's the same - register a listener on the MBeanServerDelegate.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [5.0] New mapper
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
>
>
> If the question is about using JMX1.2 - it was alredy proposed, and it
> seems nobody objected ( but nobody did it either ). If you want to do
> that - all you need is update the mbean descriptors, and change all the
> arrays to use the JNI names ( [Ljava.lang.String; instead of
> java.lang.String[] ). And of course - fix download to get jmxri instead
> of mx4j.
>
> When MX4J implements 1.2, we'll switch back.
> I'm using JMXRI1.2 - and so far it works very nice.
Ok.
The new mapper works with my simple test cases and uses some proven (but
basic) sorting algorithms. It appears to be fast, although the algorithm
cost is greater than using a hashtable or a tree. Anyway, it should be a
lot faster than the old mapper (aahhh, zero garbage mapping :-D ), but I
have to wait until I've integrated it with Catalina to know how much.
The mapper has a currently unused dependency on JNDI, and I plan to put
it in the org.apache.tomcat.util.http.mapper package.
I'll use the new fields it introduces to optimize whatever in the
pipeline was not good:
- Checks for /WEB-INF and /META-INF
- B2C conversion for the URI; the encoding will be configurable with an
attribute on the connector (people have been asking for it for some
reason, instead of using UTF-8 :-( ), and will feature a Nasty Cast (TM)
mode for "ISO-8859-1"
- (later) Request dispatcher mapping; I think request dispatching speed
is very important as it is (ab)used by popular frameworks like Struts
> Regarding the registration listener: there are 2 issues you need to
> be carefull. First, it would be good if the code is independent of
> the load order - i.e. listen for notifications but also do a query for
> the existing objects. You can do that using JMX query, or by
> using the attributes. After you take care of the existing mappings,
> you can start listening for registration - you can do both with plain
> JMX1.1.
How can I listen to registrations with JMX 1.1 ? In 1.2, this is quite
obvious, but I think I missed it in 1.1. The static queries are of
course similar.
> I don't know if all the components are registered - we do have the Context
> and Servlet, but you'll need to make sure the Context mbean is exposing the
> mappings. Unfortunately JSR77 ( or other standards I know ) do not define
> any standard attribute that a "WebModule" mbean would use to expose
> supported mappings - so the code will remain dependent of catalina, but
> with less cupling.
That's a problem. Too bad ...
> BTW, I am now able to create Context mbeans and have them registered
> automatically - and I'll try to get the same working for Valves, Connectors
> and JkHandlers. If this is used with an mbean server that supports
> reloading ( like jboss.mx ) - we'll be able to replace modules without
> restarting the VM ( which is pretty cool ).
That's good.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [5.0] New mapper
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> (This question is for Costin)
>
> As I've mentioned before, I'm writing a new mapper to replace the
> current 5.0 request mapper, which is a major performance problem right
> now.
>
> The implementation goes well enough (I'll likely commit something today
> or tomorrow; in the end, there are no fancy algorithms involved), but
> there's the problem of keeping the mapper structure in sync with
> Catalina's structure.
>
> To do that, I was planning to use a simple MBean registration listener
> (as all the components we're interested in register with JMX) with the
> MBean server. (I can only see a way of doing that using JMX 1.2)
>
> So, is it ok to do that ? Is there a better way (I don't want to use the
> Catalina listeners, obviously) ?
If the question is about using JMX1.2 - it was alredy proposed, and it
seems nobody objected ( but nobody did it either ). If you want to do
that - all you need is update the mbean descriptors, and change all the
arrays to use the JNI names ( [Ljava.lang.String; instead of
java.lang.String[] ). And of course - fix download to get jmxri instead
of mx4j.
When MX4J implements 1.2, we'll switch back.
I'm using JMXRI1.2 - and so far it works very nice.
Regarding the registration listener: there are 2 issues you need to
be carefull. First, it would be good if the code is independent of
the load order - i.e. listen for notifications but also do a query for
the existing objects. You can do that using JMX query, or by
using the attributes. After you take care of the existing mappings,
you can start listening for registration - you can do both with plain
JMX1.1.
I don't know if all the components are registered - we do have the Context
and Servlet, but you'll need to make sure the Context mbean is exposing the
mappings. Unfortunately JSR77 ( or other standards I know ) do not define
any standard attribute that a "WebModule" mbean would use to expose
supported mappings - so the code will remain dependent of catalina, but
with less cupling.
BTW, I am now able to create Context mbeans and have them registered
automatically - and I'll try to get the same working for Valves, Connectors
and JkHandlers. If this is used with an mbean server that supports
reloading ( like jboss.mx ) - we'll be able to replace modules without
restarting the VM ( which is pretty cool ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>