Re: Ignite Affinity & Binary Configuration Issues
Hi Addo,
There is no need to explicitly specify IdentityResolver. On marshaling step,
hash code is got from object and recorded in BinaryObject, and it will be
used for any affinity mapping, e.g. affinity run. Use IdentityResolver if
you need customize hash code calculation, f.e. exclude some fields or in
case of using BinaryObjectBuilder. So you may remove custom
BinaryConfiguration.
Ignite tries to avoid redundant serialization/deserialization, and for
proper work there is no need to do it. According to this rule Ignite passes
BinaryObject in AffinityKeyMapper. You don't need to deserialize the whole
object, it's enough to read just required field:
if (CacheKeyOne.class.getName().equals(bo.type().typeName()))
return bo.field("key");
You should avoid using other marshalers, because BinaryMarshaller is highly
optimized for use in Ignite.
-Dmitry.
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Affinity-Binary-Configuration-Issues-tp11897p11933.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Ignite Affinity & Binary Configuration Issues
Hello Igniters,
As we've been trying to utilize Ignite, some issues were identified which
did not seem logical at first sight. When we introduced data and compute
collocation (affinity), there were some "hacks" and "tweaks" that were
needed so that it would function properly. I will first delineate the
scenarios which resulted in the odd behavior.
The following scenarios assume you have :
* 2 Ignite server nodes (S1 and S2)
* A client node (C1)
* A cache:
--- Custom affinity key mapper
--- Cache mode partitioned
--- Write synchronization set to primary sync
* A key (K1) to-be-stored and its value in the cache is 1 { .put(K1, 1) }
--- K1 is a simple POJO (3 fields as String, 1 field as a primitive int)
Scenario #1 - Binary Configuration
- Get or create cache via C1
- Put K1 with a value of 1
- Affinity run on cache with K1 as the affinity key
- Ignite node where K1 is stored could not find key in its cache (the
partitions it owns)
Solution to #1 - Explicitly define a binary configuration to the POJO
Scenario #2 - Affinity Key Mapper
- Add a custom affinity key mapper that points to a String field in K1
- Run scenario #1 again
- Affinity run on cache with K1 could not find the key in the node chosen
Solution to #2 - Add a condition in the key mapper of when the key is a
Binary Object
We've found that, at some point, the cache was calling its affinity key
mapper on a Binary Object (and our first implementation did not take that
into account).
The questions that we're trying to answer:
1. Shouldn't ignite handle POJO affinity keys out-of-the-box?
2. Do I have to modify my binary configuration every time I need to use a
new POJO as an affinity key?
3. Does switching the serialization framework to something like Kryo solves
this automatically?
4. What other options can we have to solve this?
Thank you for your time and effort in reading this long (and hopefully
interesting) post. We'll be looking forward to your replies. Please find
*attached* the code to reproduce the issues.
Kind regards,
Addo
ignite-samples.rar
<http://apache-ignite-users.70518.x6.nabble.com/file/n11897/ignite-samples.rar>
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Ignite-Affinity-Binary-Configuration-Issues-tp11897.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
