-
1. Re: Testsuite and localhost
ryan.campbell Jun 14, 2005 6:04 PM (in response to adrian.brock)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 Jun 14, 2005 6:15 PM (in response to adrian.brock)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
starksm64 Jun 14, 2005 7:40 PM (in response to adrian.brock)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 Jun 14, 2005 7:57 PM (in response to adrian.brock)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 Jun 14, 2005 8:02 PM (in response to adrian.brock)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 Jun 14, 2005 8:04 PM (in response to adrian.brock)"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 Jun 14, 2005 8:14 PM (in response to adrian.brock)"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
starksm64 Jun 14, 2005 9:40 PM (in response to adrian.brock)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
hbarlas Jun 21, 2005 6:14 PM (in response to adrian.brock)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
hbarlas Jun 21, 2005 6:17 PM (in response to adrian.brock)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 Jun 21, 2005 6:25 PM (in response to adrian.brock)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
hbarlas Jun 21, 2005 6:35 PM (in response to adrian.brock)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
hbarlas Jun 23, 2005 5:20 PM (in response to adrian.brock)"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
hbarlas Jun 24, 2005 7:14 PM (in response to adrian.brock)ok got it to work but I had to use the following property:
${jboss.bind.address}