I've answered as best I can without having looked too much into it.
On 8 Mar 2012, at 16:28, 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.
Understood :-)
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.
I think changing ManagedDeployableContainer in the as source tree might work, or
alternatively creating another container for clustering. I'll just keep calling it
ManagedDeployableContainer for now :-) ManagedDeployableContainer is where the start/stop
calls seem to end up. Some tracking of if it is currently started/stopped could be added
to know whether to start it for real (on first start) or reloading out of admin-only. A
problem is when to do the real stop, rather than the reload->admin-only, e.g. at the
end of the suite but there might be some hooks that can be used? I guess it really depends
on if the ManagedDeployableContainer instances behind the ContainerController are the same
for each test or not.
I've not really looked at it enough to know about the ordering stuff you mention.
This would however prohibit use of stop by kill or custom "kill" and
probably use of different container confs as well.
Kill probably should kill the
process, and be tracked in the ManagedDeployableContainer so that the next start() does a
real start
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