If we could get a generic FFDC, which can be used both on client as well as server, it would help a great deal on server side as well.
Additionally, if we could get, may be the trace tool to generate toString() for classes that we have that will be great. I persanlly preffer a human readable sting output here because that is much easier in debugging. Are we looking to implement this in 1.6? I think given the time lines, it is quite possible to ship this with 1.6 Thanks, Samisa... On 5/16/05, Mark Whitlock <[EMAIL PROTECTED]> wrote: > > > > > Hi Samisa, > Axis could register a signal handler that would dump out to file various > (all?) Axis objects. On Windows, it's possible to ask for a minidump. > Applications can register their own signal handlers, and these can be > chained together. It would then be the responsibility of the application to > ensure signal handlers are chained in the correct order. I'm not sure > whether signal handlers are platform dependent or not. > > Axis' signal handler might just hex dump all objects on the object stack > (see John's note). Or it could call toString() methods on these objects, if > we produced toString() methods, either by writing them by hand, or > generating them during the build using the trace tool. > > There is no standard C++ API to do FFDC. I know of code that provides an > FFDC API. I need to investigate whether it does what we want and whether it > could be donated to or used by Apache. If that is not possible, we could > write our own implementation of FFDC. Basically it is providing signal > handlers and an API to FFDC at suitable points in the code. The FFDC would > then write out diagnostic information to a file. > > By "FFDC at suitable points in the code" I mean FFDC in a situation that > should be impossible to get to or if something becomes seriously corrupted. > An FFDC can be an excellent place to start debugging a problem - often the > most useful information is the file and line number of the FFDC that was > called, and a knowlege of what was being attempted at the time. > Mark > Mark Whitlock > IBM > > ----- Forwarded by Mark Whitlock/UK/IBM on 16/05/2005 14:14 ----- > > "Samisa > Abeysinghe" > <[EMAIL PROTECTED] To > usa.com> "Apache AXIS C Developers List" > <[email protected]> > 16/05/2005 04:57 cc > > Subject > Please respond to RE: FFDC (2) > "Apache AXIS C > Developers List" > > > > > > > > > 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:[EMAIL PROTECTED] > Sent: Friday, May 13, 2005 6:48 PM > To: [email protected] > 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/[EMAIL PROTECTED] > > BMGB > To > [email protected] > > 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/[EMAIL PROTECTED] > MGB > To > [email protected] > 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. > >
