fpCGI failure, part 2

[Tyler]

On Wed, Mar 19, 2008 at 11:35 AM, Nancy Palmquist <nlp at vss3.com> wrote:

> Tyler wrote:
> > Just in case anyone's still interested in my fpcgi saga, here's an
> update.
> >
> > Adding an entry to the submitted forms for the nohtmlreturn field didn't
> > resolve the issue.  There were minor bomb outs (meaning the filepro
> > processing didn't run and no output was produced) throughout testing,
> > but after about 5 days it stopped outputting anything for any report.
> >
> > Working with fptech on the issue, so may have more to follow up with
> > after speaking with them.
> >
>

Thanks for the suggestions, Nancy!  Let me address some of the things you've
brought up.

I have to say that you are giving fpCGI too much credit.  All it does is act
> as
> a go-between.   It grabs form data send via POST or GET methods and writes
> it to
> a file and then it executes a filePro application passing the name of that
> data
> file, which is responsible to grab the data via an IMPORT of some kind.
>  Process
> the data and generate output.
>
> The output is then dragged back to the Browser that made the request.
>
> It should be very easy to verify if the filePro application ran and
> generated
> output.
>
> If it did, it must be where and what the fpCGI was told it would be.


While the form data file IS being created, fpCGI is either not running the
filepro application correctly, or rreport is bombing out before it can
execute even a single command.  This is on a test box with no other users or
processes running, btw - all that is happening is fpcgi testing.


> Also, you can tell it to leave the IMPORT file so you can test or see what
> you
> got from the form submit.
>
> Field_removeflat=NO
>
> Since you keep saying you are getting no output, I would suggest that the
> filePro part is not running correctly.


That does appear to be the case.  However it is NOT the processing table
bombing out, as it is the *same* processing table running with the *same*
data on every single test run.  Since rreport continues to run other
processing with no problem after this issue appears, and running the same
processing at the command line that fpcgi is failing to run and having it
work just fine, I am forced to assume that it is fpcgi's way of running
rreport that is faulty.


> add some lines to do the following:
>
> putenv "LOGFILE", "Somefilename"
> logtext @td<@tm<"Starting my file"
>
> add a few logtext commands at critical places.  I might write the filename
> I
> will be generating, put one at the every end - put one at the very
> beginning.
> See what it posts.


As I posted earlier, one of the processing tables being run by fpcgi and
failing is pretty much exactly that - three lines that create a text file
with just the word 'running' in it.  There is no output.


> I think Mark's suggestion that onegate would solve your problem is wrong,
> it
> will give you different errors and recovery capabilities.  If you are
> getting
> filePro errors, or not generating any output, or reading the input file
> incorrectly, you will have the same issue with onegate.


I would agree that OneGate is not the solution.  Sorry, Mark!

I use them both.  They both work.  Issues with your report generation sounds
> like where the problem can be found.


I really don't think report generation is the issue, for the reasons
outlined above, and neither does the person we're working with at fptech.  I
appreciate the input, tho!  Always good to get other insights and plans of
attack on the problem, which is why I am posting this in the first place!
:D

Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20080319/632513bc/attachment.html