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

WorkingPool unexpected behaviour when workers are on different node #1134

Open
akbashev opened this issue Jul 20, 2023 · 4 comments
Open

WorkingPool unexpected behaviour when workers are on different node #1134

akbashev opened this issue Jul 20, 2023 · 4 comments

Comments

@akbashev
Copy link
Contributor

Description
WorkingPool unexpected behaviour when workers are on different node

Steps to reproduce
https://github.com/akbashev/WorkerPoolTest

Two nodes:

  • Master
  • Worker
  1. Join nodes and wait to be up.
  2. Spawn master with working pool on Master node.
  3. Spawn workers on Worker node.

If you run an example and submit some work—WorkingPool will terminate all workers in selectWorker() function, seems like actor is none here:

if let worker = self.workers[selectedWorkerID]?.actor {

Expected behavior
Pool is routing job to workers, e.g. will log:

2023-07-20T07:36:38+0200 info worker : cluster/node=sact://[email protected]:1111 [WorkingPoolTest] Done check for /user/Worker-d

Environment
MacOS 14.0 Beta (23A5286i), Xcode 15.0 Beta 4 (15A5195m), Swift 5.9

@ktoso
Copy link
Member

ktoso commented Jul 20, 2023

Thanks for reporting, will look soon

@akbashev
Copy link
Contributor Author

btw think I've pushed a error in SPM in example before 🙈
fixed that, now should work

@akbashev
Copy link
Contributor Author

akbashev commented Aug 25, 2023

Ok, after a bit of testing and checking repo around, think this PR and particular WeakWhenLocal wrapper can fix this issue. Will double check.

Probably there should be a better way to fix :)

@akbashev
Copy link
Contributor Author

akbashev commented Nov 3, 2023

Actually looking back again into issue and thinking a bit more about, introduction of some type like WeakWhenLocal makes sense.

Making worker reference either just weak or just strong will both give you a problem:

  • Weak references of remote actors will just be cleaned up by local system as there are no other references to this actor.
  • Strong references of local actors will create unwanted reference between worker and worker pool and won't be cleaned up from memory.

So you (or system) need to know if it's local or remote reference for WorkerPool. And this PR is actually should fix it. 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants