CODEWITHSUNDEEP
javahazelcast
Anusha Pachunuri
Anusha Pachunuri

Reputation: 1419

Is it recommended to use ExecutionCallBacks for distributed executor service - hazelcast

I observed that there is some latency involved in collecting results of the tasks submitted to the IExecutorService . This is only in the context of trying to collect results in the form of futures, by using the submit(Callable task) inherited from ExecutorService..I also found that the performance is good when you collect results via asynchronous callbacks. Considering futures are asynchronous too, i am trying to understand why there is a lag in retreiving results.Is it something specific to the way hazelcast works?

Also, if i am using submit(Callable task, ExecutionCallback callback) , what kind of behaviour should i expect? Should i expect that it randomly picks one member to execute on and with or without load balancing?

Edit:Updating question with some sample code . I am storing futures in the collection and retrieving it later.But when the main thread keeps on reading the future values,i see a delay when compared to the asynchronous callbacks.

final IExecutorService executorService = hz.getExecutorService("default");
                List<Future<String>> list = Lists.newArrayList();
                for (int i = 0; i < 100; i++) {
                    final Future<String> f = executorService.submit(new Echo(" " + i));
                    list.add(f);
                }
                System.out.println();
                for (Future<String> f : list){
                    System.out.println(f.get());
                }

as opposed to

final IExecutorService executorService = hz.getExecutorService("default");
            final List<String> list = Lists.newArrayList();
            final Stopwatch stopwatch = Stopwatch.createStarted();
            for (int i = 0; i < 100; i++) {
                executorService.submit(new Echo(" " + i), new ExecutionCallback<String>() {

                    @Override
                    public void onResponse(String response) {
                        System.out.println(response);
                        list.add(response);
                        if(list.size() == 100){
                            stopwatch.stop(); // optional
                            long millis = stopwatch.elapsed(TimeUnit.MILLISECONDS);
                            System.out.println("time taken to complete is: "+millis);
                        }
                    }

                    @Override
                    public void onFailure(Throwable t) {
                        t.printStackTrace();
                    }
                });

Upvotes: 1

Views: 1631

Answers (1)

pveentjer
pveentjer

Reputation: 11307

Difficult answer :)

When you immediately do a future.get after you do a submit, you don't give the threads a chance run but they will be blocking much of the time. When you first do a whole bunch of submits and store the futures in a collection, I guess you get similar performance to the async execution. This way submitting operations won't block on completion, and also the worker threads don't block on the queue because the queue is filled with operations. So you get a lot better throughput.

I'm working on a reactive API for Hazelcast based on the CompleteableFuture of Java 8, so you can register your callback directly on the future. Eventually the submit with callback is going to be dropped.

And I'm also working on a new OperationService implementation; the 'engine' of Hazelcast that is responsible for the actual execution of operations. I'm playing with all kinds of optimization, like the caller-runs optimization that prevents all the regular overhead of operation queueing. This is also very tighly integrated with the futures and I want to squeeze a lot more out of the performance; especially for local calls.

[edit] It will just randomly select a member in the cluster. If you want loadbalancing, you need to figure out which member is the best target for a task, and then send using 

void submitToMember(Runnable task, Member member, ExecutionCallback callback);

Upvotes: 3

Related Questions