Understand how ExecuteOnKeyOwner works

15 views
Skip to first unread message

Joan Balagueró

unread,
Nov 17, 2022, 1:26:30 PM11/17/22
to Hazelcast
Hello,

I'm executing "iExecutor.executeOnKeyOwner(Runnable, key)" within a synchronized method. The Runnable is an object that receives a 1Mb object that will be sent to the owner of the key.

My question is if this method  "iExecutor.executeOnKeyOwner(Runnable, key)" returns immediately and then the action to send the data over the network is performed on another thread.

The idea is not to block the synchrnonized method too much time since the load is very very high.

Thanks,

Joan.

Joe Sherwin

unread,
Nov 17, 2022, 2:45:07 PM11/17/22
to haze...@googlegroups.com
This is a blocking call. It will block until the owner acknowledges the receipt of your runnable and its associated payload. You can send data to Hazelcast asynchronously using map.putAsync or setAsync.  Then use a real-time pipeline job instead of the runnable to perform your logic on the key owner. https://docs.hazelcast.com/hazelcast/5.2/architecture/distributed-computing#tasks-concurrency-is-cooperative

"Since sometimes you can’t avoid making blocking calls, Hazelcast provides dedicated support for such cases. You should use the mapUsingService transform that allows you to declare your code as "non-cooperative". Hazelcast will adapt to this by running the code in a dedicated thread."

On Nov 17, 2022, at 12:26 PM, Joan Balagueró <joan.ba...@gmail.com> wrote:


--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/d430ee55-c932-40ce-b32c-5f30f51161adn%40googlegroups.com.

This message contains confidential information and is intended only for the individuals named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version. -Hazelcast

Joan Balagueró

unread,
Nov 23, 2022, 4:37:10 AM11/23/22
to Hazelcast
Thanks Zap,

But I'm using hazelcast 4.2 ... any alternative?

Joan.

Ahmet Mircik

unread,
Nov 23, 2022, 5:06:45 AM11/23/22
to haze...@googlegroups.com

Hi Joan,

submitToKeyOwner is async variant of executeOnKeyOwner. It may work for your use case.


Joe Sherwin

unread,
Nov 23, 2022, 11:08:31 AM11/23/22
to haze...@googlegroups.com
Joan... first, I highly recommend upgrading to 5.2.1, whether or not you will make use of pipeline jobs in your server-side processing. If you’re using Hazelcast in a client/server topology, your 4.2 clients should work against a 5.2.1 cluster.  As for alternatives, you could try creating a java executor services in your client to handle blocking calls. Additionally, add a shutdown hook to your client jvm to make sure all pending calls are completed before the jvm actually shuts down. You’ll see that this requires more advance coding without much hardened fault tolerance when compared to using a Hazelcast Pipeline job. Finally, some questions which will help evaluating your approach… What is the peak frequency which you’re expecting to make these calls in production? How many hazelcast nodes in your cluster? How many number of clients making these calls, or are you using an embedded design approach? See the sudo code below for the basics of designing your client to hand the submissions asynchronously...
—zap!

private static final ExecutorService blockingCallsPool = Executors.newFixedThreadPool(THREAD_COUNT);
private static void shutdownBlockingCallsPool() {
   try{
	blockingCallsPoool.shutdown();
	while(!blockingCallsPool.isTerminated()) {
//wait until all tasks are completed,or use awaitTermination() & a timeout value
}
    }catch(Throwable t){
      t.printStackTrace();
      Thread.currentThread.interrupt();
    }
}
private void attachShutDownHook(){
Runtime.getRuntime().addShutdownHook(new Thread(){
@Override
public void run() {
if(blockingCallsPool != null){
shutdownBlockingCallsPool();
}
}

});
}
public void submitWorkToHzDistributedExecutorService(Runable task, Object key){
blockingCalls.submit(new Thread(){
@Override
public void run() {
         if(key != null){
           	hzIExecutorHandle.executeOnKeyOwner(task, key)
      	}
      }

});
}


On Nov 23, 2022, at 4:37 AM, Joan Balagueró <joan.ba...@gmail.com> wrote:

Thanks Zap,
Reply all
Reply to author
Forward
0 new messages