[MTCGA]: new failures in builds [6120835] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *Test with high flaky rate in master-nightly CdcSelfTest.testMultiNodeConsumption[specificConsistentId=false, walMode=LOG_ONLY] https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4375390217325731493=%3Cdefault%3E=testDetails No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 02:48:36 12-08-2021
Re: IGNITE-15256 request for review
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 "green visa", which means that you need to run TeamCity bot and receive no blockers (see "Submitting for Review" section here [1]) Feel free to ask questions, if something is unclear. [1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute ср, 11 авг. 2021 г. в 16:52, ткаленко кирилл : > Hi, in the beginning it is worth getting a green visa. > > 11.08.2021, 15:21, "Ivan Fedorenkov" : > > Dear Ignite Devs, > > > > I would like to contribute a fix that addresses a bug associated with > > registration of user types by Ignite Java Thin Client. Could someone > please > > review the code? https://github.com/apache/ignite/pull/9307 > > > > Problem description: when Java Thin Client reestablishes connection to > > Ignite and invokes a Service API method with Externalizable input > parameter > > server node may throw ClassNotFoundException and client marks the > > connection as broken and tries to open a new one. > > > > Root cause: Ignite server nodes may lose all the registered user types > > after restart if Ignite Working Dir gets deleted or cluster moves to > > another set of hosts. Clients, at the same time, believe that they have > > already registered their user types and they skip registration after > > reconnecting. > > > > Please note that this is my first PR into Ignite repo and I may easily > miss > > some important details. > > > > Best regards, > > Ivan Fedorenkov >
Re: IGNITE-15256 request for review
Hi, in the beginning it is worth getting a green visa. 11.08.2021, 15:21, "Ivan Fedorenkov" : > Dear Ignite Devs, > > I would like to contribute a fix that addresses a bug associated with > registration of user types by Ignite Java Thin Client. Could someone please > review the code? https://github.com/apache/ignite/pull/9307 > > Problem description: when Java Thin Client reestablishes connection to > Ignite and invokes a Service API method with Externalizable input parameter > server node may throw ClassNotFoundException and client marks the > connection as broken and tries to open a new one. > > Root cause: Ignite server nodes may lose all the registered user types > after restart if Ignite Working Dir gets deleted or cluster moves to > another set of hosts. Clients, at the same time, believe that they have > already registered their user types and they skip registration after > reconnecting. > > Please note that this is my first PR into Ignite repo and I may easily miss > some important details. > > Best regards, > Ivan Fedorenkov
Re: Secondary TeamCity instance: ci2.ignite.apache.org
Thanks to Vitaly Osipov for creating a request, waiting for infra to set it up: https://issues.apache.org/jira/browse/INFRA-22190 On 2021/08/04 07:50:36, Anton Vinogradov wrote: > Great news! > Wish you good luck with this undertaking! > P.s. ci2.i.a.o sounds good to me. > > On Tue, Aug 3, 2021 at 7:36 PM Petr Ivanov wrote: > > > Seems that preserving and syncing users will be difficult to achieve — > > that info is stored in DB, and partial DB replication is tricky. > > > > Also ci2.ignite.apache.org is good name, but currently it is targeted the > > same IP as original one: > > ; ANSWER SECTION: > > ci2.ignite.apache.org. 1726IN A 195.144.253.150 > > > > > > > > > On 3 Aug 2021, at 18:33, 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 intended to be a geo-independent, secondary instance with > > availablility for community members. > > > > > > Thanks to JetBrains for providing license keys for TeamCity as their > > part of opensource sponsoring program. > > > > > > Most likely, we'll setup some domain name as tc.i.a.o or ci2.i.a.o. > > Please share your vision what would be most obvious. > > > > > > After a private discussions with Vitaliy Osipov and Petr Ivanov, I do > > believe that it would be possible to preserve current registered users. > > Build configurations are to be the same for the secondary instance. > > Technical details on how is could be achieved will be available later (most > > likely we'll start a sepearate thread to dicuss that). > > > > > > You are more than welcome to be an early adopters. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > > >
IGNITE-15256 request for review
Dear Ignite Devs, I would like to contribute a fix that addresses a bug associated with registration of user types by Ignite Java Thin Client. Could someone please review the code? https://github.com/apache/ignite/pull/9307 Problem description: when Java Thin Client reestablishes connection to Ignite and invokes a Service API method with Externalizable input parameter server node may throw ClassNotFoundException and client marks the connection as broken and tries to open a new one. Root cause: Ignite server nodes may lose all the registered user types after restart if Ignite Working Dir gets deleted or cluster moves to another set of hosts. Clients, at the same time, believe that they have already registered their user types and they skip registration after reconnecting. Please note that this is my first PR into Ignite repo and I may easily miss some important details. Best regards, Ivan Fedorenkov
Re: [ANNOUNCE] Welcome Alexander Shapkin as a new committer
Congratulations, Aleksandr! > On 11 Aug 2021, at 12:10, Pavel Tupitsyn wrote: > > The Project Management Committee (PMC) for Apache Ignite has invited > Alexander Shapkin to become a committer and we are pleased to announce that > he has accepted. > > Alexander is one of the most active user supporters and has contributed > new features and improvements to the code. > > Being a committer 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
Re: [ANNOUNCE] Welcome Alexander Shapkin as a new committer
My regards! 8/11/2021 12:10 PM, Pavel Tupitsyn пишет: The Project Management Committee (PMC) for Apache Ignite has invited Alexander Shapkin to become a committer and we are pleased to announce that he has accepted. Alexander is one of the most active user supporters and has contributed new features and improvements to the code. Being a committer 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
Re: [DISCUSSION] Allow use QuerySqlField.precision for varlen types
Hi, I suppose that we should add javadoc to QuerySqlFileds. It is weird that this feature is not documented. ср, 11 авг. 2021 г. в 00:08, Maksim Timonin : > Hi, Igniters! > > I dived to the precision param of QuerySqlField and SQL data types. The > javadocs of QuerySqlField say that the param is for decimal type only. But > actually it works for String fields out of the box. So it looks like an > easter egg. I think we should either document it or forbid it. > > Also I wonder why it works for String, but not for byte[] (analogue of > binary SQL data type). I made a few minor fixes and then it started to work > [1]. > > I think that QuerySqlField precision should work the same way as for SQL > variable length types - varchar, binary. Then I propose to allow apply > QuerySqlField.precision on String and byte[]. Is there a known reason to > avoid it? > > WDYT? > > [1] I've prepared a PR with patch for binary types, and tests for precision > (QuerySqlField and SQL), and fix the javadoc - > https://github.com/apache/ignite/pull/9315 > > P.S. I discovered that IgniteDataStreamer ignores the precision parameter > for QuerySqlField. I found a ticket that is also broken for notNull - > https://issues.apache.org/jira/browse/IGNITE-10999. It just doesn't work > at > all, not only about notNull. > -- Sincerely yours, Ivan Daschinskiy
[ANNOUNCE] Welcome Alexander Shapkin as a new committer
The Project Management Committee (PMC) for Apache Ignite has invited Alexander Shapkin to become a committer and we are pleased to announce that he has accepted. Alexander is one of the most active user supporters and has contributed new features and improvements to the code. Being a committer 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
