You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Glenn Nielsen <gl...@voyager.apg.more.net> on 2002/06/19 05:37:21 UTC
Max Sessions -> Production Tomcat instrumentation & monitoring
The current discussion about setting the maximum number of sessions
which can be created prompts me to raise an issue I have thought about
some but which I don't recall being discussed here yet.
That is, instrumenting Tomcat so it can be monitored by external
tools (Introscope comes to mind). I have a number of instances of
Tomcat 4 in production now and so far have been able to get up to
a 4 week runtime before a failure forced me to stop/restart it.
This was on a site which handles 2-3 million JSP pages per month.
For production I really need hooks in Tomcat and tools which can
provide 24/7 monitoring and notification of problems. In addition
collect metrics so that the admin has real data to use for improving
the JVM settings, etc.
Has anyone been working on this? If not, anyone interested in this?
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
costinm@covalent.net wrote:
>
> On Wed, 19 Jun 2002, Glenn Nielsen wrote:
>
> > At this point in time I don't see alot of benefit to using JMX for this
> > because you can't change the core catalina policy at runtime unless you
> > drop back all the way to the Bootstrap class and reinstantiate all the
> > catalina ClassLoader's.
>
> By 'core policy' you refer to the container classes ?
>
Yes.
> I think what's interesting is to be able to define/change policy for
> webapps, and I think that can be done at runtime, without container
> restart ( but with webapp reloading ).
>
Yup, thats what the XML security policy will support.
> > Not at all. The webapp /WEB-INF/policy.xml can only configure codeBases
> > which exist in the webapp Context. In addition no permissions can be
> > set which exceeds the max allowed permission settings configured in
> > the global tomcat conf/policy.xml. The Permission.implies() method is
> > used to enforce this.
>
> I don't see the benefit of having an untrusted webapp set its own policy
> ( even with a 'max' allowed ). I think it's usefull to have a policy.xml
> that defines what the application needs, and use it at deploy time
> ( with an admin checking it and aproving each permission ).
>
> I'm not -1, just -0.
>
The benefit is for when Tomcat is installed in a web hosting situation
where the tomcat admin sets what permissions are allowed and then
doesn't get bothered all the time to debug/set security policies for
individual webapps installed by customers.
But I can add an attribute flag which can disable /WEB-INF/policy.xml
scoped at either the Engine, Host, or Context.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by Remy Maucherat <re...@apache.org>.
costinm@covalent.net wrote:
> On Wed, 19 Jun 2002, Glenn Nielsen wrote:
>
>
>>At this point in time I don't see alot of benefit to using JMX for this
>>because you can't change the core catalina policy at runtime unless you
>>drop back all the way to the Bootstrap class and reinstantiate all the
>>catalina ClassLoader's.
>
>
> By 'core policy' you refer to the container classes ?
>
> I think what's interesting is to be able to define/change policy for
> webapps, and I think that can be done at runtime, without container
> restart ( but with webapp reloading ).
In theory, the webapp's codebases permissions are set by the webapp CL.
So when you reload, you get a new CL, so you could set new permissions,
right ?
I don't see why it wouldn't work.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by co...@covalent.net.
On Wed, 19 Jun 2002, Glenn Nielsen wrote:
> At this point in time I don't see alot of benefit to using JMX for this
> because you can't change the core catalina policy at runtime unless you
> drop back all the way to the Bootstrap class and reinstantiate all the
> catalina ClassLoader's.
By 'core policy' you refer to the container classes ?
I think what's interesting is to be able to define/change policy for
webapps, and I think that can be done at runtime, without container
restart ( but with webapp reloading ).
> Not at all. The webapp /WEB-INF/policy.xml can only configure codeBases
> which exist in the webapp Context. In addition no permissions can be
> set which exceeds the max allowed permission settings configured in
> the global tomcat conf/policy.xml. The Permission.implies() method is
> used to enforce this.
I don't see the benefit of having an untrusted webapp set its own policy
( even with a 'max' allowed ). I think it's usefull to have a policy.xml
that defines what the application needs, and use it at deploy time
( with an admin checking it and aproving each permission ).
I'm not -1, just -0.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
costinm@covalent.net wrote:
>
> On Wed, 19 Jun 2002, Glenn Nielsen wrote:
>
> > > ( I don't think you can change/add to the policy at runtime, so it may
> > > not make sense )
> > >
> >
> > Since the ProtectionDomain for a Class is created when that class is
> > instantiated by a ClassLoader policy changes can't be put in effect
> > unless the ClassLoader is dumped. So JMX doesn't really make sense.
>
> You would use JMX to configure/tune the policy - by adding new
> rules for new applications, or changing the rules for existing
> application before reload.
>
> That's for the case you deploy or re-deploy apps and you don't want
> to restart the server ( or edit files ).
>
> In addition with some tricks you can also intercept the calls
> and instrument the security - i.e. get statistics and info about
> what constraints failed ( and you can grand more - then restart ).
>
> The protection is in effect for Class/ClassLoader combination.
>
> > There is a catch 22 problem. You need to read the policy before you instantiate
> > any classes from catalina.jar so that the XML Policy can be in effect for
> > it. Setting the policy has to be done in Bootstrap. Individual webapps
>
> Not quite - the first thing to do in bootstrap is to locate a
> configuration provider - for example jdk1.4 preferences ( well, a
> wrapper that works on 1.3, like commons-logging ) or an XML or LDAP
> provider. That will be used to load the components - including the
> container, and will enable the security manager at the right time.
>
> I see no problem here ( except the fact that none of this is implemented
> yet, while your code seems almost ready :-).
>
At this point in time I don't see alot of benefit to using JMX for this
because you can't change the core catalina policy at runtime unless you
drop back all the way to the Bootstrap class and reinstantiate all the
catalina ClassLoader's.
>
> > can have their own policy in /WEB-INF/policy.xml, but they can only set
> > those permissions which are allowed by tomcats conf/policy.xml. Individual
> > webapp polices will be reloaded when the app is reloaded.
>
> Sounds dangerous, I wouldn't let a policy file in WEB-INF :-) Maybe
> some 'declarations' that would be presented to the admin to aprove,
> about what the app needs.
>
Not at all. The webapp /WEB-INF/policy.xml can only configure codeBases
which exist in the webapp Context. In addition no permissions can be
set which exceeds the max allowed permission settings configured in
the global tomcat conf/policy.xml. The Permission.implies() method is
used to enforce this.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by co...@covalent.net.
On Wed, 19 Jun 2002, Glenn Nielsen wrote:
> > ( I don't think you can change/add to the policy at runtime, so it may
> > not make sense )
> >
>
> Since the ProtectionDomain for a Class is created when that class is
> instantiated by a ClassLoader policy changes can't be put in effect
> unless the ClassLoader is dumped. So JMX doesn't really make sense.
You would use JMX to configure/tune the policy - by adding new
rules for new applications, or changing the rules for existing
application before reload.
That's for the case you deploy or re-deploy apps and you don't want
to restart the server ( or edit files ).
In addition with some tricks you can also intercept the calls
and instrument the security - i.e. get statistics and info about
what constraints failed ( and you can grand more - then restart ).
The protection is in effect for Class/ClassLoader combination.
> There is a catch 22 problem. You need to read the policy before you instantiate
> any classes from catalina.jar so that the XML Policy can be in effect for
> it. Setting the policy has to be done in Bootstrap. Individual webapps
Not quite - the first thing to do in bootstrap is to locate a
configuration provider - for example jdk1.4 preferences ( well, a
wrapper that works on 1.3, like commons-logging ) or an XML or LDAP
provider. That will be used to load the components - including the
container, and will enable the security manager at the right time.
I see no problem here ( except the fact that none of this is implemented
yet, while your code seems almost ready :-).
> can have their own policy in /WEB-INF/policy.xml, but they can only set
> those permissions which are allowed by tomcats conf/policy.xml. Individual
> webapp polices will be reloaded when the app is reloaded.
Sounds dangerous, I wouldn't let a policy file in WEB-INF :-) Maybe
some 'declarations' that would be presented to the admin to aprove,
about what the app needs.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
costinm@covalent.net wrote:
>
> On Wed, 19 Jun 2002, Glenn Nielsen wrote:
>
> > > Yes :-)
> > >
> > > The difficult part is to instrument the C side, and the jk2 scoreboard
> > > seems to resolve that. From java side - it's quite easy, all you need is
> > > add getters and collect the data, and JMX will expose them ( using
> > > per/thread structures - like notes associated with a request to avoid
> > > sync and keep it fast ).
> > >
> > > But I think we should wait for things to stabilise a bit, there are far
> > > too many things happening at once.
> > >
> >
> > I agree, JTC and Jasper2 need to get finished up before something new
> > is tackled. I am currently working on my proposal to implement a
> > java Policy() replacement which uses an XML based policy file and which
> > is easier to use for granting permissions. I need to finish that up
> > before I start on anything new.
>
> Would it make sense to have JMX-enabled Policy ?
>
> I don't know if you saw the DynamicBean stuff in jtc/util, all you need
> is a name, a bean and a method call - and it's magically JMX enabled.
>
> ( I don't think you can change/add to the policy at runtime, so it may
> not make sense )
>
Since the ProtectionDomain for a Class is created when that class is
instantiated by a ClassLoader policy changes can't be put in effect
unless the ClassLoader is dumped. So JMX doesn't really make sense.
> For the record, I think it's a bad idea to add a new XML DTD - the
> current format is at least 'standard', and if you want a replacement
> I would rather sugest something preference-like, or an integrated
> config mechanism based on JMX. Of course, that'll take a long time
> so you should go ahead with the XML.
>
There is a catch 22 problem. You need to read the policy before you instantiate
any classes from catalina.jar so that the XML Policy can be in effect for
it. Setting the policy has to be done in Bootstrap. Individual webapps
can have their own policy in /WEB-INF/policy.xml, but they can only set
those permissions which are allowed by tomcats conf/policy.xml. Individual
webapp polices will be reloaded when the app is reloaded.
Initially I am using a separate XML file which uses an XML Schema and
validation. Plus I am using Castor to generate the source from the
XML Schema for the beans used to define the policy.
Its kind of neat. The Schema allows nesting of codebase and permissions
so that parent codebase elements inherit the permissions defined for
the children. This makes the configuration more like how the JVM
implements security for API's on the stack. This makes it a great deal
easier to configure the security policy.
As of a week ago I had the global policy.xml working but still needed
to implement the code for the webapp policy.xml. But I haven't had a
chance to work on it in the last week.
> > BTW, I will be doing an eval of Introscope with Tomcat 4 the week of
> > July 15. That should help me think through the instrumentation of Tomcat.
>
> Please let me know what you find.
>
You bet.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by co...@covalent.net.
On Wed, 19 Jun 2002, Glenn Nielsen wrote:
> > Yes :-)
> >
> > The difficult part is to instrument the C side, and the jk2 scoreboard
> > seems to resolve that. From java side - it's quite easy, all you need is
> > add getters and collect the data, and JMX will expose them ( using
> > per/thread structures - like notes associated with a request to avoid
> > sync and keep it fast ).
> >
> > But I think we should wait for things to stabilise a bit, there are far
> > too many things happening at once.
> >
>
> I agree, JTC and Jasper2 need to get finished up before something new
> is tackled. I am currently working on my proposal to implement a
> java Policy() replacement which uses an XML based policy file and which
> is easier to use for granting permissions. I need to finish that up
> before I start on anything new.
Would it make sense to have JMX-enabled Policy ?
I don't know if you saw the DynamicBean stuff in jtc/util, all you need
is a name, a bean and a method call - and it's magically JMX enabled.
( I don't think you can change/add to the policy at runtime, so it may
not make sense )
For the record, I think it's a bad idea to add a new XML DTD - the
current format is at least 'standard', and if you want a replacement
I would rather sugest something preference-like, or an integrated
config mechanism based on JMX. Of course, that'll take a long time
so you should go ahead with the XML.
> BTW, I will be doing an eval of Introscope with Tomcat 4 the week of
> July 15. That should help me think through the instrumentation of Tomcat.
Please let me know what you find.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
costinm@covalent.net wrote:
>
> On Tue, 18 Jun 2002, Glenn Nielsen wrote:
>
> > The current discussion about setting the maximum number of sessions
> > which can be created prompts me to raise an issue I have thought about
> > some but which I don't recall being discussed here yet.
> >
> > That is, instrumenting Tomcat so it can be monitored by external
> > tools (Introscope comes to mind). I have a number of instances of
> > Tomcat 4 in production now and so far have been able to get up to
> > a 4 week runtime before a failure forced me to stop/restart it.
> > This was on a site which handles 2-3 million JSP pages per month.
> > For production I really need hooks in Tomcat and tools which can
> > provide 24/7 monitoring and notification of problems. In addition
> > collect metrics so that the admin has real data to use for improving
> > the JVM settings, etc.
> >
> > Has anyone been working on this? If not, anyone interested in this?
>
> Yes :-)
>
> The difficult part is to instrument the C side, and the jk2 scoreboard
> seems to resolve that. From java side - it's quite easy, all you need is
> add getters and collect the data, and JMX will expose them ( using
> per/thread structures - like notes associated with a request to avoid
> sync and keep it fast ).
>
> But I think we should wait for things to stabilise a bit, there are far
> too many things happening at once.
>
I agree, JTC and Jasper2 need to get finished up before something new
is tackled. I am currently working on my proposal to implement a
java Policy() replacement which uses an XML based policy file and which
is easier to use for granting permissions. I need to finish that up
before I start on anything new.
BTW, I will be doing an eval of Introscope with Tomcat 4 the week of
July 15. That should help me think through the instrumentation of Tomcat.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Max Sessions -> Production Tomcat instrumentation & monitoring
Posted by co...@covalent.net.
On Tue, 18 Jun 2002, Glenn Nielsen wrote:
> The current discussion about setting the maximum number of sessions
> which can be created prompts me to raise an issue I have thought about
> some but which I don't recall being discussed here yet.
>
> That is, instrumenting Tomcat so it can be monitored by external
> tools (Introscope comes to mind). I have a number of instances of
> Tomcat 4 in production now and so far have been able to get up to
> a 4 week runtime before a failure forced me to stop/restart it.
> This was on a site which handles 2-3 million JSP pages per month.
> For production I really need hooks in Tomcat and tools which can
> provide 24/7 monitoring and notification of problems. In addition
> collect metrics so that the admin has real data to use for improving
> the JVM settings, etc.
>
> Has anyone been working on this? If not, anyone interested in this?
Yes :-)
The difficult part is to instrument the C side, and the jk2 scoreboard
seems to resolve that. From java side - it's quite easy, all you need is
add getters and collect the data, and JMX will expose them ( using
per/thread structures - like notes associated with a request to avoid
sync and keep it fast ).
But I think we should wait for things to stabilise a bit, there are far
too many things happening at once.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>