gt;
> > >> > That said, I don't think that banning something is productive. At
> the
> > >> same
> > >> > time, we should make sure we pay more attention to performance
> during
> > >> > reviews. Maybe we s
with comparison of binary objects in 2.x
>
> Best Regards,
> Igor
>
>
> On Thu, Sep 9, 2021 at 4:04 PM Pavel Tupitsyn
> wrote:
>
> > Igniters,
> >
> > Tuple in Ignite 3.x is a replacement for BinaryObject in Ignite 2.x.
> > Let's discuss equality and sor
+1
Downloaded binary packages, started a cluster with a few nodes, tested new
.NET examples.
On Mon, Sep 13, 2021 at 11:21 AM Zhenya Stanilovsky
wrote:
>
>
> Thanks Maxim !
> I tries to compare this ver with 2.10 (some performance tests with
> persistence and transactional\atomic payload) and
e this API in Java. In other
> > > languages, however, we can consider this.
> > >
> > > -Val
> > >
> > > On Thu, Sep 9, 2021 at 8:01 AM Alexei Scherbakov <
> > > alexey.scherbak...@gmail.com> wrote:
> > >
> > > > Pave
a. In other
> languages, however, we can consider this.
>
> -Val
>
> On Thu, Sep 9, 2021 at 8:01 AM Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Pavel,
> >
> > I think the current API looks more natural compared to your proposal.
> >
&g
Igniters,
Tuple in Ignite 3.x is a replacement for BinaryObject in Ignite 2.x.
Let's discuss equality and sorting.
- We have multiple Tuple implementations, and our API allows custom,
user-defined Tuples as well (which can be useful for performance when
bridging Ignite with another system or
Igniters,
I propose to replace Map with List in getAll and invokeAll, and
Iterable in putAll APIs of Ignite 3.x KeyValueView.
1. Performance
putAll simply iterates over the map, we can easily accept Iterable instead.
Iterable can be implemented over anything, it can lazily read data from a
file
wrote:
> >> You can mix them easily.
> This is far from easily (you have already mentioned continuation problem),
> but for i.e. in python it is absolutely not.
> For kotlin it is a little bit easier, but also not fluent and a little bit
> ugly.
>
> чт, 9 сент. 2021
[1] --
> https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d
>
> ср, 8 сент. 2021 г. в 22:33, Pavel Tupitsyn :
>
> > To put it another way:
> > - true sync operation completes by itself
> > - sync-over-async operation requires another thread to compl
To put it another way:
- true sync operation completes by itself
- sync-over-async operation requires another thread to complete
On Wed, Sep 8, 2021 at 10:15 PM Pavel Tupitsyn wrote:
> Val,
>
> That's exactly what I have in mind.
> Yes, we block the user thread, but then we sh
>
> Am I wrong? Or you have a different implementation in mind?
>
> -Val
>
> On Wed, Sep 8, 2021 at 12:50 AM Pavel Tupitsyn
> wrote:
>
> > Val,
> >
> > Agree with your points.
> >
> >
> > > async API should be primary
> >
> &g
Orlov
> > > >> >
> > > >> >
> > > >> > > On 8 Sep 2021, at 12:23, Ivan Bessonov
> > > wrote:
> > > >> > >
> > > >> > > Hello Igniters,
> > > >> > >
> > > >> > &
must be used cautiously, developers should know whether they
> > write hot methods or not. And if methods are not hot, code simplicity
> must
> > be
> > the first priority. I don't want Ignite 3 code to look like Ignite 2
> code,
> > where
> > people would iterate o
Igniters,
Java streams are known to be slower and cause more GC pressure than an
equivalent loop.
Below is a simple filter/map/reduce scenario (code [1]):
* Benchmark Mode Cnt
Score Error Units
* StreamVsLoopBenchmark.loopSum
Val,
Agree with your points.
> async API should be primary
It should be noted that all our APIs are inherently async,
because thin client is implemented asynchronously.
> with the sync version build on top
We should document somehow that sync APIs are based on async ones,
because this may
/browse/IGNITE-15430
[3] https://issues.apache.org/jira/browse/IGNITE-15431
On Mon, Sep 6, 2021 at 10:02 PM Pavel Tupitsyn wrote:
> Val,
>
> Would you like me to start the discussion about sync-over-async in Ignite
> 3 Java APIs, or do you plan to do it yourself?
>
> On Fri, Sep 3
he IEP and the public API - looks good to me.
> > >
> > > Quick question - do you plan to add sync methods to the interfaces, or
> > > you're thinking to only leave async? If the latter, what are the
> > arguments
> > > for this? The reason I'm
r at least having a discussion about
> this).
>
> -Val
>
> On Thu, Sep 2, 2021 at 10:08 AM Pavel Tupitsyn
> wrote:
>
> > Igniters,
> >
> > Please review the IEP [1] and the PoC [2] for .NET Thin Client in Ignite
> > 3.0.
> >
> > [1]
> &g
Igniters,
Please review the IEP [1] and the PoC [2] for .NET Thin Client in Ignite
3.0.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-78+.NET+Thin+Client
[2] https://github.com/apache/ignite-3/pull/306
y someone will use it. For example, if I use micronaut or
> spring,
> > this dependency will make me angry
> >
> > сб, 21 авг. 2021 г., 16:13 Pavel Tupitsyn :
> >
> > > Ivan, the purpose is to be able to configure thin client with HOCON.
> > >
> >
21 авг. 2021 г., 13:32 Pavel Tupitsyn :
>
> > Igniters,
> >
> > I'd like to discuss Java thin client configuration API in Ignite 3.0.
> >
> > On one hand, it would be nice to use codegen approach from
> > ignite-configuration module,
> > and ha
Igniters,
I'd like to discuss Java thin client configuration API in Ignite 3.0.
On one hand, it would be nice to use codegen approach from
ignite-configuration module,
and have consistent config APIs across servers and thin clients.
On the other hand, that API may seem a bit confusing, because
+1, as long as 100% of the rules are checked automatically.
On Fri, Aug 20, 2021 at 4:00 PM Andrey Gura wrote:
> Looks good to me. But Idea configuration for style check is not
> enough. It helps developers but does not automate style checking.
>
> Checkstyle project provides ready to use
On Fri, Aug 20, 2021 at 9:31 AM Pavel Tupitsyn wrote:
> Alexander,
>
> > it is not expected that a user may want to specify their own custom
> executor
>
> That would be nice, but I'm not sure if this fits into Ignite 3
> configuration approach.
> I'd like to hear more o
ug 19, 2021 at 5:08 PM Alexander Polovtcev <
> alexpolovt...@gmail.com>
> wrote:
>
> > Pavel, thanks for the response. Do I understand correctly that it is not
> > expected that a user may want to specify their own custom executor?
> >
> > On Thu, Aug 19, 2021 at 6:55 PM Pavel
inuationExecutor": "commonPool"
},
"network": { ... }
}
On Thu, Aug 19, 2021 at 6:29 PM Alexander Polovtcev
wrote:
> Hi, Pavel!
>
> Can you please provide an example (e.g. HOCON snippet) of how this
> configuration is going to look like
Igniters,
I propose to add a configurable async continuation executor for public APIs
to Ignite 3
like we have in Ignite 2.x [1]
In short, currently, async APIs return a future to the user code.
Continuations like "myCode" in "table.getAsync().thenApply(myCode)" will be
executed by the same
client build depends
> on ignite build also.
>
>
> вт, 17 авг. 2021 г. в 18:08, Pavel Tupitsyn :
>
> > Ivan,
> >
> > > I'm sorry, but what about storing TC configs in separate repo?
> > What are the pros of this approach? What do we gain?
> > Separ
rovide an example of an open-source project with this approach?
On Tue, Aug 17, 2021 at 6:05 PM Ivan Daschinsky wrote:
> I'm sorry, but what about storing TC configs in separate repo?
> It is quite common approach.
>
> вт, 17 авг. 2021 г. в 17:33, Pavel Tupitsyn :
>
> > Anton,
&g
Anton,
> This will kill repo history.
> You'll see dozens of TC config updates vs a single Ignite fix
Not really.
I'm not suggesting something crazy, this is the modern way to do CI/CD
- see GitHub actions, Azure pipelines, etc - you write a config and store
it in Git.
> Where are you going to
Dmitry, Petr,
I think TC config should be stored in the same repo as the corresponding
code (2.x config in 2.x repo, 3.x in 3.x, etc).
Changes and updates to build scripts and project structure often come
together with changes to TC configuration,
it would be great to be able to test them by
Hi Ivan,
Thank you for your contribution!
Please see my comments in JIRA.
On Wed, Aug 11, 2021 at 5:54 PM Mirza Aliev wrote:
> Helo Ivan! Thank you for your effort!
>
> Here [1] you can find info about the process of contributing to Apache
> Ignite.
> As Krill said before, you need to get
enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.
Please join me in welcoming Alexander, and congratulating him on the new role
in
the Apache Ignite Community!
Best Regards,
Pavel Tupitsyn
I agree, let's keep the dev list clean.
Automated notifications of any kind should not be sent to dev@i.a.o.
PS Ivan, links 2 and 3 are the same.
On Mon, Aug 9, 2021 at 8:54 AM Ivan Pavlukhin wrote:
> Igniters,
>
> Recently documentation feedback notifications were set up. And
> currently
Dmitry,
This is awesome!
> tc.i.a.o or ci2.i.a.o
My vote for ci2.i.a.o
On Tue, Aug 3, 2021 at 6:33 PM Dmitry Pavlov wrote:
> Hi Igniters,
>
> I'm glad to announce that SberTech made an internal aggreement to sponsor
> a computing power to provide backup TeamCity instance. This instance is
>
Igniters,
I've made the changes to the Tuple interface, please have a look:
https://github.com/apache/ignite-3/pull/245
https://issues.apache.org/jira/browse/IGNITE-14342
On Thu, Jul 1, 2021 at 12:25 PM Pavel Tupitsyn wrote:
> Val, agreed.
> Let's add length(), value(index), and It
+1
On Mon, Jul 26, 2021 at 11:36 AM Igor Sapego wrote:
> +1 from me
>
> Best Regards,
> Igor
>
>
> On Fri, Jul 23, 2021 at 3:32 PM Ivan Daschinsky
> wrote:
>
> > +1 From me
> > 1. Checked binary packages, c module and examples on windows 10 amd64 for
> > pythons 3.6, 3.7, 3.8, 3.9
> > 2.
Igniters,
The initial implementation is ready for review.
To limit the PR size, I've only implemented insert and get operations.
https://issues.apache.org/jira/browse/IGNITE-14970
https://github.com/apache/ignite-3/pull/191
On Wed, Jul 7, 2021 at 1:56 PM Pavel Tupitsyn wrote:
> Tha
Agree with for both points
On Tue, Jul 20, 2021 at 3:14 PM Alexander Polovtcev
wrote:
> this is a very welcome change for me
>
> On Tue, Jul 20, 2021 at 10:13 AM Ivan Pavlukhin
> wrote:
>
> > + for both points.
> >
> > 2021-07-20 9:56 GMT+03:00, Ivan Daschinsky :
> > > Hi!
> > >
> > > Firstly,
Igniters,
I was asked a few times about Data Structures [1] in thin clients.
While there are plans to add them eventually, it is possible to implement
them on top of the existing thin client cache API.
I'd like to share a short blog post which demonstrates this [2].
[1]
on.
>
> Manual enlisting of tables is required, because I strive to avoid any
> thread based control of transactions in Ignite 3.
>
> Actually, a single thread will be able to work with any amount of
> transactions at the same time.
>
> I would keep it for convenience, but le
Alexei,
The API looks good to me, except "runInTransaction", which I find confusing.
It looks like every operation performed by the passed Consumer will be
automatically enlisted in a transaction,
but, looking at tests, "withTx" call is still required inside the Consumer.
I don't think we need
uding Ignition in ignite-client means that ignite-client depends on
> ignite-runner, which we cannot have.
>
> -Val
>
> On Sat, Jul 10, 2021 at 4:17 AM Pavel Tupitsyn
> wrote:
>
> > Val,
> >
> > My suggestion is to have Ignition class in ignite-clie
> вс, 11 июл. 2021 г., 17:48 Pavel Tupitsyn :
>
> > Serialization is just one example, and it does not have to be XML.
> > JSON, YAML, HOCON configs are widely used.
> >
> > Anyway, I see no reason for it NOT to be a POJO.
> > POJOs are ergonomic and work everyw
a POJO - a class with setters and getters,
> nothing else.
> Why it should? Why ClientConfiguration should be serializable? Who needs
> that? Xml configuration even in spring are not widely used for years :)
>
> вс, 11 июл. 2021 г., 00:57 Pavel Tupitsyn :
>
> > Ivan D,
&
wrote:
> Pavel, I and Ivan P. have already get examples of lettuce.io
>
> Another example is spring 5 reactive WebClient
> https://www.baeldung.com/spring-5-webclient
>
> сб, 10 июл. 2021 г., 19:50 Pavel Tupitsyn :
>
> > Ivan D.,
> >
> > > simple and s
w it name connects to bootstraping
> ignite's client.
>
> сб, 10 июл. 2021 г., 14:17 Pavel Tupitsyn :
>
> > Val,
> >
> > My suggestion is to have Ignition class in ignite-client module.
> >
> > On Fri, Jul 9, 2021 at 11:01 PM Valentin Kulichenko
re. Let's think it over and
> see if there are any suggestions.
>
> -Val
>
> On Fri, Jul 9, 2021 at 6:31 AM Pavel Tupitsyn
> wrote:
>
> > > why thin client should be in core module
> >
> > It will be in a separate module (ignite-client).
> > I was talking ab
it works with CompletableFuture.
> Users don't want to code by theyselves, they want to use ready and complete
> clients. Please, don't underestimate kotlin, kotlin coroutines and reactive
> streams. They are all the first class citizens in spring 5 for 3 years
>
> пт, 9 июл. 2
reactive is not enough, it is good idea to support
> kotlin coroutines also :)
>
> пт, 9 июл. 2021 г., 13:26 Pavel Tupitsyn :
>
> > Ivan D.,
> >
> > > container of properties
> >
> > What is a container of properties?
> > As a user, I want a si
cades for sync, async and
> reactive api. Mixing all of them in one interface is a documentation
> nightmare.
>
> пт, 9 июл. 2021 г., 11:55 Pavel Tupitsyn :
>
> > Ivan P., Ivan D.,
> >
> > I don't think it makes sense to separate IgniteConnection and
> IgniteClie
gt; > -Val
> >> >
> >> > On Thu, Jul 8, 2021 at 12:53 PM Ivan Daschinsky
> >> > wrote:
> >> >
> >> > > I'm sorry, but why we didn't consider to separate creation of Client
> >> and
> >> > > connect
t; access point. Ignition seems to be a good candidate for this.
> > >
> > > Ignition#start should eventually be removed from the public API. It is
> > > currently there only because we don't have the thin client yet.
> > >
> > > -Val
> > >
&g
Igniters,
I have a few questions regarding server node startup and thin clients.
State of things:
- Server nodes will be started with 'ignite run' from CLI [1]
- ignite-api module represents our public API
- ignite-api has Ignition interface to start server nodes
Questions:
- What's the idea
sky
> wrote:
>
> > I suppose, that general idea is great. Some details are missing, but I
> > suppose during implementation of clients we will add more details and
> > redefine some parts.
> >
> > вт, 6 июл. 2021 г., 09:59 Pavel Tupitsyn :
> >
> >
t;weight", out var weight))
doSomething(weight)
or Option weight = tuple.floatValue("weight") and so on.
On Tue, Jul 6, 2021 at 9:58 AM Ivan Daschinsky wrote:
> Sorry, but what is wrong with simple method isNull()
>
> вт, 6 июл. 2021 г., 09:55 Pavel Tupitsyn :
>
>
Ivan, Val, and others - are there any open objections or questions?
Can we accept the proposal?
On Mon, Jul 5, 2021 at 1:28 PM Pavel Tupitsyn wrote:
> Igniters,
>
> I've updated the IEP to support "Live Schema" [1] from IEP-54.
> Some operations now have schemaless
ould be a way to check if a field is nullable or not though. Schema
> already provides this information, doesn't it?
>
> -Val
>
> On Mon, Jul 5, 2021 at 11:03 AM Pavel Tupitsyn
> wrote:
>
> > Igniters,
> >
> > Looks like Tuple API has no efficient way to tell if a valu
Igniters,
Looks like Tuple API has no efficient way to tell if a value for a nullable
column of primitive type is null.
- Tuple#intValue() will return 0 when the actual value is null => not clear
if 0 is 0 or null.
- Tuple#value() works, but is more expensive due to boxing and type lookup.
Any
ll add a row (1, "abc")
> > > > > >
> > > > > > Your suggestion related to missed fields will not work this way
> as
> > it
> > > > is
> > > > > > impossible to distinct
wire protocols,
> as tarantool does.
>
> чт, 1 июл. 2021 г., 16:15 Pavel Tupitsyn :
>
> > Ivan,
> >
> > > that there is not neccesary to write schema versions in each row
> > > in collectionof tuples
> >
> > This is described in all opera
and write field name as is.
>
> чт, 1 июл. 2021 г., 14:56 Pavel Tupitsyn :
>
> > Ivan, tuple serialization section added to the IEP, let me know if it is
> > clear enough.
> >
> > Thanks!
> >
> > On Thu, Jul 1, 2021 at 2:06 PM Ivan Daschinsky
&
Ivan, tuple serialization section added to the IEP, let me know if it is
clear enough.
Thanks!
On Thu, Jul 1, 2021 at 2:06 PM Ivan Daschinsky wrote:
> I can't find any description of tuple serialization in IEP, only in code
>
> чт, 1 июл. 2021 г., 13:59 Pavel Tupitsyn :
>
> &g
ere
> isn't
> > a clear consensus about it.
> > 2. There is not any information about schrma serialization format. And
> > AFAIK, there isn't a clear consensus also.
> >
> > чт, 1 июл. 2021 г., 13:26 Pavel Tupitsyn :
> >
> >> Igniters,
> >>
Igniters,
Please review the IEP for thin client protocol in 3.0 [1].
PoC is in progress [2]
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-76+Thin+Client+Protocol+for+Ignite+3.0
[2] https://github.com/apache/ignite-3/pull/191
use other abstractions, of course.
> Every platform has its own specifics and practices, so APIs don't have to
> be identical.
>
> -Val
>
> On Wed, Jun 30, 2021 at 7:44 AM Pavel Tupitsyn
> wrote:
>
> > Hi Andrey,
> >
> > > This will force us to bother abo
t may be impossible for some data.
>
> We already have a ticket [1] to support accessing a column by an index and
> exposing some metadata.
> Will 'idx -> column' mapping only be enough for your purposes?
>
> > int Tuple.columnIndex(String)
>
>
>
> [1] https://iss
some futures.
[1]
https://docs.microsoft.com/en-us/dotnet/api/system.data.idatareader?view=net-5.0
On Wed, Jun 30, 2021 at 4:51 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Pavel,
>
> Please see my comments below.
>
> -Val
>
> On Tue, Ju
Igniters,
While working on "IEP-76 Thin Client Protocol for Ignite 3.0" [1] (to be
discussed separately), the following suggestions for the Table API came up:
1. Expose table IDs: sending table name with every operation (e.g. GET) is
inefficient, string serialization is expensive by itself and
Hi Saurabh,
I've added you to the Contributors role in JIRA.
Welcome to the Apache Ignite community!
On Tue, Jun 29, 2021 at 10:34 AM saurabh chhajed
wrote:
> Hi Team,
>
> I wanted to contribute to some ML based inference code for Ignite, and
> Requesting to be added as contributor permission
+1 (binding)
On Mon, Jun 28, 2021 at 8:23 PM Вячеслав Коптилин
wrote:
> +1
>
> Thanks,
> S.
>
> пн, 28 июн. 2021 г. в 18:09, Igor Sapego :
>
> > +1
> >
> > Best Regards,
> > Igor
> >
> >
> > On Sat, Jun 26, 2021 at 1:41 AM Nikita Ivanov
> wrote:
> >
> > > +1
> > >
> > > --
> > > Nikita Ivanov
gt;
> ср, 23 июн. 2021 г. в 14:07, Pavel Tupitsyn :
>
> > Igniters,
> >
> > Looks like there are no objections and we can accept the proposal.
> > I will close it tomorrow and move on to the thin client protocol itself.
> >
> > On Fri, Jun 18, 2021 at 12:10 P
.
>
> [1] -- https://github.com/igorcoding/asynctnt
> [2] -- https://github.com/tarantool/tarantool-python/
> [3] -- https://github.com/tarantool/go-tarantool
> [4] -- https://github.com/rtsisyk/msgpuck
>
> пт, 18 июн. 2021 г. в 11:44, Pavel Tupitsyn :
>
> >
Ivan,
> why do you use PooledMessageBufferOutput in benchmarks?
To make it fair. Ignite uses thread-local reusable buffers, see [1].
> why packer from msgpack-core show better performance than
> BinaryWriter. And I suppose that benchmark is not quite fair.
MsgPack writes and reads less
but I suppose that we should benchmark
> > formats thoroughly. And not only for Java.
> >
> > чт, 17 июн. 2021 г. в 15:29, Pavel Tupitsyn :
> >
> >> Igniters,
> >>
> >> I have drafted an IEP on thin client serialization format [1],
> >> please r
Igniters,
I have drafted an IEP on thin client serialization format [1],
please review and let me know what you think.
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-75+Thin+Client+Serialization
+1
Checked pip install from tar.gz on Python 3.8 on Ubuntu 20.04, ran some of
the examples.
On Thu, Jun 17, 2021 at 2:32 PM Igor Sapego wrote:
> +1 from me
>
> Best Regards,
> Igor
>
>
> On Thu, Jun 17, 2021 at 12:10 PM Ivan Daschinsky
> wrote:
>
> > +1 From me
> > Checked on Ubuntu 20.04 and
Hi Vladimir,
Welcome to the Apache Ignite community!
I've added you to the Contributors role in JIRA.
Note: "Committer" is a community member with direct commit access [1].
[1] https://apache.org/foundation/glossary.html#Committer
On Mon, Jun 7, 2021 at 4:27 PM Владимир Ермаков
wrote:
>
In my opinion, we should remove this rule.
Looks like a waste of time. freq or frequency, cnt or count, it is fine
either way.
On Fri, Jun 4, 2021 at 7:39 PM Nikolay Izhikov wrote:
> Hello, Igniters.
>
> Right now, we have the rule to use some predefined list of abbrevation for
> variable names
dit tickets. One more question - how can I
> create new version to move some tickets to 2.12?
>
> On 2021/06/04 11:37:55, Pavel Tupitsyn wrote:
> > Added you to the Contributors role, now you should be able to edit
> tickets.
> >
> >
> > On Fri, Jun 4, 2021 at 2:16 PM
Added you to the Contributors role, now you should be able to edit tickets.
On Fri, Jun 4, 2021 at 2:16 PM Alexey Gidaspov wrote:
> Hi, Pavel.
>
> My JIRA login is agidaspov
>
> On 2021/06/04 11:14:02, Pavel Tupitsyn wrote:
> > Hi Alexey,
> >
> > What's your J
Hi Alexey,
What's your JIRA username?
On Fri, Jun 4, 2021 at 1:50 PM Alexey Gidaspov wrote:
> Hi, All!
>
> What should I do to be able to edit fixVersion in jira tickets?
>
Fixed
https://issues.apache.org/jira/browse/IGNITE-14804
On Fri, May 28, 2021 at 5:07 PM Pavel Tupitsyn wrote:
> Ivan, yes, I'll deal with this next week.
>
> On Fri, May 28, 2021 at 12:28 PM Ivan Daschinsky
> wrote:
>
>> Hi, Pavel, could you please look at this [1]? It
e 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 move
> this way in future though.
>
> Best Regards,
> Igor
>
>
> On Tue,
Ivan, yes, I'll deal with this next week.
On Fri, May 28, 2021 at 12:28 PM Ivan Daschinsky
wrote:
> Hi, Pavel, could you please look at this [1]? It seems after updating
> TC, few new inspections arrived.
>
>
> ]1] --
>
Hi Vladimir,
Looks like this message is for d...@calcite.apache.org, not
dev@ignite.apache.org,
or am I mistaken?
On Wed, May 19, 2021 at 2:25 PM Vladimir Ozerov wrote:
> Hi,
>
> The AggregateUnionTransposeRule attempts to push the Aggregate below the
> Union.
>
> Before:
> Aggregate[group=$0,
e a client request completes, the data is guaranteed to be in the cache,
and failed requests (connection loss, node failure) can be retried.
This simplifies both client and server implementations.
Thoughts?
On Tue, Mar 9, 2021 at 6:32 PM Pavel Tupitsyn wrote:
> Alex,
>
> I did not i
Oops, here it is:
https://issues.apache.org/jira/browse/IGNITE-14719
On Fri, May 14, 2021 at 2:35 PM Ivan Daschinsky wrote:
> Pavel, sorry, but where is the link to ticket?
>
> пт, 14 мая 2021 г. в 14:13, Pavel Tupitsyn :
> >
> > Ticket created [1], I'll make the changes,
> On Wed, May 12, 2021 at 5:18 PM Ivan Daschinsky
> wrote:
> >
> > > Huge +1 from me. PA should be enabled by default.
> > >
> > > ср, 12 мая 2021 г. в 13:33, Pavel Tupitsyn :
> > > >
> > > > Igniters,
> > > >
> >
Igniters,
Partition Awareness (PA) is implemented in 5 out of 6 thin clients [1].
However, this feature is disabled by default in most clients for
compatibility reasons:
initially we only used one connection to the cluster, but with PA enabled
we establish
connections to every server node, which
Igniters,
IgniteDataStreamer#removeData does not work by default,
when allowOverwrite is not set to true.
I think we should throw an exception from the streamer in this case.
Thoughts, objections?
Pavel
Nikolay,
I agree that our binary array handling has some limitations - Ignite loses
array element type in many cases (cache.Put -> cache.Get, Binary Mode, etc).
However, for internal platform and services implementations we should fix
the root cause:
avoid extra deserialization->serialization
Pavel Tupitsyn created IGNITE-14620:
---
Summary: GridCacheAsyncOperationsLimitSelfTest#testAsyncOps is
flaky
Key: IGNITE-14620
URL: https://issues.apache.org/jira/browse/IGNITE-14620
Project: Ignite
Pavel Tupitsyn created IGNITE-14609:
---
Summary: Document old and new async continuation behavior
Key: IGNITE-14609
URL: https://issues.apache.org/jira/browse/IGNITE-14609
Project: Ignite
Agree with Ivan - internal code does not need mandatory Javadoc.
Most of it is meaningless and does not bring any value, just wastes
everyone's time.
Alexey, I think public APIs should always have Javadoc,
even if it is the same thing as the member name, but with spaces -
this will make the
Pavel Tupitsyn created IGNITE-14577:
---
Summary: .NET: error serialization failed when thread is
interrupted
Key: IGNITE-14577
URL: https://issues.apache.org/jira/browse/IGNITE-14577
Project: Ignite
er, which is the majority.
> Anyway, I'll leave to you to decide.
>
> > On 15 Apr 2021, at 11:02, Stanislav Lukyanov
> wrote:
> >
> > Hi Pavel,
> >
> > I'd prefer public pool.
> >
> > Thanks,
> > Stan
> >
> >> On 12 Apr 2021, at
Pavel Tupitsyn created IGNITE-14532:
---
Summary: Thin client: Unordered map used for putAll warning is
unavoidable
Key: IGNITE-14532
URL: https://issues.apache.org/jira/browse/IGNITE-14532
Project
proach you're suggesting if I haven't
> convinced you by now :)
>
> Thanks,
> Stan
>
> > On 29 Mar 2021, at 22:47, Pavel Tupitsyn wrote:
> >
> > Stan,
> >
> > Unfortunately, annotations have a few drawbacks:
> > * Can't configure it globally ("I
t; own
> > CQ
> > > classes and interfaces for thin client, but such API looks weird. On
> the
> > > one hand, we should use CacheEntryEventFilter (JCache interface) since
> > it's
> > > required by the server-side, on the other hand, we can't use
> > >
201 - 300 of 1756 matches
Mail list logo
