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'd previously reported a bug in daemons() when using the dispatcher. I initially thought it was a problem elsewhere, so the first report was moved to a discussion topic after some back and forth without being addressed. A second attempt was fixed in a subsequent release and has been working. I've now discovered a similar bug in the newer experimental "thread" dispatcher option. In my local experiments, it doesn't always manifest (e..g., if the daemon count is only 1 or 2), but the example below should readily summon the defect when using a daemon count of 5 or greater.
Once again, I'm not at liberty to show what I'm really doing, so I've made a rather silly and chatty reprex for you using the lgr package from Stefan Fleck. This code provisions a few daemons, loads the lgr package on them with everywhere(), and then configures the root logger on them using everywhere(). The code continues from there using mirai's future-promise approach to produce log events using the deamon logger reference that was captured during the logger's configuration (all local to each daemon). I force the resolution of all those mirai objects and then inspect the full set of them looking for any that could/did not complete. The daemons are then torn down. This full process will cycle repeatedly. The example should reproduce the issue almost immediately and, through inspection, you can see that some daemons don't have that logger reference and thus throw errors.
# reprex for thread dispatcher issue
library(mirai)
cnt <- 1L
while (TRUE) {
mirai::daemons(n = 5, dispatcher = "thread")
mirai::everywhere(library(lgr))
mirai::everywhere(.expr = {lg <<- lgr::basic_config(threshold = "all", console = "info")})
m.vec <- unlist(lapply(1:1000, FUN = function(i) {
m <- mirai::mirai(lg$info("log blather... <sigh>"))
resolved.mirai <- call_mirai_(m)
return(resolved.mirai$data)
}))
not.really.resolved.mirai.cnt <- sum(grepl(pattern = "Error*", m.vec))
if (not.really.resolved.mirai.cnt > 0) {
message("I'm not reproducible on run #", cnt, " because "
, not.really.resolved.mirai.cnt
, " time(s) out of 1000 I was not really ready :'-(")
}
daemons(0)
cnt <- cnt + 1L
}
Some real sample output:
I'm not reproducible on run #4 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #7 because 599 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #11 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #14 because 200 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #22 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #28 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #33 because 403 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #38 because 200 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #43 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #46 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #48 because 201 time(s) out of 1000 I was not really ready :'-(
I'm not reproducible on run #54 because 400 time(s) out of 1000 I was not really ready :'-(
So, you can see some pattern here which unsurprisingly behaves as a function of the daemon count. I share the output in case it's useful/helpful. You can also add a browser() in the reprex to see that missing logger reference across the mirai objects if you want. This was produced on Windows 10 under R4.4.1 with mirai 1.3.0 and nanonext 1.3.0.9000. Thank you
The text was updated successfully, but these errors were encountered:
I'd previously reported a bug in
daemons()
when using the dispatcher. I initially thought it was a problem elsewhere, so the first report was moved to a discussion topic after some back and forth without being addressed. A second attempt was fixed in a subsequent release and has been working. I've now discovered a similar bug in the newer experimental"thread"
dispatcher option. In my local experiments, it doesn't always manifest (e..g., if the daemon count is only 1 or 2), but the example below should readily summon the defect when using a daemon count of 5 or greater.Once again, I'm not at liberty to show what I'm really doing, so I've made a rather silly and chatty reprex for you using the lgr package from Stefan Fleck. This code provisions a few daemons, loads the lgr package on them with
everywhere()
, and then configures the root logger on them usingeverywhere()
. The code continues from there using mirai's future-promise approach to produce log events using the deamon logger reference that was captured during the logger's configuration (all local to each daemon). I force the resolution of all those mirai objects and then inspect the full set of them looking for any that could/did not complete. The daemons are then torn down. This full process will cycle repeatedly. The example should reproduce the issue almost immediately and, through inspection, you can see that some daemons don't have that logger reference and thus throw errors.Some real sample output:
So, you can see some pattern here which unsurprisingly behaves as a function of the daemon count. I share the output in case it's useful/helpful. You can also add a
browser()
in the reprex to see that missing logger reference across the mirai objects if you want. This was produced on Windows 10 under R4.4.1 with mirai 1.3.0 and nanonext 1.3.0.9000. Thank youThe text was updated successfully, but these errors were encountered: