-
1. Re: Work on 187, 188, 218, .bsh, StructureDeployer
This is probably too late :-) But my stuff works now
Thanks -
2. Re: Work on 187, 188, 218, .bsh, StructureDeployer
I'm almost done with tests for this work.
Just two more tests that I have in mind currently and would need some help on how to make them work. :-)
For the single deployment api in MainDeployerImpl, I added a ReentrantReadWrite lock for the following purpose.
All methods that modify existing deployments (all, topLevel, error) have a read lock, except for shutdown, which has a write lock. Meaning you can 'safely' use first methods, since it's up to the user to explicitly remove deployment, where shutdown undeploys them all - regarding how they were added: single deploy or via add/process.
A RRW lock can take multiple read locks and exclusive write lock, so this looks exactly the behavior we're looking for.
What I would like to do, is to test that a single deploy|undeploy and (add|remove)+process don't corrupt each other in multithread requests.
Another test would include a shutdown thread, from where on all other non-shutdown (deploy|undeploy) threads should fail.
The question is how to gather required information, meaning that a thread was legally allowed to go (or not go) past the locks that we've put? -
3. Re: Work on 187, 188, 218, .bsh, StructureDeployer
"alesj" wrote:
What I would like to do, is to test that a single deploy|undeploy and (add|remove)+process don't corrupt each other in multithread requests.
Another test would include a shutdown thread, from where on all other non-shutdown (deploy|undeploy) threads should fail.
The question is how to gather required information, meaning that a thread was legally allowed to go (or not go) past the locks that we've put?
Done.
The first test - DeployerSingleDeploymentTestCase.testMultiThreads - is more a proof of concept through design, unleashing multiple threads just additionally confirms assumptions that deploy/undeploy and (add|remove)+process don't interfere with each other. :-)
The second one - DeployerSingleDeploymentTestCase.testMultiThreadsAndShutdown - is better. :-)
I'm checking if certain DeployerClient method invocation got past the read lock, as such not being valid to fail due to shutdown. All others that didn't get past the read lock must fail.
Perhaps only the way how I'm checking if thread got past the lock is a bit too impl detail - intercepting Deployment.getName method invocation.