Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add runners to startup the ocis' services #8802

Merged
merged 13 commits into from
Apr 29, 2024
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
Enhancement: Prepare runners to start the services

The runners will improve and make service startup easier. The runner's
behavior is more predictable with clear expectations.

https://github.com/owncloud/ocis/pull/8802
192 changes: 192 additions & 0 deletions ocis-pkg/runner/grouprunner.go
Original file line number Diff line number Diff line change
@@ -0,0 +1,192 @@
package runner

import (
"context"
"sync"
)

// GroupRunner represent a group of tasks that need to run together.
// The expectation is that all the tasks will run at the same time, and when
// one of them stops, the rest will also stop.
//
// The GroupRunner is intended to be used to run multiple services, which are
// more or less independent from eachother, but at the same time it doesn't
// make sense to have any of them stopped while the rest are running.
// Basically, either all of them run, or none of them.
// For example, you can have a GRPC and HTTP servers running, each of them
// providing a piece of functionality, however, if any of them fails, the
// feature provided by them would be incomplete or broken.
//
// Note that, as services, the task aren't expected to stop by default.
// This means that, if a task finishes naturally, the rest of the task will
// asked to stop as well.
type GroupRunner struct {
runners sync.Map
runnersCount int
isRunning bool
runningMutex sync.Mutex
}

// NewGroup will create a GroupRunner
func NewGroup() *GroupRunner {
return &GroupRunner{
runners: sync.Map{},
runningMutex: sync.Mutex{},
}
}

// Add will add a runner to the group.
//
// It's mandatory that each runner in the group has an unique id, otherwise
// there will be issues
kobergj marked this conversation as resolved.
Show resolved Hide resolved
// Adding new runners once the group starts will cause a panic
func (gr *GroupRunner) Add(r *Runner) {
gr.runningMutex.Lock()
defer gr.runningMutex.Unlock()

if gr.isRunning {
panic("Adding a new runner after the group starts is forbidden")
}

// LoadOrStore will try to store the runner
if _, loaded := gr.runners.LoadOrStore(r.ID, r); loaded {
// there is already a runner with the same id, which is forbidden
panic("Trying to add a runner with an existing Id in the group")
}
// Only increase the count if a runner is stored.
// Currently panicking if the runner exists and is loaded
gr.runnersCount++
}

// Run will execute all the tasks in the group at the same time.
//
// Similarly to the "regular" runner's `Run` method, the execution thread
// will be blocked here until all tasks are completed, and their results
// will be available (each result will have the runner's id so it's easy to
// find which one failed). Note that there is no guarantee about the result's
// order, so the first result in the slice might or might not be the first
// result to be obtained.
//
// When the context is marked as done, the groupRunner will call all the
// stoppers for each runner to notify each task to stop. Note that the tasks
// might still take a while to complete.
//
// If a task finishes naturally (with the context still "alive"), it will also
// cause the groupRunner to call the stoppers of the rest of the tasks. So if
// a task finishes, the rest will also finish.
// Note that it is NOT expected for the finished task's stopper to be called
// in this case.
func (gr *GroupRunner) Run(ctx context.Context) []*Result {
// Set the flag inside the runningMutex to ensure we don't read the old value
// in the `Add` method and add a new runner when this method is being executed
// Note that if multiple `Run` or `RunAsync` happens, the underlying runners
// will panic
gr.runningMutex.Lock()
gr.isRunning = true
gr.runningMutex.Unlock()

results := make(map[string]*Result)

ch := make(chan *Result, gr.runnersCount) // no need to block writing results
gr.runners.Range(func(_, value any) bool {
r := value.(*Runner)
r.RunAsync(ch)
return true
})

// wait for a result or for the context to be done
select {
case result := <-ch:
results[result.RunnerID] = result
case <-ctx.Done():
// Do nothing
}

// interrupt the rest of the runners
gr.runners.Range(func(_, value any) bool {
r := value.(*Runner)
if _, ok := results[r.ID]; !ok {
select {
case <-r.Finished():
// No data should be sent through the channel, so we'd be
// here only if the channel is closed. This means the task
// has finished and we don't need to interrupt. We do
// nothing in this case
default:
r.Interrupt()
}
}
return true
})

// Having notified that the context has been finished, we still need to
// wait for the rest of the results
for i := len(results); i < gr.runnersCount; i++ {
result := <-ch
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
result := <-ch
select {
case result := <-ch:
results[result.RunnerID] = result
case time.Tick(time.Minute):
log(...)
os.Exit(1)

something like this

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmh. I don't think this is enough. A GroupRunner can be created with any Runner. There is no guarantee this is a InterruptedTimeoutRunner. If I just call this with a broken custom Runner this will hang forever. We need the timeout here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's a matter of deciding who's responsible of ensuring the program won't hang forever.

My assumption is that the responsible is the one using the package, because he knows the task and how to stop the task, so there shouldn't be a reason for him to provide a faulty task (otherwise, it's a bug that he needs to fix). The InterruptedTimeoutRunner can help, knowing its limitations, to ensure we don't block the thread, but it's the developer's choice to use it or not.
Basically, if the task hangs, it's your fault (whoever is using the package). Code comments should be clear in this regard (if it isn't clear enough, we should add more info about it).

If we're going to be responsible, there are a couple of important things to notice:

  • We can't ensure that the resources used by the task will be ever freed even if we return an error result. This needs to be clarified because it's something we CAN'T guarantee.
    Note that, before, it was your responsibility to ensure this doesn't happen, but now it's ours, and we can't ensure it.
  • We'll add more complexity to the runners. The code is kind of delicate because we need to ensure it's thread-safe, so I'd rather move the complexity out of the way if possible. Adding more code also increases the probability of more bugs.

Copy link
Collaborator

@kobergj kobergj Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

asically, if the task hangs, it's your fault (whoever is using the package). Code comments should be clear in this regard (if it isn't clear enough, we should add more info about it).

I strongly disagree. If the task is broken for some reason the programm MUST still exit. It cannot hang forever saying "this is your fault, I don't care". Since this is supposed to be the supervisor of all tasks it MUST make sure its tasks finish after a certain amount of time.

We can't ensure that the resources used by the task will be ever freed even if we return an error result.

Why not? If we exit within the grouprunner, all resources of our spawned go routines should be freed.

We'll add more complexity to the runners.

I tend to disagree again. We could remove the complete InterruptedTimeoutRunner and replace it with only one select statement. This would reduce complexity in my opinion

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jvillafanez this comment is still open? Could you add the timeout here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The runner has a guaranteed exit with the timeout, so we'll eventually get a result. A deadlock isn't possible.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Does it really need to be that complicated? We now need another channel and another go-routine to make sure a result is delivered. We could omit all that with just one single line here:

case <-time.After(r.interruptDur):

Wouldn't this be much simpler?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

runner's Run and RunAsync method as well as group runner's RunAsync method should behave the same way (returning a result after the timeout period has been reached). Just checking for the timeout there would mean that the timeout behavior would be exclusive for that method.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking for the timeout there would mean that the timeout behavior would be exclusive for that method.

But that is exactly what it is. Only the GroupRunner cares about the timeout because it needs to govern several Runners. One Runner started alone doesn't necessarily need a timeout. It could deadlock forever if its creator wants it so. But the GroupRunner needs to make sure it finishes in a reasonable amount of time.

results[result.RunnerID] = result
}

close(ch)

values := make([]*Result, 0, gr.runnersCount)
for _, val := range results {
values = append(values, val)
}
return values
}

// RunAsync will execute the tasks in the group asynchronously.
// The result of each task will be placed in the provided channel as soon
// as it's available.
// Note that this method will finish as soon as all the tasks are running.
func (gr *GroupRunner) RunAsync(ch chan<- *Result) {
// Set the flag inside the runningMutex to ensure we don't read the old value
// in the `Add` method and add a new runner when this method is being executed
// Note that if multiple `Run` or `RunAsync` happens, the underlying runners
// will panic
gr.runningMutex.Lock()
gr.isRunning = true
gr.runningMutex.Unlock()

// we need a secondary channel to receive the first result so we can
// interrupt the rest of the tasks
interCh := make(chan *Result, gr.runnersCount)
gr.runners.Range(func(_, value any) bool {
r := value.(*Runner)
r.RunAsync(interCh)
return true
})

go func() {
result := <-interCh
gr.Interrupt()

ch <- result
for i := 1; i < gr.runnersCount; i++ {
result = <-interCh
ch <- result
}
}()
}

// Interrupt will execute the stopper function of ALL the tasks, which should
// notify the tasks in order for them to finish.
// The stoppers will be called immediately but sequentially. This means that
// the second stopper won't be called until the first one has returned. This
// usually isn't a problem because the service `Stop`'s methods either don't
// take a long time to return, or they run asynchronously in another goroutine.
//
// As said, this will affect ALL the tasks in the group. It isn't possible to
// try to stop just one task.
// If a task has finished, the corresponding stopper won't be called
func (gr *GroupRunner) Interrupt() {
gr.runners.Range(func(_, value any) bool {
r := value.(*Runner)
select {
case <-r.Finished():
default:
r.Interrupt()
}
return true
})
}
Loading