RE: FFDC (2)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

RE: FFDC (2)

Samisa Abeysinghe
I too am new to FFDC. Thanks to Mark for clarifications.

So as far as I understand, if we do not do FFDC with every exception,
which I too think is a bad idea, it seems to me that we have to have
some 'monitor' or 'handler' kind of things to identify and capture the
signals that we want - like SIGSEGV as Mark has suggested. Is my
understanding correct here? If I am correct, then we may be talking
about a signal capturing mechanism, which is platform dependent. The
other question I have is, how do we attach the toString invocation
through this?

Do we have to implement this using the basic C++ API, or do we have
libraries to do this?


-----Original Message-----
From: Mark Whitlock [mailto:[hidden email]]
Sent: Friday, May 13, 2005 6:48 PM
To: [hidden email]
Subject: Fw: FFDC (2)

If we required toString() methods in our classes, then the existing
tool could generate these toString() methods during the build, since it
already parses class definitions and recognises fields within them.
Mark Whitlock

----- Forwarded by Mark Whitlock/UK/IBM on 13/05/2005 13:41 -----



                                       [hidden email]

             13/05/2005 13:39

             Please respond to         Fw: FFDC

              "Apache AXIS C

             Developers List"





I think FFDC should be used to show bugs in Axis C++ not application
errors. Places where I'd like to see FFDC are the default case in switch
statements and where a pointer is unexpectedly null. If we FFDC on all
exceptions, then most FFDCs will be showing simple application errors or
user errors which are already properly reported back to the application
the exception data. I'd really like to see FFDC where we fail to
storage (a "new" fails) or if we get a SIGSEGV in Axis code.

How will the FFDC handler know how to dump objects in the object stack
to a file? I guess it will need a toString() method on various classes.
which case the only objects that ever need to be on the object stack are
the Stub and Call objects, since all other objects are referenced
or indirectly) from Call and Stub. So Call.toString() could call
ClientAxisEngine.toString(), ..., etc, which in turn would call the
toString() method on all other objects.
Mark Whitlock

----- Forwarded by Mark Whitlock/UK/IBM on 13/05/2005 13:22 -----

                                       [hidden email]
             13/05/2005 11:52

             Please respond to         FFDC
              "Apache AXIS C
             Developers List"

Hi Folks,

time to discuss FFDC again :-)

We'd really like to see FFDC being used in the code. Here are some

FFDC is meant to be used in areas where the exception was completely
unexpected. In WebSphere application server FFDC consists of two

1.        The Object Stack
is a list of "useful things to have" so that when an FFDC situation
the FFDC handler has some information as to what state objects were in
prior to the Failure. This system is only as good as the information
put on the stack and relies on developers putting the appropriate
to the stack.

2.        FFDC at every exception
Websphere application server originally expected every exception to have
FFDC record output. This led to situations where FFDC was being produced
and the exception was being thrown back up the stack. The next catcher
would then produce more FFDC. This is obviously not a good system.

I don't believe that it's possible to automate the putting in of FFDC
that it's a completely manual process - thoughts?

Does everyone agree that we should have the Object stack or do we just
an FFDC API only? I think the Object stack would be a good idea in
circumstances - it does require that you know the code-paths (and there
respective entry points). However, we really only have a couple of these
paths so it should be fairly obvious?

Does anyone have any thoughts on the API?

thoughts please?