Re: Late Binding

2013-11-15 Thread Suresh Mathew
On Mon, Nov 11, 2013 at 11:08 AM, Suresh Mathew suresh@gmail.comwrote:




 On Mon, Nov 11, 2013 at 9:32 AM, Konstantin Kolinko 
 knst.koli...@gmail.com wrote:

 2013/11/11 Suresh Mathew suresh@gmail.com:
  Got it Konstantin, Thank you... But stopping and starting would mean
 that
  we spend time in between and wont be able to instance switch?.
 

 You meant s/instance/instant/ ?



 I meant instant. Typo..My bad..


Mark,Konstantin, We got it working by not starting the connector and later
using JMX to start it. Thank you very much.
Would it be something you would consider to be added to the code base?.



 Starting from a new connector and starting a previously stopped
 connector needs exactly the same time.

 Stopping a previously started connector requires some time, but when
 it is not under active usage it should stop fast.  Anyway you can stop
 it at any time before the actual start up.

 I got it. Let me try the connector approach and get back to you.
 Thanks for the suggestion.


 Top-posting is bad.
 http://tomcat.apache.org/lists.html#tomcat-users 6..



  Thanks for pointing this out.



  Best regards,
  Konstantin Kolinko
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org





Re: Late Binding

2013-11-11 Thread Mark Thomas
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



Re: Late Binding

2013-11-11 Thread Konstantin Kolinko
2013/11/11 Suresh Mathew suresh@gmail.com:
 Got it Konstantin, Thank you... But stopping and starting would mean that
 we spend time in between and wont be able to instance switch?.


You meant s/instance/instant/ ?

Starting from a new connector and starting a previously stopped
connector needs exactly the same time.

Stopping a previously started connector requires some time, but when
it is not under active usage it should stop fast.  Anyway you can stop
it at any time before the actual start up.

Top-posting is bad.
http://tomcat.apache.org/lists.html#tomcat-users
- 6..


 Best regards,
 Konstantin Kolinko


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Re: Late Binding

2013-11-11 Thread Suresh Mathew
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.

I agree, Let me try the connector solution and get back to you.

 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.

Parallel deployment may not work for us as the apps will be sharing the
same process. Loadbalancer will definitely work for us, but is another
application(software load balancer) to manage.



Suresh




On Mon, Nov 11, 2013 at 12:50 AM, Mark Thomas ma...@apache.org wrote:

 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




Re: Late Binding

2013-11-11 Thread Suresh Mathew
On Mon, Nov 11, 2013 at 9:32 AM, Konstantin Kolinko
knst.koli...@gmail.comwrote:

 2013/11/11 Suresh Mathew suresh@gmail.com:
  Got it Konstantin, Thank you... But stopping and starting would mean that
  we spend time in between and wont be able to instance switch?.
 

 You meant s/instance/instant/ ?



 I meant instant. Typo..My bad..



 Starting from a new connector and starting a previously stopped
 connector needs exactly the same time.

 Stopping a previously started connector requires some time, but when
 it is not under active usage it should stop fast.  Anyway you can stop
 it at any time before the actual start up.

 I got it. Let me try the connector approach and get back to you. Thanks
for the suggestion.


 Top-posting is bad.
 http://tomcat.apache.org/lists.html#tomcat-users
 - 6..

 Thanks for pointing this out.



  Best regards,
  Konstantin Kolinko
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: dev-h...@tomcat.apache.org




Re: Late Binding

2013-11-10 Thread Suresh Mathew
Hi Mark,
Thank you very much for the response. Sounds good. Would the init be
also initializing the app?. Because we want the bind(start in this
scenario) to be as small as possible.
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




Re: Late Binding

2013-11-08 Thread Mark Thomas
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



Re: Late Binding

2013-11-08 Thread Konstantin Kolinko
2013/11/8 Suresh Mathew suresh@gmail.com:
 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?



Bind it to a random port (0), then stop  reconfigure  start it via JMX?

Note that it would not work if you run Tomcat via jsvc and want to
bind it to a privileged port (80). JSVC drops privileges once the init
completes.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



Late Binding

2013-11-07 Thread Suresh Mathew
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?


Thanks
Suresh