5 Replies Latest reply on Nov 3, 2006 4:15 AM by Tim Fox

    Clustering tests and hsqldb

    Tim Fox Master

      The jms clustering tests in jms/clustering (TRUNK) require a shared database so aren't currently automatically run when running the funtional test suite.

      It's necessary to have mysql running and explicitly run the clustering-tests target.

      This is a bit clunky, one suggestion would be to make our default test target database mysql. I think this makes a lot of sense since no-one should be using hsqldb in a real setup anyway.

      This would require co-ordination with QA to make sure the continuous build works against mysql.

      For now though, could everyone ensure they run the clustering-tests target before committing after they run the normal test suite? Thanks

      Comments?

        • 1. Re: Clustering tests and hsqldb
          Tim Fox Master

          I have also updated the release checklist to make sure the clustering tests are run

          • 2. Re: Clustering tests and hsqldb
            Scott Stark Master

            What about just switching to another embedded database such as derby or javadb?

            • 3. Re: Clustering tests and hsqldb
              Ovidiu Feodorov Master

               

              Tim wrote:
              For now though, could everyone ensure they run the clustering-tests target before committing after they run the normal test suite? Thanks


              Why don't you add the clustering-tests target to "tests"?

              Also, you can configure the default database on a test-by-test basis, by overriding the value of < property name="functional.tests.database" value="hsqldb" />. Override it when you call < antcall target="clustering-tests"/>

              Scott wrote:

              What about just switching to another embedded database such as derby or javadb?


              We can do that, but I have one question and one observation related to this.

              The question is why JBoss AS doesn't use derby or javadb instead of hsqldb?

              The observation is that the value of the database a certain tests runs in top of can be changed on a test-by-test basis, so by just having an MySQL instance in stand by and configuring the tests to run with "mysql" would be sufficient. We already need MySQL for stress tests, so this would be the simplest way to get address the problem.

              • 4. Re: Clustering tests and hsqldb
                Scott Stark Master

                 

                "ovidiu.feodorov@jboss.com" wrote:

                We can do that, but I have one question and one observation related to this.

                The question is why JBoss AS doesn't use derby or javadb instead of hsqldb?

                We most likely will since that is what we are certifying with.


                • 5. Re: Clustering tests and hsqldb
                  Tim Fox Master

                  We could certainly use a different embedded database than HSQL for those tests that only require an embedded database.

                  However some of the tests, e.g. some of the clustering tests require a shared database that can be seen by all nodes in the cluster.

                  My point was, basically we should make the default test database a shared database, e.g. mysql so we can run the entire test suite.

                  When the tests are run against an embedded database, e.g. javadb, hsql or whatever not all the tests can be run which is not ideal.

                  Eventually this will be solved by running all tests against the full database matrix (Ryan told me we are on the waiting list for this after hibernate and jbpm) but until then I wanted a stop-gap solution.