Rehashing into a running cluster causes shared processing lock contention

On our initial test of 5.0.0.CR2, we wanted to test the cluster's rehashing behavior/performance and if all locks were cleaned up.

The test was to start two nodes, then add a third node, all the while issuing commands to it.

Upon adding a third node, the cluster becomes inoperable. The stack traces is in the following location:

http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node1.log,
http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node2.log,
http://dl.dropbox.com/u/10929737/5.0.0.CR2/server_node3.log