Class loading may fail when JVM is stopped using SIGINT #38154
Comments
|
The |
|
Thanks for having a look, Phil. I think I might be confused looking at the code in the future if we omit the tracking so I'd prefer to keep it. I've pushed a commit that refines the fix as I think it was a mistake to reset the thread's interrupted flag and retry the read. Instead, we now just repair the file channel and re-throw the exception. This allows the interruption on the current thread to continue will also ensuring that the file channel is usable on other threads. I've tested it with @onobc's sample that brought the problem to my attention and it seems to work. |
|
Thanks for the quick turnaround @wilkinsona and @philwebb I will pickup the SNAPSHOT and verify it w/ Spring for Apache Pulsar. |
In spring-projectsgh-38154, we started handling ClosedByInterruptException. The FileChannel was repaired by recreating it and then the exception was rethrown. This allowed other threads to use the channel that had been read by an interrupted thread while allowing that interruption to continue. This approach has proven to be insufficient as there are scenarios where the read needs to succeed on the interrupted thread. This commit updates the handling of ClosedByInterruptException so that this is the case. The FileChannel is recreated as before but the thread's interrupted flag is now cleared before retrying the read. The flag is then reinstated so that any subsequent actions that should fail due to the interruption will do so. We could clear and reinstate the interrupted flag before the first read, rather than catching ClosedByInterruptException. This approach was rejected as it will have an impact on the performance of the happy path where the thread hasn't been interrupted.
In gh-38154, we started handling ClosedByInterruptException. The FileChannel was repaired by recreating it and then the exception was rethrown. This allowed other threads to use the channel that had been read by an interrupted thread while allowing that interruption to continue. This approach has proven to be insufficient as there are scenarios where the read needs to succeed on the interrupted thread. This commit updates the handling of ClosedByInterruptException so that this is the case. The FileChannel is recreated as before but the thread's interrupted flag is now cleared before retrying the read. The flag is then reinstated so that any subsequent actions that should fail due to the interruption will do so. We could clear and reinstate the interrupted flag before the first read, rather than catching ClosedByInterruptException. This approach was rejected as it will have an impact on the performance of the happy path where the thread hasn't been interrupted. Fixes gh-38611
When the JVM is stopped using SIGINT, Boot's shutdown hook runs and closes the application context. Class loading that occurs during this close processing may fail due to a thread being interrupted while calling
FileChannel.read(ByteBuffer, long). The interruption causes the read to close the channel and fail with aClosedByInterruptException. This leavesFileChannelDataBlockwith aFileChannelthat should be open according to its reference count but isn't.The text was updated successfully, but these errors were encountered: