Fwd: Starting N instances of a given grid configuration from tests

[Raul Kripalani]

Hi,

Is there a way with GridCommonAbstractTest to start N instances of a given
grid configuration?

I see the following method signatures:

    protected Ignite startGrid();
    protected Ignite startGrid(int idx, GridSpringResourceContext ctx);
    protected Ignite startGrid(String gridName);
    protected Ignite startGrid(String gridName, GridSpringResourceContext
ctx);
    protected Ignite startGrid(String gridName, IgniteConfiguration cfg);
    protected Ignite startGrid(String gridName, String springCfgPath);

and only one:

    protected final Ignite startGrids(int cnt);

Would it make sense to create the corresponding permutations? I'm concerned
with the class becoming too long.

Or perhaps a new GridMultipleInstancesAbstractTest that extends
GridCommonAbstractTest and provides these methods?

Or a utility class instead?

Regards,

*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

[Alexey Goncharuk]

In the current test framework the easiest way to start multiple instances
would be to call startGrids(cnt) and override the method
getConfiguration(String). This method in GridCommonAbstractTest does some
optimizations that make tests run faster and prepares a default
configuration, so all you need to do is to call
super.getConfiguration(name) and then modify configuration as you like.
After grids are started, you can access them via grid(index) where 0 <=
index < cnt.

If you want to have different configurations for different nodes, you can
use getTestGridName(index) method to get a grid name that corresponds to
the given index, so the code would be something like this:

@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
    IgniteConfiguration cfg = super.getConfiguration(gridName);

    // grid(GRID_CNT - 1) is a client.
    if (gridName.equals(getTestGridName(GRID_CNT - 1)))
        cfg.setClientMode(true);

    return cfg;
}

However if you feel that the corresponding counterparts of single-node
methods will be helpful in your case, I do not see anything wrong with
adding them to an abstract multi-node test.

2015-08-12 6:14 GMT-07:00 Raul Kripalani <[hidden email]>:

> Hi,
>
> Is there a way with GridCommonAbstractTest to start N instances of a given
> grid configuration?
>
> I see the following method signatures:
>
>     protected Ignite startGrid();
>     protected Ignite startGrid(int idx, GridSpringResourceContext ctx);
>     protected Ignite startGrid(String gridName);
>     protected Ignite startGrid(String gridName, GridSpringResourceContext
> ctx);
>     protected Ignite startGrid(String gridName, IgniteConfiguration cfg);
>     protected Ignite startGrid(String gridName, String springCfgPath);
>
> and only one:
>
>     protected final Ignite startGrids(int cnt);
>
> Would it make sense to create the corresponding permutations? I'm concerned
> with the class becoming too long.
>
> Or perhaps a new GridMultipleInstancesAbstractTest that extends
> GridCommonAbstractTest and provides these methods?
>
> Or a utility class instead?
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[Semyon Boikov]

In the current test framework the easiest way to start multiple instances
would be to call startGrids(cnt) and override the method
getConfiguration(String). This method in GridCommonAbstractTest does some
optimizations that make tests run faster and prepares a default
configuration, so all you need to do is to call
super.getConfiguration(name) and then modify configuration as you like.
After grids are started, you can access them via grid(index) where 0 <=
index < cnt.

If you want to have different configurations for different nodes, you can
use getTestGridName(index) method to get a grid name that corresponds to
the given index, so the code would be something like this:

@Override protected IgniteConfiguration getConfiguration(String gridName)
throws Exception {
    IgniteConfiguration cfg = super.getConfiguration(gridName);

    // grid(GRID_CNT - 1) is a client.
    if (gridName.equals(getTestGridName(GRID_CNT - 1)))
        cfg.setClientMode(true);

    return cfg;
}

However if you feel that the corresponding counterparts of single-node
methods will be helpful in your case, I do not see anything wrong with
adding them to an abstract multi-node test.

On Wed, Aug 12, 2015 at 4:14 PM, Raul Kripalani <[hidden email]> wrote:

> Hi,
>
> Is there a way with GridCommonAbstractTest to start N instances of a given
> grid configuration?
>
> I see the following method signatures:
>
>     protected Ignite startGrid();
>     protected Ignite startGrid(int idx, GridSpringResourceContext ctx);
>     protected Ignite startGrid(String gridName);
>     protected Ignite startGrid(String gridName, GridSpringResourceContext
> ctx);
>     protected Ignite startGrid(String gridName, IgniteConfiguration cfg);
>     protected Ignite startGrid(String gridName, String springCfgPath);
>
> and only one:
>
>     protected final Ignite startGrids(int cnt);
>
> Would it make sense to create the corresponding permutations? I'm concerned
> with the class becoming too long.
>
> Or perhaps a new GridMultipleInstancesAbstractTest that extends
> GridCommonAbstractTest and provides these methods?
>
> Or a utility class instead?
>
> Regards,
>
> *Raúl Kripalani*
> Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
> Integration specialist
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>