5 Replies Latest reply on Dec 17, 2010 4:16 AM by digitalstain

    Testing parallel operations

    digitalstain
    digitalstain Dec 16, 2010 10:32 AM

      Hi people,

       

      I am using Arquillian to test a JCA connector module I am building for Neo4j. The idea is that the connector is deployed at the server along with EJBs that have the connection factory from my module and a JDBC DataSource injected and all of them participating in 2PC. Obviously, the EJBs themselves are not under test - their interface consists of simple operations over the connections. The Arquillian tests are a way to call these methods and verify that the results are the ones expected.

      As a reference, I am using Glassfish 3.0.1 in a remote setting, with TestNG, (JUnit also works).

      Although I have no problem making the calls from a single thread (with everything working fine), what I actually need is to have multiple threads running the same cases against the EJBs so that I can verify that connection pooling, tx isolation etc all work properly. So, my question is, how can I have Arquillian launch parallel test cases that will run towards a remote instance of an app server?

       

      thank you for your time,

      CG

        • 1. Re: Testing parallel operations
          aslak
          aslak Dec 16, 2010 10:57 AM (in response to digitalstain)

          In Alpha4, you can use the AS_CLIENT runmode (@Run(AS_CLIENT)), in this case Arquillian will not do incontainer testing but only act as a client. You can then lookup your ejb remote and do manual Threading inside the @Test method. Alpha4 can not be run via TestNGs parallel support.

           

          In the next version we should have a fix for this, so you can use the TestFrameworks Parallel support and launch multiple parallel test executions against a incontainer testcase.

            • Actions
          • 2. Re: Testing parallel operations
            digitalstain
            digitalstain Dec 16, 2010 1:12 PM (in response to aslak)

            Thank you very much, that worked very well.

             

            One thing that is not immediately obvious, at least to me, is that when the @Test method that spawns the threads exits, the test.jar application is undeployed and everything still running will fail. Obviously the solution is to use synchronization, possibly a Barrier, which will ensure that the "main" method will exit only after all testing threads are done. Other than that, it worked like a charm.

             

            cheers,

            CG

              • Actions
            • 3. Re: Testing parallel operations
              aslak
              aslak Dec 16, 2010 6:15 PM (in response to digitalstain)

              Cool, glad it's working!

               

              Undeployment will happen in the AfterClass lifecycle, but yes. The same rules as any other place apply for Threading in the test case.. you need to join/sync/use barriers to keep the creating thread alive so the children can do their job, else it will just exit.

               

               

                • Actions
              • 4. Re: Testing parallel operations
                aslak
                aslak Dec 16, 2010 8:47 PM (in response to aslak)

                Come to think of it, not sure why i 'insisted' on AS_CLIENT run mode for threading. Manual Threading incontainer should work just as well..

                  • Actions
                • 5. Re: Testing parallel operations
                  digitalstain
                  digitalstain Dec 17, 2010 4:16 AM (in response to aslak)

                  It does. Removing @Run (or, equivalently, setting it to IN_CONTAINER) successfully runs the multithreaded test in the container.

                    • Actions