Mailing-List: contact user-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@ignite.apache.org
Date: Wed, 5 Jul 2017 13:31:56 -0700 (MST)
From: vkulichenko <valentin.kulichenko@gmail.com>
To: user@ignite.apache.org
Message-ID: <1499286716982-14347.post@n6.nabble.com>
In-Reply-To: <1499158119109-14308.post@n6.nabble.com>
References: <1498827962798-14179.post@n6.nabble.com> <1498846287176-14185.post@n6.nabble.com> <1499091350952-14272.post@n6.nabble.com> <1499118833664-14289.post@n6.nabble.com> <1499158119109-14308.post@n6.nabble.com>
Subject: Re: NodeFilter for cache and GridDhtPartitionsExchangeFuture
 (Failed to wait for partition release future)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
archived-at: Wed, 05 Jul 2017 20:32:01 -0000

Hi Vladimir,


Vladimir wrote
> Node B must know wheter the cache is already created. If not it must not
> start to avoid such runtime problems. That's why the cache is acquired at
> the initialization. That looks like reasonable and comfortable way.

What is the exact scenario when cache is not available? If this means
absence of node A, then you can lose after initialization of B, so I believe
you have the issue anyway. It all boils down to proper API use and exception
handling. I would recommend to use Ignite#getOrCreateCache method and handle
exceptions that can be thrown by cache operations (for example, if there are
no server nodes left). In addition, it sounds like node B can be a client
which eliminates a requirement to have a node filter.


Vladimir wrote
> 1) Why does node B acquire that cache store bean? This node does not hold,
> service and create cache due to the node filter. Note that this node
> doesn't even have the cache config. Node B is supposed to seldom use the
> cache as a remote source without working directly with the database. I was
> forced to create properly named datasource bean only to satisfy the
> requirement which actually relates to other node (Node A)!

Cache store initialized on all nodes including clients. In current
implementation this is actually required only for transactional caches, but
all caches are still processed in the same way for consistency. So this is
correct behavior.


Vladimir wrote
> 2) Why no problem is met when Node B matches the node filter?

This sounds weird, I think there is some other factor that we're missing.
Can you create a simple GitHub project that reproduces this behavior and
share it with us?

-Val


--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/NodeFilter-for-cache-and-GridDhtPartitionsExchangeFuture-Failed-to-wait-for-partition-release-future-tp14179p14347.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.