He-Pin commented on PR #3681:
URL: https://github.com/apache/pekko/pull/3681#issuecomment-6382131482
I agree that the current built-in affinity dispatcher receives the raw
mailbox, so this override does not affect that path. My reason for retaining it
is to preserve the underlying Runnable’s affinity hash across fresh task
instances while keeping each task’s identity, completion, and cancellation
state independent.
A concrete use case is an internal executor-comparison POC using a common
task representation. `PekkoForkJoinTask` does not implement `Runnable`, so the
affinity side needs an adapter:
```java
PekkoForkJoinTask task = new PekkoForkJoinTask(work);
affinityPool.execute(new Runnable() {
@Override public void run() { task.invoke(); }
@Override public int hashCode() { return task.hashCode(); }
});
```
The task class is final and its wrapped Runnable is private with no
accessor. A consumer holding only the task cannot directly recover the original
Runnable’s hash. Delegation preserves that affinity hash through adaptation
without adding an unwrapping API or maintaining a separate mapping. If the
adapter also receives the original Runnable, it can of course preserve the hash
itself; the benefit here is for consumers given only the task.
A local routing POC using the real `FairDistributionHashCache`, four queues,
and a threshold of 128 produced these results for 300 submissions of one
logical Runnable:
| Routing hash | Queues used | Queue changes | Cache entries |
| --- | ---: | ---: | ---: |
| Original Runnable hash | 1 | 0 | 1 |
| Fresh task identity hash | 4 | 245 | 129 |
| Task hash delegated to the Runnable | 1 | 0 | 1 |
The identity-hash control used `System.identityHashCode(task)` to model the
inherited hash after removing the override. A separate execution probe
submitted 100 fresh tasks through the adapter to an actual `AffinityPool`: all
100 executed, the selector invoked the underlying Runnable’s hash 100 times,
and all submissions selected one queue.
This demonstrates a POC use case and the routing behavior; it does not
establish a throughput or latency improvement, or a regression in the current
built-in actor dispatch path. I would retain the override as an explicit
wrapper contract, with focused affinity coverage and the documented requirement
that the Runnable’s hash remain stable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
