3 Replies Latest reply on Nov 21, 2007 5:56 AM by Ales Justin

    Work on 187, 188, 218, .bsh, StructureDeployer

    Ales Justin Master

      I've commited (67198) the code that I've been working on this week - just as a precaution.

      All old tests are working - I just had to change/fix a few that were failing due to structure exception behavior changes and atomic deploy.

      Currently I also pass Kabir's suggested BaseNotAdvisedChildAdvisedAndProxyTestCase test.
      Kabir, could you quickly test others as well?
      Or I'll do a full check on Sunday.

      I'll write the matching/missing tests over the weekend, so things should be in decent shape on Monday.

      I'll also add fix or add missing pieces in AS5 once a full beta7 release is out.

        • 1. Re: Work on 187, 188, 218, .bsh, StructureDeployer
          Kabir Khan Master

          This is probably too late :-) But my stuff works now

          Thanks

          • 2. Re: Work on 187, 188, 218, .bsh, StructureDeployer
            Ales Justin Master

            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
              Ales Justin Master

               

              "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.