No, not using the CRON job feature. Just AJAX with timers and in some cases I call a script that terminates itself when certain conditions are met. For those I call them via Ajax, set ignore_user_abort to TRUE and set_time_limit to 0, and have the script periodically check certain files, then when certain conditions are met, the script exits - I generate a custom debug file that I write to to monitor those scripts, and everything seems to be okay there.
So, if a php process is crashes with a 233 error - what happens, does it attempt to restart another one? - providing the errors are sent to the log, I’m not noticing any problems with the apps functionality when the error occurs - just the error itself.
Simple PHP page with a menu and now with V2019 constantly getting 23 error:
Not sure what is going on but hope @gdgsupport get us a new version very soon:) So bad for me, having to crank up old VS projects and use them instead of exeout…Hard to explain to a client that a “fix” will be out soon but have no idea when…
Have you checked whether there was no remaining process related to your EXE in task manager? And is your antivirus still running in the background?
It would be better to use the new CRON timer, because it is designed to start a different PHP process to run your PHP script regularly. This will avoid possible multithreading problems.
It depends. If the PHP process crashes, the error is shown as you can see. Then, if there is a new request, a new PHP process is started.
Okay, I’ve not experimented with the new CRON timer, but that may well be the answer!
Think may have tracked down what is causing 233 error in my instance above.
Use this script to refresh an iframe which contains dynamic information from online server:
setTimeout(function(){
location.reload();
},45000);
There is also curl involved on the external page being refreshed. Seems the 233 error (no process is on the other end of pipe) is happening if the software is left open on users computer over night (or extended absents).
Will try the built-in cron instead of the script. Any tips on how to use in place of my refresh script example above appreciated.
Thank you very much for that info. That could explain the 233 error. Sure, CRON job would be better. You can assign a JavaScript call for instance that will reload the page. See here:
https://www.exeoutput.com/help/timer-cron-jobs-ui
1 Like
Regarding the 233 Error - I’ve figured out what’s going on to some extent.
As mentioned in previous post above, it occurs for me occasionally (every 5 mins or so) when doing an Ajax call that runs once a second, like this:
03/02/2019 13:47:26 Scheme Request URL start: http://heserver/getUDstats.php?_=1549201646034
03/02/2019 13:47:26 PHP ERROR: System Error. Code: 233.
No process is on the other end of the pipe
03/02/2019 13:47:26 PHP ERROR:
03/02/2019 13:47:27 Scheme Request URL start: http://heserver/getUDstats.php?_=1549201647549
I found that the 233 No process error coincides with a failed Ajax call to the getUDstats.php script that would normally return json to main script:
From the cefdebug log:
[0203/134726.545:INFO:CONSOLE(14642)] “Ajax statsUpdate error: error (ERROR)”, source: http://heserver/CAn.php?projectCode=1489549538&projectName=Adrian&KWnoScroll=1&freshOpen=1 (14642)
It seems that occasionlly (every five minutes or so) ExeOutput acts as if the getUDstats.php script doesn’t exist and throws an ExeOutput Viewer error (looks like a 500 server error), which in turn causes the Ajax call to fail. (as it’s a background script, I don’t get to see the ExeOut error page in the app, and I send the ajax error to the console and restart the scrip on errors anyway, so it currently doesn’t affect operation of the app, but for production I’d need to find a solution.)
This is what it looks like when the error occurs in devTools:
Error Thrown:
Headers tab:
Timing Tab:
Regarding the CRON feature, I’ve had a look, but not entirely sure how to implement it or it if would be be able to work in the way I’d need - would be good to have a bit of a deeper explination of how it could replace ajax - I’ve barely used any hescript yet, so it’s all a bit new to me…
The 500 error is the consequence of the 233 Error. Since the PHP cgi process crashed, it could not return a valid HTTP answer, hence the 500 error.
For your CRON job, you could just configure the timer to execute your PHP script as explained here:
https://www.exeoutput.com/help/timer-cron-jobs-ui
for instance, call the getUDstats.php script.
So are you any closer to understanding what causes the PHP cgi process to crash, is it just a consequence of EO not coping too well with multithreading or Ajax?
- in my case if it were possible to just disable the 233 error popup everything would be fine as it doesn’t cause any issues with the functioniality of my app - as soon as it causes the Ajax error I just restart the function that calls the script like so:
error: function (jqXHR, exception) {
var msg = '';
if (jqXHR.status === 0) {msg = 'Not connect.\n Verify Network.';
} else if (jqXHR.status == 404) {
msg = 'Requested page not found. [404]';
} else if (jqXHR.status == 500) {
msg = 'Internal Server Error [500].';
} else if (exception === 'parsererror') {
msg = 'Requested JSON parse failed.';
} else if (exception === 'timeout') {
msg = 'Time out error.';
} else if (exception === 'abort') {
msg = 'Ajax request aborted.';
} else {
msg = 'Uncaught Error.\n' + jqXHR.responseText;
}
console.log("Ajax statsUpdate error: (" + msg + ")");
statsUpdate(stats);
}
statsUpdate is the function that performs the Ajax call - so it effectively just calls itself again on error.
The thing is, I’m thinking the CRON timer might not be able to do what I need, or require considerable alterations to a lot of code… as it’s not just a case of calling the getUDstats script, I also send various variables and data to it at different times too, like getUDstats.php?blaaa=2&x=3 etc…
The script itself only runs for a fraction of a second each time, all it does is access a few files (that are written to via another background script) and returns some data in json format.
Might it make a difference if I replace the jquery $.ajax calls with vanilla javascript?
No. Now that we know more about what you are trying to do, we’re trying to reproduce the problem too.
1 Like
And what about disabling error messages in “PHP debugging” for your production?
Currenly I just send them to the log to avoid the popup, but yep, I would certainly disable the log too for production - so effectively that could be the simple solution. Still, would be great if we could figure out whats going on!
Hi guys, I’m just trialling ExeOutput for PHP before making the commitment to buy and I’m running into this repeated error of Error 233. What I have is a meta refresh reloading the page (a very very barebones MySQL table generator currently with 2 records to show, and it refreshes the page every 2 seconds).
After between 10-15 minutes it just shows me Error 233. Every time I’ve run the application it gives me that after a period of time, guaranteed. I saw the suggestion about RAM and available resources on another thread but I’m well within satisfactory levels on an extremely resource heavy dev machine (CPU 12-25%, still have another 18GB of RAM available).
I’ve enabled/disabled the multi-threading, I’ve tried PHP 7.3 and 5.6, I’m also using the 2019 version of ExeOutput.
Any assistance in resolving this error would be greatly appreciated.
Thank you for your contribution, we are still looking for a solution to this problem. Your detailed feedback will certainly help us.
What I have found is if I right click on the ‘page’ area of the app, the context menu shows a few options, one of them being “Home”. When I click on Home, it loads the PHP script as it would from initial load, so it’s as if PHP is recovering, but at the random interval of polling for PHP, fails, but PHP recovers in the background however it’s not there for the last refresh request and it’s idle until Home is manually requested again.
Just put v2020 to the test - the 233 Error has definitely gone, no other strange error messages so far either, everything seems very stable with this version - happy days!
1 Like
Great, thanks for the feedback. Indeed, thanks to your different reports, we could reproduce the problem and it is fixed in V2020.
1 Like