Open javarias opened 10 years ago
atejeda
commented
10 years ago This is ticket was labeled as enhancement, but the true meaning of this is to research alternatives for the notification service in terms of efficiency, implementation/integration, debugging and QoS, is abenchmark/profiling of several possible alternatives rather than a scheduled replacement.
acaproni
commented
9 years ago Jorge could you explain your sentence "ACS need a replacement for its notification service, which is based on CORBA Notification Service."?
javarias
commented
9 years ago Currently ACS relies on a CORBA Notification Service implementation (TAO Notify_Service) for its messaging system (a distributed and decoupled implementation of the Publish-subscribe architectural pattern), which is part of CORBA 2.x standard. It is known that this standard is not widely used in the industry. At this moment there are other alternatives (i.e. JMS, DDS, AMQP, etc) that may offer better support and tools to monitor what is going on inside the messaging broker software.
We, as acs community, we should look forward and find a better message broker. Better could means either better throughput, less network overhead, better management and/or monitoring, more reliable or better support from the open-source community. However the current ACS Notification Channel API must be kept, to allow to do a seamless transition to the new messaging broker.
There is a prototype done by me in the past, available here: Jorge Avarias' undergraduate thesis at UTFSM In that work I have created a similar API for the ACS Notification Channel based on DDS (OpenDDS implementation). There some validation and verification for a couple of scenarios where the ACS notification channel is used. This could be used as basis to evaluate a replacement.
javarias
commented
9 years ago I updated this ticket description using my latest comment
eschmid
commented
9 years ago Hi Jorge. Thanks for the additional information. You are of course right that the CORBA Notification Service (or CORBA itself for that matter) are no longer as prominent as technology of choice today as they were over a decade ago when ALMA decided to use them. But with most teething problems being sorted out now, they nevertheless provide a solid basis for the ALMA software system. We currently have a mere two bug tickets of low and medium priority open for the ACS notify service. No new issues have been reported for over four months now.
This should of course not discourage you - or anybody else - investigating in newer and better technologies for the future, but it must be clear that at least the ALMA software is not in any desperate need to deploy such a solution in the near future. The risks to destabilise the entire software system and hence the massive amount of testing required simply outweigh the benefits - at least in my humble opinion. I think that recent experiences with the inevitable move to DDS for the bulk data, which is much more isolated, confirm this conservative approach.
Last but not least, maybe it's better to call this "ACS should offer additional choices for the message broker" rather than a "replacement", which means one or the other.
moraklein
commented
9 years ago I would like to note that the fact that ALMA has decided not to move away from TAO NS is by no means due to lack of issues with the current implementation. Please refer to the sections dedicated to Notify Service (2.2, 3.1) in a paper on scalability issues we published a couple of years ago. As noted by Jorge, there is a lack of diagnostic and insight of the service, which has made the detection of issues unnecessarily difficult and tedious.
Note also that the relative stabilization of the situation at ALMA has required a significant effort over years (not only by the ACS development team), and impact on science commissioning and observation time. It is not clear to me that an early replacement of the service would have outweighed the effort that has actually been put into dealing with the weaknesses of TAO NS. This should be a real concern for other ACS users on large scale systems.
Finally, here are a couple more relevant references on service alternatives from the 2009 ICALEPCS conference:
Currently ACS relies on a CORBA Notification Service implementation (TAO Notify_Service) for its messaging system (a distributed and decoupled implementation of the Publish-subscribe architectural pattern), which is part of CORBA 2.x standard. It is known that this standard is not widely used in the industry. At this moment there are other alternatives (i.e. JMS, DDS, AMQP, etc) that may offer better support and tools to monitor what is going on inside the messaging broker software.
We, as acs community, we should look forward and find a better message broker. Better could means either better throughput, less network overhead, better management and/or monitoring, more reliable or better support from the open-source community. However the current ACS Notification Channel API must be kept, to allow to do a seamless transition to the new messaging broker.
There is a prototype done by me in the past, available here: Jorge Avarias' undergraduate thesis at UTFSM In that work I have created a similar API for the ACS Notification Channel based on DDS (OpenDDS implementation). There some validation and verification for a couple of scenarios where the ACS notification channel is used, was done. This could be used as basis to evaluate a replacement.