this post states that UM connections should be kept open for as long as possible. I have a couple of questions about this.
Just to clarify: when I say “connection” I mean an instance of the Java class com.pcbsys.nirvana.client.nSession.
Do we get a notification (a callback called) when a connection is closed? Why can a connection get closed? I need this in order to know when to open a fresh new connection. Or should I just call session.isConnected() before every use, and, if this returns false, open a new one? What happens with the old one? Wouldn’t I get a resource leak here?
Is a connection multithread-safe? I.e. can one open connection be simultaneously used by multiple users in multiple threads? Or should every user get its own instance (and then “release” it after it’s done)?
Yes a nSession is a Connection, the reason to keep them long lived is SSL, Auth etc
There is a class called com.pcbsys.nirvana.client.nReconnectHandler that you register against the nSession either when using nSessionFactory or directly on the nSession#addReconnectHandler. You can use this to know the state of the session. nSession will automatically reconnect when disconnected by default. If you do not close the session explicitly you will have resource leaks.
You can also use the session.isConnected API as a more naive approach.
nSession is entirely multi-thread safe, one nSession can serve many threads, at some point contention will hit and multiple sessions may help however that would be session pooling and further down the track from inital desing, a very simple consumer pattern could be a single reader pushing to a queue whether the worker thread pool will consume events at will.
Hrm… Your explanation (thanks!) still leaves a question open. If a session disconnects and reconnects asynchronously (so that a ReconnectHandler is needed) how can a client that needs a connection (which also happens asynchronously, e.g. when an external request is received) that the connection is ready to use “now”? It might happen that an external request arrives just in the moment that the session is disconnected (and is about to reconnect). And what should I do then?
This is where the deployment becomes important as distributed systems must compensate for theses issues, one approach is to never allow a session to reconnect, once its disconnected, close it and create a new session(you will need some sort of blocking approach to ensure that many sessions are not created, or that no more than the pool allows)
The other is to wait until it reconnects blocking the thread, however there is a chance this does not happen for a long period of time, even with a new session as network outages do occur regularly.
You can also queue the messages depending on the system requirements.
Thank you @Joshua_Buckton! I assumed this would sound like this . As of now, I’m pursuing the usage via JMS (with the help of Spring) where I get notified when a message arrives. Thus I won’t have to cope with disconnecting problems.
I still do not understand fully how it will work, but I hope that UM and Spring do magics together .
. As of now, I’m pursuing the usage via JMS (with the help of Spring) where I get notified when a message arrives. Thus I won’t have to cope with disconnecting problems.