Reconnect method will allow to automatically reconnect when the Raibbtmq server goes down.
This method is really tricky and it will imply a design decision: should we maintain the list of clients connected? to which exchanges and queues they were connected? or, should the client re-bind to exchanges and queues when everything goes again ok? The answer is not so easy... if the broker manager needs to re-create connections with exchanges and queues of the clients, implies to keep a list of clients, queues and exchanges. If we do this, our services will not be stateless!!! This will difficult a lot the horizontal scalability of AEON. What if we have three instances of the broker manager? What if requests goes to different instances? you could have created a first connection to one instance and lately you go to another that could not have you as a client.
There are ways of sharing these information through a shared data base, but it would add difficulties to implement and more points of fail. I wrote about that some time ago:
Dear all, last Friday I deployed AEON in our iCargo infraestructure. One of the AEON's modules is a socket.io gateway to push notifications to the clients. Everything was ok until I enabled 2 dynos (to machines). This raise two issues: * Sticky sessions, all the request of a client needs to go the same dynos during the session. Not supported by heroku: https://github.com/Automattic/engine.io/issues/261 * The two independent socket server doest not each other. So, different clients connected to the same room in different dynos will not be notified correctly. There are solutions for that, which is clustering socket.io servers: http://socket.io/docs/using-multiple-nodes/# http://stackoverflow.com/questions/27662575/errors-going-to-2-dynos-on-heroku-with-socket-io-socket-io-redis-rediscloud Well, I dont know if you have experience with that, but at least I share with you these interesting articles about horizontal scaling with Socket.io
Maybe clients needs to do reconnection. Of course I dont mean final users, the sdk-eventsmanager would be in charge of that. The protocol between aeon clients and aeon server could have more logic, but maybe simplify the thing:
1 client subscribe to the events manager 2 events manager create the subscription 3 rabbitmq server goes down 4 events manager notify client 5 client is aware 6 events manage notify everything goes ok 7 goto 1