Use larger static buffer for key send and send in chunks. #27
Conversation
That fixes a bug when using large chunks would lock the
worker indefinitely, e.g.
```
y = foreach(x=runif(100000),.combine = c,.options.redis=list(chunkSize=10000)) %dopar% {x}
```
was locking before (RHEL 6.5, R 3.2.0), and now it does not.
The reason for the lock was because the key was constructed as concatenation
of task indices, and truncated by nsprintf.
This might also solve issue bwlewis#11.
|
This is a great catch, thanks! Longer term, this has got me thinking that the way we encode the tasks is bad, I think a new approach is warranted, maybe a lookup table or something. Thanks again, for this. |
Use larger static buffer for key send and send in chunks.
|
Yes, it was my thought too, but that encoding was assumed in quite a few places throughout both master and worker R code, and I did not want to upset things too much. The C code would need some more checking for various error conditions, in my opinion. Maybe you could use some library like 0MQ that takes care of robustness? Thanks for the great package with some unique design features! I really like the ability of having dynamic membership of the worker pool - it is so easy to feed the workers through some array job on the cluster. And using a message broker makes deployment very flexible. For example, I can run the master on my laptop in RStudio, and have the heavy lifting done in foreach loop on the Linux cluster. |
Andrey Tovchigrechko pointed out in #27 that the fault tolerance task encoding is bad. This commit improves that.
That fixes a bug when using large chunks would lock the
worker indefinitely, e.g.
was locking before (RHEL 6.5, R 3.2.0), and now it does not.
The reason for the lock was because the key was constructed as concatenation
of task indices, and truncated by nsprintf.
This might also solve issue #11.