RE: acive session count?
> > 1. Extensible/Modular. Maybe you want to get other internal > > informations, > > or change other parameters at run time. > > > > 2. Minimal ( or no ) changes in the core or protocols. Changes are bad > > bacause they add bugs, require releases , etc, and if we do (1) right, > > then no other change is needed. > > > > I agree. The less work done to the core, the better. ( and best left to the > pros! :) Don't get me wrong - I have nothing against changing the core per se, I just think we have the hooks we need ( and if we don't we should add them ASAP ), and it would be great to keep it frozen so that we can start developing the needed modules and features. > > Well, having Ajp13 or Http listeners is almost the same, you > > don't need > > the HTTP running if you have Ajp13 ( and a Ajp13 client - > > like apache ). > > Regarding login for each query - this is an admin task, so it's not > > performance-critical. > > > So, in addition to setting up AJP12 in the load balance list, you're saying > to set up a AJP13 on each tomcat as well? (to allow [restricted] access to > the specific TC) ? Sounds good. Sorry, I meant Ajp12 ( i.e. if you have ajp12 or ajp13 or jni connector, you don't need standalone http - just connect to apache and you can do any http request - including /admin, and any other servlet ). ( in addition, you can use all Apache directives to double the security if you want to - in addition to password ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: acive session count?
Title: RE: acive session count? > Yes, both Apache and tomcat need a mechanism to get status and change > configuration dynamically. > > Session count is a particular case. Adding/removing workers is another > particular case. > > What I'm thinking about is a general solution. The goals: > > 1. Extensible/Modular. Maybe you want to get other internal > informations, > or change other parameters at run time. > > 2. Minimal ( or no ) changes in the core or protocols. Changes are bad > bacause they add bugs, require releases , etc, and if we do (1) right, > then no other change is needed. > I agree. The less work done to the core, the better. ( and best left to the pros! :) > > Well, having Ajp13 or Http listeners is almost the same, you > don't need > the HTTP running if you have Ajp13 ( and a Ajp13 client - > like apache ). > Regarding login for each query - this is an admin task, so it's not > performance-critical. So, in addition to setting up AJP12 in the load balance list, you're saying to set up a AJP13 on each tomcat as well? (to allow [restricted] access to the specific TC) ? Sounds good. > > > Whatever the front end is, I'll still need to add > getSessionCount() methods > > to the ContextManager, StandardManager, and > StandardSessionManager. (yes?) > > I'm not sure you need to change ContextManager for that - you > can get the > list of Contexts, and for each Context you can access the > StandardManager > - and get the session count from it. All that can be done ( > IMHO ) from a > servlet, without any change in the core - the only special thing is > getting a pointer to the ContextManager. > Hmmm, I'll look closer at Context and the StandardManager. thanks. > > > Sorry for the long rant, but I think I'm working on some > good functionality > > that others could use as well, and I want to get it right. > > +1. > > Costin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] >
RE: acive session count?
> I agree that a jk_admin type application to control the load balancer and > get session info would be great and very usefull, but that would have to > access information from the web server (who's in the list, who's active) and > each TC (how many sessions). So even if I built an Apache admin app, I would > still have to add methods to Tomcat to return active session counts. > (Although I would not have to modify AJP12...) Yes, both Apache and tomcat need a mechanism to get status and change configuration dynamically. Session count is a particular case. Adding/removing workers is another particular case. What I'm thinking about is a general solution. The goals: 1. Extensible/Modular. Maybe you want to get other internal informations, or change other parameters at run time. 2. Minimal ( or no ) changes in the core or protocols. Changes are bad bacause they add bugs, require releases , etc, and if we do (1) right, then no other change is needed. > As another solution, I could leave 8080 running on each TC and have a > servlet that accesses the Response to get the session count (with the > getSessionCount() methods I've added) (ie the /admin app as you suggested > before with minor modifications). Although, I'm not too fond of this > solution because I'd have to keep the 8080 TCP listener, (in order to access > a specific TC) and have a login for each query... > But for simplicity's sake, it may be the way to go. Well, having Ajp13 or Http listeners is almost the same, you don't need the HTTP running if you have Ajp13 ( and a Ajp13 client - like apache ). Regarding login for each query - this is an admin task, so it's not performance-critical. > Whatever the front end is, I'll still need to add getSessionCount() methods > to the ContextManager, StandardManager, and StandardSessionManager. (yes?) I'm not sure you need to change ContextManager for that - you can get the list of Contexts, and for each Context you can access the StandardManager - and get the session count from it. All that can be done ( IMHO ) from a servlet, without any change in the core - the only special thing is getting a pointer to the ContextManager. > Sorry for the long rant, but I think I'm working on some good functionality > that others could use as well, and I want to get it right. +1. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: acive session count?
Title: RE: acive session count? Morning, Comments below... > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 10, 2001 11:20 AM > To: '[EMAIL PROTECTED]' > Subject: RE: acive session count? > > > Hi, > > > Solution: Dan Milstein is adding my patch to mod_jk. It > forces an instance > > of Tomcat in the load balance list to reject new > connections, but continue > > to service existing sessions. (by setting worker.name.active=0, and > > restarting my apaches) > > Question: can this be done _without_ restarting apache ? > Not without having some platform/product specific code... As you suggest below, I would have to add function to Apache only, and I would really like this to work for all web servers. Granted, it would be good to be able to change a containers status without a restart, but I didn't/don't consider restarting the web server to be bad. (In our case, we do it as required with a 'killall -USR1 httpd' for a graceful restart), but we do have 6 Apaches LVS'd...) > I was thinking about the whole > "configuration/reconfiguration/signales" mechanism, > and IMHO there is a simpler solution: instead of using > signals and AJP13 > extensions, it may be better to just use plain HTTP and normal > servlets/apache handlers. The extensions I made to AJP12 were to _query_ the TC instance for an acive session count (from the command line). > > Creating a simple /jk_admin is not difficult ( a simple > handler that will > accept an authenticated HTTP request and alter the > configuration ). That > will allow run-time addition of apps and workers without restarting > apache. > > For tomcat side, few extra servlets on the admin app will be > much easier > and safer to develop than changing the protocols or other > internals ( and > will probably be more re-usable ). I have to agree that the changes I've made to the protocol are quite intrusive. Again, I'm looking for a simple way to get the active session count from a specific TC instance. I agree that a jk_admin type application to control the load balancer and get session info would be great and very usefull, but that would have to access information from the web server (who's in the list, who's active) and each TC (how many sessions). So even if I built an Apache admin app, I would still have to add methods to Tomcat to return active session counts. (Although I would not have to modify AJP12...) As another solution, I could leave 8080 running on each TC and have a servlet that accesses the Response to get the session count (with the getSessionCount() methods I've added) (ie the /admin app as you suggested before with minor modifications). Although, I'm not too fond of this solution because I'd have to keep the 8080 TCP listener, (in order to access a specific TC) and have a login for each query... But for simplicity's sake, it may be the way to go. Whatever the front end is, I'll still need to add getSessionCount() methods to the ContextManager, StandardManager, and StandardSessionManager. (yes?) Sorry for the long rant, but I think I'm working on some good functionality that others could use as well, and I want to get it right. Thanks, mk
Re: acive session count?
Costin, Hmmm. On the one hand, I very much like your idea of a) moving these admin-type functions out of the mod_jk code and into a handler and b) not requiring a restart of the web server. On the other hand: 1) Michael's code doesn't actually modify the Ajp13 protocol -- it adds a new configuration option to mod_jk.conf, which alters how the web server behaves. So it's not adding any complexity to the protocol. 2) An admin handler would have to be controlling the behavior of the web server. Since one of the strengths of the mod_jk C code is that it works with many servers, any handler which ran in the web server's space would have to be written for a variety of servers. The configuration code which Michael modified is cross-platform, so this is not an issue. 3) Although I, too, fear creeping featurism, I think this function (having the load balancer stop sending new sessions to a container instance) is actually an important piece of what a load balancer does. 4) My instinct is that requiring a restart is probably not a tremendously evil thing. I'm inclined to commit his patch on the 3.3 branch -- I don't think it belongs on 3.2, because it's not really a bug fix. What do you think? -Dan [EMAIL PROTECTED] wrote: > > Hi, > > > Solution: Dan Milstein is adding my patch to mod_jk. It forces an instance > > of Tomcat in the load balance list to reject new connections, but continue > > to service existing sessions. (by setting worker.name.active=0, and > > restarting my apaches) > > Question: can this be done _without_ restarting apache ? > > I was thinking about the whole "configuration/reconfiguration/signales" mechanism, > and IMHO there is a simpler solution: instead of using signals and AJP13 > extensions, it may be better to just use plain HTTP and normal > servlets/apache handlers. > > Creating a simple /jk_admin is not difficult ( a simple handler that will > accept an authenticated HTTP request and alter the configuration ). That > will allow run-time addition of apps and workers without restarting > apache. > > For tomcat side, few extra servlets on the admin app will be much easier > and safer to develop than changing the protocols or other internals ( and > will probably be more re-usable ). > > In general, using common servlets / handlers is much easier, will allow > more people to contribute and can be done independently ( without change > in the main distribution, so without too much to worry about tomcat > release cycle or featurism ). > > ( For apache/server side - while changing mod_jk and adding /jk_admin > inside it may look simple, we can also create a new module and then use it > to manage jk - this will keep the mod_jk code simple ). > > Costin > -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: acive session count?
Hi, > Solution: Dan Milstein is adding my patch to mod_jk. It forces an instance > of Tomcat in the load balance list to reject new connections, but continue > to service existing sessions. (by setting worker.name.active=0, and > restarting my apaches) Question: can this be done _without_ restarting apache ? I was thinking about the whole "configuration/reconfiguration/signales" mechanism, and IMHO there is a simpler solution: instead of using signals and AJP13 extensions, it may be better to just use plain HTTP and normal servlets/apache handlers. Creating a simple /jk_admin is not difficult ( a simple handler that will accept an authenticated HTTP request and alter the configuration ). That will allow run-time addition of apps and workers without restarting apache. For tomcat side, few extra servlets on the admin app will be much easier and safer to develop than changing the protocols or other internals ( and will probably be more re-usable ). In general, using common servlets / handlers is much easier, will allow more people to contribute and can be done independently ( without change in the main distribution, so without too much to worry about tomcat release cycle or featurism ). ( For apache/server side - while changing mod_jk and adding /jk_admin inside it may look simple, we can also create a new module and then use it to manage jk - this will keep the mod_jk code simple ). Costin P.S. I'm working on the bug reported by Larry ( encoding ) - I want to resolve it in a good way, but as I read more the hardest it becomes. If anyone has any experience with encoding/charsets/non-ascii URLs/ JIS /localization - I need help on this one. It seems that it is perfectly reasonable for a japanese/etc user to type his name in a form, and the URL will be generated with SJIS-encoded chars ( GET case ). I found some pages on the internet - but most of them are discussing the problem, and it seems nobody knows any good solution. ( the original problem - keeping the escaped URL and using it for the methods that return escaped paths - is simple. The main problem is what to do when un-escaped paths are needed and when serving files with non-ASCII chars in the name - and even more, how to do that in a way that is consistent with Apache,IIS,NES,AOL behavior. I found an interesting reference at http://www.arsdigita.com/asj/multilingual, and few RFCs, but it's still far from what I need ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: acive session count?
Title: RE: acive session count? Costin, (et. al.) Getting the session count from the /admin app worked pretty well... BUT, I've got multiple Tomcats in a load balance and I need to access a _specific_ instance. My problem: gracefully remove a Tomcat box from the list for maintenance. Solution: Dan Milstein is adding my patch to mod_jk. It forces an instance of Tomcat in the load balance list to reject new connections, but continue to service existing sessions. (by setting worker.name.active=0, and restarting my apaches) That's half the battle, now I need to know when all the sessions are ended. (Without having Tomcat specific code in my servlets...) I was hoping to send a SIGUSR1 through the JVM, but that is a platform dependant signal... Then I looked at StopTomcat.java... I created SignalTomcat.java (based on StopTomcat) and modified Ajp12ConnectionHandler.java (and others) to accept a USR1 (int 16) and return the active session count back down the socket. This is called through the command 'tomcat.sh send 16' I guess my question is: what do you think (of the idea)? Is anyone else needing this same funcionality? Is there a better way? In regards to distributed sessions; How will/would/should the distributed sessions handle an inactive Tomcat, or what will happen to the distributed sessions when a TC is remove from the list? > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 06, 2001 1:49 PM > To: tomcat-dev (E-mail) > Subject: Re: acive session count? > > > > I need to get a count of the number of active sessions in > an instance of > > Tomcat. > > > > Was hoping it could be a flag (Tomcat -getSessionCount) or > the like, so I've > > been looking at adding a getSessionCount() method from the > StandardManager, > > through to Tomcat... But I need to get the ContextManager > for the running > > instance. And that isn't stored as a static. > > > > Is this info available through other avenues? Any > solutions/ Pointers in the > > right direction? > > You can take a look at the /admin application - there is code > to access > the Request and from there you can access the ContextManager, all > Interceptors, etc. > > The mechanism for accessing Request is greatly enhanced in 3.3 ( and a > taglib is provided ), but 3.2 and 3.1 should work as well. > > Costin > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] >
Re: acive session count?
> I need to get a count of the number of active sessions in an instance of > Tomcat. > > Was hoping it could be a flag (Tomcat -getSessionCount) or the like, so I've > been looking at adding a getSessionCount() method from the StandardManager, > through to Tomcat... But I need to get the ContextManager for the running > instance. And that isn't stored as a static. > > Is this info available through other avenues? Any solutions/ Pointers in the > right direction? You can take a look at the /admin application - there is code to access the Request and from there you can access the ContextManager, all Interceptors, etc. The mechanism for accessing Request is greatly enhanced in 3.3 ( and a taglib is provided ), but 3.2 and 3.1 should work as well. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: acive session count?
Michael Kuz wrote: I need to get a count of the number of active sessions in an instance of Tomcat. Was hoping it could be a flag (Tomcat -getSessionCount) or the like, so I've been looking at adding a getSessionCount() method from the StandardManager, through to Tomcat... But I need to get the ContextManager for the running instance. And that isn't stored as a static. Is this info available through other avenues? Any solutions/ Pointers in the right direction? Well, anything that accesses Tomcat internals is going to be Tomcat-specific ... You might consider one of the following approaches: * Under Tomcat 3.2 (servlet 2.2 API), have your application always install an object of a particular class in the user's session when they log on. Have this class implement HttpSessionBindingListener. Then, you can accumulate and maintain a list (or count, or whatever) of the active sessions. * Under Tomcat 4.0 (servlet 2.3 API), implement an application events listener that hears about all session creations and destructions. This works without even needing cooperation from other parts of your app to make sure they install an HttpSessionBindingListener object. Thanks, mk Craig McClanahan
acive session count?
Title: acive session count? I need to get a count of the number of active sessions in an instance of Tomcat. Was hoping it could be a flag (Tomcat -getSessionCount) or the like, so I've been looking at adding a getSessionCount() method from the StandardManager, through to Tomcat... But I need to get the ContextManager for the running instance. And that isn't stored as a static. Is this info available through other avenues? Any solutions/ Pointers in the right direction? Thanks, mk
