EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: log message filter in Asyn
From: Mark Rivers <[email protected]>
To: "'[email protected]'" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 18 Apr 2012 14:00:22 +0000
> The drivers would then need to decide when to reset that flag, to print the message again. 
> For example, if a comms error was resolved, but re-occurred again (say, an hour later). You would want a new message in that case.

If the error logging follows Daleio's rule, then there would be an intervening message saying that the comms error had been resolved, so this would not be a problem.

But this is not the way that asyn currently works: it logs errors with ASYN_TRACE_ERROR, but typically not success (unless ASYN_TRACE_FLOW is set), which is what a re-connect would be.

My previous suggestion has problems if error messages are being produced by both device support and the driver.  These will both be using the same pasynUser, and so there will not be back-to-back identical messages.  Rather the messages will alternate between those produced by the driver and those produced by device support.

One solution to this is to require that drivers not actually call asynPrint(pasynUser, ASYN_TRACE_ERROR, ...), but rather just format an error message in pasynUser->errorMessage, and return asynError.  That is actually the way that the drvAsynSerialPort and drvAsynIPPort drivers are currently written.  They only call asynPrint for ASYN_TRACE_FLOW and ASYN_TRACEIO_DRIVER, not for ASYN_TRACE_ERROR.  In this case it is only device support (or whatever layer calls the driver) that will call asynPrint, and then the messages should be identical to the previous one, and my suggestion of ASYN_TRACE_NOREPEATS would work.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Wednesday, April 18, 2012 8:45 AM
To: Mark Rivers; [email protected]; [email protected]
Subject: RE: log message filter in Asyn

Hi,

> One simple idea would be to add a bit to the asynTrace flags,
> ASYN_TRACE_NOREPEATS.  The asynTrace facility could remember the
> previous error message for a particular pasynUser, and if the next one
> is the same (except for the time stamp) then the message would not be
> output.
> 

The drivers would then need to decide when to reset that flag, to print the message again. For example, if a comms error was resolved, but re-occurred again (say, an hour later). You would want a new message in that case.

Seems like, in general, people wouldn't mind this functionality in the errlog layer. Perhaps as Nick suggested as a library that implemented the same interface, and was plugged in somehow. Or, could modify errlog by adding a function call in each function, that checks the message and rejects or accepts it.

Cheers,
Matt


> This would make it easy for asyn drivers to adhere to the Dalesio rule
> with no changes to the driver at all, just a change in the startup
> script.
> 
> Mark
> 
> ________________________________________
> From: [email protected] [[email protected]] on
> behalf of Ralph Lange [[email protected]]
> Sent: Wednesday, April 18, 2012 3:38 AM
> To: [email protected]
> Subject: Re: log message filter in Asyn
> 
> Hm...
> 
> so it is not really the same issue, as in Mark's case (I assume)
> procServ is doing the logging while in your case (I assume) console is
> doing it.
> Which shows adding the filter to procServ or console is a bad idea, as
> it would have to be reimplemented for every client people use to access
> their IOCs.
> 
> Eric is safe when holding to his opinion, as there is no log server
> involved in both cases.
> 
> Maybe the errlogPrintf layer should define a plugin API for such
> filters, and allow adding filtering either general (for all loggers and
> the console), or for each configured logger. (To allow no-filtering
> connections to log servers that are ready to take all the crap.)
> 
> If I remember correctly, the Dalesio test (R) for drivers included
> pulling and reconnecting the device cable from the IOC, and demanded
> that the driver log each of these actions with exactly one log message,
> and no secondary resulting messages inbetween.
> With all due respect, Asyn would fail this badly.
> 
> Cheers,
> ~Ralph
> 
> 
> On 17.04.2012 19:27, [email protected] wrote:
> > Hi,
> >
> > We have the same issue that Mark described, in that we're using
> procServ along with conserver to log from our IOCs. I agree that
> filtering should be part of any log server. But I think there's a place
> for it in clients too. For example, we already do rate limiting of
> alarms from records using things like hysteresis fields.
> >
> > Yes, Asyn itself probably isn't the best place for it though.
> >
> > Cheers,
> > Matt
> >
> > ________________________________________
> > From: [email protected] [[email protected]]
> on behalf of Eric Norum [[email protected]]
> > Sent: 17 April 2012 16:39
> > To: [email protected] Talk
> > Subject: Re: log message filter in Asyn
> >
> > On Apr 17, 2012, at 8:26 AM, Mark Rivers wrote:
> >
> >> You can also turn off asynTrace messages for a particular device
> with
> >>
> >> asynSetTraceMask(port, addr, 0)
> >>
> >> But I see the utility of what Matt is proposing.  We use procServ to
> run our IOCs, both soft IOCs and vxWorks IOCs.  On vxWorks the procServ
> is controlling a telnet session to an Ethernet terminal server, which
> is connected to the vxWorks console port.  For logging we just use the
> log file capability of procServ, not a special logging program.  If a
> device becomes unavailable the log file can quickly grow very large
> with asynTrace error messages.
> >>
> >> Of course we could manually set the asynTrace mask to 0, as shown
> above.  But it would be nice to have the capability that Matt proposes,
> to automatically reduce the number of messages in the log file if they
> are all just repeats.
> > Agreed, but I'm holding to my opinion that this capability belongs in
> the log server, not in all the log clients.   It certainly does not
> belong in the ASYN layer.   In the errlogPrintf layer, perhaps, but
> really this belongs in the log server.
> >
> > --
> > Eric Norum
> > [email protected]
> >
> >
> >
> >
> >
> >
> 


-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 





References:
log message filter in Asyn matthew.pearson
Re: log message filter in Asyn Andrew Johnson
RE: log message filter in Asyn Mark Rivers
Re: log message filter in Asyn Eric Norum
RE: log message filter in Asyn matthew.pearson
Re: log message filter in Asyn Ralph Lange
RE: log message filter in Asyn Mark Rivers
RE: log message filter in Asyn matthew.pearson

Navigate by Date:
Prev: RE: log message filter in Asyn matthew.pearson
Next: CSS Training at EPICS meeting next week: Agenda, what to prepare Kasemir, Kay
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: log message filter in Asyn matthew.pearson
Next: Re: log message filter in Asyn Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·