Calendar timing out (Not displaying at all)

Management and Administration
1

juggernautsei wrote on Monday, October 10, 2011:

Hi,

I ran the patch 4.1.0  this weekend. They system seemed to work fine. This morning now the calendar is giving me this error.

Fatal error: Maximum execution time of 60 seconds exceeded in \interface\main\calendar\modules\PostCalendar\pnuserapi.php on line 1515

I have tried to go back to my backup copy of the program but that is not working either.

It is a windows 2003 server with xampp install package.

I cleared the folder interface\main\calendar\modules\PostCalendar\pntemplates\compiled\ and it is still not coming up.

It came up this weekend before clearing that folder but now I have tried putting it back and is still times out.

SOS, can’t do any work till this is fixed.

Sherwin

2

bradymiller wrote on Monday, October 10, 2011:

Hi Sherwin,

Removing stuff in interface\main\calendar\modules\PostCalendar\pntemplates\compiled\ should not cause issues (the reason this step was added, because the “compiled” scripts were interfering with the calendar mods in the patch.

Try the following:
Ensure you didn’t remove that directory completely.
Clear all the cookies in your web browser
Restart the apache server

Still issues?

-brady

3

juggernautsei wrote on Monday, October 10, 2011:

I had removed the directory. I did put it back and restarted Apache and the calendar still times out.

I looked in the folder and there are new files in the folder but the calendar is not showing.

Thanks - brady

Sherwin

4

bradymiller wrote on Monday, October 10, 2011:

Hi,

Since you actually removed the directory itself, there is potential that when you re-added it, the permission are incorrect. Ensure that it has the same permissions as the interface\main\calendar\modules\PostCalendar\pntemplates\cache directory (and would again remove everything within the compiled directory)

Also, clear the web browser cookies.

-brady

5

yehster wrote on Monday, October 10, 2011:

Sherwin,
The line (1515 in pnuserapi.php) you referenced where it times out seems to be related to repeating calendar events.  Did you create any new repeating events recently?  Is this a test system or is there real data in it?  If it’s a test system, I would try purging the openemr_postcalendar_events table using the query tool of your choice (mysql command line, phpAdmin) and seeing if that brings back the display.  Backup the table data first.

Alternately, just try deleting the newest entries in that table.

My guess is that something with a repeating event is causing your system to go into an infinite loop, hence the timeout limit gets reached.

If I’m correct, it would be good to know the details of the rogue calendar event so we can try to figure out what happened.

-Kevin

6

juggernautsei wrote on Tuesday, October 11, 2011:

The folder is being written to so I think that permissions are correct but I had the system copy the permissions down to the child folders.

This is not a test system. This is a live install with patients. I don’t know what was entered last. I can try finding the calendar and delete the latest entry.

7

juggernautsei wrote on Tuesday, October 11, 2011:

I have even gone as far as to restore the database to the day before and the calendar still hangs.

Sherwin

8

juggernautsei wrote on Tuesday, October 11, 2011:

I have looked at the appointments in the calendar database and I don’t know exactly what I am looking for in a rogue appointment.

a:6:{s:17:“event_repeat_freq”;N;s:22:“event_repeat_freq_type”;N;s:19:“event_repeat_on_num”;s:1:“1”;s:19:“event_repeat_on_day”;s:1:“0”;s:20:“event_repeat_on_freq”;s:1:“0”;s:6:“exdate”;s:0:"";}

This is one of the appointments and I am not sure how to read this string. Does this mean that it is a repeating event?

Sherwin

9

yehster wrote on Tuesday, October 11, 2011:

Not sure either what the rogue event would look like.  I also could be wrong about that being the issue.  Since you have a backup of the table, I think it would be easier to debug this issue if you just cleared the whole table and seeing if the display comes back.  If so, then it would make sense to restore the records and continue the hunt, if not, then I’m wrong, and you hopefully haven’t spent too much time exploring my hypothesis.

10

juggernautsei wrote on Tuesday, October 11, 2011:

Kevin,

you were right. It is a rogue piece of data. I cleared the database and the calendar came backup. I reloaded the data to the table and the calendar stopped coming up.

Any suggestions on how to find what data is causing the issue?

Sherwin

11

yehster wrote on Tuesday, October 11, 2011:

Sherwin,
Hopefully it is only one row in the table otherwise this approach won’t work, but I would “binary search” the table. 

http://en.wikipedia.org/wiki/Binary_search_algorithm

Partition the table by the pc_eid.  Delete half of the rows.  See if the calendar still crashes.  If so, then delete half of the remaining rows.  etc… any time it stops crashing, you have to restore the deleted rows.  Eventually you will narrow it down to hopefully to one row.

Alternately, since it’s probably something new, you could just start at the end and delete chunks until it works again.

12

bradymiller wrote on Tuesday, October 11, 2011:

hi,

Nice catch on this problem. To not forget this issue/solution, gonna place it on a troubleshooting wiki page:
http://open-emr.org/wiki/index.php/General_Troubleshooting

Note this page can be found in the following wiki section:
http://open-emr.org/wiki/index.php/OpenEMR_Wiki_Home_Page#Troubleshooting

-brady

13

juggernautsei wrote on Wednesday, October 12, 2011:

I have worked on this for two days now and it is not getting too much better.
I have managed to stop the time outs. Loading all the data back to the data base cause the system to hang. I have narrowed it down to the last 100 enters in the sytem. My question becomes about these two enteries that are different than all the others because of the word ‘Array’.

(6252, 10, 0, ‘Array’, ‘963’, ‘New Patient’, ‘2011-10-11 12:55:53’, ‘New Patient Referred to by Dr. Nottingham’, 0, 0, 1, ‘7’, ‘2011-10-13’, ‘0000-00-00’, 900, 0, ‘a:6:{s:17:“event_repeat_freq”;s:0:"";s:22:“event_repeat_freq_type”;s:0:"";s:19:“event_repeat_on_num”;s:1:“1”;s:19:“event_repeat_on_day”;s:1:“0”;s:20:“event_repeat_on_freq”;s:1:“0”;s:6:“exdate”;s:0:"";}’, 0, ‘09:00:00’, ‘09:15:00’, 0, ‘a:6:{s:14:“event_location”;s:0:"";s:13:“event_street1”;s:0:"";s:13:“event_street2”;s:0:"";s:10:“event_city”;s:0:"";s:11:“event_state”;s:0:"";s:12:“event_postal”;s:0:"";}’, NULL, NULL, NULL, NULL, NULL, 1, 1, NULL, ‘-’, 0, 3, ‘NO’, ‘NO’, 3),
(6255, 10, 0, ‘Array’, ‘963’, ‘New Patient’, ‘2011-10-11 13:05:26’, ‘New Patient Referred by Dr. Nottinham’, 0, 0, 1, ‘17’, ‘2011-10-17’, ‘0000-00-00’, 900, 0, ‘a:6:{s:17:“event_repeat_freq”;s:0:"";s:22:“event_repeat_freq_type”;s:0:"";s:19:“event_repeat_on_num”;s:1:“1”;s:19:“event_repeat_on_day”;s:1:“0”;s:20:“event_repeat_on_freq”;s:1:“0”;s:6:“exdate”;s:0:"";}’, 0, ‘13:30:00’, ‘13:45:00’, 0, ‘a:6:{s:14:“event_location”;s:0:"";s:13:“event_street1”;s:0:"";s:13:“event_street2”;s:0:"";s:10:“event_city”;s:0:"";s:11:“event_state”;s:0:"";s:12:“event_postal”;s:0:"";}’, NULL, NULL, NULL, NULL, NULL, 1, 1, NULL, ‘-’, 0, 3, ‘NO’, ‘NO’, 3),

What would cause the words array to be placed in the appointment catagory where there should be numbers?

14

juggernautsei wrote on Wednesday, October 12, 2011:

Is there a limit to the number of records the calendar table can hold?

The reason that I am asking is that the calendar will stay stable for  a while then it starts timing out again. I have emptied the table and repopulate it a little at a time and this last time I left out the last 100 records and the system still started timing after about three hours with no entries being made to the system.

I am dying here.

Sherwin

15

tmccormi wrote on Wednesday, October 12, 2011:

I’m not sure what script you would put this in, somewhere near the top of the call stack for calendar,  but you might consider adding set_time_limit(0);   This will override the PHP max execution time (60 secs). 

It could solve the problem or allow the script to run forever and not come back….  but it might be worth a test run.

-Tony

16

yehster wrote on Wednesday, October 12, 2011:

The simplest place to put it would probably be
/openemr/interface/main/calendar/modules/PostCalendar/pntemplates/default/views/header.html
This file gets included and executed by all of the calendar views.  It uses Smarty tags  and  rather than normal php tags, but works the same as a regular php file otherwise.

Curious if you have anything else running, like a third party patient portal or some other import/export process? Are other people actively using the system?

[-php-]
/* in an attempt to not 'rock the boat' too much the concurrent_layout
 * color scheme remains unchanged
 */
if ($GLOBALS['concurrent_layout']) {
    echo "<body style='background-color:".$GLOBALS['style']['BGCOLOR2']."'>";
}
else {
    echo "<body class='body_top'>";
}
// add set_time_limit here
set_time_limit(0); 
[-/php-]
17

yehster wrote on Wednesday, October 12, 2011:

Are you running low on disk space?  You say that no entries are being added, but are you actually checking the database to verify the fact? or are you just going on the assumption that nobody did anything?

18

juggernautsei wrote on Wednesday, October 12, 2011:

No, I am not running low on disk space. There is 55GB of space on my hard drives. I am running a raid 5 system on a DELL 2550 dual Xeon processors.

Yes, there is no records being added. There are 5204 records in the table and has not changed in two days.

I reverted the system back to the original 4.1 with out the updates and the system is still timing out. It may be the data.

No, I am not running any third party portals or addons to the system. This is the base EMR product on modification or anything of the such. I have two other clients on the same server and they are not experiencing any issues.

Correction, there was only one recorded added and the table started timing out again.

Thanks for the suggestions. I tryed the tag to over ride the default time out and it did not work.,

Regards,

Sherwin

19

bradymiller wrote on Wednesday, October 12, 2011:

Hi,

Probably a good idea to rule out any database corruption also:
http://beginlinux.com/blog/2009/12/maintaining-mysql-databases/

-brady

20

juggernautsei wrote on Wednesday, October 12, 2011:

I am sure it is the data but I have no clue on how to figure out what record it is but to sit and import them one at a time. When I import the data excluding the last 30 days. The system runs.

Sherwin