Thanks for this great suggestion. The answers are the same, so it looks like my
original premise is incorrect, and there are no issues with javax.crypto
classes running in JDK22 on virtual threads.
The remaining possibility is that the AWS client JAR, which is a thin layer
atop a REST API
Can you try recording the challenge and the answer in each round and then
recalculate them in a plain single thread standalone program to verify if the
answers are still the same? (Hopefully this calculation is deterministic).
--Weijun
> On May 2, 2024, at 4:18 PM, Chris Marshall wrote:
>
>
Hi Alan,
The code is completely unchanged between JDK21 and JDK22; it is using virtual
threads and StructuredTaskScope in both cases (and also, via a different path,
platform threads in both cases).
I should perhaps have given a bit more background about why I think that the
crypto classes
On 02/05/2024 19:33, Chris Marshall wrote:
:
Last week I upgraded the application to be compiled by JDK22, and run
on JDK22. Immediately, we started to see failures from within the
User-SRP auth code /only when it was run on a virtual thread from
within a StructuredTaskScope./ The failures
Hi,
I work for an organisation which runs a number of applications inside an EKS
cluster hosted in AWS. In order for the applications to communicate, they
obtained bearer tokens from the AWS Cognito library, and in order to obtain the
tokens, we have coded up User-SRP auth. This code has been