Vova,
Are we notifying listeners that a message has been sent? I thought that you
were talking about reply notifications.
D.
On Fri, Oct 16, 2015 at 2:13 AM, Vladimir Ozerov
wrote:
> Dima,
>
> If user call IgniteMessaging.send() in the thread T1, then local message
> listeners on this topic wi
Dima,
If user call IgniteMessaging.send() in the thread T1, then local message
listeners on this topic will be notified in the same thread before
returning from send() method. This our pseudo-code:
IgniteMessaging.send(Object topic, Object msg) {
...
sendToRemoteNodes(topic, msg);
...
On Thu, Oct 15, 2015 at 11:00 PM, Vladimir Ozerov
wrote:
> Sorry, not very clear. "same" means the same thread that sent a message.
> This way if we have a listener and a single thread generating messages
> locally, only one CPU core will be utilizied.
>
Still confused. How can the thread that s
Sorry, not very clear. "same" means the same thread that sent a message.
This way if we have a listener and a single thread generating messages
locally, only one CPU core will be utilizied.
On Fri, Oct 16, 2015 at 3:49 AM, Dmitriy Setrakyan
wrote:
> On Thu, Oct 15, 2015 at 9:59 AM, Vladimir Ozer
On Thu, Oct 15, 2015 at 9:59 AM, Vladimir Ozerov
wrote:
> Folks,
>
> It looks like the problem is deeper and is not limited to futures. It
> relates to any user code. For example:
>
> 1) Register either local or remote message listener:
> Ignite.message().localListen("myTopic", myLsnr);
>
> 2) Se
Folks,
It looks like the problem is deeper and is not limited to futures. It
relates to any user code. For example:
1) Register either local or remote message listener:
Ignite.message().localListen("myTopic", myLsnr);
2) Send a message to the topic from the same node:
Ignite.message().send("myTo
On Mon, Oct 12, 2015 at 9:39 AM, Vladimir Ozerov
wrote:
> It would be cool, but CompletableFuture is available since Java 8.
>
Well, we could add some methods from CompletableFuture to IgniteFuture
then. I will take a look and suggest a few.
>
> On Mon, Oct 12, 2015 at 7:25 PM, Dmitriy Setraky
It would be cool, but CompletableFuture is available since Java 8.
On Mon, Oct 12, 2015 at 7:25 PM, Dmitriy Setrakyan
wrote:
> Would it be possible for us to support CompletableFuture from Java instead
> of adding one-off methods?
>
> On Mon, Oct 12, 2015 at 6:53 AM, Vladimir Ozerov
> wrote:
>
Would it be possible for us to support CompletableFuture from Java instead
of adding one-off methods?
On Mon, Oct 12, 2015 at 6:53 AM, Vladimir Ozerov
wrote:
> Yakov, two points there:
>
> 1) This is a matter of convenience. Current mainstream solution for similar
> tasks is Java's CompletableFu
Yakov, two points there:
1) This is a matter of convenience. Current mainstream solution for similar
tasks is Java's CompletableFuture. Here is what it offers:
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#runAsync-java.lang.Runnable-
https://docs.oracle.com
Not sure if I get the point. You can do exactly the same inside your
listener.
final Executor executor = ...;
// Bla-bla
cache.future().listen(() => {
executor.execute(new Runnable() {
latch.await();
/** Do something useful. */
}
});
--Yakov
2015-10-09 17:22 GMT+03:00 V
t: Friday, October 9, 2015 4:22 PM
> Subject: Which thread is used to run IgniteFuture continuations?
> To:
>
>
>Igniters,
>
> We are missing an ability to specify which thread should run continuation
> routine when future is completed.
>
> Curre
Excellent idea! +10
PS. Got burnt by this a few times already
_
From: Vladimir Ozerov
Sent: Friday, October 9, 2015 4:22 PM
Subject: Which thread is used to run IgniteFuture continuations?
To:
Igniters,
We are missing an ability to
Igniters,
We are missing an ability to specify which thread should run continuation
routine when future is completed.
Currently we either run routine in the callee thread or in completion
thread (usually system pool thread). It means user cannot have any blocking
or cache operations inside the co
14 matches
Mail list logo
