Re: "Application" vars -
On Sat, Jul 3, 2010 at 7:08 PM, Christopher Schultz wrote: > Heck, you can > even use a single class that is a servlet but also implements > ServletContextListener, and have everything in one class. Setting up a case study for a "Real-life Refactoring" course? :-) -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric, On 6/28/2010 11:37 PM, Eric P wrote: > I've been loading up my web.xml with context and init params for my > first app, but I'm thinking at some point it'd be nice to tweak these > values on the fly while the app is running. > > What are some good practices to accomplish this? > > I'm leaning towards storing all application variables in a database > table w/one record, and loading these values into the application scope > w/a servlet on app startup. Then if I need to tweak any values I could > update the db record and hit this servlet to reload all the application > scope vars. I think this seems like a reasonable idea. I would use a ServletContextListener to trigger the initial load from the db or other data source (properties file, etc.). You could even use variables from web.xml in s if you want. The only caveat to this option is that you can't very well change web.xml during runtime and re-load the vars. Instead, you'd have to have a mechanism to change those variables either manually and individually (like an admin "system settings" page), or load from another data source, at which point you may as well forget s in the first place. You'll want to use a servlet, of course, for re-loading your settings from file/db/etc. I would recommend making the aforementioned ServletContextListener and this servlet share a helper class that loads and settings and puts them into the application scope. Heck, you can even use a single class that is a servlet but also implements ServletContextListener, and have everything in one class. Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwv7SUACgkQ9CaO5/Lv0PAyBQCggcLWFKXPqTSksO5dUVORJ8ih LtQAoK6wZbIArJSQe1pZ9fqeGWtn/PvV =Vdua -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
Just my comments on the dispatching idea proposed below... If smooth processing with no freeze-time is important, I'm assuming there is also some sort of cluster/high-availability functionality. If this is the case, you are already running at least two Tomcats on different servers, and using some load-balancing/dispatch mechanism - for example Apache with mod_jk. If you have just one Tomcat you have much more to worry about than Tomcat freezing during webapp reload :) So, why not just use the load balancer's functionalities, instead of writing a dispatcher yourself (webappX below)? In other words, you stop the webapp on tomcat1 - the load balancer (or mod_jk or whatever) detects this immediately and stops forwarding requests to it. You do whatever config change, and start the app again. At this point the new app is added back to the load balancer. Repeat same thing with tomcat2, tomcat3... Seems simpler than deploying two copies of a webapp + a third dispatcher that you need to write and maintain (and all this across the N servers in your cluster)... One last note: if I remember correctly, you can only forward requests within the same servlet context (i.e. webapp), so "dispatching" from webappX to webappA or webappB would be non-trivial. You could do redirections, but this exposes your internal mechanism to clients and is really bad. Shay On Fri, Jul 2, 2010 at 4:27 AM, André Warnier wrote: > Eric P wrote: > >> So it makes sense to go into what "disruption" means. I'm not 100% sure >>> about the following, it would be good if a tomcat heavyweight would >>> confirm/refute what I say. >>> >>> When you initiate a webapp reload, Tomcat waits for requests that have >>> already started processing to terminate. This ensures that people who >>> accessed your app just before the webapp get a complete response. Once >>> that's done, the application is reloaded and your servlets' init methods >>> are >>> called if necessary. During this time, incoming requests aren't denied, >>> they >>> are just paused until the reload is complete. >>> >>> So the only disruption people see is your application freezing up for the >>> time it takes to reload (which is going to depend on what you your >>> initialization consists of). No ugly server unavailable errors or >>> anything >>> of the sort. >>> >>> If you don't like the idea of your app freezing, think about this. >>> Rereading >>> environment params without reloading has its own risks, namely potential >>> race conditions. Imagine you have 5 parameters, and requests are coming >>> in >>> as you are reading these in and initializing your webapp. A request might >>> be >>> handled while 2 params have been read, but 3 still contain the old >>> values. >>> If you start to think about locking/synchronization to solve this you're >>> definitely better off just using Tomcat's reload mechanism. >>> >>> So my answer would be, trust Tomcat's reloading process unless you >>> absolutely want to avoid your webapp freezing for the time it will take >>> for >>> it to init (this depends on the webapp). If you want to do your own >>> "reloading", think long and hard about potential race conditions (which >>> will >>> occur in all except the simplest cases). >>> >>> Again, all this should probably be verified, you can set up very simple >>> test >>> cases with a JSP that sleeps, etc. >>> >>> >>> >> Shay, >> I think you made a good case for keeping app vars in web.xml (i.e., seems >> pretty apparent now that's where they belong). >> >> Thanks for taking the time to respond. I sincerely appreciate it! >> Eric P. >> >> +1 > Very neat explanation. > > While not being a great specialist, I would just like to expone what may be > an alternative, if one really wants to diminish the (apparent) time it takes > for a new version of a webapp to become available. Since I am no great > specialist, I will just outline the idea without Java/servlet specifics. > > (Maybe also I am barging through an open door, and there already exists a > standard mechanism for doing this, but oh well..) > > Imagine that you have 2 identical versions of the same intrinsic webapp > deployed, like > > catalina_base/webapps/webappA > catalina_base/webapps/webappB > > You create a 3rd webapp webappX, which is the one the users see, and which > is just a "dispatcher" to either one of the two webapps webappA and webappB. > So you now have : > > catalina_base/webapps/webappX > catalina_base/webapps/webappA > catalina_base/webapps/webappB > > The users always use the URL "/webappX". > When a call is made to webappX, /it/ decides, in function of some external > parameter Y, whether to dispatch the call to either webappA or webappB. > > Say that initially the external parameter Y (which could be a system-wide > property) is set so that all calls to "/webappX" are currently dispatched to > /webappA. > Now you want to update webappA. > You change the parameter Y so that calls are now dispatched to (identical) > /webappB. > Th
Re: "Application" vars -
Eric P wrote: So it makes sense to go into what "disruption" means. I'm not 100% sure about the following, it would be good if a tomcat heavyweight would confirm/refute what I say. When you initiate a webapp reload, Tomcat waits for requests that have already started processing to terminate. This ensures that people who accessed your app just before the webapp get a complete response. Once that's done, the application is reloaded and your servlets' init methods are called if necessary. During this time, incoming requests aren't denied, they are just paused until the reload is complete. So the only disruption people see is your application freezing up for the time it takes to reload (which is going to depend on what you your initialization consists of). No ugly server unavailable errors or anything of the sort. If you don't like the idea of your app freezing, think about this. Rereading environment params without reloading has its own risks, namely potential race conditions. Imagine you have 5 parameters, and requests are coming in as you are reading these in and initializing your webapp. A request might be handled while 2 params have been read, but 3 still contain the old values. If you start to think about locking/synchronization to solve this you're definitely better off just using Tomcat's reload mechanism. So my answer would be, trust Tomcat's reloading process unless you absolutely want to avoid your webapp freezing for the time it will take for it to init (this depends on the webapp). If you want to do your own "reloading", think long and hard about potential race conditions (which will occur in all except the simplest cases). Again, all this should probably be verified, you can set up very simple test cases with a JSP that sleeps, etc. Shay, I think you made a good case for keeping app vars in web.xml (i.e., seems pretty apparent now that's where they belong). Thanks for taking the time to respond. I sincerely appreciate it! Eric P. +1 Very neat explanation. While not being a great specialist, I would just like to expone what may be an alternative, if one really wants to diminish the (apparent) time it takes for a new version of a webapp to become available. Since I am no great specialist, I will just outline the idea without Java/servlet specifics. (Maybe also I am barging through an open door, and there already exists a standard mechanism for doing this, but oh well..) Imagine that you have 2 identical versions of the same intrinsic webapp deployed, like catalina_base/webapps/webappA catalina_base/webapps/webappB You create a 3rd webapp webappX, which is the one the users see, and which is just a "dispatcher" to either one of the two webapps webappA and webappB. So you now have : catalina_base/webapps/webappX catalina_base/webapps/webappA catalina_base/webapps/webappB The users always use the URL "/webappX". When a call is made to webappX, /it/ decides, in function of some external parameter Y, whether to dispatch the call to either webappA or webappB. Say that initially the external parameter Y (which could be a system-wide property) is set so that all calls to "/webappX" are currently dispatched to /webappA. Now you want to update webappA. You change the parameter Y so that calls are now dispatched to (identical) /webappB. Then you update (redeploy) webappA. Users see no delay, because they get directed to webappB. When webappA is deployed and started (which you could check by calling it directly), you can reset the parameter Y to its former value, and users will again be dispatched to webappA. Now you can redeploy webappB, to keep it in sync. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
So it makes sense to go into what "disruption" means. I'm not 100% sure about the following, it would be good if a tomcat heavyweight would confirm/refute what I say. When you initiate a webapp reload, Tomcat waits for requests that have already started processing to terminate. This ensures that people who accessed your app just before the webapp get a complete response. Once that's done, the application is reloaded and your servlets' init methods are called if necessary. During this time, incoming requests aren't denied, they are just paused until the reload is complete. So the only disruption people see is your application freezing up for the time it takes to reload (which is going to depend on what you your initialization consists of). No ugly server unavailable errors or anything of the sort. If you don't like the idea of your app freezing, think about this. Rereading environment params without reloading has its own risks, namely potential race conditions. Imagine you have 5 parameters, and requests are coming in as you are reading these in and initializing your webapp. A request might be handled while 2 params have been read, but 3 still contain the old values. If you start to think about locking/synchronization to solve this you're definitely better off just using Tomcat's reload mechanism. So my answer would be, trust Tomcat's reloading process unless you absolutely want to avoid your webapp freezing for the time it will take for it to init (this depends on the webapp). If you want to do your own "reloading", think long and hard about potential race conditions (which will occur in all except the simplest cases). Again, all this should probably be verified, you can set up very simple test cases with a JSP that sleeps, etc. Shay, I think you made a good case for keeping app vars in web.xml (i.e., seems pretty apparent now that's where they belong). Thanks for taking the time to respond. I sincerely appreciate it! Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
Hi Eric. On Wed, Jun 30, 2010 at 9:20 PM, Eric P wrote: > Shay, > > Forgive all potential newbness in my responses below. I'm still learning > this stuff. > > No worries for newbiness, your responses all make sense. > > Shay Rojansky wrote: > >> Hi Eric. >> >> Would making your servlet reload all application vars not be akin to >> simply >> reloading your servlet altogether, by changing context/init params in your >> web.xml or context.xml? >> >> > Do you mean "reloading your 'application' altogether"? If so wouldn't that > cause disruption to users currently on the app? This disruption is what I'd > like to avoid. So it makes sense to go into what "disruption" means. I'm not 100% sure about the following, it would be good if a tomcat heavyweight would confirm/refute what I say. When you initiate a webapp reload, Tomcat waits for requests that have already started processing to terminate. This ensures that people who accessed your app just before the webapp get a complete response. Once that's done, the application is reloaded and your servlets' init methods are called if necessary. During this time, incoming requests aren't denied, they are just paused until the reload is complete. So the only disruption people see is your application freezing up for the time it takes to reload (which is going to depend on what you your initialization consists of). No ugly server unavailable errors or anything of the sort. If you don't like the idea of your app freezing, think about this. Rereading environment params without reloading has its own risks, namely potential race conditions. Imagine you have 5 parameters, and requests are coming in as you are reading these in and initializing your webapp. A request might be handled while 2 params have been read, but 3 still contain the old values. If you start to think about locking/synchronization to solve this you're definitely better off just using Tomcat's reload mechanism. So my answer would be, trust Tomcat's reloading process unless you absolutely want to avoid your webapp freezing for the time it will take for it to init (this depends on the webapp). If you want to do your own "reloading", think long and hard about potential race conditions (which will occur in all except the simplest cases). Again, all this should probably be verified, you can set up very simple test cases with a JSP that sleeps, etc. > > If you really want to avoid an application reload, why not just have your >> app read its values from a properties config file instead of a DB? It >> would >> be much more lightweight and standard. >> >> > That's an idea. But wouldn't file I/O every time a servlet needs an > application value be way more expensive than storing settings in a record, > reading and setting them to the application scope once, and only resetting > these vars manually when needed? > I wasn't proposing to perform I/O and parse the properties file upon every request, simply to parse it once upon init and load it into application-scoped vars. This is exactly the same as what you were planning to do, except that instead of pulling the values from a DB record you pull them from a properties file. Note that using a property file will almost surely be faster (and not to mention simpler) than a database, as connecting to a database usually means network activity, authentication, etc. It would also make changing those values easier - editing a properties file is more straightforward than a database with its schema. But at the end of the day, it all depends on your app. If you already have everything in your DB and it makes sense to have those config values in there too, why not. > > Is this standard documented somewhere? > What exactly? :) > > Thanks... I appreciate the ideas. > Eric > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: "Application" vars -
Shay, Forgive all potential newbness in my responses below. I'm still learning this stuff. Shay Rojansky wrote: Hi Eric. Would making your servlet reload all application vars not be akin to simply reloading your servlet altogether, by changing context/init params in your web.xml or context.xml? Do you mean "reloading your 'application' altogether"? If so wouldn't that cause disruption to users currently on the app? This disruption is what I'd like to avoid. If you really want to avoid an application reload, why not just have your app read its values from a properties config file instead of a DB? It would be much more lightweight and standard. That's an idea. But wouldn't file I/O every time a servlet needs an application value be way more expensive than storing settings in a record, reading and setting them to the application scope once, and only resetting these vars manually when needed? Is this standard documented somewhere? Thanks... I appreciate the ideas. Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
Hi Eric. Would making your servlet reload all application vars not be akin to simply reloading your servlet altogether, by changing context/init params in your web.xml or context.xml? If you really want to avoid an application reload, why not just have your app read its values from a properties config file instead of a DB? It would be much more lightweight and standard. Shay On Mon, Jun 28, 2010 at 11:37 PM, Eric P wrote: > I've been loading up my web.xml with context and init params for my first > app, but I'm thinking at some point it'd be nice to tweak these values on > the fly while the app is running. > > What are some good practices to accomplish this? > > I'm leaning towards storing all application variables in a database table > w/one record, and loading these values into the application scope w/a > servlet on app startup. Then if I need to tweak any values I could update > the db record and hit this servlet to reload all the application scope vars. > > I'm guessing there's some other possibly better ways to go about this. > > Thanks for reading, > Eric P. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
"Application" vars -
I've been loading up my web.xml with context and init params for my first app, but I'm thinking at some point it'd be nice to tweak these values on the fly while the app is running. What are some good practices to accomplish this? I'm leaning towards storing all application variables in a database table w/one record, and loading these values into the application scope w/a servlet on app startup. Then if I need to tweak any values I could update the db record and hit this servlet to reload all the application scope vars. I'm guessing there's some other possibly better ways to go about this. Thanks for reading, Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org