Kombu filesystem transport not thread safe #398
Comments
|
I've been able to see this where the file length that is read (by a consumer) ends up being zero length; quite odd, even if I use the |
|
A few more examples with a test program that seems to cause this issue... http://paste.ubuntu.com/8184078/ https://github.com/harlowja/BrokenTest is the test program (at test.py) Pretty reliably get that error... |
|
Also the virtualenv that I am using: Babel==1.3 |
|
I ran the BrokenTest Josh posted above too, and saw similar errors. |
|
It probably isn't thread safe, and that would be low on my priorities to fix |
|
Understandable that its low priority, but seems at least justified to document that? |
|
Attached the version we use, which also avoids the copy of the msgs to tmp. Credit to https://github.com/benediktschmitt/py-filelock. |
|
Thanks! @mpenalver I also have this problem and will try your fix. Can you submit it as a PR? |
fix: celery#398 Currently only write lock used in msg/exchange file written. Cause reading in other thread got some incomplete result. 1. Add timeout for the lock acquire. 2. Add Share locks when reading message from filesystem. 3. Add a unit test for the `lock` and `unlock` 4. Add a unit test to test the lock during message processing.
fix: celery#398 Currently only write lock used in msg/exchange file written. Cause reading in other thread got some incomplete result. 1. Add timeout for the lock acquire. 2. Add Share locks when reading message from filesystem. 3. Add a unit test for the `lock` and `unlock` 4. Add a unit test to test the lock during message processing.
* Solve Kombu filesystem transport not thread safe fix: #398 Currently only write lock used in msg/exchange file written. Cause reading in other thread got some incomplete result. 1. Add timeout for the lock acquire. 2. Add Share locks when reading message from filesystem. 3. Add a unit test for the `lock` and `unlock` 4. Add a unit test to test the lock during message processing. * Replace deprecated function.
partly fix: celery#398 1. add exclusive lock during the whole exchange file update. 2. add some unit test for file lock
partly fix: celery#398 1. add exclusive lock during the whole exchange file update. 2. add some unit test for file lock
partly fix: celery#398 1. add exclusive lock during the whole exchange file update. 2. add some unit test for file lock
partly fix: #398 1. add exclusive lock during the whole exchange file update. 2. add some unit test for file lock
partly fix: celery#398 1. add exclusive lock during the whole exchange file update. 2. add some unit test for file lock
From looking it over it appears that this transport isn't thread safe.
I've hit errors like http://paste.openstack.org/show/102226/ a few times and am thinking these class of errors are due to files getting moved by more than one thread. Perhaps some basic locking is in order?
The text was updated successfully, but these errors were encountered: