[infinispan-dev] Starting caches in parallel

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Starting caches in parallel

Dan Berindei
Hi guys

I've found a deadlock with transactions spanning multiple caches
during rehashing if the joiner's caches are started sequentially (for
more details see https://gist.github.com/1124740)
After discussing a bit on IRC with Manik and Galderz it appears the
only solution for 5.0.0.FINAL would be to have a mechanism to start
all the caches in parallel.

There are several options to implement that. All of them require the
users to know that they should create the caches in parallel at
application startup to avoid problems.

1. Advise the users about the problem, but let them create their own
threads and call EmbeddedCacheManager.getCache() on those threads.


2. Add a method EmbeddedCacheManager.getCaches() to start multiple
caches in parallel.

This is not as straightforward as it may seem, first there is a
question of whether to use template parameters or not:
2.a. Set<Cache> getCaches(String... cacheNames);
vs
2.b. Set<Cache<K, V>> getCaches(String... cacheNames);

I don't think having the same K and V for all the caches is going to
be very common, so I'd go with 2.a.

Then there is the problem of how to request the default cache. I think
"" should be fine, but we'd need to document it and also change the
regular getCache() methods to accept it.


3. Add an async version of EmbeddedCacheManager.getCache():

Future<Cache<K, V>> getCacheAsync(String cacheName);
Future<Cache<K, V>> getCacheAsync();

This nicely sidesteps the generics issue in solution 2 and it's also
easier for the users than solution 1, so it's currently my favourite.


What do you think?


Dan
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Sanne Grinovero-3
2011/8/4 Dan Berindei <[hidden email]>:

> Hi guys
>
> I've found a deadlock with transactions spanning multiple caches
> during rehashing if the joiner's caches are started sequentially (for
> more details see https://gist.github.com/1124740)
> After discussing a bit on IRC with Manik and Galderz it appears the
> only solution for 5.0.0.FINAL would be to have a mechanism to start
> all the caches in parallel.
>
> There are several options to implement that. All of them require the
> users to know that they should create the caches in parallel at
> application startup to avoid problems.
>
> 1. Advise the users about the problem, but let them create their own
> threads and call EmbeddedCacheManager.getCache() on those threads.
>
>
> 2. Add a method EmbeddedCacheManager.getCaches() to start multiple
> caches in parallel.
>
> This is not as straightforward as it may seem, first there is a
> question of whether to use template parameters or not:
> 2.a. Set<Cache> getCaches(String... cacheNames);
> vs
> 2.b. Set<Cache<K, V>> getCaches(String... cacheNames);
>
> I don't think having the same K and V for all the caches is going to
> be very common, so I'd go with 2.a.
>
> Then there is the problem of how to request the default cache. I think
> "" should be fine, but we'd need to document it and also change the
> regular getCache() methods to accept it.

You could use org.infinispan.manager.CacheContainer.DEFAULT_CACHE_NAME.

> 3. Add an async version of EmbeddedCacheManager.getCache():
>
> Future<Cache<K, V>> getCacheAsync(String cacheName);
> Future<Cache<K, V>> getCacheAsync();
>
> This nicely sidesteps the generics issue in solution 2 and it's also
> easier for the users than solution 1, so it's currently my favourite.
>
>
> What do you think?

I think it's very bad but it doesn't surprise me, since starting more
than a single cache in sequence brings you in the scenario of
ISPN-658,
unless you're quick enough. So yes it's not nice, but we highlighted
the problem since long I think?

Are you proposing a temporary API to make things work before ISPN-658
is solved? I don't like the Future approach, it's still unclear that I
have to send all requests before blocking on any get.
I'd make a

void startCaches(String... names);

which implicitly includes the default cache too, and you throw an
exception if getCache() is used on an unstarted cache, and
unfortunately you should also throw an exception if startCaches() is
invoked more than once.

Cheers,
Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Pete Muir

On 4 Aug 2011, at 12:01, Sanne Grinovero wrote:

>> This is not as straightforward as it may seem, first there is a
>> question of whether to use template parameters or not:
>> 2.a. Set<Cache> getCaches(String... cacheNames);
>> vs
>> 2.b. Set<Cache<K, V>> getCaches(String... cacheNames);
>>
>> I don't think having the same K and V for all the caches is going to
>> be very common, so I'd go with 2.a.

Dan and I discussed this on IRC. The JLS says that using the raw type of a parameterized type is bad practice

"The use of raw types is allowed only as a concession to compatibility of leg- acy code. The use of raw types in code written after the introduction of genericity into the Java programming language is strongly discouraged. It is possible that future versions of the Java programming language will disallow the use of raw types."

The correct signature of 2a. is

Set<? extends Cache<Object, Object>>

which encodes that we never expect K,V to be same for all caches retrieved this way.

If we do expect K, V to be the same in any case we should specify it as Set<Cache<K, V>> as this allows the compiler to infer the generic type arguments, and doesn't prohibit Set<Cache<Object, Object>>, or make any more typing for the user.
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Dan Berindei
In reply to this post by Sanne Grinovero-3
On Thu, Aug 4, 2011 at 2:01 PM, Sanne Grinovero <[hidden email]> wrote:

> 2011/8/4 Dan Berindei <[hidden email]>:
>> Hi guys
>>
>> I've found a deadlock with transactions spanning multiple caches
>> during rehashing if the joiner's caches are started sequentially (for
>> more details see https://gist.github.com/1124740)
>> After discussing a bit on IRC with Manik and Galderz it appears the
>> only solution for 5.0.0.FINAL would be to have a mechanism to start
>> all the caches in parallel.
>>
>> There are several options to implement that. All of them require the
>> users to know that they should create the caches in parallel at
>> application startup to avoid problems.
>>
>> 1. Advise the users about the problem, but let them create their own
>> threads and call EmbeddedCacheManager.getCache() on those threads.
>>
>>
>> 2. Add a method EmbeddedCacheManager.getCaches() to start multiple
>> caches in parallel.
>>
>> This is not as straightforward as it may seem, first there is a
>> question of whether to use template parameters or not:
>> 2.a. Set<Cache> getCaches(String... cacheNames);
>> vs
>> 2.b. Set<Cache<K, V>> getCaches(String... cacheNames);
>>

It turns out the proper generic version should be Map<String, Cache<?
extends Object, ? extends Object>> createCaches(String...), but even
this version produces unchecked warnings.
We'd also had to make the return type a map, otherwise the user has no
way of getting a specific cache.

>> I don't think having the same K and V for all the caches is going to
>> be very common, so I'd go with 2.a.
>>
>> Then there is the problem of how to request the default cache. I think
>> "" should be fine, but we'd need to document it and also change the
>> regular getCache() methods to accept it.
>
> You could use org.infinispan.manager.CacheContainer.DEFAULT_CACHE_NAME.
>

I thought it was something hidden from the users, I wasn't aware it's
in the public API. This is perfect.

>> 3. Add an async version of EmbeddedCacheManager.getCache():
>>
>> Future<Cache<K, V>> getCacheAsync(String cacheName);
>> Future<Cache<K, V>> getCacheAsync();
>>
>> This nicely sidesteps the generics issue in solution 2 and it's also
>> easier for the users than solution 1, so it's currently my favourite.
>>
>>
>> What do you think?
>
> I think it's very bad but it doesn't surprise me, since starting more
> than a single cache in sequence brings you in the scenario of
> ISPN-658,
> unless you're quick enough. So yes it's not nice, but we highlighted
> the problem since long I think?
>

The workaround for ISPN-658 is to start all caches on application
startup. This scenario appeared specifically because I was trying to
avoid an asymmetric cluster and moved the creation of all caches to a
central location.

> Are you proposing a temporary API to make things work before ISPN-658
> is solved? I don't like the Future approach, it's still unclear that I
> have to send all requests before blocking on any get.

The fix for ISPN-658 will most likely prevent existing nodes from
sending request to a joiner until that joiner has finished the initial
rehash, so I presume it will make my scenario impossible.
There is another JIRA planned for 5.1 that is targeted more
specifically as a workaround for ISPN-658: allow
InboundInvocationHandler to create caches automatically when it has an
incoming command for that cache (can't find the id now).

> I'd make a
>
> void startCaches(String... names);
>
> which implicitly includes the default cache too, and you throw an
> exception if getCache() is used on an unstarted cache, and
> unfortunately you should also throw an exception if startCaches() is
> invoked more than once.
>

I've had a long chat on IRC about this with Sanne and Pete, and our
conclusion was that adding a startCaches method is the clearest option
for the users.
The intention of this API is only to start the caches, so the name
should clearly state that. It will also eliminate an uncertainty for
users: at the end of startCaches call they will know that the caches
have started and that further getCache calls won't fail.

We can't afford to break getCache() for users though (including
ourselves), so getCache() will still start the cache. It should still
print a warning when doing so, directing people to call startCaches
instead.
I don't think we should throw an exception if startCaches is invoked
more than once either to match getCache() and all the other
components.

Cheers
Dan
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Galder Zamarreno
In reply to this post by Sanne Grinovero-3

On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:

> 2011/8/4 Dan Berindei <[hidden email]>:
>> </snip>
>
> Are you proposing a temporary API to make things work before ISPN-658
> is solved? I don't like the Future approach, it's still unclear that I
> have to send all requests before blocking on any get.
> I'd make a
>
> void startCaches(String... names);
>
> which implicitly includes the default cache too, and you throw an
> exception if getCache() is used on an unstarted cache, and
> unfortunately you should also throw an exception if startCaches() is
> invoked more than once.

We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.

>
> Cheers,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Pete Muir

On 4 Aug 2011, at 14:01, Galder Zamarreño wrote:

>
> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:
>
>> 2011/8/4 Dan Berindei <[hidden email]>:
>>> </snip>
>>
>> Are you proposing a temporary API to make things work before ISPN-658
>> is solved? I don't like the Future approach, it's still unclear that I
>> have to send all requests before blocking on any get.
>> I'd make a
>>
>> void startCaches(String... names);
>>
>> which implicitly includes the default cache too, and you throw an
>> exception if getCache() is used on an unstarted cache, and
>> unfortunately you should also throw an exception if startCaches() is
>> invoked more than once.
>
> We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.

Dan's latest email contains an updated proposal, which would mean that getCache would still start the cache for 5.0 (and possibly 5.x) but would be "deprecated" (not recommended by docs, javadocs updated, warning logged) if called on an unstarted cache. startCaches would also be available in 5.x for those who do need to start multiple caches.

WDYT? It seems to me this:

* improves the API (makes the behavior of getCache more expected - just a getter, and completely idempotent)
* indicates to the user that they do need to start the cache, and probably they will be more likely to start the cache at app start as well
* doesn't break the existing API, but does offer a way to get around the problem
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Galder Zamarreno

On Aug 4, 2011, at 3:43 PM, Pete Muir wrote:

>
> On 4 Aug 2011, at 14:01, Galder Zamarreño wrote:
>
>>
>> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:
>>
>>> 2011/8/4 Dan Berindei <[hidden email]>:
>>>> </snip>
>>>
>>> Are you proposing a temporary API to make things work before ISPN-658
>>> is solved? I don't like the Future approach, it's still unclear that I
>>> have to send all requests before blocking on any get.
>>> I'd make a
>>>
>>> void startCaches(String... names);
>>>
>>> which implicitly includes the default cache too, and you throw an
>>> exception if getCache() is used on an unstarted cache, and
>>> unfortunately you should also throw an exception if startCaches() is
>>> invoked more than once.
>>
>> We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.
>
> Dan's latest email contains an updated proposal, which would mean that getCache would still start the cache for 5.0 (and possibly 5.x) but would be "deprecated" (not recommended by docs, javadocs updated, warning logged) if called on an unstarted cache. startCaches would also be available in 5.x for those who do need to start multiple caches.
>
> WDYT? It seems to me this:
>
> * improves the API (makes the behavior of getCache more expected - just a getter, and completely idempotent)
> * indicates to the user that they do need to start the cache, and probably they will be more likely to start the cache at app start as well
> * doesn't break the existing API, but does offer a way to get around the problem

Ok, let's go with this as long as the old method is left around. startCaches would definitely make the API cleaner.

Btw, let's make the API fluent, so instead of:

void startCaches(String... names);

Do:

CacheContainer startCaches(String... names);

To be able to do:

startCaches(x).getCache(x)

 But we can't go final directly after making this change. We need at least another CR to fix any potential issues that might require changing the API.

> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Pete Muir

On 4 Aug 2011, at 15:12, Galder Zamarreño wrote:

>
> On Aug 4, 2011, at 3:43 PM, Pete Muir wrote:
>
>>
>> On 4 Aug 2011, at 14:01, Galder Zamarreño wrote:
>>
>>>
>>> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:
>>>
>>>> 2011/8/4 Dan Berindei <[hidden email]>:
>>>>> </snip>
>>>>
>>>> Are you proposing a temporary API to make things work before ISPN-658
>>>> is solved? I don't like the Future approach, it's still unclear that I
>>>> have to send all requests before blocking on any get.
>>>> I'd make a
>>>>
>>>> void startCaches(String... names);
>>>>
>>>> which implicitly includes the default cache too, and you throw an
>>>> exception if getCache() is used on an unstarted cache, and
>>>> unfortunately you should also throw an exception if startCaches() is
>>>> invoked more than once.
>>>
>>> We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.
>>
>> Dan's latest email contains an updated proposal, which would mean that getCache would still start the cache for 5.0 (and possibly 5.x) but would be "deprecated" (not recommended by docs, javadocs updated, warning logged) if called on an unstarted cache. startCaches would also be available in 5.x for those who do need to start multiple caches.
>>
>> WDYT? It seems to me this:
>>
>> * improves the API (makes the behavior of getCache more expected - just a getter, and completely idempotent)
>> * indicates to the user that they do need to start the cache, and probably they will be more likely to start the cache at app start as well
>> * doesn't break the existing API, but does offer a way to get around the problem
>
> Ok, let's go with this as long as the old method is left around. startCaches would definitely make the API cleaner.
>
> Btw, let's make the API fluent, so instead of:

Nice :-)

>
> void startCaches(String... names);
>
> Do:
>
> CacheContainer startCaches(String... names);
>
> To be able to do:
>
> startCaches(x).getCache(x)
>
> But we can't go final directly after making this change. We need at least another CR to fix any potential issues that might require changing the API.
>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Sanne Grinovero-3
In reply to this post by Galder Zamarreno
2011/8/4 Galder Zamarreño <[hidden email]>:

>
> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:
>
>> 2011/8/4 Dan Berindei <[hidden email]>:
>>> </snip>
>>
>> Are you proposing a temporary API to make things work before ISPN-658
>> is solved? I don't like the Future approach, it's still unclear that I
>> have to send all requests before blocking on any get.
>> I'd make a
>>
>> void startCaches(String... names);
>>
>> which implicitly includes the default cache too, and you throw an
>> exception if getCache() is used on an unstarted cache, and
>> unfortunately you should also throw an exception if startCaches() is
>> invoked more than once.
>
> We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.

agreed, as discussed with Dan we won't throw exceptions but log a
warning to recommend people use the startCaches().

Dan I still think the #startCaches method should at least log a
warning if it's invoked more than once: it's very useful to be aware
of the ISPN-658 as early as possible in the application design, and
this is a good chance for us to detect the unsupported usage pattern.
I think these two warnings combined can save a lot of time and stress,
and won't affect any body who is doing it correctly already.

+1 for Galder's fluent idea :)

Cheers,
Sanne

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Galder Zamarreno

On Aug 4, 2011, at 4:22 PM, Sanne Grinovero wrote:

> 2011/8/4 Galder Zamarreño <[hidden email]>:
>>
>> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:
>>
>>> 2011/8/4 Dan Berindei <[hidden email]>:
>>>> </snip>
>>>
>>> Are you proposing a temporary API to make things work before ISPN-658
>>> is solved? I don't like the Future approach, it's still unclear that I
>>> have to send all requests before blocking on any get.
>>> I'd make a
>>>
>>> void startCaches(String... names);
>>>
>>> which implicitly includes the default cache too, and you throw an
>>> exception if getCache() is used on an unstarted cache, and
>>> unfortunately you should also throw an exception if startCaches() is
>>> invoked more than once.
>>
>> We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.
>
> agreed, as discussed with Dan we won't throw exceptions but log a
> warning to recommend people use the startCaches().
>
> Dan I still think the #startCaches method should at least log a
> warning if it's invoked more than once: it's very useful to be aware
> of the ISPN-658 as early as possible in the application design, and
> this is a good chance for us to detect the unsupported usage pattern.
> I think these two warnings combined can save a lot of time and stress,
> and won't affect any body who is doing it correctly already.

Hmmmm, not sure about the warn message. Surely a no-op and if it's no-op from the 2nd time onwards, what's the warning about?

>
> +1 for Galder's fluent idea :)
>
> Cheers,
> Sanne
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Galder Zamarreno

On Aug 4, 2011, at 4:28 PM, Galder Zamarreño wrote:

>
> On Aug 4, 2011, at 4:22 PM, Sanne Grinovero wrote:
>
>> 2011/8/4 Galder Zamarreño <[hidden email]>:
>>>
>>> </snip>
>>
>> agreed, as discussed with Dan we won't throw exceptions but log a
>> warning to recommend people use the startCaches().
>>
>> Dan I still think the #startCaches method should at least log a
>> warning if it's invoked more than once: it's very useful to be aware
>> of the ISPN-658 as early as possible in the application design, and
>> this is a good chance for us to detect the unsupported usage pattern.
>> I think these two warnings combined can save a lot of time and stress,
>> and won't affect any body who is doing it correctly already.
>
> Hmmmm, not sure about the warn message. Surely a no-op and if it's no-op from the 2nd time onwards, what's the warning about?

Btw, whatever is done, start() and stop() need to be symmetric, and currently calling stop() on a already stopped cache does nothing.

In fact, a debug message is shown to indicate that the 2nd call is ignored:

AbstractComponentRegistry.stop():

getLog().debugf("Ignoring call to stop() as current state is %s", this);


>> Cheers,
>> Sanne
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Sanne Grinovero-3
In reply to this post by Galder Zamarreno
> Hmmmm, not sure about the warn message. Surely a no-op and if it's no-op from the 2nd time onwards, what's the warning about?

My reasoning is that if you're starting caches multiple times, then
you're likely expecting Infinispan to support asymmetric clusters.

Many expect asymmetric clusters to just work, not all realize that
they are wrong until in a late development stage: it's obviously
unlikely that people test their application in cluster in its early
design phases.
This had bitten myself and it did no good to my project, and I still
think we're not making this limitation clear enough. A log is quite
likely going to be noticed, and I see no harm in it; users could save
a lot of time; I see no reason to not warn?

Cheers,
Sanne
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Galder Zamarreno

On Aug 4, 2011, at 5:06 PM, Sanne Grinovero wrote:

>> Hmmmm, not sure about the warn message. Surely a no-op and if it's no-op from the 2nd time onwards, what's the warning about?
>
> My reasoning is that if you're starting caches multiple times, then
> you're likely expecting Infinispan to support asymmetric clusters.

Hmmmmmmm, I see what you mean but I think this needs further baking. You're implying that if you do the following, "manik" cache could be started a different time:

cacheContainer.startCaches("galder", "sanne") -> starts galder and sanne
cacheContainer.startCaches("galder", "sanne") -> does nothing, why warn?
cacheContainer.startCaches("galder", "sanne", "manik") -> starts manik - yeah could be seen as asymmetric clusters - maybe this one should show a warning saying that "manik" was started at a different time to the other caches, and point to the docu...

>
> Many expect asymmetric clusters to just work, not all realize that
> they are wrong until in a late development stage: it's obviously
> unlikely that people test their application in cluster in its early
> design phases.
> This had bitten myself and it did no good to my project, and I still
> think we're not making this limitation clear enough. A log is quite
> likely going to be noticed, and I see no harm in it; users could save
> a lot of time; I see no reason to not warn?
>
> Cheers,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Starting caches in parallel

Sanne Grinovero-3
2011/8/4 Galder Zamarreño <[hidden email]>:

>
> On Aug 4, 2011, at 5:06 PM, Sanne Grinovero wrote:
>
>>> Hmmmm, not sure about the warn message. Surely a no-op and if it's no-op from the 2nd time onwards, what's the warning about?
>>
>> My reasoning is that if you're starting caches multiple times, then
>> you're likely expecting Infinispan to support asymmetric clusters.
>
> Hmmmmmmm, I see what you mean but I think this needs further baking. You're implying that if you do the following, "manik" cache could be started a different time:
>
> cacheContainer.startCaches("galder", "sanne") -> starts galder and sanne
> cacheContainer.startCaches("galder", "sanne") -> does nothing, why warn?
> cacheContainer.startCaches("galder", "sanne", "manik") -> starts manik - yeah could be seen as asymmetric clusters - maybe this one should show a warning saying that "manik" was started at a different time to the other caches, and point to the docu...

+1
you could check for that, even better user experience.

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev