Scott Fauerbach

@mullerch .NET is my second client, java being the first. I figured it out by doing some debugging, it looked like the connect string was sent just fine. But then...

I'm not quite sure why this behavior is required, but if you trace down the file version it also ends up calling `Nkeys.FromSeed(seed);` each time.

@ColinSullivan1 I have reviewed java and java does clear. There are 3 library handlers. FileAuthHandler, StringAuthHandler and MemoryAuthHandler. Memory uses String. Both the File and String do this, which is...

The original problem was that the user was providing the sign function instead of using the code in the client. The java client does do it as part of the...

See V2 client

@igor-komar @michelwilson This issue has been fixed in PR https://github.com/nats-io/nats.java/pull/820 and released in 2.16.6 Thanks to @MauriceVanVeen The core issues was the lazy nature of the message size calculation was...

@prasannak-ra Based on this note: > **These are the steps to solve GraalVM issues:** > * Refactor the static dependency of `SecureRandom` to non static (its nasty but possible) >...

@prasannak-ra @turing85 This article may be relevant: https://oss.oracle.com/pipermail/graalvm-dev/2020-April/000049.html Also, do any of these options help? https://www.graalvm.org/latest/reference-manual/native-image/overview/Options/

There is a feature in progress that will allow you to retry on the initial connect. Currently any failure on initial connect does not try to retry. There should be...

Yeah, it will be changed to this, adding a bool flag to the signature (bool reconnectOnConnect = true) to the create connection, true means reconnect on connect. ``` Connection =...