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. There are several interesting issues:
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)! 2) Why no problem is met when Node B matches the node filter? -- 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-tp14179p14308.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.
