<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>From: </b></span><span style="font-family:'Helvetica'; font-size:medium;">David Heddle <<a href="mailto:david.heddle@cnu.edu">david.heddle@cnu.edu</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Subject: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: [Clas12_software] Meeting May 24,2012</b><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Date: </b></span><span style="font-family:'Helvetica'; font-size:medium;">June 14, 2012 10:19:24 AM EDT<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>To: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Dennis Weygand <<a href="mailto:weygand@jlab.org">weygand@jlab.org</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1.0);"><b>Cc: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:clas12_software@jlab.org">clas12_software@jlab.org</a>, CLAS Offline <<a href="mailto:clas_offline@jlab.org">clas_offline@jlab.org</a>><br></span></div><br>
<h1>BLOG (hall B LOGging), a Logging
Service for CLARA </h1><p class="MsoNormal">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. </p><p class="MsoNormal">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. </p><p class="MsoNormal"><br></p><p class="MsoNormal">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 <i>in situ</i>.</p><p class="MsoNormal"><br></p><p class="MsoNormal">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. </p><p class="MsoNormal"><br></p><p class="MsoNormal">I would suggest the logging feature contains the following
features:</p><div><br class="webkit-block-placeholder"></div><ul><li>·
It should be an actual CLARA Service, perhaps a
core service</li><li>·
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.</li><li>·
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.</li><li>·
The logging service receives messages from the
services, and logs them (after timestamping them) or discards them based on the current level.</li><li>·
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.</li><li>·
The messages are <i>not</i> 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.</li></ul><div><br class="webkit-block-placeholder"></div><div> <br class="webkit-block-placeholder"></div><p class="MsoNormal">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:</p><div><br class="webkit-block-placeholder"></div><ul><li>·
Time</li><li>·
Source (the service from which the message
originated)</li><li>·
Minimum message level</li></ul><div><br class="webkit-block-placeholder"></div><p class="MsoNormal">This is just a strawman design sketch. Perhaps we can
discuss this at a future Thursday software meeting.</p><div> <br class="webkit-block-placeholder"></div><p class="MsoNormal"> dph</p><div> <br class="webkit-block-placeholder"></div><div> <br class="webkit-block-placeholder"></div>
</blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>--</div><div>Dennis Weygand</div><div><a href="mailto:weygand@jlab.org">weygand@jlab.org</a></div><div>(757) 269-5926 (office)</div><div>(757) 870-4844 (cell)</div><div><br class="khtml-block-placeholder"></div><br class="Apple-interchange-newline"></span></div></span></span><br class="Apple-interchange-newline">
</div>
<br></body></html>