Stephen Asbury

sounds like some options: * clients should check before hand, this has 0 performance consequences * server can check if there are > 2 elements on subscribe, which only catches...

I added https://github.com/nats-io/nats.java/issues/243 to the java client. I am worried about fixing before a major update because this will add an exception where there wasn't one before. If someone happens...

While the go client is considered the gold standard - i don't see how this is logically wrong :-) If flush uses a ping, shouldn't flushes be limited the same...

thanks felix, i have to do some maintenance on the library next week and will look at adding this.

ugh, forgot to look for 2.6.6, i will try to get this in my brain next time

I don't have plans for that. I think there is some talk of doing an API revisit for all the clients, so perhaps during that. Perhaps Richard has some insight.

could be that we are too agressive closing the stan connection or at least "forgetting" about it somehow so we try to recreate when we shouldn't

set the connectionlost handler and only try to reconnect when you get notification from that cb, not the low level NATS disconnect handler

another option maybe to provide a way to update the config without a full sighup stop/start cycle

The code has chance significantly apparently, how would you like to proceed on this change?