ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Wilson <raymond_wil...@trimble.com>
Subject Re: Custom Affinity Functions proposed for removal?
Date Wed, 04 Nov 2020 20:11:36 GMT
We actually use different mappers assigned to different caches using the
same source key, eg:

public class Key

public class AffinityFunctionOne : IAffinityFunction
  public int GetPartition(object key)
    return PartitionHash((object as Key).p)

public class AffinityFunctionTwo : IAffinityFunction
  public int GetPartition(object key)
    return PartitionHash((object as Key).x, (object as Key).y)

On reviewing this code I see we do actually perform the AssignPartitions()
step as this is a required aspect of implementing the IAffinityFunction
interface, but this is not necessary for our application. This is just a
round robin assignment of partitions to nodes in
the AffinityFunctionContext.CurrentTopologySnapshot list of nodes
participating in the cache the key is for.


On Thu, Nov 5, 2020 at 4:54 AM mnk <moti.nisenson@gmail.com> wrote:

> For our case, we have a stateful instance associated with each user
> session,
> that actually handles user requests. That stateful instance is usually
> long-lived. In this case, we want the data for that instance to be stored
> on
> other nodes - at the dispatch stage, we choose a node to host the session
> such that it isn't in the primary or backup nodes for the selected
> partition. In the case we lose that node, we can always recover our state
> on
> a new node from the data stored.
> Short-lived case is less interesting... in this case we dispatch to the
> primary node and thus there is affinity for doing the replay.
> Due to limitations in how cache groups work (whereby new caches still
> result
> in PME), we have our own implementation there for storing logically
> separated data in the same cache - we then have a garbage cleanup phase
> which can evaluate expired/terminated sessions and clean out the cache.
> That
> process is all done locally - in other words, a primary node is able to
> determine which sessions need cleaning and clean out the data all locally.
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message