PDF output of large forms is failing (HTTP 500 error)

[bggann]

I've got a large form with many repeated groups (many is >40). The process uses pdf output 2 ways.

- There is a PDF button on the form. The user can press PDF and get an output.
- On final submission a pdf is attached to an email using the "Attach PDF" Function in the email plugin.

My problem is that when the repeated groups gets above ~35, both fail.
- The pdf button generates a HTTP "500" error saying the site cannot process the request at this time.
- The email never runs.

Things I've tried.
- increasing execution time for php. Increasing memory limits.
(Note, I'm not seeing reports of unusual loading on the server)
- using Fabrik DEBUG PDF. The html seems to generate just fine.

Using Current Joomla, Fabrik just one release back, Shared server with Php 7.015.

When it fails - you get nothing, so debugging has not helped.

Things I'm considering:
- Alternate pdf converter. I create an html email that maybe could be fed to a pdf converter.
- Turning off pdf. The problem with that is that, believe it or not, users need a printed copy in a vehicle
- Splitting the form up into multiple groups.

I've got a debug version running on the same server.
- Bob

 

[cheesegrits]

Does it work when you generate it from the detail view of the form, rather than through email?

Really can't do much without a more detailed error msg. Do you have error reporting in J! set to Maximum?

I've thought about switching from DOMPDF to tcpdf, but both libraries have issues. Right now I'm looking at the possibility of simply writing a Phoca PDF plugin and handing the whole issue of PDF generation off to them.

Bottom line, J! has no built in PDF support, so we have to use a third party library, and whichever one we go with, those have issues. There are some really good ones, but those are proprietary.

-- hugh

 

[troester]

@cheesegrits :
wkhtmltopdf is working very well (I'm creating list outputs with >100 pages) but needs the programm installed on your server and exec allowed
Maybe there could be a Fabrik option for using a "custom" PDF.
At the moment it needs hacking Fabrik core and an existing domPDF folder.

Fabrik is not using the latest domPDF. It may have been improved but they changed the interface so you can't just update the lib.

 

[bggann]

Yeah - I hear you on the not enough info.

It fails at a predictable number of repeat groups - so I can add/subtract a repeat and make it fail

The only error I get is when I generate from the form view acessed either from the front end or from the backend when I view data and open a record. In that case I get the 500 error - Server cannot process the request at this time.
That is the only error and it fails at the server so I get no J! output at all.

When generated on the email - the site eventually comes back - with no error, but no email is generated so I think it is failing in the email plugin. I havent checked to see if the record is updated on the submit that kicks the email. I'll do that.

I spend all day yesterday poking around the code to try to find it error and I'm pretty darn confident it is in dompdf that it is dying.
Here is what I can do.

If I turn on Debug PDF in Fabrik and press the PDF button - the HTML is output to the screen as expected and looks complete. I can download it and pull it into adobe dc and it will create a pdf from it.

In the email plugin - I hacked it so that rather than send the rendered page to dompdf, it writes that data to the same file that the pdf would have been written to (I changed the name to end in .html). That file is written and attached to the email instead of the pdf and the email, with it attached, is properly sent. I open that attachement fine and use adobe or other free converters to create a pdf from it.

In both cases, the html that would be sent to dompdf looks and displays well and can be used to create pdf's using adobe and at least one free html-pdf converter page.

So - I'm pretty much 100% sure that dompdf is the problem.

I'll try cranking up J! debug again and see if I can catch anything, perhaps in the email sequence.
I've also looked at server logs to see if I can see anything. I cannot.

It seems silly to spend all this time on pdf, but here is my problem. This site is used to create aggreements that are used for emergency response (fires and such). In some cases, large events, agencies are re-imbursed per this aggreement. They MUST have a printed copy in the apparatus to carry with them. So - I must create some kind of output they can print.

Right now - my best approach is to create the html file I described above, and use it to create the pdf for the agencies or give them a method to do it. I'd really like it to be automated.

I also need a way to print a viable copy from the form view. They agencies sometimes need to proof read or something. PDF from the form is the best way, but if I can figure out another way I'm open to it. neither the print button or email button really work for that. Perhaps I can make the print button work.

So - to summarize
- When creating PDF from the form - I get HTTP error 500 and nothing more.
- When attaching PDF to the email, - I get no error and no email.
- With DEBUG PDF on in the form - I get the html output and that output is fine and can be used to create a pdf seperately. domPDF is not used in this case so no error
- With a hack to the email plugin I can write the html that would be sent to domPDF to a temp file and attach it to the email. That works fine and the html can be used to create a pdf. domPDF is not used in this case so no error.

What I need is:
- Some way to create a pdf or printable output from the form and email (or a way to email one to people on request)

One other temporary patch.
- If there is a way I can access the count of repeated groups in the email plugin condition, I can only attach the pdf if it falls below a certain number. That would keep the system running.

One further note. I can't really involve my hosting provider in this because they are very picky about development on the hosting servers. They provide a gaurenteed level of service and if they think you have a site that is buggy, they will boot you till you fix it. So I have to solve this problem on the dev server, then fix it on the hosting site. That said, they have not reported any overload issues so whatever limit I'm hitting is a soft one.
-bob

 

[bggann]

Okay - got into the office where I have a better internet connection and can work better. (I have satellite connection at home. Not much better than dialup).

I did some more debuging/error reporting.

J! Settings:
With: Error Reporting: Development, Debug J! off.
- I get a warning about depreciated item in dump.php on any page.
- When I try PDF from the form, I get nothing - blank screen. No error, no, no nothing. Page source is empty.

With Error Reporting: Dev, Debug J! on.
- The main page loads. I get debug console info - I really don't know what I'm looking at. Some "reds" in profile.
- When I try to load list view of my records (front end): I get
** Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 118784 bytes) in /home/dvuwwvnu/public_html/crrf_backup_site/plugins/system/debug/debug.php on line 1075**
and not output.
- If I drill down into a 'problem' record by pasting in the link to that record (the same link I would get if the previous list page displayed).
I get a result. Again J! console information. I don't know what I'm looking at - but lots of red in the profile.
** I notice in the profile that a sequence related to form plugin's runs 837 times which seems a bit excessive.
That sequence is similar to (sometimes exactly, other times, close)
Time: 0.04 ms / 159.92 ms Memory: 0.001 MB / 14.59 MB Application: runPlugins: method_exists: PlgFabrik_FormEmail, usesSession
Time: 0.20 ms / 160.12 ms Memory: 0.015 MB / 14.61 MB Application: runPlugins: preflight OK, starting: PlgFabrik_FormEmail, usesSession
Time: 0.02 ms / 160.13 ms Memory: 0.002 MB / 14.61 MB Application: runPlugins: method_exists: PlgFabrik_FormAutofill, usesSession
Time: 0.13 ms / 160.27 ms Memory: 0.015 MB / 14.63 MB Application: runPlugins: preflight OK, starting: PlgFabrik_FormAutofill, usesSession
Time: 0.01 ms / 160.28 ms Memory: 0.001 MB / 14.63 MB Application: runPlugins: method_exists: PlgFabrik_FormPHP, usesSession
Time: 0.14 ms / 160.42 ms Memory: 0.015 MB / 14.64 MB Application: runPlugins: preflight OK, starting: PlgFabrik_FormPHP, usesSession
Time: 0.01 ms / 160.44 ms Memory: 0.001 MB / 14.64 MB Application: runPlugins: method_exists: PlgFabrik_FormRedirect, usesSession
Time: 0.13 ms / 160.56 ms Memory: 0.015 MB / 14.66 MB Application: runPlugins: preflight OK, starting: PlgFabrik_FormRedirect, usesSession
Time: 0.01 ms / 160.58 ms Memory: 0.001 MB / 14.66 MB Application: runPlugins: method_exists: PlgFabrik_FormEmail, usesSession
Time: 0.12 ms / 160.70 ms Memory: 0.001 MB / 14.66 MB Application: runPlugins: preflight OK, starting: PlgFabrik_FormEmail, usesSession

Total memory and time shown in profile.
Time: 11.70 ms / 7629.29 ms Memory: 1.817 MB / 39.34 MB Application: afterRender
Database queries total: 72.93 ms

Memory section - Total Memory.
51.89 MB (54,408,120 Bytes)



My form has the following plugins:
- Email (condition 1)
- Autofill
- PHP
- Redirect
- Email (condition 2).
So this matches the plugins on the form. But it runs 837 times. It is only about 1 msec each....so only a second. I don't know if these are real-time or cpu or what.
- looks like maybe it runs every time I open an element.

I also get these errors: I'll take a look at this. There is are 3 or 4 calc fields - this is one of them.
Notice: Undefined property: stdClass::$fmo_email in /home/dvuwwvnu/public_html/crrf_backup_site/plugins/fabrik_element/calc/calc.php(123) : eval()'d code on line 14

Notice: Undefined property: stdClass::$fmo_email in /home/dvuwwvnu/public_html/crrf_backup_site/plugins/fabrik_element/calc/calc.php(123) : eval()'d code on line 14

Notice: Undefined variable: array in /home/dvuwwvnu/public_html/crrf_backup_site/plugins/fabrik_element/calc/calc.php(123) : eval()'d code on line 17

Notice: Undefined variable: array in /home/dvuwwvnu/public_html/crrf_backup_site/plugins/fabrik_element/calc/calc.php(123) : eval()'d code on line 19

Notice: Undefined variable: array in /home/dvuwwvnu/public_html/crrf_backup_site/plugins/fabrik_element/calc/calc.php(123) : eval()'d code on line 19

 

[bggann]

Update on the calc.php errors. Fixed. A typo in the Calc code.
No impact on the pdf issue.

 

[bggann]

Okay- working on a work around right now.

Can somebody tell me if it is possible to access the Repeated Group Count (sizeof (group) basically) from inside the Conditions in the email plugin. Alternatively, in the emailplugin code. That is so I can abort the pdf creation on big versions till I get this working.

Bob

 

[cheesegrits]

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 118784 bytes)

I suggest the first thing you try is to increase the memory_limit in your php.ini to at least 256MB. I know DOMPDF is memory hungry, and so are we. So it's entirely possible you are simply running out of allowed memory when generating the PDF.

The easiest way to tell if your output is killing DOMPDF is to generate a PDF in debug mode from the details view of a "too big" record, and copy and paste the HTML source into the "Manual Entry" on this page:

http://eclecticgeek.com/dompdf/debug.php

One further note. I can't really involve my hosting provider in this because they are very picky about development on the hosting servers. They provide a gaurenteed level of service and if they think you have a site that is buggy, they will boot you till you fix it. So I have to solve this problem on the dev server, then fix it on the hosting site. That said, they have not reported any overload issues so whatever limit I'm hitting is a soft one.

Frankly, I'd find another provider. Unless they run a very sloppy service, there's nothing you can do which would impact any of their other clients. That would only be a concern if they are running "shared" hosting rather than virtual machines, and if it's shared, they have no business offering it with SLAs.

-- hugh

 

[bggann]

Thanks Hugh,

I'll try increasing the memory - however, I don't know that it will help. I think I tried that (blur).

I do know that the html being sent to dompdf is causing a problem. Not sure why it is size related. Here is why
- I modified the email plugin to take the html that is about to go to dompdf and write it to a file.
- I then ran that file through tidy
- I then took the output of tidy and put it in the file
- I then read the input in the email plugin and send that to dompdf.

I get no crash and a good pdf is created.

The issue with the html is a bunch of items - I don't know which is creating the problem
Some is document structure (there is no DOCTYPE, <head>, charset). the file starts with the body - but there is no <body> (actually no <html>)

But- I suspect those are not the problem.
I get a lot of errors about <tr> and <td> tags.
Basically - there is a set of <td>'s outside a <tr>. then there is a <tr></tr> pair with no <td>'s.
I'm not sure if these are coming from my template or what.

I'll take that same html input file and push it through the link you suggested and see what it says.

As far as the hosting provider - yeah they are kind of anal about this. Probably too much. I had a situation once where we were running a pedigree building program. We upgraded it and forgot to change the "maximum generations" limit to something reasonable. Somebody run some pedigrees that went back many generations and that causes 2^gen expansion. We hit our limits and they brought down the site for violating fair usage agreements - said we needed to go to dedicated server (way too expensive). I had a hell of a time proving to them we simply needed to change a config variable. That was many years ago - servers have gotten much more controlled since then, so I probably would not have the same problem - but....

Bob

 

[bggann]

Okay- I fed the suspect html to debug.php on dompdf.
It did create a quasi-valid pdf.
I compared the "Source html" to the DOMDocument html (both are tabs on the site) and they 'repaired' some thing.
DOMDocument seems to have these changes
<html> and <head> tags added.
The rogue </tr><td> has been replaced with </tr><tr><td> and a matching </tr> added.

So - off in search of where these are coming from. My guess - my template...

 

[cheesegrits]

I'll try increasing the memory - however, I don't know that it will help. I think I tried that (blur).

Well, we know something you are doing is crapping out because it's running out of memory, 'cos it threw that error. May not be the PDF generation, but it never hurts to bump up memory. You should consider 128M as the absolute minimum to run J! and Fabrik, and at the first sign of any issue (which we now have), bump it up. Especially when you have an issue which is related to "when I have more than X number of something, it blows up". May not cure the problem, but will eliminate a potential suspect.

For validating HTML, the reference is:

https://validator.w3.org/

... although that's going to toss a lot of basically trivial warnings about entities and such. But after a while you get the hang of scanning through and looking for actual problems with things like unclosed tags. You may have to add a doctype, I forget, it's a while since I ran a PDF debug output through it.

-- hugh

 

[cheesegrits]

Oh, and depending how you increase your memory_limit, it's worth checking in the J! configuration information, PHP info, to make sure it "took". If you are doing it in (say) an htaccess or a per-directory php.ini rather than the server's global one, your host may have set PHP up so it ignores you. So check the PHP info, and make sure it really picked up your 256M setting.

-- hugh

 

[bggann]

Okay- it is up and running.

Took 2 things - I had to fix the error in my template (Details template used for pdf). I had reversed the nesting of <tr> and <td>

I had to bump memory to 256M (I'm not sure I had to go that far, but that works).

I did check in PHP info - the 256 took. It says "Gobal Value" 128M, "Local Value" 256M so - I'm thinking I went from 128 to 256.

If that is true - this is a patch. There are some agencies who will have double the # of apparatus (more than that) than they had when it failed. I'm likely to hit a 256M limit.

I do think the html being sent to dompdf is not optimal. That is because one that failed with lower memory settings, succeed after running the same input file through tidy. So the "tidy" one would run in less memory.
and yes - validator.w3.org is what I've been using and it throws lots of errors that I didn't fix.

Sigh.... Why did I volunteer to do this....

 

[cheesegrits]

Sigh.... Why did I volunteer to do this....

LOL.

If that is true - this is a patch. There are some agencies who will have double the # of apparatus (more than that) than they had when it failed. I'm likely to hit a 256M limit.

I doubt it. It seems that only the largest of your forms are having problems, so you are only just hitting the 128M ceiling with those. And that's the whole of J!, Fabrik's form rendering, and DOMPDF. Doubling the amount of repeats won't double your memory usage.

And it's only memory. When I set up sites, I usually set 256M as my default, and go from there.

-- hugh

 

[cheesegrits]

notice in the profile that a sequence related to form plugin's runs 837 times which seems a bit excessive.

Not really. Those profile msgs are from the main runPlugins() method, which will potentially run thousands of times on a page load like yours. Each element being rendered will run it at least once or twice, so with 40+ repeats of a group with 8 or 10 elements in it ... the count racks up fast. And those msgs don't mean code is actually being kicked off, it's just telling us where we are in the code, and that we're checking to see if plugins should run.

-- hugh

 

[bggann]

Okay- a bit of an update.
In attempts to ramp up this process to larger departments I've done a bunch of work.

• I've increased memory to 512M. Variables to 5000. I've also increased max_execution_time and max_input_time.
• All of these changes are reflected in the php info in J! system info - so I know they are hitting.
• I've also contacted the hosting provider who has applied some adjustments that helped.
• I've increased the hosting level to include a 'burst level' hosting that provides more capability for peak loads

The net result is

• Forms are running faster, but I run into performance issues at 80 or so "repeated groups". Those issue include
  • Load time for cascading dropdowns. Each "repeated group" has a pair of cascading dropdowns.
  • Pick the value from the first one, the second one can take seconds (10's) to load.
  • Paging (next/prev) can take a minute or more.
  • I'm hitting 100% cpu limits in cpanel when doing this.
  • PDF Generation on the page may fail.
  • PDF generation for email attachment may fail, in which case the email does not send
  • I have one that is failing to sent the email at 48 resources - with these changes implimented.

Some problems are just "slow". Others are failures to execute (500) or "this request took too long to process".

---
So
- I'm going to have to limit the number of resources that can be added to a form, and create a structure that allows multiple "submissions".
- I would really like to be able to use the number of repeated groups to determine if a PDF is attached to an email or not. I can use "condition" to do this - but I need to have a count of repeated groups.

Can somebody tell me what code/placeholder/etc. to put in condition on email plugin to see how many repeated groups are in the form?

Any other suggestions. I'm not sure indexes are optimally set for instance.

Bob

 

[cheesegrits]

Pick the value from the first one, the second one can take seconds (10's) to load.

That's almost always an issue with the foreign key not being unique.

I'll need to look at your setup, but the site in your My Sites isn't reachable at the moment (DNS could not be found).

-- hugh

 

[bggann]

I forgot I updated the 'testing copy' to a subdomain. I've updated the information in my "sites" to be correct. youll see it goes to a subdomain called backup.<site>.
If you log in there using the information in the sites, and then select the View All link, you will get a list display entered records. Youll see one there with 60 resources (Utilities) - if you open that one you will see the problem with performance. You have to "Next" 2 times to get to the repeated group page. Those credentials will get you to the backend too by clicking on the staff login link. Please assure you stay on the 'backup.<site>" subdomain. This is a reasonably recent clone of the site and does not have live data in it.
Note: that backup site is on the same server as the live site, but does not have a couple of the latest php_value updates for execution time and such. It does have the variable and memory updates. Those changes only really come into play if you try to generate a pdf or "submit" a final form.

I have no viable computer access tonight. I'm doing this on an android tablet using a teathered phone with limited connection and I have no Skype tonight. Hugh, I think you have my phpadmin access information from previous skypes. I don't have the username/password for cpanel with me here.

I'll try to check this later tonight/morning if my access holds (storm is causing power issues)

 

[bggann]

Didn't see anything come in last night, so I'm assuming you didn't get a chance to look at it.

One thing I noticed is that my fabrik_session table "data" field - where session data is stored - is hitting 65K some times. Based on the documentation I see for this a text field - I'm hitting the limit.
If true - this would impact session data storage/processing and may explain some of my issues.

Is it possible/advisable to change this field to a mediumtext. Would that trash all sessions.
If session is getting that big - is that where my performance issues hit?

Bob
BTW - On skype now.

Well - not really - Skype decided to update

 

[cheesegrits]

Just FYI, the 3.6.1 release (hopefully this week) will include a MySQL update to increase the form_session data field from TEXT to MEDIUMTEXT, which should solve that problem.

It was supposed to be in the 3.6 release, but I spaced out on version naming, and called the update file 3.7.sql instead of 3.6.sql (got the Fabrik and J! versions confused).

-- hugh