Changes are ready for review:
https://issues.apache.org/jira/browse/IGNITE-14187
https://github.com/apache/ignite/pull/8847
On Tue, May 18, 2021 at 12:03 PM Igor Sapego wrote:
> Pavel,
>
> +1 from me for a stateless approach. We could definitely invent something
> here to make a stateful
Pavel,
+1 from me for a stateless approach. We could definitely invent something
here to make a stateful approach working but that would make this feature
too complex and error-prone, IMO. It makes sense to file an improvement
ticket with benchmark results and maybe code draft if we decide to
Igniters,
I've implemented a "stateful" approach (see IEP) in .NET Thin Client:
client-side flush adds data to server-side streamer, but does not flush it
immediately.
It provides ~35% perf improvement over stateless approach (where every
client request opens a new streamer, adds data, closes
Alex,
I did not include this for two reasons:
1) Existing thick API behavior is very confusing and counter-intuitive:
it returns a Future that won't complete unless you call more APIs.
I've seen multiple users doing this:
await streamer.Add(1, 1);
await streamer.Add(2, 2);
This code hangs -
Pavel,
IEP looks good to me overall. I have only one concern: currently, for thick
client "add" method we return the future which completes when the current
batch is actually added to the cache, even if "flush" method is not invoked
explicitly. For thin client with the proposed protocol we can't
Agree, this is completely offtopic here.
пт, 5 мар. 2021 г. в 17:02, Pavel Tupitsyn :
> > custom DSL
> This is a topic for 3.0 - would you like to start a separate thread?
>
> On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky
> wrote:
>
> > I suppose, that the best variantl -- custom DSL similar
> custom DSL
This is a topic for 3.0 - would you like to start a separate thread?
On Fri, Mar 5, 2021 at 4:54 PM Ivan Daschinsky wrote:
> I suppose, that the best variantl -- custom DSL similar to MongoDB query
> language.
> I understand that implementing this is much harder, but users want
I suppose, that the best variantl -- custom DSL similar to MongoDB query
language.
I understand that implementing this is much harder, but users want this
variant.
пт, 5 мар. 2021 г. в 16:52, Pavel Tupitsyn :
> > I suppose this is of questional usability, same for existing
> > implementation for
> I suppose this is of questional usability, same for existing
> implementation for ScanQuery and ContinousQuery
One way or another, we need to be able to run custom logic
on the server side from thin clients.
Our current direction can be seen as "Java is our DSL":
write server-side logic in
>>> - Corresponding types should exist on server nodes
Ok, but I suppose this is of questional usability, same for existing
implementation for ScanQuery and ContinousQuery.
For queries it's probably ok to add some custom filters and put them in
servers' classpathes, but I can hardly imagine
> How do you suggests to serialize this object?
Like a normal binary object. This scenario already exists for ScanQuery and
ContinuousQuery filters.
- It works for Java and .NET; potentially for other platforms
- Corresponding types should exist on server nodes
E.g. if a Java class `MyFilter {
I also suppose, that closing should be done wia OP_RESOURCE_CLOSE. It'is
more consistent and resembles with existing cursor api.
пт, 5 мар. 2021 г. в 15:37, Ivan Daschinsky :
> >> Both proposed requests have a Flush flag - please see Details sections
> in the IEP.
> Ok, sorry, I missed this.
>
>> Both proposed requests have a Flush flag - please see Details sections
in the IEP.
Ok, sorry, I missed this.
>> StreamReceiver is public API [1]
I know it. But this "object" should contains custom logic for putting data
in cache. How do you suggests to serialize this object?
Implement custom
Ivan,
> Receiver is mostly internal stuff
StreamReceiver is public API [1]
> STREAMER_FLUSH_REQUEST should be added too
Both proposed requests have a Flush flag - please see Details sections in
the IEP.
When user code calls client-side Flush method, we send the current
client-side batch with
IMHO, also STREAMER_FLUSH_REQUEST should be added too. Client can flush
large batches instead of closing resource.
IMHO this is preferable than creating streamer per batch.
пт, 5 мар. 2021 г. в 14:48, Ivan Daschinsky :
> Pavel, thank you for your effort.
>
> BTW, are you sure that receiver
Pavel, thank you for your effort.
BTW, are you sure that receiver should be a param of STREAMER_START_REQUEST?
Receiver is mostly internal stuff and I can hardly imagine why
someone would decide to change defaults.
пт, 5 мар. 2021 г. в 13:01, Pavel Tupitsyn :
> Igor,
>
> As per our private
Igor,
As per our private conversation, I'll try to provide some perf measurements
for those 4 variants, and more detailed descriptions too.
Thanks!
On Fri, Mar 5, 2021 at 12:55 PM Igor Sapego wrote:
> Pavel,
>
> I've checked the IEP and I like it. The only thing that seems a bit
> confusing
Pavel,
I've checked the IEP and I like it. The only thing that seems a bit
confusing to me
is that there are 4 different variants for clients but there are cons and
pros for
different variants. Maybe at least few sentences should be written here to
give developers who are not familiar with
Igniters,
Please review the IEP [1] and let me know what you think.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-68%3A+Thin+Client+Data+Streamer
19 matches
Mail list logo
