Maxim,
I believe I could fix the ticket [1] by the end of the next week.
[1] https://issues.apache.org/jira/browse/IGNITE-14204
Best Regards,
Igor
On Thu, Feb 18, 2021 at 6:30 PM Max Timonin wrote:
> Hi! I've today found an issue [1], there is wrong handling of inlined POJO.
> This bug appea
gt;
> > > > > Fixed an issue that caused a deadlock when user cache was created
> in
> > > > > parallel with TTL worker was in progress.
> > > > > https://issues.apache.org/jira/browse/IGNITE-14078
> > > > >
> > > > > On Thu, 18 Fe
The following commit should be
cherry-picked: 0675e2a7e800730c9c8230332b82809754ddae5a
Sorry for a delay.
Best Regards,
Igor
On Mon, Mar 1, 2021 at 9:06 PM Igor Sapego wrote:
> Maxim,
>
> The issue is fixed and is merged to master now.
>
> Best Regards,
> Igor
>
>
>
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 DataStr
+1 (binding)
Checked C++ compilation, C++ examples
Best Regards,
Igor
On Fri, Mar 5, 2021 at 12:32 AM Denis Magda wrote:
> +1 (binding)
>
> Downloaded the binary package and started a 2-node cluster on MacOS with
> ignite.sh.
>
> -
> Denis
>
>
> On Wed, Mar 3, 2021 at 1:03 PM Maxim Muzafarov
Nikolay,
That's because we now have separate repos for them: [1], [2] and [3].
Actually, active development is moved to those repos some time ago and
those directories in main repo are not actual anymore anyway.
Decision of moving those clients to separate repos was discussed in [4]
[1] - https:
Pavel, I like the proposal,
+1 from me
Best Regards,
Igor
On Tue, Mar 16, 2021 at 6:49 PM Pavel Tupitsyn wrote:
> Alexey,
>
> .NET thick API delegates to Java directly.
>
> When you do ICache.PutAsync():
> * Future is created on Java side, .listen() is called
> * TaskCompletionSource is creat
The Project Management Committee (PMC) for Apache Ignite has invited
Ivan Daschinsky to become a committer and we are pleased to announce that
he has accepted.
Ivan made a lot of contributions to Apache Ignite.
He helped a lot to improve our Python Thin Client fixing a lot of different
bugs and co
+1 from me.
Best Regards,
Igor
On Fri, Apr 16, 2021 at 5:05 PM Ivan Daschinsky
wrote:
> Ivan Daschinsky
> чт, 15 апр., 21:37 (19 часов назад)
> кому: dev
> Dear Igniters!
>
> Release candidate binaries are at least uploaded and ready for vote
> You can find them here:
> https://dist.apache.or
Hi,
Ivan, I like your suggestion. To me it looks better than the current
approach.
Best Regards,
Igor
On Mon, Apr 26, 2021 at 11:47 AM Nikita Safonov
wrote:
> Hi Ivan,
>
> Thanks for sharing the information.
> I'll look through the docs and share my thoughts and suggestions soon.
>
> Regards,
Thanks for issuing a ticket. I'll take a look at it.
Best Regards,
Igor
On Fri, Apr 23, 2021 at 1:40 PM teligenz.dheeraj
wrote:
> Team,
>
> I have used nodejs thin client to connect ignite. With single query at time
> on socket works fine. But when hit multiple request simultaneously, getting
+1 from me. There were no major issues with this feature and it gives
good performance boost for many cases.
Best Regards,
Igor
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 :
> >
> > Ig
t this will not work at all.
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > пт, 5 мар. 2021 г. в 15:23, Pavel Tupitsyn <
> >> > > ptupit...@apache.org
> >> > > > >:
> >>
Hi Igniters,
I've noticed a weird behaviour of python thin client. In those places where
we have
timeouts or any other parameters that take time in some places we treat it
like integer
number of milliseconds, in others it can take both floats (as a number of
seconds)
and ints (number of millisecon
+1 from me
Uploaded to test.pipy.org: https://test.pypi.org/project/pyignite/0.5.0/
Everything looks good.
Best Regards,
Igor
On Tue, Jun 15, 2021 at 10:09 PM Ivan Daschinsky
wrote:
> Also checked hash sums and signature. Packages are verified and
> signature is OK, signed by Igor
ht. But there is no need to
> > notice or deprecate something. This functionality is not released yet
> >
> > вт, 15 июн. 2021 г., 23:41 Igor Sapego :
> >
> >> Hi Igniters,
> >>
> >> I've noticed a weird behaviour of python thin client. In those pla
I propose to cancel this release and fix the issue which was highlighted in
the
"Seconds and milliseconds confusion in python thin client" thread.
WDYT?
Best Regards,
Igor
On Wed, Jun 16, 2021 at 12:10 AM Igor Sapego wrote:
> +1 from me
>
> Uploaded to test.pipy.org: ht
+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 windows 10
> 1. Installation from wheels for pythons 3.6 3.7 3.8 3.9
> 2. Native module work
> 3. Examples
>
> Checked on Ubuntu 20.04 building from source package a
.0 so not sure if it’s a regression, but it’s
> >>>>> not great.
> >>>>>
> >>>>> > On 18 Jun 2021, at 09:36, Stephen Darlington <
> >>>>> stephen.darling...@gridgain.com> wrote:
> >>>>> >
> >
+1
Best Regards,
Igor
On Sat, Jun 26, 2021 at 1:41 AM Nikita Ivanov wrote:
> +1
>
> --
> Nikita Ivanov
>
>
>
> On Fri, Jun 25, 2021 at 3:31 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Dear Community,
> >
> > In the last several months, the development of Ignite 3 has
Ivan, what are extra serde steps you are talking about?
Best Regards,
Igor
On Thu, Jul 1, 2021 at 5:52 PM Ivan Daschinsky wrote:
> > I agree. But this was decided before in IEP-54, and is out of scope for
> current IEP.
> Would you like to start a separate thread to discuss this? Or I can do t
and gpg signatures (signed by Igor Sapego (CODE
> SIGNING KEY) 5C10 A072 2D94 7727 923C 98B5 AF35 DBD9
> 58FE 8DC5)
> key is inside https://downloads.apache.org/ignite/KEYS)
>
> пт, 23 июл. 2021 г. в 13:52, Ivan Daschinsky :
>
> > The voting finishes at 07/27/2021 12:00 UT
Igniters,
I suggest adding [1] to the scope of release, because it contains
changes to code introduced by [2], which is already included in release.
[1] - https://issues.apache.org/jira/browse/IGNITE-14815
[2] - https://issues.apache.org/jira/browse/IGNITE-14658
Best Regards,
Igor
On Mon, Jul
ockers. I may be
> wrong, but this ticket doesn't seem to be of that kind.
>
> On 2021/07/28 21:00:15, Igor Sapego wrote:
> > Igniters,
> >
> > I suggest adding [1] to the scope of release, because it contains
> > changes to code introduced by [2], which is a
t the incomplete change from 2.11 in order
> to reintroduce it in 2.12 in full form if Igor agrees and RE thinks this is
> the best course of action.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 29 июл. 2021 г. в 18:07, Igor Sapego :
>
> > Alexey,
> >
>
e it in 2.12 in full form if Igor agrees and RE thinks
> this is
> > > the best course of action.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 29 июл. 2021 г. в 18:07, Igor Sapego :
> > >
> >
Well, fortunately we do not provide a C client if you don't consider ODBC
as one so we should not think about it. For C++ I believe we should use
standard std::future+std::promise for async, but still can provide sync
methods,
built on top of async methods. There is no continuation problem in C++ A
sync API.
Best Regards,
Igor
On Thu, Sep 9, 2021 at 2:29 PM Ivan Daschinsky wrote:
> Igor, and what about C++20 and coroutines [1]
>
> [1] -- https://en.cppreference.com/w/cpp/language/coroutines
>
> чт, 9 сент. 2021 г. в 14:12, Igor Sapego :
>
> > Well, fortunately we
+1
Best Regards,
Igor
On Thu, Sep 9, 2021 at 8:33 PM Maxim Muzafarov wrote:
> +1
>
> On Thu, 9 Sept 2021 at 14:08, Nikolay Izhikov wrote:
> >
> > +1 to release ASAP.
> >
> > > 9 сент. 2021 г., в 13:43, Ivan Daschinsky
> написал(а):
> > >
> > > TC build of release branch --
> > >
> https://tc
I actually agree with Pavel, at least at putAll() part. We require a Map
from user
when we do not really need a Map in this method. What we really need here is
an iterable collection of pairs. Can not see why user can not pass for
example an
array here.
Now, when we talk about getAll() method it's
Sounds very reasonable to me.
+1
Though the default comparator should be implemented very carefully
as we had issues 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 Binar
Sounds good, no objections from my side.
Best Regards,
Igor
On Wed, Oct 6, 2021 at 11:46 AM Stanislav Lukyanov
wrote:
> Hi Igniters,
>
> I found the following usability issue with java thin client API.
>
> Whenever you do `try (IgniteClient client = Ignition.startClient(cfg))`,
> you're forced
Hi guys,
Why can not a user implement such context on application level?
I believe Ignite provides all necessary tools for that. User can just
implement such a context as user type and pass it to services they
need. Are the arguments why would Ignite need a separate feature
for such a use case?
B
Kevin,
Basically, to change this we need people who would actively drive
development of the client and be active community members.
Best Regards,
Igor
On Mon, Sep 27, 2021 at 6:02 PM Ivan Daschinsky wrote:
> Hi! I can share my experience how to drive this activity. Personally, I've
> driven f
Val,
I think we need to upload the nuget package we want to upload so the
community
would know what we are going to upload and can check that everything is
right.
WDYT?
Best Regards,
Igor
On Wed, Oct 13, 2021 at 8:03 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Pavel,
>
>
Sorry,
I meant we need to publish the package as part of RC, so it can be reviewed.
Best Regards,
Igor
On Thu, Oct 14, 2021 at 11:34 AM Igor Sapego wrote:
> Val,
>
> I think we need to upload the nuget package we want to upload so the
> community
> would know what we are goin
Pavel,
What is ClientOperationType? Will it list basically all operations or only
types like Idempotent, NonIdempotent?
Best Regards,
Igor
On Wed, Nov 24, 2021 at 5:21 PM Pavel Tupitsyn wrote:
> Igniters,
>
> I've prepared a proposal about thin client retry behavior.
> Please review and let m
+1 (binding)
Best Regards,
Igor
On Tue, Jan 25, 2022 at 10:44 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> +1 (binding)
>
> On Tue, Jan 25, 2022 at 11:43 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Dear Community,
> >
> > Ignite 3 is moving forward
Feature seems useful for me as it makes connection management more robust
and
predictable.
I agree with Pavel, that we should print warning when heartbeat period is
larger than
idle timeout, but I see a problem here as idle timeout is configured on
server and is not
known to clients, while heartbe
Hi, Igniters
I've prepared an IEP for Ignite 3 Client Lifecycle [1]. The main idea is to
define client lifecycle as well as core algorithms and mechanisms used by
clients. This proposal can be used as a reference for implementation of a
new client for Ignite when dealing with such problems as:
In the case of a secured cluster it does not matter, because
> authentication/authorization keeps intruders out.
>
>
> On Mon, May 16, 2022 at 11:07 PM Igor Sapego wrote:
>
> > Hi, Igniters
> >
> > I've prepared an IEP for Ignite 3 Client Lifecycle [1]. The main
>>
> >> Also, do I understand correctly that a server has enough information
> >> about client connections so it will be possible to observe a
> >> connections list on the server? It would be useful for cluster
> >> monitoring purposes.
> >>
> >
+1
Best Regards,
Igor
On Fri, Jun 10, 2022 at 1:37 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> +1
>
> On Thu, Jun 9, 2022 at 9:17 AM Alexander Polovtcev <
> alexpolovt...@gmail.com>
> wrote:
>
> > Looks good, so many great features! +1
> >
> > On Thu, Jun 9, 2022 at 6:42 PM
I like the closable iterator approach more as well. The difference in API
is not as critical in my opinion, as we have a lot of differences in thick
and
thin APIs already and users would normally seek thin client examples and
not just re-use thick client code with thin client.
Best Regards,
Igor
hu, May 19, 2022 at 10:55 PM Igor Sapego wrote:
> >
> > Andrey,
> >
> > 1. If a server generates a UUID that already exists it can check and just
> > re-generate it straight away
> > as a check is just a simple map lookup.
> >
> > 2. Well,
Pavel,
Great, this feature showed great results in Ignite 2, so It's a good idea
to implement
it in Ignite 3 as well.
The IEP itself looks good to me, except it's not clear how a server would
know when
assignment has changed.
Regardless of the Tracking Assignment Changes section, I like the firs
Guys,
I've merged https://issues.apache.org/jira/browse/IGNITE-17590 to main and
I really think it should be included in this release, because without it
current
C++ client implementation is pretty much useless. And it does not affect any
other parts of the product except for the C++ part anyway s
+1 from me
Best Regards,
Igor
On Wed, Nov 2, 2022 at 3:48 AM Stanislav Lukyanov
wrote:
> Igniters,
>
> The initial code freeze date for 3.0.0 beta 1 was missed, so we need to
> pick a new timeline.
>
> There are currently 5 tickets in progress or in review that are in the
> scope, with signifi
+1
Github Actions look great to me.
Best Regards,
Igor
On Mon, Nov 7, 2022 at 5:38 PM Ivan Daschinsky wrote:
> Hi, Igniters!
>
> I suppose it is time to release pyignite 0.6.0, since we have released our
> previous release more than a year ago.
>
> Firstly, python 3.6 reached its EOL, the bra
+1
Best Regards,
Igor
On Fri, Nov 11, 2022 at 5:41 PM Ivan Daschinsky
wrote:
> Dear Igniters!
>
> Release candidate binaries for subj are uploaded and ready for vote
> You can find them here:
> https://dist.apache.org/repos/dist/dev/ignite/pyignite/0.6.0.rc0
>
> If you follow the link above, y
+1
Best Regards,
Igor
On Mon, Nov 14, 2022 at 5:23 PM Ivan Daschinsky
wrote:
> >>
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc0/examples.html
>
> https://apache-ignite-binary-protocol-client.readthedocs.io/en/0.6.0.rc1/examples.html
>
> пн, 14 нояб. 2022 г. в 16:
+1 (binding)
Best Regards,
Igor
On Tue, Nov 15, 2022 at 11:10 PM Vladislav Pyatkov
wrote:
> +1
>
> On Tue, Nov 15, 2022 at 3:35 PM Denis C wrote:
> >
> > +1
> >
> > вт, 15 нояб. 2022 г. в 13:33, Alexander Lapin :
> >
> > > +1
> > >
> > > вт, 15 нояб. 2022 г. в 08:48, Pavel Tupitsyn :
> > >
>
Great work
Best Regards,
Igor
On Wed, Nov 16, 2022 at 1:50 PM Ivan Daschinsky
wrote:
> The Apache Ignite Community is pleased to announce the release of
> Apache IGNITE python thin client (pyignite) 0.6.0.
>
> This new release is mostly the maintenance one. However, there are some
> new import
Congrats, guys!
Best Regards,
Igor
On Thu, Nov 17, 2022 at 4:39 PM Вячеслав Коптилин
wrote:
> Dear Igniters,
>
> I'm happy to announce that the 1st beta version of Ignite 3 is out!
>
> On top of the functionality that was previously released, Beta 5 adds the
> following major features:
> - RPM
Great job,
I think we should have details like this in documentation, not only in wiki
Denis, what do you think?
Best Regards,
Igor
On Wed, Oct 16, 2019 at 7:19 PM Ivan Pavlukhin wrote:
> Sergey,
>
> Thank you for a review!
>
> > It seems to me that document tries to focus on details of the
Pavel,
The proposed solution won't work for PHP, Python, Node.js,
but it will work for C++ and .NET, isn't it? We will just have
to deploy C++/.NET code in closter (just as in Java).
Best Regards,
Igor
On Thu, Nov 21, 2019 at 12:59 PM Aleksandr Shapkin
wrote:
> Folks,
>
>
>
> I started to imp
Pavel,
I'm against adding this feature, as there were talks recently, that we
should stop supporting TextQuery altogether. No sense in adding
something, that we will need to depreciate and remove soon.
Best Regards,
Igor
On Tue, Dec 3, 2019 at 5:46 PM Pavel Tupitsyn wrote:
> Oh wow, the next
+1, sounds reasonable to me.
Best Regards,
Igor
On Fri, Dec 20, 2019 at 10:25 AM Pavel Tupitsyn
wrote:
> +1, let's rename while we have a chance before 2.8 is released.
>
Alexey, if I understand correctly, Ilya does not suggest to pre-built
binaries, just to ship it with configure script pre-generated, which
is a common practice for autotools packages. Building will be still
required for the user, but there will be less requirements and
possible errors during build.
Sorry for the late reply.
Approach with taskId will require a lot of changes in protocol and thus
more "heavy" for implementation, but it definitely looks to me less hacky
than reqId-approach. Moreover, as was mentioned, server notifications
mechanism will be required in a future anyway with high
Hi Dmitrii,
Can you please explain your use case?
I'm not sure I'm getting what is the motivation of this change.
Best Regards,
Igor
On Wed, Jan 22, 2020 at 5:11 PM Pavel Tupitsyn wrote:
> Hi Dmitrii,
>
> Honestly, I could not grasp the problem, can you explain it in more detail?
> What do we
Hi Igniters,
As we have a lot of different thin clients now, maintained by different
people, the issues with our backward compatibility mechanism becomes
more and more prominent.
Currently, we use protocol versioning as the only approach to provide
backward compatibility. The main issue of this a
sion for introducing
> flags.
> >
> > On 23.01.2020 15:47, Alexei Scherbakov wrote:
> > > Igor Sapego,
> > >
> > > I do not understand how feature masks can remove the necessity of
> having
> > > protocol versioning.
> > > A protocol for one featur
gt; > and
> > > > > > raises
> > > > > > > > > > > > > questions:
> > > > > > > > > > > > >
> > > > > > > > > > > > > - Why is UserAttributes property related to
> > >
; which tries to clear sensitive data from it.
>
> However, it is no good for authenticating nodes anyway, since discovery
> message have to travel via ring, so all server nodes will have access to
> sensitive information.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> в
020 at 9:58 PM Ivan Pavlukhin
> wrote:
>
> > Hello Ignite Community,
> >
> > The Project Management Committee (PMC) for Apache Ignite has invited
> > Igor Sapego to join the PMC as a new member and we are pleased to
> > announce that he has accepted.
>
Do you suggest to introduce it in general configuration? Why not introduce
it only on platform side? Is there any .NET-specific configuration?
Best Regards,
Igor
On Tue, Feb 18, 2020 at 1:10 AM Pavel Tupitsyn wrote:
> Igniters,
>
> I'm working on .NET Near Cache feature [1]
> (storing deserial
By the way, some ODBC tests became flaky about the same time as well.
May it be there is one root cause somewhere in SQL?
Best Regards,
Igor
On Mon, Feb 17, 2020 at 9:36 PM Pavel Tupitsyn wrote:
> I did a quick look some time ago, no idea what is going on, honestly. Tests
> became flaky for no
Hi,
I believe, we definitely should not ignore this.
Alexey, you are the author of this code. What do you think?
Best Regards,
Igor
On Thu, Feb 27, 2020 at 3:56 PM Aleksandr Shapkin wrote:
> Hello!
>
>
>
> I just noticed that the Java thin client throws the following internal
> exceptions:
>
That's right, only C++ and .NET clients have partition awareness
Best Regards,
Igor
On Tue, Mar 3, 2020 at 5:02 PM Artem Budnikov
wrote:
> Hi everyone,
>
> Looks like the following line from the Ignite 2.8 release notes is a bit
> of an overstatement and should be removed:
>
> > Added support
?
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/platforms/README.txt
>
> On Wed, 26 Feb 2020 at 21:42, Denis Magda wrote:
> >
> > Igor Sapego, Igniters,
> >
> > I've been working on Ignite website improvements that will be introduced
>
>
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Mar 25, 2020 at 5:47 AM Alex Plehanov >
> > > wrote:
> > >
> > > > Hello guys.
> > > >
> > > > I've implemented PoC and created IEP [1]
I'm not very experienced in Python, but if no one else wants
to take a look, I'll do it.
Best Regards,
Igor
On Sat, Mar 28, 2020 at 2:04 AM Denis Magda wrote:
> Igniters,
>
> Is any of you is skillful enough to contribute improvements to our Python
> thin client? For instance, that's one of th
My plan includes:
* Cluster API for C++ thick client
* Moving Python, Node.js and PHP thin clients in separate repositories and
separate release cycles.
* Partition Awareness for Python and Node.js thin clients
* SQL for C++ thin client.
Steven,
There are some third-party golang clients AFAIK, fo
Guys,
It was discussed on the dev list a few times that it would be a good
idea to move Python, Node.js and PHP thin clients to separate repos
and separate release cycles.
In short there are several arguments for that:
1. There are no dependencies on the core functionality so there is simply
no
sitive effect
> on
> > > community growth. Since newcomer may want to fix a bug and later use
> > result
> > > in his/her production environment.
> > >
> > > вт, 21 апр. 2020 г. в 13:27, Alexey Zinoviev :
> > >
> > >> Agree with thes
Great, this feature is long awaited.
1. I believe so. Since I've proposed Partition Awareness feature I was
thinking
about a way for clients to discover cluster nodes.
2. In my opinion a simple boolean flag is enough for the beginning. In
future
maybe we can add a node filter. This can be useful
t; client endpoints over 10.0.0.0/24 as well.
> >
> > We have to conform with IgniteConfiguration.LocalHost setting.
> > If it is not set, or set to 0.0.0.0, we should gather IPs from all
> > interfaces.
> > But if it is set to something, we should gather only matching
I guess it makes sense. If anyone needs more control over connection
we would need to implement a new feature anyway (like node filter we
discussed earlier)
Best Regards,
Igor
On Tue, Apr 28, 2020 at 12:29 PM Pavel Tupitsyn
wrote:
> > enable the capability if the best effort affinity is on
> I
;
> > > Ok, I've updated IEP and POC accordingly:
> > > * Config flag removed
> > > * IPs and host names retrieval simplified - use existing node
> properties
> > > and attributes instead of Compute
> > >
> > > On Tue, Apr 28, 2020 at 7:57 PM Ig
Great!
Let's start with creating a TC suite for it.
The only concern I have is that it is one more build system
to support. Should we get rid of autotools in 3.0?
Best Regards,
Igor
On Tue, May 26, 2020 at 2:44 PM Alexey Kukushkin
wrote:
> +1. I recently completed a cross-IDE (MS Visual Stud
e, so even this step (generation of project) is no
> more necessary.
>
>
> On 26.05.2020 16:02, Igor Sapego wrote:
> > Great!
> >
> > Let's start with creating a TC suite for it.
> >
> > The only concern I have is that it is one more build system
>
Pavel,
What's about "stop" message? How can user unsubscribe from receiving
notifications?
Also, I believe I've seen discussions on removing initial query from
continuous queries,
as there are not any guarantees about getting consistent results with them.
Should
we avoid adding them in thin proto
m continuous queries
> Interesting, I'm not aware of this. Can you please link those discussions?
>
> On Fri, Jul 10, 2020 at 2:04 PM Igor Sapego wrote:
>
> > Pavel,
> >
> > What's about "stop" message? How can user unsubscribe from receiv
icates issue with the initial query, but I
> did
> > > not
> > > >> give it a second thought.
> > > >>
> > > >> Now I see that Vladimir was right - Initial query seems to be
> > pointless,
> > > >> since users can
> > > >>
Guys,
Currently, Node.js, Python and PHP thin clients are not included in
Ignite release process, meaning we do not publish them on pip, npm,
etc during release and do not publish API references for these clients.
I propose to add steps to build and publish these client packages and
API documenta
t weird to me, can you please describe it
> in more detail?
>
> Thanks,
> Pavel
>
> On Mon, Aug 24, 2020 at 10:47 PM Denis Magda wrote:
>
>> @Pavel Tupitsyn , @Igor Sapego
>> ,
>>
>> Michael has been integrating Ignite with Micronaut and we hit some
>>
Hi, Val,
I've been working on my implementation for some time, but
didn't commit to it lately so it's pretty much abandoned. Maybe we should
join our forces here :)
Best Regards,
Igor
On Thu, Jul 2, 2020 at 1:00 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Pavel,
>
> Yes, I
Great, I'll take a look.
Best Regards,
Igor
On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky
wrote:
>
>
> Thanks Ivan Daschinsky for review, does anyone more who could check it ?
>
> thanks !
> >Igniters, seems i complete with transactions in thin cpp client
> >implementation [1], part of ie
Yes, it was an attempt to separate thick and thin clients as much as
possible
to move them in separate libs in future.
Alex, what do you think? What is the right path here from the Java
developer viewpoint?
Best Regards,
Igor
On Mon, Aug 24, 2020 at 9:40 AM Alex Plehanov
wrote:
> Hi Val,
>
>
Alexey, what do you think? Which Future should be used here?
Now, about the "not fully sync" interface - I believe this is acceptable as
a first
approach.
Best Regards,
Igor
On Mon, Aug 24, 2020 at 12:37 PM Pavel Tupitsyn
wrote:
> I've changed the IEP and added a new future interface to the P
Николай,
It looks a little bit hacky to me. I believe SQL drivers usually use that
approach
as a workaround because there is no other common way to do that.
Sure we can recommend users to use cache.size() or anything other
similar way
to ensure the connection is alive, but it still looks like a w
gt; > > On the other hand, dedicated `ping` operation makes our API heavier
> > > without adding new feature -
> > > We can do the same with the other part of the API.
> > >
> > > Moreover, response to the ping doesn’t mean that SQL or cache query can
> &g
Hi,
Can you share your ignite::binary::BinaryType::Read method where reading of
the std::vector is going on?
Also, are your strings large too or only vectors?
Best Regards,
Igor
On Mon, Sep 28, 2020 at 8:29 PM Brett Elliott wrote:
> Hello,
>
> Tl;dr: I'm doing some profiling, and the cpp thi
,
Igor
On Tue, Sep 29, 2020 at 11:22 AM Igor Sapego wrote:
> Hi,
>
> Can you share your ignite::binary::BinaryType::Read method where reading of
> the std::vector is going on?
>
> Also, are your strings large too or only vectors?
>
> Best Regards,
> Igor
>
>
> O
m is my own fault. Thanks for
> making me have a look at that again.
>
> Thanks,
> Brett
>
> -Original Message-
> From: Igor Sapego [mailto:isap...@apache.org]
> Sent: Tuesday, September 29, 2020 2:22 AM
> To: dev
> Subject: [EXTERNAL] Re: cpp thin client vector
Sounds like a good idea to me.
Best Regards,
Igor
On Mon, Nov 9, 2020 at 3:32 PM Alex Plehanov
wrote:
> +1 for using GridNioServer as java thin client communication layer.
>
> вс, 8 нояб. 2020 г. в 19:12, Pavel Tupitsyn :
>
> > Igniters,
> >
> > This is a continuation of "Use Netty for Java th
Pavel,
I totally support that. Also, if we are aiming for
stronger platform-independance,
in our schemas we may want to support bit-notation (int32, uint64)? For
example
"long" can mean a different type on different platforms and it's easy to
confuse
them (happens often when using ODBC for example
gt; >
> >
> >
> >
> > On Tue, Nov 24, 2020 at 2:04 PM Pavel Tupitsyn
> > wrote:
> >
> > > Agree, let's get rid of "long, short, byte" in the protocol definition.
> > >
> > > We can use Rust style, which is concise and
O
> > > [2] https://github.com/apache/ignite/pull/8483
> > >
> > > On Mon, Nov 9, 2020 at 4:07 PM Ivan Daschinsky
> > > wrote:
> > >
> > >> I suppose that the best variant -- ability to switch to netty if this
> > lib
> > >> is in
1 - 100 of 665 matches
Mail list logo
