Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Pavel Tupitsyn
Ivan P., Ivan D., I don't think it makes sense to separate IgniteConnection and IgniteClient like Lettuce does, because IgniteClient will maintain connections to multiple server nodes automatically, and the number of connections can grow and shrink dynamically. This is required to support dynamic

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Ivan Daschinsky
Pavel, actually I suggests to separate container of properties(client in lettuce) and actual connection or connections (stateful connection in lettuce). Actual connection initialization could be sync or async, it doesn't matter. It can be Ignition#startClient or Ignition#startClientAsync, but I'd p

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Pavel Tupitsyn
Ivan D., > container of properties What is a container of properties? As a user, I want a simple way to start a client and perform operations. I don't want anything confusing and complicated like Netty Bootstrap. There might be a reason for Netty to be this way - it is a low-level library. But I

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Ivan Daschinsky
You forget about reactive api :) And whats a problem with discocerability? var syncApi = client.sync(); syncApi.put(k, v); var rxApi = client.reactive(); rxApi.put(k,v).flatMap(res -> ); And sync, async and reactive is not enough, it is good idea to support kotlin coroutines also :) пт, 9

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Pavel Tupitsyn
> You forget about reactive api I don't think we need an explicit reactive API in the core library. Observable.fromFuture bridges async to Rx easily: Observable.fromFuture(client.putAsync(k, v)).flatMap(...) Same story with Kotlin, it works with CompletableFuture. On Fri, Jul 9, 2021 at 1:31 PM

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Ivan Daschinsky
> I don't think we need an explicit reactive API in the core library. Have you ever thought about why thin client should be in core module? Why we do the same thing as we did in ignite 2.x? In the days of cloud native we still think about large uber-jar with everything? > Same story with Kotlin,

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Pavel Tupitsyn
> why thin client should be in core module It will be in a separate module (ignite-client). I was talking about "core library" as a primary set of modules that we ship. Integrations with 3rd party libraries and frameworks can be shipped as extensions. Anyway, let's postpone the discussion of Rx a

TC bot problems

2021-07-09 Thread Alexey Gidaspov
Hi, all! I'm trying to compare release 2.11 against 2.10. I'm using [1] and I can't see any data related to the release of 2.10. And when I'm trying to specify base branch using dropdown menu, I can't select ignite-2.10 branch. What am I doing wrong? [1] https://mtcga.gridgain.com/pr.html?s

Re: Ignite 3.0 Ignition API, node startup, and thin client startup

2021-07-09 Thread Valentin Kulichenko
Pavel, Ivan actually brings a good point. While the client is in a separate module, Ignition (if we make it static) will have to depend on both ignite-client and ignite-runner, and we will have to ship it along with the client. This indeed creates an uber-jar, so we can't really have a single entr