Yesterday we updated our Calendar module to version 16.0.28. This resulted in us not being able to view our calendars, it “gets stuck” on loading and eventually gives an AJAX error. We also immediately started getting emails approx. every 2 minutes with the below message.
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 536870920 bytes) in /var/www/html/admin/modules/calendar/IcalParser/IcalRangedParser.php on line 114
I tried changing the PHP memory limit to 256 which did not resolve the issue. I was able resolve the issue by downgrading the calendar module to version 16.0.22. I tried some of the modules later than 16.0.22 and they all resulted in this error.
We are running PBXact 16.0.40.7.
Anyone have any idea’s how to resolve this without downgrading to an old module?
I have a similar problem. Three machines updated the calendar module to 16.0.28. Since then, a process “fwconsole job --run --quiet” runs at 100% cpu load and eats more and more memory until the system stucks.
The machines have different setups, but the calendar module is linked in many routes, so it is not possible to remove them. All machines run also with auto update.
As a quick fix, i wrote a cronjob, which kills the “fwconsole job” task every 5 minutes. I also had to change all routes, so that they do not link to a calendar condition, otherwise no inbound calls are possible, because the call stucks at checking the calendar conditions.
Well typically here I would look at the difference between the versions but according to github calendar hasn’t been touched in 7 months since version 16.0.27. Yet more evidence they have NOT moved to github just closed the public out of seeing the code and development.
yeah it seems like they are still using the atlassian stack just don’t want it to be public. The funny thing is FreePBX had assuming someone maintained the relationship an open source license so public access by way of crowd cost nothing. So this saves them nothing unless of course they lost that license
Hey! I’m the developer of the patches in 16.0.23 and the fix related in 16.0.27. I don’t see any problem in .27 so I think you should rollback to that because there were some large improvements in the speed of matching (the issue is lost but anyway it was like 100x faster).
And if you need any clarification about the code I’m here
Edit: I also know the code well now, if you want to share with me the buggy version I could have a look into
Can you tell us why none of this code is public so others can review it? If it was on github there may already be a patch rather than waiting for advice to do what is already being done. If had gone through a proper PR process and code review on github then people like myself who wrote the code could have given feedback if something was a miss.
Ok it seems like the source of .28 version was released on GitHub. They added very few lines of code to one of the functions I added with my previous commits! So I think I’m the perfect guy to debug why it goes stuck now
I will have a look into later and see what’s the problem.
I’m curious, why are you using the goto function in PHP? This kind of goes back to @jfinstrom point of not being able to review. Nothing else in the FreePBX code uses goto to handle things and there should be consistency in this code for handle functions/routines that everything uses.
As an example, all the database interactions are done with PDO in FreePBX. Writing a fix/module/feature that requires all MySQLi calls goes outside the standard of database interaction. The MySQLi should be converted to PDO for consistency.
I don’t remember why I used the goto right now, anyway the code did go through the review process and everything, it was publicly available on Jira and GitLab (both of which are down now so you can’t see it).
Anyway the problem is related to recurring events and it seems like in some cases calendar will get stuck calculating it. It’s true that 16.0.27 was here for 7 months now, so in theory should be a specific issue with some kind of event. I’m trying to dive into but I need more information.
As for myself I’m using this version for I think a year now with no problem at all.
And if you wanna know why those patches were implemented it was because matching time of old recurring events (I had many starting 2 years prior the system date) was taking something like 15 seconds, so every incoming call was delayed by 15 seconds!
I’ll wait for some update by the author (and others) of the post. And will also delete the goto
So this site is a bit of an anomaly… It’s a pbx that is shared between two offices that have different hours and the Dentist has religious holidays that they are closed outside of the normal nationally recognized bank holidays.
Typically I set my systems up with 3 local calendars and use time conditions. Open Hours, Holiday and Weather/Special Events.
The open hours is self explanatory, the Holiday and Weather calendars will send the call to an announcement stating the reason the office is closed during normal hours and then dump the call to whatever the after hours location is. The additional two calendars for this PBX are for the special religious holidays the Dentist’s office observes.
So… to answer you questions…
8 local calendars, all used with time conditions in calendar mode.
How many calendars you have and the type (OAuth, CalDav…)
We have 18 calendars. 4 of them are local calendars, 14 of them are Remote iCal Calendars
How the match for the route is setup (are you using Time Conditions with calendar mode? Calendar groups? something else?)
Call flow is as follows:
1- 3 Local holiday calendars are tested
2- Local Work day calendar is tested
3- If 2 has a match - Play business hours IVR
If 2 does not match - Play After Hours IVR
Since we have 24x7 emergency service, after hours IVR gives an option to request emergency service.
If the caller selects the after hours service option, the 14 iCal calendars will be tested. When
a match is found the call is routed to the on call person.
@prophead@ashcortech
Thank you very much to both for the information. Yep everything is useful! Would you mind to share with me one event (.ics format) for the Open hours (those are recurring events right?) so that I can import it and hopefully catch the error?
