Fix race condition leading to duplicate tailing#181
Fix race condition leading to duplicate tailing#181snorecone merged 6 commits intopapertrail:masterfrom
Conversation
|
Hi @Bowbaq, great catch. About the test that is hijacking logs, would you consider instead making the |
|
@snorecone converted the tests. The build was still failing due to a race condition, but it's a different one. This one is because this read is not protected and the value can be written to concurrently. The last commit should fix |
|
@Bowbaq thanks, this is great. Sorry about the race in the test, I'll probably want to revisit the shutdown code later so that mutexes aren't used for every write. |
|
re: mutex I haven't benched it but my guess is, in the absence of contention, acquiring a read lock should be very cheap |
|
Yeah, I agree. No need to dig into it unless there's a benchmark. |
|
Do you know when the next release will be? We're being billed up double for our logs until we deploy this |
|
Sweet, thanks |
Expected
If a file is matched by two (or more) globs,
remote_syslog2matches the first glob in the list, and ignores subsequent matchesActual
Sometimes, due to a race condition, a log file ends up being tailed twice. I encountered this today, we're using 0.18. Here's a trace. Notice that the some files are forwarded twice (line 7 and 29 for example).
Fix
Adding the file to the registry synchronously seems to fix the problem. I've added a test (not necessarily a fan of hijacking the logs but ...). Running that test on the current
masterfails most of the time.