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?

Thanks,
Samisa...

-----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
trace
tool could generate these toString() methods during the build, since it
already parses class definitions and recognises fields within them.
Mark
Mark Whitlock
IBM

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

             Mark

             Whitlock/UK/IBM@I

             BMGB
To
                                       [hidden email]

             13/05/2005 13:39
cc
 

 
Subject
             Please respond to         Fw: FFDC

              "Apache AXIS C

             Developers List"

 

 

 

 









Hi,
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
in
the exception data. I'd really like to see FFDC where we fail to
allocate
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
out
to a file? I guess it will need a toString() method on various classes.
In
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
(directly
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
Mark Whitlock
IBM

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

             John
             Hawkins/UK/IBM@IB
             MGB
To
                                       [hidden email]
             13/05/2005 11:52
cc

 
Subject
             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
thoughts....

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

1.        The Object Stack
is a list of "useful things to have" so that when an FFDC situation
occurs
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
given
put on the stack and relies on developers putting the appropriate
objects
to the stack.

2.        FFDC at every exception
Websphere application server originally expected every exception to have
an
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
and
that it's a completely manual process - thoughts?


Does everyone agree that we should have the Object stack or do we just
want
an FFDC API only? I think the Object stack would be a good idea in
certain
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?


cheers,
John.