Issue 339 in glassdb: Better debugging support for FastCGI

Status: Accepted
Owner: [hidden email]
Labels: Type-Defect Priority-Medium GLASS-Server Version-GLASS0.231

New issue 339 by [hidden email]: Better debugging support for FastCGI
http://code.google.com/p/glassdb/issues/detail?id=339

During a discussion with Norbert[1], it came up that we could have better  
debugging support for FastCGI by snapping off continuations. in the error  
handlers ... make this conditional on a flag, since it may not always be  
safe to commit the continuation ... however, when debugging it would  
definitiely be useful.

[1]  
http://forum.world.st/Instructions-to-start-zinc-gs-adaptor-td4526192.html

Comment #1 on issue 339 by [hidden email]: Better debugging support  
for FastCGI
http://code.google.com/p/glassdb/issues/detail?id=339

Another big help for debugging FastCGI would be to provide more information  
in GsGsSocketServer>>notifyUnreportableError: ...  printing stacks or  
a "location code" identifying the caller would help isolate the particular  
problem a bit more ...

Comment #2 on issue 339 by [hidden email]: Better debugging support  
for FastCGI
http://code.google.com/p/glassdb/issues/detail?id=339

The code in FSGsSocketServer>>notifyUnreportableError: should look like  
this:

   notifyUnreportableError: aString
        "unconditional logging to stdout"
        | stdout stack |
        stack := GsProcess stackReportToLevel: 300.
        stdout := GsFile stdoutServer.
        stdout nextPutAll: '-----------  Unreportable ERROR Encountered: ',  
DateAndTime now printString.
        stdout nextPutAll: aString.
        stdout cr.
        stdout nextPutAll: stack.
        stdout nextPutAll: '-----------'.
        stdout cr.
        stdout close.