You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been using this library for a few months now, it fits well my use case and my messages volume.
I recently got to the point where I need to start multiple servers (all pointing to the same Redis instance, but on a different DB index) using errgroup.WithContext.
I see that, as per the Wiki, asynq.Server already has a waitForSignals method to gracefully shut itself down, but in my specific case I need to terminate all the instances in the (unlikely) case one of them can not start, or in the (more likely) case another goroutine from the same errgroup terminates.
So, given:
the context returned by errgroup.WithContext() is already cancelled on first error
I was wondering whether it'd be beneficial to implement a RunContext method on asynq.Server to accept a context argument (to be fed into signal.NotifyContext) and have the instance gracefully shutdown when either an OS signal is caught or the parent context is cancelled - the latter event may occur too with t.Context() (from the testing package), which I utilise to run certain component tests that leverage a Redis docker container.
For the time being, I worked around that with a helper function (e.g.: example03/asynq_generated) where I invoke Server.Run, wait on <-ctx.Done, and then I call Server.Stop + Server.Shutdown.
However, I'm not entirely sure that is the correct approach because both methods leverage the srv.state.mu.Lock but call Unlock as soon as the srv.state.value changes (rather than waiting for the server to actually stop or shut down): this to me looks like I'm hitting a potential race condition where either my explicit Stop or Shutdown invocations return early without waiting, because chances are waitForSignals has already initiated the termination process.
Update: found the way!
Using Start() instead of Run() made this fairly trivial to solve, e.g.:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Update: solved, see bottom
Hello!
I've been using this library for a few months now, it fits well my use case and my messages volume.
I recently got to the point where I need to start multiple servers (all pointing to the same Redis instance, but on a different DB index) using errgroup.WithContext.
I see that, as per the Wiki,
asynq.Serveralready has a waitForSignals method to gracefully shut itself down, but in my specific case I need to terminate all the instances in the (unlikely) case one of them can not start, or in the (more likely) case another goroutine from the sameerrgroupterminates.So, given:
errgroup.WithContext()is already cancelled on first errorI was wondering whether it'd be beneficial to implement a
RunContextmethod onasynq.Serverto accept a context argument (to be fed intosignal.NotifyContext) and have the instance gracefully shutdown when either an OS signal is caught or the parent context is cancelled - the latter event may occur too witht.Context()(from the testing package), which I utilise to run certain component tests that leverage a Redis docker container.For the time being, I worked around that with a helper function (e.g.: example03/asynq_generated) where I invoke
Server.Run, wait on<-ctx.Done, and then I callServer.Stop+Server.Shutdown.However, I'm not entirely sure that is the correct approach because both methods leverage the
srv.state.mu.Lockbut callUnlockas soon as thesrv.state.valuechanges (rather than waiting for the server to actually stop or shut down): this to me looks like I'm hitting a potential race condition where either my explicitStoporShutdowninvocations return early without waiting, because chances arewaitForSignalshas already initiated the termination process.Update: found the way!
Using
Start()instead ofRun()made this fairly trivial to solve, e.g.:Beta Was this translation helpful? Give feedback.
All reactions