On 11/11/2013 04:35, Suresh Mathew wrote: > Hi Mark, > Thank you very much for the response. Sounds good. Would the init be > also initializing the app?.
No. The Containers would start normally. It would just be the the connector(s) that had to be started later. > Because we want the bind(start in this > scenario) to be as small as possible. The more you articulate your requirement, the more I think this is the wrong solution and that what you really need to be doing is either using a load-balancer or using parallel deployment. You also have the option of the approach Konstantin suggested elsewhere in this thread. I'm reluctant to add yet another configuration option for a use case that can already be met in multiple ways. Mark > Thanks > Suresh > > > > > > > On Fri, Nov 8, 2013 at 12:25 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 08/11/2013 04:18, Suresh Mathew wrote: >>> All, >>> Can we add a new state to bind the port after the startup is completed. >>> >>> Right now start will start the app after binding to the port. We can >> delay >>> the binf after connector is started using bindOnInit. But this is a >> little >>> different. >>> >>> StartOnly - Starts The Server and the apps. >>> Bind - Then Binds it to the Port and the server starts listening >>> Unbind - Unbinds the port, but keep the server running not listening >>> Stop- Will Stop(and unbind if bound) the server. >>> >>> The usecase for this is instant rollback (which can also be achieved with >>> parallel deployment, but within the same process), Two servers will be >>> running but one will be bound, and if there is a need to rollback to the >>> old version, we can unbind this and bind the other. >>> >>> This will also help make the best use of the PORT_REUSE of the latest >> 3.9.0 >>> linux kernel feature. >>> >>> Does that make any sense? >> >> It does, but I think I'd implement it a different way. A flag could be >> added to the Service to decouple the init() and start() of the >> connectors. They could then be started and stoped as required via JMX. >> Stopping the Service would always stop and attached connectors. >> >> Mark >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
