fpCGI failure

[Nancy Palmquist]

Tyler Style wrote:
> On Thu, Mar 13, 2008 at 10:37 AM, Ron Kracht <rkracht at filegate.net> wrote:
> 
>      Tyler wrote:
>      > fpCGI, both v1 and 2, bombs out on our Apache2 web server running
>      > fp5.0.14 on SCO OS 6.  It simply stops outputting HTML files for any
>      > rreports run.  It requires rebooting the entire machine to get it
>      > going again.  Running the commands thru fpcgi that it was stalling on
>      > works perfectly fine after the reboot.
>      >
>      > Via our resller via Ray at fptech, Ron at fptech says that it looks
>      > like an application error, and that we should just set
>      > Field_nohtmlfound to some other page.  This is obviously 
> unsatisfactory.
>      >
>      > Can anyone shed any light on this, or how to avoid it?
>      >
>      > Tyler
>      > 
> ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Filepro-list mailing list
>      > Filepro-list at lists.celestial.com
>      > http://mailman.celestial.com/mailman/listinfo/filepro-list
>      >
>      I did not say it was an application error. I said that from the logs it
>      looked like there was a flaw in the fpcgi logic that you were
>      occasionally hitting when report does not produce an html document and
>      that this flaw could be avoided by setting Field_nohtmlfound.  I do not
>      see why this is "obviously unsatisfactory".  You should always have 
> some
>      sort of html document ready to report to the user that no output was
>      produced - that is the purpose of Field_nohtmlfound.  As I said in my
>      response to support if you already have Field_nohtml found set to point
>      to such a document that my analysis was incorrect and I'd need get more
>      information.
> 
>      Ron
> 
> Hmmm.  What you wrote, "it looks like they may have hit upon a flaw in 
> the programming logic", is ambiguous.  Since my frame of reference is 
> that we're talking about fpCGI, I assumed that the 'programming logic' 
> being referred to here was fpCGI's, not the filepro report being run.
> 
> Unfortunately, this is not the case.  We were running a destruct test on 
> a test box for fpcgi v2 to see if it would solve this issue.  The same 
> data was being submitted to the same processing over and over again.  If 
> it was a filepro processing table issue the problem would surface every 
> time it was submitted, and it would not prevent all subsequent runs of 
> rreport by fpCGI (regardless of the processing table being run or the 
> data being submitted) from outputing files.  It certainly wouldn't 
> require rebooting our server to get it going again, which is what we 
> have to do now.
> 
> It would be very odd for one report bombing out to block every 
> subsequent report from running; if that was the case, it should bring 
> our whole system to a halt right away as no one would be able to run 
> reports at all.  I think this isolates it pretty much to the actual 
> fpcgi binary.

Not odd at all.  I see just this behavior when something gets stuck and I hit 
the license limit.  Then everything gets stuck.

The hung process is waiting for something.

> 
> This problem is severe enough that we have a cron job script running 
> every 10min against fpcgi that will email us if it doesn't get a 
> response back from fpcgi:
> 
> response=`curl -s -d Field_ddir=/usr/local/apache/htdocs/ -d 
> Field_base=fpcgts -d 
> Field_cmd=rreport+kinocontrol+-fp+fpcgitest+-a+-n+-u 
> http://www.kinotox.net/cgi-bin/fpcgi | grep running`;
> 
> The filepro processing is:
> ::html :cr @pw{".htm"
> ::html :tx "running"
> ::html :cr-
> ::exit
> 
> When this script sends us emails saying that this processing isn't 
> producing output files anymore, we know it's time to reboot (or 
> customers/employees call complaining that they can't use our web tools).
> 
> I find it very unlikely that this processing has a "a flaw in the 
> programming logic" that is causing fpCGI to die :D  So back to the 
> drawing board, alas :(
> 
> Tyler
> 
> PS: None of our forms have "Field_nohtmlfound" - I've never heard of it. 
>   It isn't in my fp dev reference book, nor can i find it when I do a 
> search in the online fp manual.  Is this some new feature in v2?  If so, 
> we wouldn't be using it as our production server is still v1. Or has it 
> been around and just not been ever documented?

Feature of fpcgi - look in those docs.  Ask Ray to send you current ones if you 
don't have time.  This was new to 2.0.

Nancy

> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 


-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com