Periodically send refresh signal to Application

[friedrichroell]

I primarily use PPM to have all kinds of data ready for computation at runtime when a request is coming in. In order for that data to be fresh, i need to reload periodically.
Because ttl only reloads after a request, i cannot be sure that my data is fresh.

Also, with this feature the worker does not get killed but only the method refreshApplication() will be fired on the bridge every refresh-interval seconds.

Note: Only ¼ of the workers in ready state and ready to refresh will be sent to refresh once every 5 seconds.

[andig]

Thank you for the time to write this PR.

I must admit though, that I'm not sure I like the approach. We used to have a AsyncInterface on the bridge that allowed the application to share the slave's loop and execute any async operation. It seems a more general approach than this PR (and a lot less code), however it was never used in production and thus removed.

Would something like that work for you?

[friedrichroell]

Thanks @andig for the feedback.
In order to guarantee availability, refreshes need to be controlled by the main process to prevent all workers from refreshing at the same time. Do you have an idea for a more general approach while at the same time guaranteeing high availability?

In any case, we will test this implementation for our use case and get back to you with hopefully some useful learnings.

[andig]

Once you have async processes rhey could negotiate refreshes amongst themselves using round robin (and a KV store) or any other mechanism.

[friedrichroell]

That would not prevent the balancer from sending requests to workers that are refreshing/reloading because the worker state cannot be shared with the main process.

what exactly is it about this approach, that is bugging you?

[andig]

It is a very specific requirement with a lot of code while, at the same time, we might have one or two long-standing issues.

As for the master sending requests to the client that would not matter as long as they are async as suggested.

Long story short: I feel your PR is a bit beyond the scope of this library.

[friedrichroell]

async or not, if the worker is busy fetching and preparing data, it will not be handling any requests and thus the request will be queued.

Anyway, i understand your concern as in this PR kind of being out of scope and the solution to narrow or rather too use case specific.

I will think about a different and more generic approach. And maybe keeping in mind issue 463

[andig]

Thanks for your understanding. But please also consider that if the worker is async he can well refresh state and handle request concurrently.

[friedrichroell]

Sure, if you rebuild your app to use non blocking deserialisation, db queries and disc I/O operations. But if not, the worker will be blocked on all those operations, regardless of any event loop.

[acasademont]

Hi @Fitzel , you could periodically send a signal to the master process in order to gracefully reload the slaves, I guess that would work?