--- Comment #16 from Remy Maucherat <> ---
I added a follow up:

As this didn't happen with the regular JSSE engine, I think the missing
underflow status is the root cause (the unwrap loops in SecureNio(2)Channel
will clearly misbehave if all input has just been consumed and no output has
been produced while the returned status remains OK; they will then return 0
rather that do a network read). I have no idea why it seemingly didn't happen
with NIO. It should also affect the non blocking/async read calls but obviously
the blocking read issue is more common and noticeable.

If the fix is correct then the NIO2 blocking read loop added in should not be needed.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to