1 2 Previous Next 16 Replies Latest reply on Jul 6, 2005 9:19 PM by Adrian Brock

    Testsuite and localhost

    Adrian Brock Master

      I don't see a thread for this, so I'm starting a new one.
      http://jira.jboss.com/jira/browse/JBAS-476

      I've been investigating today, there are a number of different problems that need to
      be solved.

      1) Allowing the server to run against a binding other than "localhost"
      and the testsuite can still be run. This is important for when test machines are shared,
      and you don't want testsuites colliding.
      I count 261 references to localhost in testsuite/src/ and that doesn't
      include references in build files, e.g. see the jaxr tests.

      2) Issues with some services using udp (e.g. clustering) that will still pickup requests
      that are intended for a specific machine running the testsuite. This is for the same
      problem as (1), but also on the same network where you want to control the
      machines in the cluster.
      I don't know really how to resolve this one. Since you are basically with broadcast
      ports that need to be isolated across different users on the same network.
      Some sort of mechanism like DHCP where you can lease udp socket/ports? :-)

      3) Being able to run the testsuite against a remote machine, i.e. deploy remotely
      which requires that the testsuite can pass a url other than a file url, or it uses
      another mechanism such as jsr88 to pass the deployment as binary rather than
      as a reference url. This is the subject of the JIRA issue.

        • 1. Re: Testsuite and localhost
          ryan.campbell Expert

          The clustering tests run against node0 and node1, so the natural thing to do is to get the rest of the testsuite to run against ${node0}

          As for #1, 4 things are required:

          a. The start-jboss* macros should to default to ${node0} instead of localhost.

          b. JUnit tests should use JBossTestCase/JBossTestServices API to find URLs instead of hard coding them, just like the clustering tests do now.

          c. Serverside test deployments should use jboss.bind.addr

          d. src/resources/** should be filtered with a token like @NODE_0@.

          3. This will only allow you to run targets like one-test or tests-standard-unit which don't start jboss servers. The entire "tests" target could not be run against a remote box?

          • 2. Re: Testsuite and localhost
            Clebert Suconic Master

            For 2)
            What about defining a property like jboss.tomcat.udp.bind and jboss.ejb.udp.bind, in the same way we do to jboss.bind.address?

            Or we could at least do some replace into /build/output/server/relevant-places.

            • 3. Re: Testsuite and localhost
              Scott Stark Master

              There should be no need to service specific bind address properties. Every service should already be defaulting its bind address to the jboss.bind.address property. Where do you see a need for a service specific bind address?

              Also, every server start macro does bind the server to a specific address using the -b option as far as I know. The problem is that localhost is used for the tests target.

              The client side of the tests is what is needed most as there are many hard coded localhost references.

              • 4. Re: Testsuite and localhost
                Clebert Suconic Master

                This is to the UDP IPs. It's very common having conflicts between different runnings when both are running the testsuite in the same environment/network. (for example dev01, 2 and 3).

                I didn't mean specifically to change our distribution, but to have some way to isolate different clustered UDPs as Adrian has mentioned:

                2) Issues with some services using udp (e.g. clustering) that will still pickup requests
                that are intended for a specific machine running the testsuite. This is for the same
                problem as (1), but also on the same network where you want to control the
                machines in the cluster.
                I don't know really how to resolve this one. Since you are basically with broadcast
                ports that need to be isolated across different users on the same network.
                Some sort of mechanism like DHCP where you can lease udp socket/ports? :-)



                So, that's why I suggested the creation of the property. We would do a in those cluster UDP configs if the property is available.

                • 5. Re: Testsuite and localhost
                  Adrian Brock Master

                  The problem is caused not because the multicast aren't bound to the
                  jboss.bind.address (they are). This allows multiple servers to boot on the same
                  machine.

                  The problem is that they actually communicate over the udp groups,
                  so the ip binding does not matter.

                  Any servers on the same machine or network are going to form a cluster
                  which is not what you want when you have two or more people trying to run
                  isolated tests.

                  To properly isolate the indepenent tests, you need a simple notion to isolate the
                  udp groups. e.g. Each user gets their own mcast address and then they can use
                  ports within that address.

                  As Clebert said, a simple jboss.mcast.address should solve the problem?

                  • 6. Re: Testsuite and localhost
                    Adrian Brock Master

                     

                    "scott.stark@jboss.org" wrote:

                    Also, every server start macro does bind the server to a specific address using the -b option as far as I know. The problem is that localhost is used for the tests target.


                    Only because I fixed this yesterday. I didn't even check them all, just the unit tests.

                    • 7. Re: Testsuite and localhost
                      Adrian Brock Master

                       

                      "adrian@jboss.org" wrote:

                      The problem is that they actually communicate over the udp groups,
                      so the ip binding does not matter.


                      Of course I assume that the bind addresses are reachable from one another
                      which is the case at least in our lab.

                      • 8. Re: Testsuite and localhost
                        Scott Stark Master

                        So the standard cluster-service.xml config should come with the multicast group parameterized as well then:

                         <mbean code="org.jboss.ha.framework.server.ClusterPartition"
                         name="jboss:service=${jboss.partition.name:DefaultPartition}">
                        
                         <!-- Name of the partition being built -->
                         <attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
                        ...
                         <Config>
                         <UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" mcast_port="45566"
                        
                        


                        This is a sufficiently general configuration issue.


                        • 9. Re: Testsuite and localhost
                          Haroon Barlas Newbie

                          IP address parameterization in testsuite
                          http://jira.jboss.com/jira/browse/JBAS-1864

                          The IP address parameterization in the JBoss testsuite is a modification which will allow the testsuite to run off any IP instead of binding exclusively to localhost. Without these modifications the testsuite runs its tests only on localhost and will only allow one person on a particular machine to run the testsuite (running multiple testsuites will cause conflicts). With these modifications in place, multiple testsuites can be run on the same machine.

                          Here is the core modification:

                          I applied a Filterset on the NODE_0 token for the src/resources directory, replacing the token with the ${node0} property.
                          The files containing the token are .xml and .properties files. The chunk of code is as follows:

                          <copy todir="${build.resources}" filtering="no" overwrite="${resourceOverwrite}">
                           <fileset dir="${source.resources}">
                           <include name="**/*.xml"/>
                           <include name="**/*.properties"/>
                           </fileset>
                           <filterset>
                           <filter token="NODE_0" value="${node0}"/>
                           </filterset>
                          </copy>
                          <copy todir="${build.resources}" filtering="no" overwrite="${resourceOverwrite}">
                           <fileset dir="${source.resources}">
                           <exclude name="**/*.xml"/>
                           <exclude name="**/*.properties"/>
                           </fileset>
                          </copy>
                          


                          The ${node0} property can be instantiated as follows:

                          Example :
                          $ build -Dnode0=192.168.xxx.xxx tests

                          For now it is not advised to run with node0 having a value other than localhost because localhost is still hardcoded in several portions of the testsuite .java files. That is still Work in Progress.

                          • 10. Re: Testsuite and localhost
                            Haroon Barlas Newbie

                            the following are files which were changed in /testsuite/ to accomodate for node0 :

                            build.xml
                            imports/test-jars.xml
                            imports/code-generation.xml
                            imports/server-config.xml
                            src/resources/cosnaming.jndi.properties
                            src/resources/iiop.jndi.properties
                            src/resources/jndi.properties
                            src/resources/log4j.xml
                            src/resources/aop/META-INF/jboss-service.xml
                            src/resources/aop/invocationlog/META-INF/jboss-service.xml
                            src/resources/cluster/http/cluster-bindings.xml
                            src/resources/isolation/a/ejb/META-INF/jboss.xml
                            src/resources/jca/autocommit/hsqldb-singleconnection-ds.xml
                            src/resources/jca/ha/test-ha-ds.xml
                            src/resources/jca/inflow/META-INF/ra.xml
                            src/resources/jca/inflowmdb/META-INF/ejb-jar.xml
                            src/resources/jca/jdbc/testdriver-ds.xml
                            src/resources/jca/jdbc/META-INF/jboss-service.xml
                            src/resources/naming/jar/META-INF/jboss.xml
                            src/resources/security-srp/service-inf/jboss-service.xml
                            src/resources/test-configs/webservice-ssl/deploy/jbossweb-tomcat55.sar/server.xml
                            src/resources/testbeancluster/cif-ds.xml
                            src/resources/web/SecuredDD.xml
                            src/resources/web/UnsecuredDD.xml
                            src/resources/webservice/admindevel/META-INF/jboss-client.xml
                            src/resources/webservice/attachment/META-INF/jboss-client.xml
                            src/resources/webservice/encstyle/document/jboss-client.xml
                            src/resources/webservice/encstyle/rpc/jboss-client.xml
                            src/resources/webservice/exception/META-INF/jboss-client.xml
                            src/resources/webservice/header/META-INF/jboss-client.xml
                            src/resources/webservice/jbws124/META-INF/jboss-client.xml
                            src/resources/webservice/jbws153/META-INF/jboss-client.xml
                            src/resources/webservice/jbws163/META-INF/jboss-client.xml
                            src/resources/webservice/jbws165/META-INF/jboss-client.xml
                            src/resources/webservice/jbws168/META-INF/jboss-client.xml
                            src/resources/webservice/jbws217/META-INF/jboss-client.xml
                            src/resources/webservice/jbws68/META-INF/jboss-client.xml
                            src/resources/webservice/jbws70/META-INF/jboss-client.xml
                            src/resources/webservice/jbws71/META-INF/jboss-client.xml
                            src/resources/webservice/jbws79/META-INF/jboss-client.xml
                            src/resources/webservice/jbws82/META-INF/jboss-client.xml
                            src/resources/webservice/jbws83/META-INF/jboss-client.xml
                            src/resources/webservice/jbws84/META-INF/jboss-client.xml
                            src/resources/webservice/marshalltest-doclit/META-INF/jboss-client.xml
                            src/resources/webservice/marshalltest-rpcenc/META-INF/jboss-client.xml
                            src/resources/webservice/marshalltest-rpclit/META-INF/jboss-client.xml
                            src/resources/webservice/message/META-INF/jboss-client.xml
                            src/resources/webservice/samples/client-appl/config.xml
                            src/resources/webservice/samples/client-appl/META-INF/jboss-client.xml
                            src/resources/webservice/samples/client-ejb/META-INF/jboss.xml
                            src/resources/webservice/samples/client-web/WEB-INF/jboss-web.xml
                            src/resources/webservice/samples2/doclit/config-client.xml
                            src/resources/webservice/samples2/doclit/jboss-client.xml
                            src/resources/webservice/samples2/rpclit/jboss-client.xml

                            • 11. Re: Testsuite and localhost
                              Adrian Brock Master

                              The jboss-client.xml are parsed using the MetaData classes.

                              These already perform the system property replacement so you should use

                              ${jbosstest.server.host:localhost}
                              


                              In the code, it should be using JBossTestCase.getServerHost()
                              although I don't believe there is an equivalent for serverside processing.

                              I can't comment on the others without looking at them.

                              • 12. Re: Testsuite and localhost
                                Haroon Barlas Newbie

                                Some of the hardcoded instances of localhost in the testsuite can be replaced by reusing a few methods in JbossTestClusteredServices.java
                                Should these methods (example : getNamingURL(), getHttpURL() ) be pulled up into JBossTestServices.java?

                                Consider for example the use of getHttpURL() in org.jboss.test.webservice.samples.ServerSideJSETestCase:

                                URL url = new URL("http://localhost:8080/ws4ee-samples-server-jse/Organization?wsdl");


                                Here I could say something like :
                                URL url = new URL(getHttpURL(0) + "/ws4ee-samples-server-jse/Organization?wsdl");


                                where getHttpURL(0) will give me a url consisting of node0 instead of localhost.

                                • 13. Re: Testsuite and localhost
                                  Haroon Barlas Newbie

                                   

                                  "adrian@jboss.org" wrote:
                                  The jboss-client.xml are parsed using the MetaData classes.

                                  These already perform the system property replacement so you should use
                                  ${jbosstest.server.host:localhost}
                                  




                                  Adrian, I couldn't get this property to evaluate to the host ie 'node0'. It evaluates to the default value "localhost" each time probably because the property is not set in the first place. I confirmed from the one-test target and 'jbosstest.server.host' is indeed specified there as a system property. Am I doing something wrong?

                                  here is how I am testing:

                                  $ build -Dnode0=hbarlas -Dtest=??? one-test
                                  


                                  • 14. Re: Testsuite and localhost
                                    Haroon Barlas Newbie

                                    ok got it to work but I had to use the following property:

                                    ${jboss.bind.address}
                                    


                                    1 2 Previous Next