ed in-order, despite
the asynchronous execution of the callback. Without such guarantee, the
applicability of the async callback feature would be very limited.
Thanks
Andrey
> Date: Tue, 29 Mar 2016 19:22:50 +0300
> Subject: Re: API for asynchronous execution.
> From: ntikho...@gridgain
Agree. Let’s use the annotation approach. However, annotation can be easily
missed, so we should make sure we document it with examples, and javadoc it
with examples.
D.
On Mon, Apr 18, 2016 at 5:39 AM, Nikolay Tikhonov
wrote:
> Dima,
> We have also JCache API which allow register/deregister co
Dima,
We have also JCache API which allow register/deregister continuous query
javax.cache.Cache#registerCacheEntryListener(CacheEntryListenerConfiguration)
and we can't change it.
I think that annotation looks better for consistency both API.
On Mon, Apr 18, 2016 at 7:26 AM, Dmitriy Setrakyan
wr
Instead of the Async annotation, why not just have a setter
“setAsyncFilter(true)”?
D.
On Fri, Apr 15, 2016 at 4:33 AM, Nikolay Tikhonov
wrote:
> Yakov is right. Benchmarks show performance drop 3-8% when using
> asynchronous callbacks.
>
> On Fri, Apr 15, 2016 at 11:34 AM, Yakov Zhdanov
> wro
Yakov is right. Benchmarks show performance drop 3-8% when using
asynchronous callbacks.
On Fri, Apr 15, 2016 at 11:34 AM, Yakov Zhdanov wrote:
> I am pretty sure that making all filter notifications asynchronous will
> terribly affect performance. I would leave it only for cases when some
> com
I am pretty sure that making all filter notifications asynchronous will
terribly affect performance. I would leave it only for cases when some
complex processing needs to be done involving, for example, cache
operations. If filter is simple then I would leave it sync (by default).
--Yakov
2016-04
Nick,
Can you explain why we would ever want to have a synchronous callback?
Aren’t all filter notifications supposed to be asynchronous, especially if
there is no performance degradation?
D.
On Thu, Apr 14, 2016 at 11:17 AM, Nikolay Tikhonov
wrote:
> The following code snippet show how make a
, April 14, 2016 21:17
To: dev@ignite.apache.org
Subject: Re: API for asynchronous execution.
The following code snippet show how make asynchronous filter in continuous
query. Difference in configuration between sync and async filters just in
annotation on class.
IgniteCache cache
The following code snippet show how make asynchronous filter in continuous
query. Difference in configuration between sync and async filters just in
annotation on class.
IgniteCache cache = ...;
ContinuousQuery qry = new ContinuousQuery();
qry.setRemoteFilterFactory(FactoryBuiler.factoryOf(Filt
Do we have a coding example for this functionality somewhere? It would be
nice to review the changes from usability standpoint.
On Thu, Apr 14, 2016 at 3:58 AM, Nikolay Tikhonov
wrote:
> We are close to completing IGNITE-2004 ticket.
> As part this ticket was made the following changes on public
We are close to completing IGNITE-2004 ticket.
As part this ticket was made the following changes on public API
- if callback has @IgniteAsyncCallback annotation then callback should be
run asynchronously
- these callbacks are executed in special pool (callback thread pool) which
is configured by I
I think this approach works unless user does not initiate number of
concurrent cache operations greater than MSG_QUEUE_SIZE. Where msg queue
size default is 1024, but still configurable.
Thanks!
--
Yakov Zhdanov, Director R&D
*GridGain Systems*
www.gridgain.com
2016-03-30 11:44 GMT+03:00 Vladimi
Does it mean that if cache update rate is greater than filter execution
rate, then at some point we will stop reading messages from socket? If yes,
then it seems we still cannot execute cache operations:
1) Filter starts cache operation for a key. Current node is backup for this
key.
2) Cache messa
Vladimir,
Communication should stop reading from connection is there are too many
unprocessed messages. Sender will be blocked on putting message to queue.
--Yakov
2016-03-30 11:11 GMT+03:00 Vladimir Ozerov :
> Guys,
>
> Can you explain how backpressure control is implemented? What if event
> a
Guys,
Can you explain how backpressure control is implemented? What if event
arrival speed is greater than filter processing speed?
On Wed, Mar 30, 2016 at 10:37 AM, Semyon Boikov
wrote:
> Andrey,
>
> I agree that current situation with threading in Ignite is very
> inconvenient when user callb
Andrey,
I agree that current situation with threading in Ignite is very
inconvenient when user callbacks execute some non-trivial code. But
changing this to async dispatch is huge refactoring, even changing this
just for continuous queries callback is not so easy task.
We can start with https://i
Vladimir, Igniters
Here are my 2 cents.
The current situation with threading when it comes to executing user callbacks
-- the CQ filters (either local or remote), the CQ listeners, the event
listeners, the messaging listeners, the entry processors (did I miss anything?)
-- is pretty sad. The
Vova,
1) As far as I remember, we enforce ordering of updates for the same key,
> right? If yes, then stalled filter invoke for update #1 will stall all
> further updates.
>
Invocation of filter will be implemented in thread-partition style for
supporting ordering of updates.
> 2) Listener noti
Nick,
I hardly can image why user would like to have async entry processor
provided that we already have IgniteCache.withAsync(). Moreover, usually
this method is invoked while holding lock on entry, so it doesn't seem to
be a valid use case (plus remember about unwrap() method). Though, may be I
This approach works for cases when callback will be invoked on local node
(cache future, local listener and etc), but how user set a thread pool when
callback executed on remote nodes (remote filter, entry processor and etc)?
On Tue, Mar 29, 2016 at 2:57 PM, Vladimir Ozerov
wrote:
> We already h
We already had discussion about it several months ago. Normal practice is
to allow user specify thread pool where he would like to execute the
callback. This is how things work in JDK CompletableFutures and Hazelcast
futures, and this is the most flexible approach.
On Tue, Mar 29, 2016 at 2:23 PM,
Hello Igniters,
Lately I'm working on a ticket
https://issues.apache.org/jira/browse/IGNITE-2004. As part of the ticket
need to add API which will provide an ability to execute operation
asynchronously. The ability might be useful not only for continuous query
filter but also for cache and discove
22 matches
Mail list logo
