search

tailhook / rotor

The mio-based framework for rust for doing I/O in simple and composable way (ABANDONED)
MIT License
361 stars 25 forks source link

Add Machine to Running Loop #25

Closed KodrAus closed 8 years ago

KodrAus commented 8 years ago

Is it possible to add a new state machine to a loop that's already running? I'm looking through rotor_cantal and see it maintains a set of listeners, but those are added before the loop is run, right?

I'm building a rotor_http impl for the Elasticsearch API, where we can have multiple nodes at different addresses that I want to maintain a persistent connection to. The issue is that if the nodes change; new nodes appear, nodes curl up and die etc, I need to be able to add/remove connections accordingly.

To add new machines do I need to stop the running loop, recreate the machines and then rerun it? Or can I somehow register a new machine with the scope from another machine?

EDIT: Actually thinking now it might be better to have a known number of connection machines, and connect to any address in the cluster, provided there isn't already a listener on that address. Then if stuff changes, they can either reconnect elsewhere, or just go to sleep. Does that sound like a good idea?

tailhook commented 8 years ago

Sure, you can add a machine to a running loop. Here is the (somewhat complicated) example.

The basic idea is that you return Response::spawn from a state machine and then Machine::create is used to construct a state machine from the Seed value (the value that you pass to spawn).

If you need to create additional state machines (i.e. a list of them) you return Reponse::spawn from the Machine::spawned as it is called after each new state machine is created (on the state machine that originally returned the Response::spawn).

tailhook commented 8 years ago

Actually thinking now it might be better to have a known number of connection machines, and connect to any address in the cluster, provided there isn't already a listener on that address. Then if stuff changes, they can either reconnect elsewhere, or just go to sleep. Does that sound like a good idea?

Yes and no. I like persistent connections. I.e. that always reconnect and ready to use instead of being spawned on a request. But this part:

Then if stuff changes, they can either reconnect elsewhere or just go to sleep

Looks weird. It's better to create the number of state machines that exactly matches the number of connections (i.e. the number of servers in a cluster). Having "spare" ones looks weird.

KodrAus commented 8 years ago

It's better to create the number of state machines that exactly matches the number of connections (i.e. the number of servers in a cluster). Having "spare" ones looks weird.

That makes sense, having a set number of machines that may or may not be larger than the total possible servers to connect to was my fallback incase it wasn't possible to create them on-the-fly.

As usual I shall dig through your examples and wing it :)