Unit test enhancements - #170

er... working on an update to merge cleanly with master.

@evanmcc Once that merges cleanly, I'll give it a run. My first glance says that yes, this is a good solution.

An important issue with this is that it does make a large number of buckets with altered properties, which can eventually make the ring on your test cluster sad. It used to break it right away, but I've reached the limit of the stuff that I can do to make it easier, I think.

Not something to run on a cluster that you care about, I suppose.

@evanmcc If we run this against 1.3, we'll be able to clean up properties at least a little thanks to @jrwest. Once we have the feature detection in there, we could conditionally clear the properties.

Had thought about that. How do we use it, just call a HTTP DELETE on the
bucket?

On Fri, Nov 23, 2012 at 11:48 AM, Sean Cribbs notifications@github.comwrote:

@evanmcc https://github.com/evanmcc If we run this against 1.3, we'll
be able to clean up properties at least a little thanks to @jrwesthttps://github.com/jrwest.
Once we have the feature detection in there, we could conditionally clear
the properties.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/170#issuecomment-10668343.

@evanmcc yea but its only supported in the newer api, however, so DELETE /buckets/<bucket>/props.

was about to fix build_rest_path to use the v2 path spec, but then realized that your refactor of the transports likely includes it, @seancribbs . This can wait on that to land to get merged.

@evanmcc Any chance this could be made to merge cleanly now that #179 landed?

Will get work on the merge today.

running the tests (skipping pool tests) against a single 1.3rc2 node running the memory backend.

loop 30 times pre ring-clearing commit:

• first test: Ran 184 tests in 4.065s
• last test: Ran 184 tests in 16.395s
• ring size: 150k

post ring-clearing commit:

• first test: Ran 184 tests in 4.906s
• last test: Ran 184 tests in 20.775s
• ring size: 67k

Going to update with some changes to use fewer buckets per run.

here lies evan, trolled by a mochiglobal

EDIT: or maybe by his own tyops

OK, this should be all done now. Ring size doesn't explode anymore.

There are still a large number of buckets being created, and that's what's causing most of the time growth, but it's much slower now. Still not a great idea on a production cluster, but something that for testing we can live with now, I think.

I think I did that just to test and then left it in. I think that I'll move it back to retries to keep the exception. I realize that it's a corner case of a corner case, but what if the HTTP connection isn't set up/accessible?

OK, that should, at long last, be it.

Awesome work, @evanmcc, 👍 to merge.