FW: Soops has release Opentalk-Reliable-Communication-Layer to the cincom public repository

Hi all,

For the last year or so I have been working at Soops in Amsterdam. www.soops.nl . One of the first tasks I did was to implement a more reliable communications layer for open talk that would automatically recover from network outages etc. With the fine team here we have really stress tested this and it is in production with their energy trading system. I got permission to put it in the public repository and share it with everyone under the MIT license.

So if you ever wanted to get rid of all those exception handlers and headaches with remote open talk sends etc, give the Opentalk-Reliable-Communication-Layer a try. It will make life a lot simpler for you out of the box and works for 7.6 7.7 and the current 7.8 development track. It also works in the 7.4 and 7.5 images as well although I do not guarantee future changes will work in these unless I have time and money to do so ( J ) I intend to add features to this etc and also make it better and am open to suggestions and feature requests etc. We encourage folks to give it a try.

 The package comments have some code an examples to get you started.

It has features like specifying if you want message order maintained for an object (default) or you can specify which selectors can get sent in any order etc.

If there is a communication break the system can recover from where it left off including getting any replies that you missed etc. It will maintain integrity among threads communicating to a remote object.

With the recovery application you can extend it to do things like failover rather easily without the calling thread being the wise to the fact that you have sent the request elsewhere for a response etc. the Recovery application also provides the developer with staus of the remote process etc. so you can see if you are deadlock rather than a communication problem etc. you can test and ping the remote broker etc.

It is pluggable so you can put in you own recovery application if there is a sever failure in the system and the application developer now has a lot more options for dealing with communication failures. You have the ability to skip messages and proceed or kill the particular thread on both client and server.

I encourage folks to give it a try and any questions or problems or request you can post to list and cc me J

Kind Regards,

Sean Glazier

Soops.nl

 freelance small talker