> I don't think we need an explicit reactive API in the core library.
> Observable.fromFuture bridges async to Rx easily:
Cannot immediately agree here. Observable.fromFuture is not fair
reactive Publisher because computation for wrapped future most likely
starts before any subscription. While
Pavel, actually, setters in builder is not ok. But as for me, the better
approach is something like this:
IgniteClient client = IgniteClient.start("127.0.0.1:10800")
or
CompletableFuture client =
IgniteClient.startAsync(IgniteClientConfiguration.builder()
.addresses("127.0.0.1:10800)
Val,
Ivan D has convinced me above to try the builder pattern, which is used by
many other drivers (Redis, Mongo, etc).
With IgniteClient class in ignite-client module:
Ignite client = IgniteClient.builder()
.setAddresses("127.0.0.1:10800")
.setTimeout(5000)
.build();
What do you
Pavel,
If Ignition is the single entry point, it needs to have access to the
server node instance, so it needs to depend on ignite-runner. Therefore,
including 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
Ivan D, ok, you have convinced me.
Builder pattern is popular for this sort of thing, and not only in the Java
world.
Let's see if there are other opinions.
On Sun, Jul 11, 2021 at 6:59 PM Ivan Daschinsky wrote:
> The main reason is that immutable configurations nowadays is more
> preferable
The main reason is that immutable configurations nowadays is more
preferable variant than mutable. For example, when you initialize client
you must copy configuration in order to be consistent. Nobody nowadays read
configuration from files as is, moreover -- the most microservices
retrieves just
But if you looked at other competitors, non of them doesn't use mutable
configurations. POJO or even more, JavaBeans are not used in the mos
products.
I just asked if you looked at others. Today it looks like you suggest use
just the same interfaces as in 2.x. Things changed a lot.
вс, 11 июл.
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 everywhere.
On Sun, Jul 11, 2021 at 8:24 AM Ivan Daschinsky wrote:
> > But configuration should be a POJO
> But configuration should be 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,
>
> Let's
Ivan D,
Let's compare WebClient approach with Ignite 2.x approach:
// Ignite 2.x
var cfg = new ClientConfiguration()
.setAddresses("127.0.0.1:10800", "127.0.0.1:10801")
.setTimeout(4000);
Ignite client = Ignition.startClient(cfg);
// Ignite 3.x
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 straightforward client builder
> Can you please provide an example of
Ivan D.,
> simple and straightforward client builder
Can you please provide an example of that, a piece of code with suggested
API usage? Ideally compared to the current 2.x approach.
On Sat, Jul 10, 2021 at 3:20 PM Ivan Daschinsky wrote:
> It is a quite questionable decision , as for me, to
It is a quite questionable decision , as for me, to have specific static
method within strange class with strange name (and it is a well known
antipatter ) with chained twisted configuration class instead of just
simple and straightforward client builder, isn't it? Name 'Ignition' is may
be fun,
Val,
My suggestion is to have Ignition class in ignite-client module.
On Fri, Jul 9, 2021 at 11:01 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Pavel,
>
> Ivan actually brings a good point. While the client is in a separate
> module, Ignition (if we make it static) will have
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
> 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
> 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,
> 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
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
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
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
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
Val,
> Ignition IS the entry point to Ignite, so I'm not sure I got your point :)
> Either way, please feel free to give your suggestions for an alternative name
> if you have any.
Well, it is not only about naming but it is also about code
organization. Ivan D. already referenced to
Ivan,
I've seen the link, but I still don't understand what exactly you propose
to change in the current API, and what is your concern. Could you please
clarify? How you think Ignite API should look like?
-Val
On Thu, Jul 8, 2021 at 2:18 PM Ivan Daschinsky wrote:
> Val, I have already gave
Val, I have already gave examples -- lettuce, a very performant and modern
redis java client
I can duplicate links again
https://lettuce.io/core/release/api/io/lettuce/core/RedisClient.html
https://lettuce.io/core/release/api/io/lettuce/core/api/StatefulRedisConnection.html
Ivan,
Can you please clarify what you mean by "separate creation of client and
connection"? Can you give an example?
-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
> connection? Why not to make async
Pavel,
Yes, makes sense.
-Val
On Wed, Jul 7, 2021 at 11:50 PM Pavel Tupitsyn wrote:
> Val,
>
> So the plan is:
>
> - Remove Ignition#start from the public API
> - Make Ignition a class, not an interface
> - Add static Ignition#startClient
>
> Sounds good?
>
> On Thu, Jul 8, 2021 at 6:13 AM
I'm sorry, but why we didn't consider to separate creation of Client and
connection? Why not to make async variant of connection? See for example [1]
[1] --- https://lettuce.io/core/release/api/index.html
чт, 8 июл. 2021 г., 09:50 Pavel Tupitsyn :
> Val,
>
> So the plan is:
>
> - Remove
Val,
So the plan is:
- Remove Ignition#start from the public API
- Make Ignition a class, not an interface
- Add static Ignition#startClient
Sounds good?
On Thu, Jul 8, 2021 at 6:13 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Hi Ivan,
>
> Ignition IS the entry point to
Hi Ivan,
Ignition IS the entry point to Ignite, so I'm not sure I got your point :)
Where is the contradiction?
Either way, please feel free to give your suggestions for an alternative
name if you have any.
-Val
On Wed, Jul 7, 2021 at 7:56 PM Ivan Pavlukhina wrote:
> A side note. Actually
A side note. Actually “Ignition” naming always confused me. I think about it as
some fancy named API entry point for Ignite. Perhaps it is a good moment to
revisit naming.
> On 8 Jul 2021, at 07:09, Valentin Kulichenko
> wrote:
>
> Hi Pavel,
>
> I don't think we will need the pure embedded
Hi Pavel,
I don't think we will need the pure embedded mode, but we still need to be
able to access the API from compute and services. That said, there are two
usages of the 'Ignite' API:
1. Remote, via the binary protocol.
2. Local - needed for compute and services. (This is how it works
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
33 matches
Mail list logo
