Deadlock database error when activating tickets

[bizdoktor]

Maybe I missed a setting? After turning off ALL the plugin as you instructed me to do for testing tri.be products I had to check every setting for each plugin … (it’s an hours work – don’t ask that again)!! 🙂

My host presented me for an error.log

Here is a small cut (I have 600 more lines):
((Some translation from the Danish log – databasefejl = database error.
forespørgslen = query

[16-Jul-2015 00:12:14 UTC] WordPress-databasefejl Deadlock found when trying to get lock; try restarting transaction for forespørgslen DELETE FROM <code>dogWhisp_options</code> WHERE <code>option_name</code> = '_transient_tribe_events_pro_processing_batch_1880' fra do_action_ref_array, call_user_func_array, Tribe__Events__Pro__Recurrence__Queue_Processor->process_queue, Tribe__Events__Pro__Recurrence__Queue_Processor->do_processing, Tribe__Events__Pro__Recurrence__Queue->clear_in_progress_flag, delete_transient, delete_option
[16-Jul-2015 00:12:14 UTC] WordPress-databasefejl Deadlock found when trying to get lock; try restarting transaction for forespørgslen DELETE FROM <code>dogWhisp_options</code> WHERE <code>option_name</code> = '_transient_tribe_events_pro_processing_batch_1880' fra do_action_ref_array, call_user_func_array, Tribe__Events__Pro__Recurrence__Queue_Processor->process_queue, Tribe__Events__Pro__Recurrence__Queue_Processor->do_processing, Tribe__Events__Pro__Recurrence__Queue->clear_in_progress_flag, delete_transient, delete_option
[16-Jul-2015 00:17:59 UTC] WordPress-databasefejl Deadlock found when trying to get lock; try restarting transaction for forespørgslen DELETE FROM <code>dogWhisp_options</code> WHERE <code>option_name</code> = '_transient_tribe_events_pro_processing_batch_1880' fra do_action_ref_array, call_user_func_array, Tribe__Events__Pro__Recurrence__Queue_Processor->process_queue, Tribe__Events__Pro__Recurrence__Queue_Processor->do_processing, Tribe__Events__Pro__Recurrence__Queue->set_in_progress_flag, set_transient, delete_option
[16-Jul-2015 00:19:10 UTC] WordPress-databasefejl Deadlock found when trying to get lock; try restarting transaction for forespørgslen DELETE FROM <code>dogWhisp_options</code> WHERE <code>option_name</code> = '_transient_tribe_events_pro_processing_batch_1880' fra do_action_ref_array, call_user_func_array, Tribe__Events__Pro__Recurrence__Queue_Processor->process_queue, Tribe__Events__Pro__Recurrence__Queue_Processor->do_processing, Tribe__Events__Pro__Recurrence__Queue->clear_in_progress_flag, delete_transient, delete_option

I have like 2.5GB log file in only 6 days!!!

Another error log from my lazy “vacation-host” tordenbox.dk – From C-Panel

[Fri Jul 17 06:21:52.511536 2015] [authz_core:error] [pid 3092:tid 140119910627072] [client 85.129.89.228:29996] AH01630: client denied by server configuration: /home/dogwhisp/public_html/xmlrpc.php, referer: http://dogwhisperer.dk/
[Thu Jul 16 16:18:27.529265 2015] [autoindex:error] [pid 22328:tid 140119858177792] [client 128.90.91.154:56051] AH01276: Cannot serve directory /home/dogwhisp/public_html/wp-content/plugins/the-events-calendar/src/: No matching DirectoryIndex (index.html.var,index.htm,index.html,index.shtml,index.xhtml,index.wml,index.perl,index.pl,index.plx,index.ppl,index.cgi,index.jsp,index.js,index.jp,index.php4,index.php3,index.php,index.phtml,default.htm,default.html,home.htm,index.php5,Default.html,Default.htm,home.html) found, and server-generated directory index forbidden by Options directive
[Thu Jul 16 16:17:59.054540 2015] [authz_core:error] [pid 22258:tid 140119910627072] [client 128.90.91.154:56029] AH01630: client denied by server configuration: /home/dogwhisp/public_html/wp-content/plugins/the-events-calendar/readme.txt
[Thu Jul 16 16:17:45.250828 2015] [autoindex:error] [pid 22358:tid 140119732299520] [client 128.90.91.154:56018] AH01276: Cannot serve directory /home/dogwhisp/public_html/wp-content/plugins/wootickets/: No matching DirectoryIndex (index.html.var,index.htm,index.html,index.shtml,index.xhtml,index.wml,index.perl,index.pl,index.plx,index.ppl,index.cgi,index.jsp,index.js,index.jp,index.php4,index.php3,index.php,index.phtml,default.htm,default.html,home.htm,index.php5,Default.html,Default.htm,home.html) found, and server-generated directory index forbidden by Options directive
[Thu Jul 16 16:17:37.708996 2015] [authz_core:error] [pid 22258:tid 140119868667648] [client 128.90.91.154:56009] AH01630: client denied by server configuration: /home/dogwhisp/public_html/wp-content/plugins/wootickets/readme.txt
[Tue Jul 14 14:34:09.290024 2015] [access_compat:error] [pid 21878:tid 140119910627072] [client 217.237.185.168:30185] AH01797: client denied by server configuration: /home/dogwhisp/public_html/xmlrpc.php, referer: http://dogwhisperer.dk/blog/

Hope someone has a magic wand? LOL

Peter

[George]

Hey Peter,

I’m really sorry that you’re running into these issues on your site.

First, if the domain where this problem is occurring is http://dogwhisperer.dk, can you go to this admin URL on your site:

• http://dogwhisperer.dk/wp-admin/post.php?post=1880&action=edit

How is this event’s recurrence pattern configured? If possible, please take a screenshot of the event information, then upload that image to a site like imgur.com and share a link to it so we can see the information.

Next, who is your web hosting provider?

Thank you!
George

[bizdoktor]

Hi,

I found the post 1880
More has joined the “ERROR party” since 🙂 I am now deleting 1 GB og logfile pr. day 🙂

http://imgur.com/a/FaFco

http://imgur.com/PkY0CeR

My no good Webhost 🙂 – That do not reply to my support tickets are http://www.tordenbox.dk – I am considering moving back to my old host GigaHost.dk

We might have to delete all events made with the reoccurring function! 🙁 ??
Please tell me how to fix this issue….
I tried to turn off ALL plugins – like in “ALL”…. 🙂
And waited a few minutes to see if the error_log file still grew… It did! So my guess is that it’s the DB running a super loop forever. (Forrest Gump running) LOL

Thanks for helping out I appreciate your help

Peter

[George]

Hey Peter,

That’s really odd, since you have no Recurrence data but the “Generating Recurrence info” warning is there…I’ve never seen that before, myself.

Also, you mention having a “crap host” – this could be a major source of the problem here. If your web host has very bad performance or bad configurations of their server technology, that could lead to all sorts of weird issues like this one.

I will share your update with other members of our team and see if we can figure out what’s causing that recurrence issue. Thank you for your patience here!

— George

[George]

Hey Peter,

One of our developers Barry took a closer look here and unfortunately came to similar conclusions as me – it seems like your web host has some strict and/or just poor-quality performance limitations, which can lead to the sort of issues you’re facing 🙁

I’m really sorry to bear that news. It means that, at the end of the day, the only way out of odd issues like this one are to do what you suggested in your post above and migrate to another, hopefully-better host.

With that being said, Barry did come up with something that MIGHT help here – he’s a crafty fella, but before sharing the idea, I want to make it clear that:

• a) If your web hosting provider itself is the source of the problem because of bad performance, then no code solution we try may work, period 🙁
• b) This solution will slow down the Batch Processing of your Recurring Events quite dramatically, so don’t be alarmed if you see such processing going slowly. That’s the goal here. Read on to see why…

A Possible Solution

Okay, so as hinted above this bit of will slow down the Recurrence processing on your site. This is intentional, because if your web host is throttling processing resources for sites like yours, then by lowering the performance burden of Recurrence processing (by lowering the batch number), it might not hit those upper thresholds and, while going at a slower pace, not produce all the errors you’ve encountered thus far.

To use this bit of code and try it out, you’ll want to head to your theme’s functions.php file and add this snippet there:

function custom_rec_batch_size() {
return 1;
}

add_filter( 'tribe_events_pro_recurrence_batch_size', 'custom_rec_batch_size' );


Then, save the file and refresh things on your site. It might help.

Let us know if this seems to make any difference at all. If not, we’ll unfortunately have to declare this issue as something that stems from – and can only be resolved by – your hosting situation, since we don’t have reports of this issue anywhere else and cannot reproduce it ourselves.

Really sorry about some of the bad news above, but hey, if your host is bad and this gets you to move to be a better one, I guess that’s a good thing in the long run, right? 🙂 A bit of a pain, for sure, and I don’t mean to belittle that, but hopefully something good does come out of all this.

Thanks for your patience Peter – let us know what you find!
George

[bizdoktor]

Hi,

I applied the script – It made it worse – The error_log is now growing 100mb pr. hour (Maybe a new world record is taking place here Juubiii)

Where do I get my hands on the updated translated file? Or could I myself do the edit with my Po-Edit?
What file is the error in? (and line#) 🙂

I’ll keep you posted what happends
My plan is first to delete the events 1880 and 1883 that seems the “bad ones”… And hope for the best!
If anything goes belly up (We are already there – site is slower than a CMD64 from 1994 😉

My “Up-2-No-Good” host still hasn’t answered my request to increase the time-out for scripts …?
I bet my left pinkie that we will move to another and serious server than Tordenbox.dk <<< Eacks! May hes behind itch and his arms to short to reach 🙂

Best of code-ing energy

Peter

[George]

Thanks for the update Peter, the fact that the debug log grew a bit in size is actually not too surprising – if the error is with processing itself, then slowing down the processing batch size would increase the number of attempts at batching and thus the number of errors.

Unfortunately, I think your host is indeed the main culprit here and that there’s little that can be done on the front-end of your site to work around this. Let us know what you find with the things you suggested here, but most likely, changing hosts is unfortunately the only thing that will work here.

Sorry to bear that news Peter. Let us know if you have any other questions, concerns, etc.

Cheers!
George

[bizdoktor]

Update
I removed the script again. To get some life back – Every browser timed out when clicking anything inside admin (front loaded after 35 min. (Yes min)
Admin page – I got it to show after 2 hours. 1.2 hours later I had the list of events (Yes I am patience (drank a lot of coffee and read some good stuff in my bible. Prayer always helps)) I did manage to click the delete button on #1880 (it took 2 hours to delete) them another 1 hour to delete the #1883 – Suddenly the site came back to life!
Everything back to normal – It was properly the two event that I created as a “Master” reoccurrent event!
I took a FULL backup (BackupBuddy) and checked everything! Full speed and BIG SMILES!

I plan a “move”-day when the site is done 100% (still some development left). Back to good old Gigahost.dk 🙂
So the story ends good! Thx for supporting me here!

Have a fantastic weekend

Peter
BizDoktor.dk

[George]

Hey Peter,

Wow, I’m glad things are working now but am not sure what happened with those two events. Any chance you could elaborate on what you mean when you refer to these events as “Master” recurring events?

Just curious – thanks for the update and for your patience with this issue.

Cheers!
George

[zobel]

Hi George
Sure, the two events was the ones I created as the first and as recurring events.
It was in that topic I did everything at once – Made all the other weekly events until 31-12-2015
One event to rule them all 🙂
That’s why I called it the “masters”.
1880 was starting on a Sunday running every week.
1883 was staring on a Tuesday running every week.

Best regards

Peter

[George]

Thanks for the information Peter. I think these events are indeed a bit large considering how long they run but that on a normal hosting provider, they would still work relatively well. I’m glad you’ve got things for now, regardless, and wish you luck as you look for a new web host! 🙂

Cheers,
George

[Author]

Posts