#Lustre Server Components and long running process, that should stop when the server components stops

1 messages · Page 1 of 1 (latest)

red mesa
#

Hi,

On my journey of exploring lustre server components, I came across the following scenario, where I would love some input and how to do this:

In the server I have some global state, that I would like to share and update with all clients (so all running server components).
To do this, the state is held by an actor that also uses glubsub (pubsub library) to Broadcast state updates to any process, that subscribed.

So when a new server component is created (in the lustre init function) I start a custom effect, that spawns a process which:

  • Subscribes to the state updates using glubsub
  • Calls dispatch whenever it receives an update to inform the server component of the update

So far, so good.
But what do I do when the server component stops?
I dont want the proces, that I started at init, to also exit.

But how can I do that? How do I "know" that the sever component has exited?

Thanks!

magic pivot
#

So you have a new process per connection that runs forever? Or does it stop at some later time?

red mesa
#

Yes, exactly, I start a process which runs forever and listens to the pubsub.

#

And when it receives something on the pubsub, it calls the dispatch function to send a message which in turn updates the model.

magic pivot
#

Exactly to which one?

#

I asked A or B 😁

red mesa
#

It runs forever, it does not stop at a later time.

magic pivot
#

That’s a memory leak then, your server will OOM after enough visits

red mesa
#

Yes, exactly. That is the problem I am trying to solve.

magic pivot
#

So sorry, do you do want them to shut down when the client disconnects?

red mesa
#

Yes exactly. And I am struggling on how to do that.

Since the process is created from an lustre effect in the init handler, I don't know how to communicate with it from the "on_close" handle of the websocket.
I was thinking, maybe I can "inject" some sort of "Shutdown" event into the lustre server component, when the websocket shuts down but I have not figured out if that is possible.

dapper patrol
#

do you even need that separate process? if all it does is register itself and forward messages can't you register the component actor directly?

magic pivot
#

Does it not shut down when the parent shuts down?

regal steppe
#

if i'm understanding correctly, the lustre component process spawns a process for pubsub subscriptions, and the subscription process doesn't shutdown when the lustre component shuts down?

#

how are you spawning the subscription process? the two should be linked

red mesa
red mesa
red mesa
dapper patrol
magic pivot
#

I'd probably go for group_registry over glubsub, glubsub's design is rather slow

#

It's using an actor as as store of concurrently accessed state, which isn't what they're for

dapper patrol
#

same, but it's really convenient right now that we still have the old one I guess ^^

red mesa
magic pivot
dapper patrol
#

what are searching for that it doesn't show up 🤔

magic pivot
#

Though Chip's design looks better than glubsub, but I think it's outdated and doesn't support current Gleam OTP

red mesa
magic pivot
#

Google isn't very useful for finding packages

dapper patrol
#

it's above chip for me

image.png
#

but yeah google is really bad these days 😅

magic pivot
#

I guess that's what happens without the search engine tailoring results to your history

dapper patrol
#

still in first place for me on ddg hmmm

magic pivot
#

huh

red mesa
#

But looking directly in the gleam package index is a good tip 🙂

image.png