RE: IocLogInit pu consumption (who to blame)

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

> I would therefor suggest that getting an ENETUNREACH should be grounds
> for completely aborting the log client startup process, rather than just
> trying the connection again later with the same address.

My understanding is that the routes _can_ be dynamically updated at any time
on most OS so it's probably reasonable to keep trying in case the problem is
going to go away. For example, the user might connect the system's modem to
an ISP, and this might install a new route. The connect retry poll rate
should of course be set slow enough so as to introduce an insignificant
load.

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:anj@aps.anl.gov]
> Sent: Monday, September 11, 2006 12:18 PM
> To: Jeff Hill
> Cc: 'Gasper Jansa'; 'Tech Talk'
> Subject: Re: IocLogInit pu consumption (who to blame)
> 
> Hi Jeff,
> 
> thanks for the response.
> 
> Jeff Hill wrote:
> >
> > Typically, the socket connect system call will block the calling thread
> > should the connect attempt be unsuccessful, but apparently if there are
> no
> > local routing options the call fails out immediately (without suspending
> the
> > thread for any amount of time) opening up a CPU consumption
> vulnerability
> > because the code as written attempts to connect again immediately. The
> fix
> > will probably be a delay inserted where the socket connect attempt fails
> > (prior to rejoining the loop sustaining the connection attempts).
> 
> I can see two scenarios that might result in getting an ENETUNREACH
> status:  A) There is a temporary network routing problem which will get
> solved at some point in the future, and B) The user put the wrong
> address into EPICS_IOC_LOG_INET.  The latter problem seems a much more
> likely cause to me, since I could only get the ENETUNREACH error by
> removing the default route from my workstation's routing tables.
> 
> I would therefor suggest that getting an ENETUNREACH should be grounds
> for completely aborting the log client startup process, rather than just
> trying the connection again later with the same address.
> 
> Completely aborting the client at this point gives the user the option
> of fixing the problem by changing EPICS_IOC_LOG_INET if necessary (or
> adding the appropriate route) and running iocLogInit() again.  Just
> retrying the same IP address again a few seconds/minutes later only
> solves the problem in scenario A above (and as I found, scenario A might
> not even be able to cause an ENETUNREACH).  Retrying does nothing for
> problem B; in that case the user would have to restart the IOC
> completely because we don't currently have any way of shutting down the
> log client in order to change its configuration parameters.
> 
> I am definitely distinguishing the ENETUNREACH case from a connection
> timeout problem where the log server might be down at the time the IOC
> starts - that's a case where we do want to keep the current behaviour
> since it's likely that the server will be restarted, and we'd want to
> connect to it automatically when it does.
> 
> - Andrew
> --
> There is considerable overlap between the intelligence of the smartest
> bears and the dumbest tourists -- Yosemite National Park Ranger