[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #10 from Yilong Li --- (In reply to Mark Thomas from comment #9) > I'm trying to reproduce these results. Could you share how you configured > the tests to run with RV-Predict. The general

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #11 from Yilong Li --- (In reply to Yilong Li from comment #10) > (In reply to Mark Thomas from comment #9) > > I'm trying to reproduce these results. Could you share how you configured > > the

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #9 from Mark Thomas --- I'm trying to reproduce these results. Could you share how you configured the tests to run with RV-Predict. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #8 from Remy Maucherat --- Yes, I think that's too many questions for BZ. NIO2 does not allow concurrency, and in addition to the SSL engine, concurrency would also corrupt all the buffers used. The socket wrapper

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #4 from Mark Thomas --- Given bug 57799 which suggests that there might be a concurrency issue with NIO2 and TLS it might be worth taking a closer look at the stack traces in this report to see if they offer any

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #3 from Remy Maucherat --- No idea, it sounds too specific to the NIO2 behavior. Sure the completion handler is going to be called directly by the main thread pool, but only once per IO operation, and since a read

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #5 from Remy Maucherat --- Yes, but I don't see how a concurrent read is possible, and this is a "non blocking" read, that other bug is supposed to be using blocking IO. -- You are receiving this mail because:

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #7 from Yilong Li --- (In reply to Remy Maucherat from comment #3) > No idea, it sounds too specific to the NIO2 behavior. Sure the completion > handler is going to be called directly by the main

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #6 from Yilong Li --- (In reply to Remy Maucherat from comment #3) > No idea, it sounds too specific to the NIO2 behavior. Sure the completion > handler is going to be called directly by the main

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 Remy Maucherat changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 58321] Using non-thread-safe javax.net.ssl.SSLEngine inside org.apache.tomcat.util.net.SecureNio2Channel without synchronization

https://bz.apache.org/bugzilla/show_bug.cgi?id=58321 --- Comment #2 from Yilong Li --- (In reply to Remy Maucherat from comment #1) > This looks invalid as the IO operations are protected by pending flags > and/or semaphores. I get it your tool seems to use