I'm talking about real case [1]. User actually doesn't care about
difficulties of connection establishing or if message wasn't sent. But
now he has to manually resolve such case. Why not to use existing async
mode here?
-Dmitry.
[1]
http://apache-ignite-users.70518.x6.nabble.com/ignite-messaging-disconnection-behaviour-td11218.html#a11418
24.03.2017 21:10, Valentin Kulichenko пишет:
I believe it can be blocked if connection can't be established (i.e. socket
can't be opened within a timeout). But I don't think that it makes much
sense to add async support because of this. Also it would be very confusing
as actual send is always asynchronous.
-Val
On Fri, Mar 24, 2017 at 9:10 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
I am a bit confused. The "send()" method does not wait for any replies, why
would it block?
On Fri, Mar 24, 2017 at 2:38 AM, Dmitry Karachentsev <
dkarachent...@gridgain.com> wrote:
Hi Igniters!
We have in IgniteMessaging interface async support, and it's used only
for
registering/deregistering listeners, not for message sending. But user
may
fall into the case, when connection to destination node was lost and
user's
thread is blocked on IgniteMessaging.send()/sendOrdered() methods till
failureDetectionTimeout is up.
I think, it may be a good idea to support async mode for sending messages
(and probably without creating separate future for each message).
What do you think?
Thanks!
Dmitry.
