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.
