Deadlock Avoidance by Xon 1.0.18

[Xon]

Xon submitted a new resource:

Deadlock Avoidance - Workarounds for sporadic deadlocks on busy forums

XenForo's Datawriters have a _postSaveAfterTransaction() method. This method is intended to run after a database transaction is finished, but if a DataWriter is called from with-in another DataWriter, this does not happen.

This incurs the risk that various notification actions will pull in large queries into the transaction, which increasing the risk of deadlocks on a busy forum.

This is a formally private add-on which has been in use for about a month before being released.

This add-on is only for busy forums which sometimes experience deadlocks on the listed...

Read more about this resource...

 

[TheComputerGuy]

Just installed on largest forum. 15M Posts!
thanks!

 

[TheComputerGuy]

Actually, it throws a number of errors conflicting with the tapatalk addon.

Parse error: syntax error, unexpected T_STRING, expecting T_CATCH in /home/xxx/library/SV/DeadlockAvoidance/XenForo/DataWriter/ReportComment.php on line 12

 

[Xon]

@TheComputerGuy sorry, but I don't think this add-on will work for you.

Actually, it throws a number of errors conflicting with the tapatalk addon.

Not that surprising, but there is little I can do to fix that as I don't have tapatalk installed.

Parse error: syntax error, unexpected T_STRING, expecting T_CATCH in /home/xxx/library/SV/DeadlockAvoidance/XenForo/DataWriter/ReportComment.php on line 12

This add-on requires php 5.5, not php 5.4, I'll update the add-on description to correctly state that.

 

[TheComputerGuy]

@TheComputerGuy sorry, but I don't think this add-on will work for you.


Not that surprising, but there is little I can do to fix that as I don't have tapatalk installed.


This add-on requires php 5.5, not php 5.4, I'll update the add-on description to correctly state that.

Makes sense! thanks for the quick reply...We are upgrading to php 5.6+ soon....but the tapatalk...well its sticking around.

Thanks!

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Bugfix release

• Ensure correctness of when _postSaveAfterTransaction is called.

Read the rest of this update entry...

 

[HWS]

We use galera for multi master replication. The add-on does not work always, we got this error even with it installed:

Zend_Db_Statement_Mysqli_Exception: Mysqli statement execute error : Deadlock found when trying to get lock; try restarting transaction - library/Zend/Db/Statement/Mysqli.php:214
Generated By: Unknown Account, Today at 1:31 AM
Stack Trace
#0 /var/www/*****/library/Zend/Db/Statement.php(297): Zend_Db_Statement_Mysqli->_execute(Array)
#1 /var/www/*****/library/Zend/Db/Adapter/Abstract.php(479): Zend_Db_Statement->execute(Array)
#2 /var/www/*****/library/XenForo/Model/Thread.php(2422): Zend_Db_Adapter_Abstract->query('\n\t\t\tINSERT  INT...', 571128)
#3 /var/www/*****/library/XenForo/ControllerPublic/Thread.php(159): XenForo_Model_Thread->logThreadView(571128)
#4 /var/www/*****/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#5 /var/www/*****/index.php(13): XenForo_FrontController->run()
#6 {main}
Request State
array(3) {
  ["url"] => string(62) "http://*****/threads/threadtitle.571128/"
  ["_GET"] => array(1) {
    ["/threads/threadtitle_571128/"] => string(0) ""
  }
  ["_POST"] => array(0) {
  }
}

 

[Xon]

@HWS That is really weird, I'm not sure how the hell you can get a deadlock from a single-statement insert on a code path with no explicit transactions for a table never touched by the thread or post DataWriters.

Especially when this add-on isn't even active in that code-path, or any other code paths related to xf_thread_view table!

 

[HWS]

Weird for us too. Must have something to do with the Galera setup. We hoped it will be solved with your add-on. Unfortunately it isn't. Would help if XF automatically retries transactions out of the box.

 

[Xon]

This add-on wasn't designed to target that sort of deadlock, but to target what is basically a design flaw in DataWriters. There are a few other sites patched, which are called inside a DataWriter transaction which shouldn't be.

Weird for us too. Must have something to do with the Galera setup. We hoped it will be solved with your add-on. Unfortunately it isn't. Would help if XF automatically retries transactions out of the box.

Hmm, I think what you are seeing is the fact that updateThreadViews and logThreadView interact poorly with Galera. Especially if the xf_thread_view tables is the default table types.

One of my other add-ons (Redis View Counters) uses Redis to store view counters logs until they can be persisted to the database as very simple update statements, without the update/join/truncate hoops. But this does require switching over from Memcache to Redis as your caching layer.

And I don't think how that Redis View Counter add-on uses Redis will work with a Redis cluster, which is a long term plan to fix.

 

[HWS]

We converted all *_view tables from memory to innodb, since this is Galera'a only supported table type.

I'll try your Redis add-on.

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Maintenance update

• Support for User DataWriter's _postSaveAfterTransaction() - does not impact stock XenForo but for my future add-ons.

Read the rest of this update entry...

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Maintenance update

• On post/thread saving, push search updates till after the transaction.

Read the rest of this update entry...

 

[melbo]

Question:
What's a large forum?
So if we have 100 online trying to post 'something' at the same time or we have 1000 doing the same.
Won't we hit these deadlocks either way? and would it hurt to install this addon on a not large forum?

 

[Xon]

Question:
What's a large forum?
So if we have 100 online trying to post 'something' at the same time or we have 1000 doing the same.
Won't we hit these deadlocks either way? and would it hurt to install this addon on a not large forum?

I've developed these features for forums which peak at 2000-3000 users online within 15 minutes, and as they grow I'll update this add-on to keep it scaling.

This add-on also introduces shortcuts; such as remove the list of online members which I feel are useless when you have that many online.

Installing this add-on wouldn't hurt, but at the same time it introduces non-standard behaviour which may surprise you.

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Feature update release

Hoist post-transaction behaviour out of nested transactions for:

• Like/Unlike
• Moving Posts.

Implements workarounds using "UPDATE FOR" to reduce deadlocks for:

• Deleting posts.
• Liking a post.

Read the rest of this update entry...

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Bugfix release

• Fix merging/hard-deleting posts.
  

Read the rest of this update entry...

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Feature update release

• Support for Merge Posts.

Read the rest of this update entry...

 

[Xon]

Xon updated Deadlock Avoidance by Xon with a new update entry:

Feature update release

• Workaround to prevent race conditioning when following someone who is already followed.

Read the rest of this update entry...

 

[RobParker]

How would we see if deadlocks are happening to us like this?

Our forum falls into the "busy" category so it sounds like we might benefit from this but we also have a pretty powerful server so not sure...