[Clas12_software] Fwd: Meeting May 24,2012

[Dennis Weygand]

Begin forwarded message:

> From: David Heddle <david.heddle at cnu.edu>
> Subject: Re: [Clas12_software] Meeting May 24,2012
> Date: June 14, 2012 10:19:24 AM EDT
> To: Dennis Weygand <weygand at jlab.org>
> Cc: clas12_software at jlab.org, CLAS Offline <clas_offline at jlab.org>
> 
> BLOG  (hall B LOGging), a Logging Service for CLARA 
> 
> As Dennis mentioned in his recent talk, debugging is a big issue for us. Debugging in a Service Oriented Architecture (SOA) is difficult to say the least.  Our environment contains up to and including: multiple threads, multiple processes, multiple cores, multiple nodes, and components from multiple languages. If an application comprised of a chain of services fails to produce the expected output it is a rather daunting task to debug. The tried and true method of setting breakpoints and stepping through code is not an option.
> 
> This problem is not unique to SOAs. Simple multithreaded applications on a single processor already present difficulties. But the CLARA environment—with its more or less ultimate flexibility—presents the mother-of-all challenges to debugging.
> 
> 
> 
> This is why we need to pay so much attention to single unit testing. Finding bugs in services in isolation will be far easier than finding them in situ.
> 
> 
> 
> For the inevitable additional debugging we have to look backwards, back to the medieval practice of debugging by print statements.  The way to accomplish that in an SOA is by a common logging service.
> 
> 
> 
> I would suggest the logging feature contains the following features:
> 
> 
> ·      It should be an actual CLARA Service, perhaps a core service
> ·      It should be level based. That is, the logger should be settable to a granularity, such as: {FINEST = 0, FINE = 1, INFO = 2, WARNING = 3, ERROR = 4}.  The logger will ignore messages lower that its current level. This can control the volume of messages—with FINEST being used only when debugging is in full swing.
> ·      Messages are sent to the logging from services. They identify the source and level of the message. They payload is a string (the message proper)  which might be simple or it might be a stack trace resulting from an exception.
> ·      The logging service receives messages from the services, and logs them (after timestamping them)  or discards them based on the current level.
> ·      The current level should be readable (and settable?) by the services. This way they can choose to avoid sending reams of “FINEST” messages that will only be discarded. By the same token, the logging service should notify services if the logging level has changed.
> ·      The messages are not logged to a database. The log files should have a relatively short shelf life. Instead the messages are serialized out to flat files and periodically swept clean. The short shelf life will mitigate the problem of serialization mismatches.
> 
>  
> Additionally there needs to be a additional service or a extension to the primary logging service that permits inspection of the log. This “BLOG Console” should be a GUI based application that allows the user to extract log messages with filtering based on, at a minimum:
> 
> 
> ·      Time
> ·      Source (the service from which the message originated)
> ·      Minimum message level
> 
> This is just a strawman design sketch. Perhaps we can discuss this at a future Thursday software meeting.
> 
>  
>  dph
> 
>  
>  

--
Dennis Weygand
weygand at jlab.org
(757) 269-5926 (office)
(757) 870-4844 (cell)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/clas12_software/attachments/20120614/508ff8ad/attachment-0002.html>