Shutting down Vert.x

[yahim stnsc]

The documentation about vert.x shutdown is quite scarce. Except for Vertx.close i did not find much in the guide. 

Is there a way to trap the shutdown of vert.x and do my own clean asynchronous shutdown and then trigger the vertx shutdown? 

The goal is:

1. precicely control the order in which Verticles are shutdown. (I have long lived connections and no point in shutting down those before 

2. maybe i could "move" some verticles and simulate an HA (since the HA verticle are not restarted in case of a clean shutdown)

Regards,

Mihai

[Tim Fox]

Hi Yahim,

If you close Vert.x then any deployed verticles are undeployed and various other things like http servers, client, net servers, clients, timer handlers and event bus handlers are deregistered before exiting.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mihai Stanescu]

Hi Tim,

If you close Vert.x then any deployed verticles are undeployed and various other things like http servers, client, net servers, clients, timer handlers and event bus handlers are deregistered before exiting.

This i agree, however i am mostly interested in the order how this happens (i miss the the control over the order). This orchestration is of course not necessarily the job of the framework but it should give me control to do my shutdown before is going down. 

In my case i am doing a kind of stateful message exchange between some peers  and when its shutting down i have to cleanly notify these peers. Of course there are mechanisms in the whole system to recover if a node fails its just that the clean notification would be more friendly to the users. (doing a best effort). I could even move some of this state to other nodes before loosing it so the peers would not necesarily feel it. 

Regards

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/q80wHgHiyqA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Tim Fox]

On 02/07/15 12:36, Mihai Stanescu wrote:

Hi Tim,

If you close Vert.x then any deployed verticles are undeployed and various other things like http servers, client, net servers, clients, timer handlers and event bus handlers are deregistered before exiting.

This i agree, however i am mostly interested in the order how this happens (i miss the the control over the order). This orchestration is of course not necessarily the job of the framework but it should give me control to do my shutdown before is going down.

If you could give me a concrete example of why order of undeploy is important that would help me understand. I think usually it makes sense to design a system such that undeploy order (amongst peers) is not important.

But even with Vert.x standard undeploy there is still some degree of ordering - e.g. child verticles of a verticle are undeployed before the parent.

In my case i am doing a kind of stateful message exchange between some peers  and when its shutting down i have to cleanly notify these peers.

I'm not sure I understand the connection between doing a clean notification and undeploy order....

But in any case, you have full control over undeployment order anyway. Just call vertx.undeploy() in whatever order you want.

[Mihai Stanescu]

Hi, 

If you could give me a concrete example of why order of undeploy is important that would help me understand. I think usually it makes sense to design a system such that undeploy order (amongst peers) is not important.

So i have voip clients connected over SSL to a node lets say and we have

 - client connection verticles (a kind of bridge from SSL to eventbus) (long lived authenticated connections) (legacy stuff this this is how it is now)

 - call verticles (handle signaling state of a voip call, timers, setup the audio bridges, write statistics, etc).

But even with Vert.x standard undeploy there is still some degree of ordering - e.g. child verticles of a verticle are undeployed before the parent.

The connection verticles are not necessarily a parent of the call verticles. 

In my mind the sequence should go like this:

 - vert.x detects a request to shutdown

 - vert.x notifies the "app" somehow through some handler (if one registered) to perform the shutdown procedure and then waits

 - "app" gets a shutdown notification and undeploys the call verticles then when these are finished undeploys the connection verticles and closes the SSL connection.

Closing the connection is not enough because the voip clients are quite resilient and initially treat the failure as a recoverable failure and continue being in a call until proven otherwise after some timeout. Also this authenticated client connection is shared with other services.

As i said, the system survives converges eventually, its just not very "reactive" . I just could not find a way to perform the sequence. I looked a bit into the jvm shutdown hooks but i see are executed in parallel. 

Thanks for your time.

Mihai

[Tim Fox]

Mihai,

On 02/07/15 13:14, Mihai Stanescu wrote:

Hi, 

If you could give me a concrete example of why order of undeploy is important that would help me understand. I think usually it makes sense to design a system such that undeploy order (amongst peers) is not important.

So i have voip clients connected over SSL to a node lets say and we have

 - client connection verticles (a kind of bridge from SSL to eventbus) (long lived authenticated connections) (legacy stuff this this is how it is now)

 - call verticles (handle signaling state of a voip call, timers, setup the audio bridges, write statistics, etc).

But even with Vert.x standard undeploy there is still some degree of ordering - e.g. child verticles of a verticle are undeployed before the parent.

The connection verticles are not necessarily a parent of the call verticles. 

In my mind the sequence should go like this:

 - vert.x detects a request to shutdown

 - vert.x notifies the "app" somehow through some handler (if one registered) to perform the shutdown procedure and then waits

 - "app" gets a shutdown notification and undeploys the call verticles then when these are finished undeploys the connection verticles and closes the SSL connection.

This is all doable without any changes in Vert.x.

You can create a "manager" verticle (your "main" verticle) who's purpose is to deploy all the other verticles - call, connection and ssl. It can do this in whatever order you like.

Then in the stop() method of your manager verticle just undeploy them in whatever order you like.

Then to undeploy your app just stop the manager verticle.