On Thu, 7 Jan 2021 20:29:35 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java line 50:
>>
>>> 48: }
>>> 49:
>>> 50: private static class SessionLeaker {
>>
>> The term "leak/leaker" is used extensively in the test, however, this is not
>> really a leak conceptually, but rather sessions w/ active states/operations
>> which are unusable and lead to unexpected PKCS#11 errors subsequently. Maybe
>> replace it with other terms like "corrupt/corruptor" or other similar terms
>> would be more suitable?
>
> I chose the term 'leak' in the sense of a resource not properly cleaned up.
> In this case, the 'leak' would not cause a memory/sockets/file-descriptors
> but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is
> that something (a Session) unexpectedly (with an active operation) passes
> from one side (a P11Cipher instance) to another (the Session Manager). I
> don't believe 'corruptor' describes the concept better than 'leaker'. The
> Session is not corrupt, it can be used for for a specific purpose (the same
> operation that previously failed). Any other suggestion? Hmm... I cannot
> think of something better.
So, after this PKCS11 session failed with an error, you can continue using it,
say give it another byte[] and it would continue to work as if the earlier
failed call never happened? I have not really tried it and thought that this
session is unusable due to the combination of an existing error (say some
exception happened during the encrypt update call) and active operation state.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1901
