Re: Re: Heartbeat stopped messages

[mcs101main@xxxxxxx]

--NextPart_Webmail_9m3u9jl4l_27070_1087345234_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

I concur that elaborative error information should have its own class.
I also think the essential purpose of the hbeat should be to identify
if a node can provide a service rather than identify that a node can
provide a heartbeat.
A maintenance function needs detailed information of what broke.  A system
health function simply needs to know if a service is available or not.
Hbeat is a special-purpose class and it seems to be a waste that its sole
function in life is to support a hubs knowledge of a message that needs
to be repeated.  If the need for the hub was to disappear because of an
OS change then it would follow that the Hbeat class would also disappear
since in its current implementation the hub is the only function that
has a use for it.

[I'm not sure that mail client you use, Michael, but Yahoo seems to
struggle with quoting it properly]  ... I'm on the road and using a browser
interface to my mail server.  Not very fancy but it gets the job done

-------------- Original message from Stuart Booth : -------------- On Tue,
15 Jun 2004 07:29:50 -0000, patrick@xxxxxxx wrote:

>I think notification of generic errors of this type should probably
>use a standard class as a matter of policy (e.g. xap-user-error, xap-
>technical-error) and intercepted and displayed in A.N.other GUI --
>just because there's so many potential combinations; it would be
>difficult to cram meaningful error descriptions (end user
>description, error code, application state etc) into a poor heartbeat.

This better describes my own feelings actually.

There was a small class schema for xAP.Debug and xAP.Error suggested a
while back now (I'll dig out the post if I can find it) which allows
some basic information to be reported.

I'd only used these lightly myself until last night when I was having
trouble getting the RR Connector to start as a Windows Service (my log
files weren't filling up quite as I'd expected). So I dropped in a
couple of lines of xFx code in some of the key exception handler
blocks and immediately solved the problem.

So I'm very positive about these lightweight messages and I'll be
using them more thoroughly, where appropriate, in future updates to my
software apps.

I've been wrapping the xAP.Debug ones in debug only code conditional
compilation blocks, but find these equally useful. I like using Viewer
as a debug monitor rather than crawling through oodles of trace
information, but each has its place.

S
--
Stuart Booth <stuart@xxxxxxx>
xAPFramework.net - a xAP software development framework for .net

http://www.xapautomation.org/ 
     http://www.xapframework.net/