| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: ICALEPCS and EPICS iocCore V4 |
| From: | Steve Lewis <[email protected]> |
| To: | <[email protected]> |
| Date: | Mon, 17 Oct 2005 12:59:20 -0700 |
At 1:23 PM -0600 2005/10/17, Jeff Hill wrote:
Proper uniform definition of connection responsiveness notification interfaces is also a very important issue that is often overlooked in a first cut CORBA based approach. In any case that was what the reviewers commented about initial efforts at NIF.
I was one of those early reviewers. Although we did not see the full negative implications and coupling of the wide, early-binding interfaces, we did notice the fundamentally synchronous nature of the CORBA in use (again, the available vendors did not support the event system and some other CORBA features).
Much was done (by the vendors and the NIF developers) to mitigate this, but when either a tier-1 or tier-2 program dies, often it is not possible to smoothly re-insert it into the mesh of still running programs in all 3 tiers. There are also messages queued up deep in the (opaque) CORBA and TCP/IP layers that "assault" a newly restarted IOC and can cause it to fail again. Often the only recourse is to tear down a substantial block of tier-1, -2, and -3 programs and restart them in a benign order.
A non-solution is the practice of storing the dynamic connection information (CORBA references) back in the RDB: after a really nasty crash, the RDB has to be (manually) scrubbed, since no starting order works. This might have implications for a central nameserver in a 3-tier EPICS system--unless you think there will be no "nasty crashes" ever :-)