[JENKINS-25218] - Hardening of FifoBuffer operation logic #100
Conversation
…ince we use non-atomic int
…ith the FifoBuffer#receive() loop
…s waiting on the lock
| if (closed) | ||
| throw new IOException("closed during write operation"); | ||
|
|
||
| if (closeRequested) { |
There was a problem hiding this comment.
I'm still not comfortable about not having timeout if the buffer is full && does not get freed by other threads
|
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
|
🐝 without much comprehension. I will assume this has gotten some interactive testing at least? |
|
From the description, it sounds like there ought to be a way to write a test demonstrating a fix of the known bug condition. |
|
It's being soaked for ~4 days now. Seems to be stable on frequent data interactions. Regarding tests, I can likely reproduce b6e71fa, but it's pretty obvious. Other changes are related to some parallel code fun, so I do not see a way to reproduce them in tests without PowerMock bytecode magic. Since it's just hardening, maybe we do not want to have it in the stable branch (excepting NPE fix) |
|
I decided to merge this PR towards the 3.0 branch, which will have some stabilization interval in weekly releases |
|
🐝 AIUI |
|
I will merge it into 3.2 since we need a |
|
The PR has been soak tested enough. 2.62.4 is unlikely going into Jenkins LTS, so I will just merge it |
The most of JENKINS-25218 has been handled in 3ea38c8 by @andresrc. But there are still potential issues in the FifoBuffer behavior.
Changes:
close()calls previouslyClosedChannelExceptionfrom the underlying channel@reviewbybees