I've thought about this too.
I thought about "invocation valves" (buffering up requests until you are ready to process them - an idea from the JBoss camp), but then ended up thinking more like you.
Invocation valves are probably the natural way to go in e.g. standalone Jetty. However, in a clustered situation, I see no reason to hold up the request is another node can process it.
Firstly, a Listener should only be started if there is something to serve - this means that the load-balancer will look elsewhere whilst there is nothing available on a node. Taken to the logical conclusion this would mean starting the listener after the first app is deployed, stopping it if the number of apps ever falls below one and starting it again when the number rises above 0.
Secondly, as you suggest, the load-balancer should be able to check for the availability of an individual context. Thus, when the Listener is active, and more than one app deployed, it will only forward requests for which it knows an application is waiting. (I believe BIGIP can be configured to look for a particular string in a particular page - this would be perfect, as it could either look for e.g. your apps front page, or a mention of a particular context in an admin page which listed all current deployments).
There is one further issue, which I think JSR88 (or 77, I always get them muddled) suggests as an option - the distinction between {undeploy();deploy();} and redeploy(). If requests are going to be stored up during a redeployment then the container needs to know that a redeployment is occurring and not simply that a webapp is being undeployed, with no guarantee that it will ever be deployed again.
I have discussed this with Greg, and I think Jetty is moving in that direction although I am not sure about specifics.
How does that sound ?
Jules
Dennis Cartier wrote:
Hello Everyone,
I recently asked about preventing 404's when a webapp is being redeployed,
or JBoss is being booted. You can read my original post at:
http://www.jboss.org/forums/thread.jsp?forum=64&thread=24532
Sacha, suggested I discuss it on the Jetty list.
I have given this a fair bit of thought recently. I see this as 2 seperate
yet related situations. When a webapp is being redeployed, or when it (or
JBoss) is not running.
The best possbile solution I could come up with, is to modify the AJP13 code
to add a method of querying the availability of a particular context/URI of
a running Jetty instance. In my situation, my loadbalancer (mod_Backhand),
allows me to select a candidate server based on custom candidacy functions.
So if I were able to query Jetty and ask each node if it could serve a
particular URI, that would allow me to eliminate the nodes that will 404
becasue of a redeploy or missing webapp.
This is how I currently make sure JBoss is running before sending a request
to the AJP port. I have a function that connects to the 8009 port and skips
any servers that do no have that port open.
What Sacha said got me to thinking this might be solvable another way, and
work out better in the long run. If altering the "invocation-valve" could
fix the 404 on redeploy, then all that would be left is the ~30 seconds or
so while the AJP port is open (so mod_backhand starts forwarding request
here), but the webapps are not deployed yet. If the order could be altered,
so that the webapps were deployed first, then the AJP listener, this would
work for me.
Hmmm, what about removing the AJP listener config from the jboss-service.xml
file and having a webapp (the last one to load), activate it. Could this be
done? If so how?
Thanks
Dennis Cartier
---
The man with tremendous wealth is a paradox: he has to be smart enough to
get it, yet stupid enough to want it. - Chesterton
For the latest information about Jetty, please see http://jetty.mortbay.org
To alter your subscription to this list goto http://groups.yahoo.com/group/jetty-discuss
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
