[JBoss AS Development] - Re: Graceful Shutdown
by emuckenhuber
"bstansberry(a)jboss.com" wrote :
| "emuckenhuber" wrote : Additionally you should combine deployer and runtime services into one consistent profile description (incl. the acceptor).
| |
| | This would also mean that e.g. acceptor.start() will be called before even looking at the user deploy folder.
|
| I think the deployment of an "acceptor" can be part of the deployment of the stuff in the deploy folder; e.g. its an element in what gets deployed as part of a war. It's not a general part of the web server that exists independent of a war. For example, to handle a similar problem (url]https://jira.jboss.org/jira/browse/JBAS-6534[/url]) deployment of a clustered war includes installing a Tomcat Valve. I'm starting to experiment with a similar thing as the implementation of an "acceptor" for the web container.
|
| When the acceptor gets called to execute it's graceful shutdown logic is a different thing from how it gets deployed. The call of course needs to happen very early in the shutdown process.
|
Hmm ok, i thought of an acceptor more of a facade handling both. First making sure connectors and other ports are openend once all apps are deployed and closed before undeploying. As well as handling the actually context bound to specific applications you were referring to.
"bstansberry(a)jboss.com" wrote :
| "emuckenhuber" wrote : Doing a brief research - in the TomcatService there is a handleNotification, which actually starts and stops the connectors. So the question is if the acceptor interface should also specify a contract for this. Otherwise we could end up opening ports without any user application installed, as this is something MC also does not know about.
|
| Interesting question. The way the TC Connector gets started/shutdown is pretty ad-hoc. I talk above about a "war-scoped acceptor", which may be necessary. But maybe I'm wrong and it can all be done with a single acceptor associated with the connector. As I experiment I'll try and see how that can fit.
|
Well i think it would be good to handle this a better way than requiring services to listen to a jmx notification, since JMX should be optional at one point. Although we need to check how much sense it makes for other services. With the "pretty ad-hoc" startup/shutdown of TC connectors you refer to time it needs to start. Compared to starting of some clustering services?
It was more an issue i noticed - so it might does not really work trying to solve both with the same interface. So far i considered what happens in the gracefulShutdown() method as implementation detail - therefore mostly ignored that. So it really depends on your experiment what would should be done.
"bstansberry(a)jboss.com" wrote :
| anonymous wrote : That's why i was asking if we need something like a 'acceptor' deployment phase - which is deployed last and undeployed first. So that you can just write your usual MC bean deployment thingy. In the end this is also not something ProfileService knows about, but it controls when deployments are deployed.
| | It most probably makes more sense to move the responsibility to the "central management bean" and the acceptor interface - where you basically have to decouple the acceptor from the MC lifecycle, or so ?
|
| Do deployment phases fit with the shortish-term vision for the profile service? IIRC when I looked at this before, the order in which sub-profiles got deployed was based on the order in which they are specified in the xml; i.e. no real deployment phases any more.
|
| If there are deployment phases, is it this "central management bean" that gets deployed in the last deployment phase? Acceptors are deployed with the runtime services; get injected into central management bean when it deploys last. In start(), which is now the last thing, it activates the acceptors. In stop() it tells the acceptors to do their graceful shutdown stuff.
Hmm, yeah DeploymentPhase was maybe a wrong term. I should have rather referred to it as DeploymentPhaseGroup or something similar. Where each Profile defines a deployment phase, but we have an additional helper defining a sort of relative ordering. Since Profiles like "deploy/" and "farm/" would be considered as user profiles they would end up at the end of this list - even without specifying any additional dependencies. So there could be a addition for an activator phase/group thingy.
As you referred to the ordering in the xml - yeah this is something we are working on to get done in a better way. There will be post about this once there this is in a better shape.
"bstansberry(a)jboss.com" wrote :
| Without deployment phases that can still work; the "central management bean" is just part of the last sub-profile in the list.
Hmm i'm not really sure if the install callbacks work if you install it at the end - so this bean should be rather get deployed quite early.
First i thought we can connect that to the ProfileServiceBootstrap, but if you need an Executor created by jboss-threads this won't make much sense. Maybe we should just wait a bit on your experiment and then look again where to exactly put that?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268771#4268771
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268771
16 years, 1 month
[JBoss AS Development] - Re: Graceful Shutdown
by bstansberry＠jboss.com
Warning: I wander all over in this post as I think things through. :-)
"emuckenhuber" wrote : Additionally you should combine deployer and runtime services into one consistent profile description (incl. the acceptor).
|
| This would also mean that e.g. acceptor.start() will be called before even looking at the user deploy folder.
I think the deployment of an "acceptor" can be part of the deployment of the stuff in the deploy folder; e.g. its an element in what gets deployed as part of a war. It's not a general part of the web server that exists independent of a war. For example, to handle a similar problem (url]https://jira.jboss.org/jira/browse/JBAS-6534[/url]) deployment of a clustered war includes installing a Tomcat Valve. I'm starting to experiment with a similar thing as the implementation of an "acceptor" for the web container.
When the acceptor gets called to execute it's graceful shutdown logic is a different thing from how it gets deployed. The call of course needs to happen very early in the shutdown process.
"emuckenhuber" wrote : Doing a brief research - in the TomcatService there is a handleNotification, which actually starts and stops the connectors. So the question is if the acceptor interface should also specify a contract for this. Otherwise we could end up opening ports without any user application installed, as this is something MC also does not know about.
Interesting question. The way the TC Connector gets started/shutdown is pretty ad-hoc. I talk above about a "war-scoped acceptor", which may be necessary. But maybe I'm wrong and it can all be done with a single acceptor associated with the connector. As I experiment I'll try and see how that can fit.
anonymous wrote : That's why i was asking if we need something like a 'acceptor' deployment phase - which is deployed last and undeployed first. So that you can just write your usual MC bean deployment thingy. In the end this is also not something ProfileService knows about, but it controls when deployments are deployed.
| It most probably makes more sense to move the responsibility to the "central management bean" and the acceptor interface - where you basically have to decouple the acceptor from the MC lifecycle, or so ?
Do deployment phases fit with the shortish-term vision for the profile service? IIRC when I looked at this before, the order in which sub-profiles got deployed was based on the order in which they are specified in the xml; i.e. no real deployment phases any more.
If there are deployment phases, is it this "central management bean" that gets deployed in the last deployment phase? Acceptors are deployed with the runtime services; get injected into central management bean when it deploys last. In start(), which is now the last thing, it activates the acceptors. In stop() it tells the acceptors to do their graceful shutdown stuff.
Without deployment phases that can still work; the "central management bean" is just part of the last sub-profile in the list.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4268653#4268653
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4268653
16 years, 1 month