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
Perhaps worth noting, though, that the Swim port (9001 in the below example) does get released, so some sort of cleanup seems to be happening.
Swim does have a shutdownhook so it is probable that the bug is in there.
Small (hopefully minimal) example:
// WastefulAgent.javapackagenstream.starter;
importswim.kernel.Kernel;
importswim.server.ServerLoader;
publicclassWastefulAgentextendsAbstractAgent {
@OverridepublicvoiddidStart() {
System.out.println(nodeUri() + ": didStart");
while (true) {
// You may wish to throttle this a bitSystem.out.println(nodeUri() + ": ping");
}
}
publicstaticvoidmain(String[] args) {
finalKernelkernel = ServerLoader.loadServer();
kernel.start();
System.out.println("Running Main ...");
kernel.run();
}
}
Running the main method results in an unstoppable process (outside of a kill -9 command).
This happens whether the running method is an IDE, Gradle, or a plain old Java command.
(Note that when running with Gradle, ctrl+C will seem to work, but the process is still visible w/ ps or top.)
Variations
asyncStage()
It's especially disturbing that moving the infinite loop to a proper asyncStage() call does not fix anything:
packagenstream.starter;
importswim.api.agent.AbstractAgent;
importswim.concurrent.AbstractTask;
publicclassWastefulAgentextendsAbstractAgent {
@OverridepublicvoiddidStart() {
System.out.println(nodeUri() + ": didStart");
asyncStage().task(newAbstractTask() {
@OverridepublicvoidrunTask() {
while (true) {
// You may wish to throttle this a bitSystem.out.println(nodeUri() + ": ping");
}
}
@OverridepublicbooleantaskWillBlock() {
returntrue;
}
})
.cue();
}
}
The text was updated successfully, but these errors were encountered:
swim.concurrent.Theater appears to contain the root cause of this problem. Theater#stop will hang if a currently-executing Task within it never completes.
All this does is "while the pool hasn't shut down, blocking-check for up to 100ms if it hasn't shut down." A long-running task within the threadpool will forever make the check return false.
Perhaps the right logic is, "while the pool hasn't shut down, give each incomplete task within it up to X milliseconds to shut down". Or even, "while the pool hasn't shut down, force-shut-it-down." These may cause issues with persistence, though, and some tasks are surely "more important" than others (the Swim Clock escapes this already, we may need to add others if we go down this approach).
Note that it does not seem to be possible to cancel() a currently-runningTask via its TaskRef (the invocation only returns true if the task is cueed; if the task is running, it is not cueed (ignoring "re-cues" of course, which are not pertinent to this discussion)). So even if were to get handles on specific tasks somehow within the stop() method for task disambiguation purposes (currently seems rather difficult), this doesn't make individual-task cancellation much easier.
Also note that the following code does NOT cause such the "non-terminable" situation; it does infinite loop, but it stops fine with ctrl+C. This is probably because SIGINT is used to "escape" the await; the problem in Swim is that SIGINT (eventually) triggers the above await logic.
Perhaps worth noting, though, that the Swim port (9001 in the below example) does get released, so some sort of cleanup seems to be happening.
Swim does have a shutdownhook so it is probable that the bug is in there.
Small (hopefully minimal) example:
Running the main method results in an unstoppable process (outside of a
kill -9
command).This happens whether the running method is an IDE, Gradle, or a plain old Java command.
(Note that when running with Gradle, ctrl+C will seem to work, but the process is still visible w/
ps
ortop
.)Variations
asyncStage()
It's especially disturbing that moving the infinite loop to a proper
asyncStage()
call does not fix anything:The text was updated successfully, but these errors were encountered: