Hi, I've had a vague thought. I'm not familiar with the clustering tests bit from a glance there seems to be a lot of stopping and starting of servers going on? These tests run very slowly, so if all this

stopping/starting is contributing to the slowness, it could be an idea to explore changing the container so that stop -> executes a reload on the server so that it is reloaded in admin-only mode start -> executes a reload on the server so that is is reloaded in 'normal' mode Radoslav, do you see any issues with this?

Kabir, what exactly is admin mode? Is it the same server profile but with controls on communication from clients? The problem is that you're replacing a dead server (no communication channels) with a live server in admin mode (with live communication channels). So IIUC, you depend on the admin mode working correctly to block communications from the outside. Also, if JGroups detected failed group members using a standard OS ping mechanism (which it doesn't), then this could change JGroups view of failed vs non-failed hosts - that is, if admin mode did not also block pings. On 03/08/2012 11:28 AM, Radoslav Husar wrote: > On 03/06/2012 06:34 PM, Kabir Khan wrote: >> Hi, >> >> I've had a vague thought. I'm not familiar with the clustering tests >> bit from a glance there seems to be a lot of stopping and starting of >> servers going on? These tests run very slowly, so if all this > Hi Kabir, > > Thanks for the tough. Yes that is true and surely does contribute to the > slowness. > > The reason for the lots of stopping is because we need to use manual > containers (for simulating failover, state transfer, undeploy, > singleton, etc). The containers are set to manual mode and unmanaged > deployments. > > Unfortunately, this currently means that the containers are stopped > after *each* test class and then started again. ARQ does this. We would > also need to be able to order the test class executions. Most of these > cases (currently all) the running container could be re-used (even > though we shut it down in the middle of the test). > > For this we would probably need support in Arquillian. (class order + > dont turn off container after class?) Aslak, WDYT? > >> stopping/starting is contributing to the slowness, it could be an >> idea to explore changing the container so that >> >> stop -> executes a reload on the server so that it is reloaded in >> admin-only mode start -> executes a reload on the server so that is >> is reloaded in 'normal' mode >> >> Radoslav, do you see any issues with this? > How would this actually work? Use auto containers and use stop and start > to simulate up and down without having to do any fix in ARQ? Hmhm, thats > interesting. > > This would however prohibit use of stop by kill or custom "kill" and > probably use of different container confs as well. > > However, this seems to me too much of a workaround (for instance the > server's JVM never shuts down). > > Rado > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Kabir, what exactly is admin mode? Is it the same server profile but with controls on communication from clients?

The problem is that you're replacing a dead server (no communication channels) with a live server in admin mode (with live communication channels). So IIUC, you depend on the admin mode working correctly to block communications from the outside.

Also, if JGroups detected failed group members using a standard OS ping mechanism (which it doesn't), then this could change JGroups view of failed vs non-failed hosts - that is, if admin mode did not also block pings.

On 03/08/2012 11:28 AM, Radoslav Husar wrote: > On 03/06/2012 06:34 PM, Kabir Khan wrote: >> Hi, >> >> I've had a vague thought. I'm not familiar with the clustering tests >> bit from a glance there seems to be a lot of stopping and starting of >> servers going on? These tests run very slowly, so if all this > Hi Kabir, > > Thanks for the tough. Yes that is true and surely does contribute to the > slowness. > > The reason for the lots of stopping is because we need to use manual > containers (for simulating failover, state transfer, undeploy, > singleton, etc). The containers are set to manual mode and unmanaged > deployments. > > Unfortunately, this currently means that the containers are stopped > after *each* test class and then started again. ARQ does this. We would > also need to be able to order the test class executions. Most of these > cases (currently all) the running container could be re-used (even > though we shut it down in the middle of the test). > > For this we would probably need support in Arquillian. (class order + > dont turn off container after class?) Aslak, WDYT? > >> stopping/starting is contributing to the slowness, it could be an >> idea to explore changing the container so that >> >> stop -> executes a reload on the server so that it is reloaded in >> admin-only mode start -> executes a reload on the server so that is >> is reloaded in 'normal' mode >> >> Radoslav, do you see any issues with this? > How would this actually work? Use auto containers and use stop and start > to simulate up and down without having to do any fix in ARQ? Hmhm, thats > interesting. > > This would however prohibit use of stop by kill or custom "kill" and > probably use of different container confs as well. > > However, this seems to me too much of a workaround (for instance the > server's JVM never shuts down). > > Rado > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev