HazelcastInstance.getMap() - does it block for I/O?

[Frederico Ferro Schuh]

Hi,

I can't find any documentation about this, does calling getMap() in a cluster cause my current thread to block and wait for I/O?

I'm wondering if getMap() performs any communication with the other nodes, which would certainly cause my thread to block in that case.

Can anyone confirm this? 

And if that is the case, would it be possible to call getMap() asynchronously?

Thanks!

Fred

[Ahmet Mircik]

Hi, 

Depends on the configuration. For example, if you configure a map-store with EAGER mode, getMap() blocks current thread till the end of data loading in whole cluster. Or if you have entry-listeners, registering them to cluster may take time.

But in common case, getMap should not do any other blocking operation

Currently no out-of-the-box way to call getMap() asynchronously.

--
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 post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/c6c1fc34-24b9-4d5b-8d46-11fcdad1765e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ih...@hazelcast.com]

In addition to what Ahmet wrote, if you are doing this on a client, the client communicates with the cluster to create a proxy if it is the first time this map is being used, and this communication is blocking but usually this is a fast operation.

[Frederico Ferro Schuh]

Thanks for the insight on this question.

From the looks of it, all IMap operations block for I/O one way or another, even if sometimes it's a fast operation that only happens once, such as getMap().

Still, it would be better if we could have more control over this behavior.

In fact, I think IMap should have a fully synchronous API, as it has been originally. 

Over time, we've been getting some async methods added to IMap, but to get full async behavior a lot more will need to be added, which will effectively become a duplication of the whole IMap interface.

Instead of adding a few async methods here and there, a fully asynchronous API on a different interface would be a more convenient choice IMHO.

That way we'd have the power to choose whether to work in a non-blocking way, and it would simplify an already growing IMap interface for blocking users.

Something along the lines of AsyncAtomicLong... my guess is that we'll get an AsyncIMap soon? :)

Here's hoping that we get a fully asynchronous API for IMap in the future.