issues with partition operations

[Ryan Lee]

Hello,

I would like some support with the management of partition-aware operations. I am not able to see use of partition-operation threads within eclipse debugger (see attached images). Only ForkJoinPool workers are ever used.

This is applicable to the following operations:

1. map.submitToKey(strategyId, new TriggerUpdateEntryProcessor(update)): This is using a Offloadable implementation (but not readonly) therefore should be processed in blocking mode, but it does not.
2. executorService.executeOnKeyOwner(triggerUpdateTask, strategyId): It’s also meant to be possible to submit a partition-aware task https://docs.hazelcast.com/imdg/4.2/performance/data-affinity#partitionaware but this doesn’t work either.

Also, regardless of submitTo or executeOn, both act the same.

Should I see threads running under partition-operations? Is this a configuration issue.

I am assuming that executorService functionality is correct in that it’s only partition-aware in terms of running the thread on the right member but not running on a partition-operation thread, though would still expect it to run on a generic-operation thread.

This is confusing in the documentation as there are limited examples of partition operations and “partition” it seems is used to refer to both literal partition threading and member location.

• The only examples are IMap.get is and executor.submitToMember is not. But executor also has submitToKeyOwner so will get processed on the right partition but will it be by that member's generic-operation thread instead of partition-operation...
• Data Affinity topic states "Data affinity ensures that related entries exist on the same member. If related data is on the same member, operations can be executed without the cost of extra network calls and extra wire data. This feature is provided by using the same partition keys for related data."

[Ryan Lee]

Sorry i cannot currently add attachements...

[Ryan Lee]

This has been answered here: https://stackoverflow.com/questions/73884972/hazelcast-not-using-its-own-partition-operations-threads-resulting-in-lack-of-o

The help text guidance at https://docs.hazelcast.com/imdg/4.2/computing/entry-processor#offloadable-entry-processor seems a little misleading but if that's how it actually works then i can work with that.

[Ryan Lee]

Just to add:

The documentation here: https://docs.hazelcast.com/imdg/4.2/computing/entry-processor#offloadable-entry-processor states: "Offloading unblocks the partition thread allowing the user to profit from much higher throughput. The key is locked for the time span of the processing in order to not generate a write conflict."

So there must be something wrong?

[Ryan Lee]

After further investigation, I realised that where I had the breakpoint, that this was at the end of a cascade of async calls, post entry processing thread hence ultimately ended up on worker threads.

So with the breakpoint in the correct place, and the removal of Offloadable, i then see in the debugger the use of the partition thread.

However, when using Offloadable, the threading uses a hz cached.thread, but does still block on the key! By placing a thread.sleep in there i can see that it does indeed block on the key.

So, the docs do tie up with the operation.