Closed artem-webdev closed 3 years ago
I think we are having a communication problem here. I have repeated many times that the connection that you lost the pointer to is still valid! There is no way you will be able to create a new connection with the same client ID. The server will reject the new one because it can contact and get a response from the "old" one.
Instead of doing all that you do above, why you don't simply store in the sync map the actual STAN (not NATS) connection the first time it gets created? The "key" would be the client ID. Then, the proxy.StanConn == nil
issue disappears because when you need access to the connection you will look it up from the sync map.
I don't know enough, obviously, of the actual application to see how easy that would be, but I believe that you should attack the issue at the root (losing reference to the pointer) instead of trying to patch it this way. As I said many times, with the way NATS Streaming client and server are designed, trying to create a new connection with same client ID while one is still valid will not work.
I probably agree with you. Thanks for the help !
I apologize for closing this question - https://github.com/nats-io/stan.go/issues/333
having understood a little in the code, I realized that the problem can be bypassed by reconnecting to nats Do you think it is safe? here is an example solution