RE: Very slow reconnection to medm after IOC reboot

["Jeff Hill" <johill@lanl.gov>]

> Unfortunately on Windows this is not possible; installing a new version of
> a .DLL or .EXE is not permitted by the OS until all programs using it have
> quit, thus one has to stop the IOC before the rebuild can be started.

On any contemporary windows system it takes less than 30 seconds to rebuild
the IOC - so this would work also?

O stop IOC
O rebuild IOC
O start IOC

I don't doubt that optimizations can be installed, but my perspective is
that this should not impact the stability of R3.14.

> -----Original Message-----
> From: Andrew Johnson [mailto:anj@aps.anl.gov]
> Sent: Monday, January 26, 2009 8:57 AM
> To: Jeff Hill
> Cc: 'Mark Rivers'; 'epics'
> Subject: Re: Very slow reconnection to medm after IOC reboot
> 
> On Friday 23 January 2009 16:40:22 Jeff Hill wrote:
> > But perhaps this would work just as well (with very fast reconnect
times)
> >
> > O rebuild the application
> > O reboot the IOC
> 
> Unfortunately on Windows this is not possible; installing a new version of
> a .DLL or .EXE is not permitted by the OS until all programs using it have
> quit, thus one has to stop the IOC before the rebuild can be started.
> 
> > Nevertheless, if by chance one ends up with the first scenario,
> restarting
> > the MEDM screen isn't, from my perspective, exactly heavy lifting -
> > considering that we are presumably waiting at the edge of the seat for
> the
> > channel's to reconnect. Synchronization might be the primary
aggravation,
> > but perhaps it will even be successful the first try if one waits
> > approximately long enough for the IOC to finish rebooting before
> restarting
> > the medm screen.
> 
> For the moment that does appear to be Mark's only alternative to waiting
> the 4
> minutes, but this is not an acceptable long-term solution (and contrary to
> what you say below, this needs to be fixed in R3.14 since it got broken in
> R3.14).  I'd like to have a discussion (on core-talk or at the codeathon)
> about other reconnection algorithms that could be used to fix this while
> still protecting the network from the UDP storms that we used to get.
> 
> > I am busy with other projects at the moment, but perhaps you might
> consider
> > creating a mantis entry (we want to minimize changes to R3.14 so this
> would
> > be against R3.15) describing the problem (and including a copy of this
> mail
> > exchange), and perhaps some improvements can be made (within the
> > constraints of reliable operation of course).
> 
> I have filed Mantis bug #330 which refers to this tech-talk discussion
> thread
> for the details.
> 
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harold Welte