[MTCGA]: new failures in builds [6093884] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New test failure in master GridCommandHandlerTest.testSuccessStopWarmUp https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4363338353725121117=%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 06:44:25 21-07-2021
Re: [Discussion] Race on heartbeat update in checkpoint thread
1. I mean calling listeners in CheckpointWorkflow.markCheckpointBegin(): This -- for (CheckpointListener lsnr : dbLsnrs) lsnr.beforeCheckpointBegin(ctx0); ctx0.awaitPendingTasksFinished(); -- And this: -- // Listeners must be invoked before we write checkpoint record to WAL. for (CheckpointListener lsnr : dbLsnrs) lsnr.onMarkCheckpointBegin(ctx0); ctx0.awaitPendingTasksFinished(); -- Inside lsnr.beforeCheckpointBegin(ctx0) and lsnr.onMarkCheckpointBegin(ctx0) we call CheckpointContextImpl.executor() which submit heartbeat update tasks in threadpool. But due to a bug in registration, ctx0.awaitPendingTasksFinished() do not work correctly. Checpoint thread does not wait for all tasks to complete and moves on. This could lead to other bugs because as written in the comment "// Listeners must be invoked before we write checkpoint record to WAL." 2. About the fix. Yes, the fix resolves the issue, but does not resolve the root cause - a race between checkpoint thread and threads run in asyncRunner. Also, as I understand, there should be no attempts to update heartbeat inside blockingSection, but the fix does not exclude such attempts but blocks them. 3. But my main point is that it looks strange to update the heartbeat of thread A from thread B. It's like doing artificial respiration and chest compressions. Thread A is waiting on async tasks completion, but these tasks are updating progress of thread A. I suppose that blockingSection was designed for such situations when the thread is waiting for something and does not perform any progress. вт, 20 июл. 2021 г. в 21:43, Ivan Daschinsky : > +1 For current fix. Code is clean and understandable. I suppose that the > current fix is a correct variant to update heartbeatTs. > > вт, 20 июл. 2021 г. в 16:13, Alex Plehanov : > > > Hello, Ilya > > > > > But anyway, I propose to remove the update of the heartbeat from other > > threads altogether and wrap the call to listeners in a blockingSection. > > I don't quite understand your proposal. Which call to listeners do you > > mean? If we wrap the listener into the blocking section the result will > be > > the same. > > Alternatively, I think we can wrap awaitPendingTasksFinished into the > > blocking section, this will also solve the problem, but in this case we > can > > never detect lack of progress by async executor threads and checkpointer > > thread hangs due to this reason. > > What's wrong with the current fix? It solves the current problem and I > hope > > will protect us from problems like this in the future. > > > > вт, 20 июл. 2021 г. в 15:28, Ilya Kazakov : > > > > > Hi Igniters, hi Alexey. > > > > > > I want to discuss this issue: > > > https://issues.apache.org/jira/browse/IGNITE-15099. I have caught it > > too. > > > > > > I was able to determine where there is a race. > > > > > > The update of the heartbeat happens asynchronously into the listener > > code. > > > But we always wait in the checkpoint thread for all pending async > > > tasks. And this is reasonable. > > > > > > for (CheckpointListener lsnr : dbLsnrs) > > > lsnr.beforeCheckpointBegin(ctx0); > > > > > > ctx0.awaitPendingTasksFinished(); > > > > > > The race was because of inappropriate order of future registration. In > > > CheckpointContextImpl.executor () (inside listeners execution) > > > > > > GridFutureAdapter res = new GridFutureAdapter<>(); > > > res.listen(fut -> heartbeatUpdater.updateHeartbeat()); > > > asyncRunner.execute(U.wrapIgniteFuture(cmd, res)); > > > pendingTaskFuture.add(res); > > > > > > Here we create a task, submit a task to the executor, and only after > this > > > do we register the task. Thus we got a situation where checkpointer > > thread > > > was moving on after ctx0.awaitPendingTasksFinished(); and still, > > > the unregistered asyncRunner task was moving on in parallel. > > > > > > But anyway, I propose to remove the update of the heartbeat from other > > > threads altogether and wrap the call to listeners in a blockingSection. > > > > > > As I understand heartbeat was designed just to indicate self-progress > by > > a > > > worker. If a worker can not indicate self-progress we should wrap such > > code > > > into blockingSections. In case of listeners, worker can not indicate > > > self-progress, thus let's wrap it into blockingSection. > > > > > > Guys, what do you think about this? > > > > > > - > > > Ilya Kazakov > > > > > > > > -- > Sincerely yours, Ivan Daschinskiy >
[MTCGA]: new failures in builds [6095041] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Thin client: Node.js https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ThinClientNodeJs?branch=%3Cdefault%3E 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 05:14:25 21-07-2021
[MTCGA]: new failures in builds [6094100] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Control Utility (Zookeeper) https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper?branch=%3Cdefault%3E 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 01:59:25 21-07-2021
Re: [DISCUSS] Confuse default inspections.
I totally agree.
Let's get rid of them.
вт, 20 июл. 2021 г. в 18:11, Konstantin Orlov :
> + for both
>
> --
> Regards,
> Konstantin Orlov
>
>
> > On 20 Jul 2021, at 16:32, Pavel Tupitsyn wrote:
> >
> > Agree with for both points
> >
> > On Tue, Jul 20, 2021 at 3:14 PM Alexander Polovtcev <
> alexpolovt...@gmail.com>
> > 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, lets talk about interfaces.
>
> 1. First of all, do we have an automatic inspection for it? AFAIK we
> >>> don't
> 2. I am for consistency. At least for production code. Nothing worse
> is
> when someone mixes both approaches.
>
> About a prohibition of curly brackets around one line -- I am strongly
> against this rule, it should be removed. There were a few bugs that
> >> this
> rule caused.
>
> вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky
> >>> > :
>
> >
> > Igniters, i understand that this is very long and fundamental story.
> >> but
> > … still want to rise up this discussion, we have 2 very strange
> > inspections:
> > * «public» modifier in interface methods.
> > * Illegal ‘{}’ for one line statement. — i found it harmful.
> > I don`t want to link additional discussion about pos. 2 i think that
> >>> harm
> > is obvious.
> > I suggest to get rid of them.
> >
> > what do you think ?
> >
> >
> >
>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
> >>>
> >>>
> >>> --
> >>>
> >>> Best regards,
> >>> Ivan Pavlukhin
> >>>
> >>
> >>
> >> --
> >> With regards,
> >> Aleksandr Polovtcev
> >>
>
>
--
Живи с улыбкой! :D
Re: [MEETUP] Join Apache Ignite 3.0 Alpha 2 Build Demo on July 20
Many thanks to all who attended the gathering and shared the feedback! Some of the questions I hope to see on the dev list soon. Here's the video: https://youtu.be/C3vfFWhKX-M пн, 19 июл. 2021 г. в 13:18, Kseniya Romanova : > Hi Igniters, if you'd like to get an update on Ignite 3.0 progress and > overview the following stages of development join community gathering on > July 20: https://hopin.to/events/apache-ignite-3-alpha > > TIMEZONES > 9 AM Pacific Standard Time > 12 PM Eastern Standard Time > 5 PM British Summer Time > 6 PM Central European Summer Time > 7 PM Israel Standard Time > 7 PM Moscow Time > 9:30 PM Indian Standard Time > > Links: > [1] The Alpha build of the next Apache Ignite major version is available > for internal testing at https://github.com/apache/ignite-3 > [2] Discussion > http://mail-archives.apache.org/mod_mbox/ignite-user/202101.mbox/%3CCABuYRcpgKQvTJDhSvqHOzKWJf5wN-mLKUHiNR5qyaNLvLsds8w%40mail.gmail.com%3E > [3] Wiki Page > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0 > [4] Getting Started Guide: > https://ignite.apache.org/docs/3.0.0-alpha/quick-start/getting-started-guide > [5] Apache Ignite 3.0: Major Changes and Features presentation > https://youtu.be/zPuLJgUfLaM > [6] Ignite 3.0 Alpha 1 Community Gathering https://youtu.be/zAVmKGRa1Jc > > Cheers, > Kseniya > > Devrel at GridGain > Don't miss upcoming community events, join > https://www.meetup.com/Apache-Ignite-Virtual-Meetup/ >
Re: [DISCUSS] Confuse default inspections.
+ for both
--
Regards,
Konstantin Orlov
> On 20 Jul 2021, at 16:32, Pavel Tupitsyn wrote:
>
> 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, lets talk about interfaces.
1. First of all, do we have an automatic inspection for it? AFAIK we
>>> don't
2. I am for consistency. At least for production code. Nothing worse is
when someone mixes both approaches.
About a prohibition of curly brackets around one line -- I am strongly
against this rule, it should be removed. There were a few bugs that
>> this
rule caused.
вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky
>>> :
>
> Igniters, i understand that this is very long and fundamental story.
>> but
> … still want to rise up this discussion, we have 2 very strange
> inspections:
> * «public» modifier in interface methods.
> * Illegal ‘{}’ for one line statement. — i found it harmful.
> I don`t want to link additional discussion about pos. 2 i think that
>>> harm
> is obvious.
> I suggest to get rid of them.
>
> what do you think ?
>
>
>
--
Sincerely yours, Ivan Daschinskiy
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Ivan Pavlukhin
>>>
>>
>>
>> --
>> With regards,
>> Aleksandr Polovtcev
>>
Re: [Discussion] Race on heartbeat update in checkpoint thread
+1 For current fix. Code is clean and understandable. I suppose that the current fix is a correct variant to update heartbeatTs. вт, 20 июл. 2021 г. в 16:13, Alex Plehanov : > Hello, Ilya > > > But anyway, I propose to remove the update of the heartbeat from other > threads altogether and wrap the call to listeners in a blockingSection. > I don't quite understand your proposal. Which call to listeners do you > mean? If we wrap the listener into the blocking section the result will be > the same. > Alternatively, I think we can wrap awaitPendingTasksFinished into the > blocking section, this will also solve the problem, but in this case we can > never detect lack of progress by async executor threads and checkpointer > thread hangs due to this reason. > What's wrong with the current fix? It solves the current problem and I hope > will protect us from problems like this in the future. > > вт, 20 июл. 2021 г. в 15:28, Ilya Kazakov : > > > Hi Igniters, hi Alexey. > > > > I want to discuss this issue: > > https://issues.apache.org/jira/browse/IGNITE-15099. I have caught it > too. > > > > I was able to determine where there is a race. > > > > The update of the heartbeat happens asynchronously into the listener > code. > > But we always wait in the checkpoint thread for all pending async > > tasks. And this is reasonable. > > > > for (CheckpointListener lsnr : dbLsnrs) > > lsnr.beforeCheckpointBegin(ctx0); > > > > ctx0.awaitPendingTasksFinished(); > > > > The race was because of inappropriate order of future registration. In > > CheckpointContextImpl.executor () (inside listeners execution) > > > > GridFutureAdapter res = new GridFutureAdapter<>(); > > res.listen(fut -> heartbeatUpdater.updateHeartbeat()); > > asyncRunner.execute(U.wrapIgniteFuture(cmd, res)); > > pendingTaskFuture.add(res); > > > > Here we create a task, submit a task to the executor, and only after this > > do we register the task. Thus we got a situation where checkpointer > thread > > was moving on after ctx0.awaitPendingTasksFinished(); and still, > > the unregistered asyncRunner task was moving on in parallel. > > > > But anyway, I propose to remove the update of the heartbeat from other > > threads altogether and wrap the call to listeners in a blockingSection. > > > > As I understand heartbeat was designed just to indicate self-progress by > a > > worker. If a worker can not indicate self-progress we should wrap such > code > > into blockingSections. In case of listeners, worker can not indicate > > self-progress, thus let's wrap it into blockingSection. > > > > Guys, what do you think about this? > > > > - > > Ilya Kazakov > > > -- Sincerely yours, Ivan Daschinskiy
Re: [DISCUSS] Confuse default inspections.
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, lets talk about interfaces.
> > >
> > > 1. First of all, do we have an automatic inspection for it? AFAIK we
> > don't
> > > 2. I am for consistency. At least for production code. Nothing worse is
> > > when someone mixes both approaches.
> > >
> > > About a prohibition of curly brackets around one line -- I am strongly
> > > against this rule, it should be removed. There were a few bugs that
> this
> > > rule caused.
> > >
> > > вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky
> > > >>:
> > >
> > >>
> > >> Igniters, i understand that this is very long and fundamental story.
> but
> > >> … still want to rise up this discussion, we have 2 very strange
> > >> inspections:
> > >> * «public» modifier in interface methods.
> > >> * Illegal ‘{}’ for one line statement. — i found it harmful.
> > >> I don`t want to link additional discussion about pos. 2 i think that
> > harm
> > >> is obvious.
> > >> I suggest to get rid of them.
> > >>
> > >> what do you think ?
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > > --
> > > Sincerely yours, Ivan Daschinskiy
> > >
> >
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >
>
>
> --
> With regards,
> Aleksandr Polovtcev
>
Re: [Discussion] Race on heartbeat update in checkpoint thread
Hello, Ilya > But anyway, I propose to remove the update of the heartbeat from other threads altogether and wrap the call to listeners in a blockingSection. I don't quite understand your proposal. Which call to listeners do you mean? If we wrap the listener into the blocking section the result will be the same. Alternatively, I think we can wrap awaitPendingTasksFinished into the blocking section, this will also solve the problem, but in this case we can never detect lack of progress by async executor threads and checkpointer thread hangs due to this reason. What's wrong with the current fix? It solves the current problem and I hope will protect us from problems like this in the future. вт, 20 июл. 2021 г. в 15:28, Ilya Kazakov : > Hi Igniters, hi Alexey. > > I want to discuss this issue: > https://issues.apache.org/jira/browse/IGNITE-15099. I have caught it too. > > I was able to determine where there is a race. > > The update of the heartbeat happens asynchronously into the listener code. > But we always wait in the checkpoint thread for all pending async > tasks. And this is reasonable. > > for (CheckpointListener lsnr : dbLsnrs) > lsnr.beforeCheckpointBegin(ctx0); > > ctx0.awaitPendingTasksFinished(); > > The race was because of inappropriate order of future registration. In > CheckpointContextImpl.executor () (inside listeners execution) > > GridFutureAdapter res = new GridFutureAdapter<>(); > res.listen(fut -> heartbeatUpdater.updateHeartbeat()); > asyncRunner.execute(U.wrapIgniteFuture(cmd, res)); > pendingTaskFuture.add(res); > > Here we create a task, submit a task to the executor, and only after this > do we register the task. Thus we got a situation where checkpointer thread > was moving on after ctx0.awaitPendingTasksFinished(); and still, > the unregistered asyncRunner task was moving on in parallel. > > But anyway, I propose to remove the update of the heartbeat from other > threads altogether and wrap the call to listeners in a blockingSection. > > As I understand heartbeat was designed just to indicate self-progress by a > worker. If a worker can not indicate self-progress we should wrap such code > into blockingSections. In case of listeners, worker can not indicate > self-progress, thus let's wrap it into blockingSection. > > Guys, what do you think about this? > > - > Ilya Kazakov >
[Discussion] Race on heartbeat update in checkpoint thread
Hi Igniters, hi Alexey. I want to discuss this issue: https://issues.apache.org/jira/browse/IGNITE-15099. I have caught it too. I was able to determine where there is a race. The update of the heartbeat happens asynchronously into the listener code. But we always wait in the checkpoint thread for all pending async tasks. And this is reasonable. for (CheckpointListener lsnr : dbLsnrs) lsnr.beforeCheckpointBegin(ctx0); ctx0.awaitPendingTasksFinished(); The race was because of inappropriate order of future registration. In CheckpointContextImpl.executor () (inside listeners execution) GridFutureAdapter res = new GridFutureAdapter<>(); res.listen(fut -> heartbeatUpdater.updateHeartbeat()); asyncRunner.execute(U.wrapIgniteFuture(cmd, res)); pendingTaskFuture.add(res); Here we create a task, submit a task to the executor, and only after this do we register the task. Thus we got a situation where checkpointer thread was moving on after ctx0.awaitPendingTasksFinished(); and still, the unregistered asyncRunner task was moving on in parallel. But anyway, I propose to remove the update of the heartbeat from other threads altogether and wrap the call to listeners in a blockingSection. As I understand heartbeat was designed just to indicate self-progress by a worker. If a worker can not indicate self-progress we should wrap such code into blockingSections. In case of listeners, worker can not indicate self-progress, thus let's wrap it into blockingSection. Guys, what do you think about this? - Ilya Kazakov
Re: [DISCUSS] Confuse default inspections.
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, lets talk about interfaces.
> >
> > 1. First of all, do we have an automatic inspection for it? AFAIK we
> don't
> > 2. I am for consistency. At least for production code. Nothing worse is
> > when someone mixes both approaches.
> >
> > About a prohibition of curly brackets around one line -- I am strongly
> > against this rule, it should be removed. There were a few bugs that this
> > rule caused.
> >
> > вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky
> >>:
> >
> >>
> >> Igniters, i understand that this is very long and fundamental story. but
> >> … still want to rise up this discussion, we have 2 very strange
> >> inspections:
> >> * «public» modifier in interface methods.
> >> * Illegal ‘{}’ for one line statement. — i found it harmful.
> >> I don`t want to link additional discussion about pos. 2 i think that
> harm
> >> is obvious.
> >> I suggest to get rid of them.
> >>
> >> what do you think ?
> >>
> >>
> >>
> >
> >
> >
> > --
> > Sincerely yours, Ivan Daschinskiy
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>
--
With regards,
Aleksandr Polovtcev
Re: [Announcement] Apache Ignite 2.11 Code Freeze started
Folks, Since the release branch was created some time ago, should we bump up the master branch version to the next one? On Thu, 1 Jul 2021 at 17:15, Alexey Gidaspov wrote: > > Hi, Pavel. > > I think, it looks like blocker. Please cherry-pick it to 2.11 release branch > > On 2021/07/01 09:29:57, Pavel Pereslegin wrote: > > Hello, Alexey! > > > > Is it possible to include a hotfix that corrects the command syntax > > output in the control script? [1] > > > > This bug can significantly complicate the use of the snapshot restore > > function (one of the important features of 2.11). In addition, this > > may raise a number of questions to the product support, which we can > > prevent by adding this patch in 2.11. > > > > This patch does not affect any functions other than the "help" output > > of the control script. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14989 > > > > чт, 1 июл. 2021 г. в 11:56, Alexey Gidaspov : > > > > > > Hi, Iilya! > > > > > > As I can see, this feature highly improves debugging during incidents. So > > > I think we can call it blocker and cherry-pick to ignite-2.11 branch > > > > > > On 2021/06/30 20:26:43, Shishkov Ilya wrote: > > > > Hello, Alexey! > > > > Is it possible to add system views for BaselineNode attributes [1] and > > > > corresponding documentation [2] to 2.11? > > > > > > > > 1. https://issues.apache.org/jira/browse/IGNITE-15007 > > > > 2. https://issues.apache.org/jira/browse/IGNITE-15028 > > > > > > > > ср, 30 июн. 2021 г. в 11:07, Nikita Amelchev : > > > > > > > > > Thanks! I have cherry-picked the commit to the 2.11 branch. > > > > > > > > > > ср, 30 июн. 2021 г. в 11:00, Alexey Gidaspov : > > > > > > > > > > > > Hi, Nikita! > > > > > > > > > > > > I think it's important fix and should be included in 2.11 release. > > > > > > I've > > > > > tagged ticket by fixVersion 2.11. Can you cherry-pick it to > > > > > ignite-2.11 > > > > > branch? And please fill release notes or delete flag. > > > > > > > > > > > > On 2021/06/30 07:55:04, Nikita Amelchev > > > > > > wrote: > > > > > > > Hello, Alexey. > > > > > > > > > > > > > > I suggest adding to the 2.11 scope the resolved issue [1]. It > > > > > > > fixes > > > > > > > incorrect values of cache, cache groups, data region metrics after > > > > > > > cluster reactivation. > > > > > > > WDYT? > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14990 > > > > > > > > > > > > > > вт, 29 июн. 2021 г. в 15:09, Alexey Gidaspov > > > > > > > : > > > > > > > > > > > > > > > > Ok, we can add this fix to release scope. > > > > > > > > > > > > > > > > On 2021/06/29 08:36:00, Сурков Александр > > > > > Викторович wrote: > > > > > > > > > Hi Alexey. > > > > > > > > > > > > > > > > > > I think need add ticket: JmxMetricExporter fails to export > > > > > discovery metrics - https://issues.apache.org/jira/browse/IGNITE-14376 > > > > > > > > > > > > > > > > > > On 2021/06/15 14:43:55, Alexey Gidaspov > > > > > > > > > wrote: > > > > > > > > > > Apache Ignite 2.11 Code Freeze started now> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Best wishes, > > > > > > > Amelchev Nikita > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best wishes, > > > > > Amelchev Nikita > > > > > > > > > > >
Re: Not enough permissions to run RC build
It's OK now. Thank you. On 2021/07/20 07:44:19, Petr Ivanov wrote: > Check you permissions now, please. > > > > > On 20 Jul 2021, at 10:24, Alexey Gidaspov wrote: > > > > Petr, my login is agidaspov > > > > On 2021/07/20 07:22:26, Petr Ivanov wrote: > >> Aleksey — what is your login / email in TC? > >> > >> > >>> On 19 Jul 2021, at 16:10, Alexey Gidaspov wrote: > >>> > >>> No, but I'm release manager for 2.11 release and I think I should be able > >>> to run RC build. > >>> > >>> On 2021/07/19 12:47:46, Petr Ivanov wrote: > Hi! > > > Are you committer or PMC on Apache Ignite? > > > > On 19 Jul 2021, at 14:40, Alexey Gidaspov wrote: > > > > Hi, All! > > > > I've found out that I don't have enough permissions to run RC build for > > ignite-2.11 branch on TC. Can anyone help me? > > > >> > >> > >
Re: Not enough permissions to run RC build
Check you permissions now, please. > On 20 Jul 2021, at 10:24, Alexey Gidaspov wrote: > > Petr, my login is agidaspov > > On 2021/07/20 07:22:26, Petr Ivanov wrote: >> Aleksey — what is your login / email in TC? >> >> >>> On 19 Jul 2021, at 16:10, Alexey Gidaspov wrote: >>> >>> No, but I'm release manager for 2.11 release and I think I should be able >>> to run RC build. >>> >>> On 2021/07/19 12:47:46, Petr Ivanov wrote: Hi! Are you committer or PMC on Apache Ignite? > On 19 Jul 2021, at 14:40, Alexey Gidaspov wrote: > > Hi, All! > > I've found out that I don't have enough permissions to run RC build for > ignite-2.11 branch on TC. Can anyone help me? >> >>
Re: Not enough permissions to run RC build
Petr, my login is agidaspov On 2021/07/20 07:22:26, Petr Ivanov wrote: > Aleksey — what is your login / email in TC? > > > > On 19 Jul 2021, at 16:10, Alexey Gidaspov wrote: > > > > No, but I'm release manager for 2.11 release and I think I should be able > > to run RC build. > > > > On 2021/07/19 12:47:46, Petr Ivanov wrote: > >> Hi! > >> > >> > >> Are you committer or PMC on Apache Ignite? > >> > >> > >>> On 19 Jul 2021, at 14:40, Alexey Gidaspov wrote: > >>> > >>> Hi, All! > >>> > >>> I've found out that I don't have enough permissions to run RC build for > >>> ignite-2.11 branch on TC. Can anyone help me? > >> > >> > >
Re: Not enough permissions to run RC build
Aleksey — what is your login / email in TC? > On 19 Jul 2021, at 16:10, Alexey Gidaspov wrote: > > No, but I'm release manager for 2.11 release and I think I should be able to > run RC build. > > On 2021/07/19 12:47:46, Petr Ivanov wrote: >> Hi! >> >> >> Are you committer or PMC on Apache Ignite? >> >> >>> On 19 Jul 2021, at 14:40, Alexey Gidaspov wrote: >>> >>> Hi, All! >>> >>> I've found out that I don't have enough permissions to run RC build for >>> ignite-2.11 branch on TC. Can anyone help me? >> >>
Re: [DISCUSS] Confuse default inspections.
+ for both points.
2021-07-20 9:56 GMT+03:00, Ivan Daschinsky :
> Hi!
>
> Firstly, lets talk about interfaces.
>
> 1. First of all, do we have an automatic inspection for it? AFAIK we don't
> 2. I am for consistency. At least for production code. Nothing worse is
> when someone mixes both approaches.
>
> About a prohibition of curly brackets around one line -- I am strongly
> against this rule, it should be removed. There were a few bugs that this
> rule caused.
>
> вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky >:
>
>>
>> Igniters, i understand that this is very long and fundamental story. but
>> … still want to rise up this discussion, we have 2 very strange
>> inspections:
>> * «public» modifier in interface methods.
>> * Illegal ‘{}’ for one line statement. — i found it harmful.
>> I don`t want to link additional discussion about pos. 2 i think that harm
>> is obvious.
>> I suggest to get rid of them.
>>
>> what do you think ?
>>
>>
>>
>
>
>
> --
> Sincerely yours, Ivan Daschinskiy
>
--
Best regards,
Ivan Pavlukhin
Re: [DISCUSS] Confuse default inspections.
Hi!
Firstly, lets talk about interfaces.
1. First of all, do we have an automatic inspection for it? AFAIK we don't
2. I am for consistency. At least for production code. Nothing worse is
when someone mixes both approaches.
About a prohibition of curly brackets around one line -- I am strongly
against this rule, it should be removed. There were a few bugs that this
rule caused.
вт, 20 июл. 2021 г. в 09:23, Zhenya Stanilovsky :
>
> Igniters, i understand that this is very long and fundamental story. but
> … still want to rise up this discussion, we have 2 very strange inspections:
> * «public» modifier in interface methods.
> * Illegal ‘{}’ for one line statement. — i found it harmful.
> I don`t want to link additional discussion about pos. 2 i think that harm
> is obvious.
> I suggest to get rid of them.
>
> what do you think ?
>
>
>
--
Sincerely yours, Ivan Daschinskiy
[ANNOUNCE] Release pyignite-0.5.1
Igniters! I suppose it is time to release pyignite 0.5.1. There are few good features available and some users are eager to try it. 1. Added ability to record clients' events by event listeners. This is a quite agile mechanism, and it allows writing custom metrics, tracing and debugging. 2. Added debug logging When implementing these features, I have found and fixed a few bugs thanks for excessive logging and events. (see release notes of [1]). Also I want to implement one minor feature that can be useful (ability to set handshake timeout). I am going to implement it in a few days. [2] Full list of tickets for release is here [3] I think that code freeze will be at 15:00 UTC 07/23. And on monday, 07/26 we will publish a release candidate for voting. WDYT? [1] -- https://issues.apache.org/jira/browse/IGNITE-15102 [2] -- https://issues.apache.org/jira/browse/IGNITE-15118 [3] -- https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20python-0.5.1
[DISCUSS] Confuse default inspections.
Igniters, i understand that this is very long and fundamental story. but …
still want to rise up this discussion, we have 2 very strange inspections:
* «public» modifier in interface methods.
* Illegal ‘{}’ for one line statement. — i found it harmful.
I don`t want to link additional discussion about pos. 2 i think that harm is
obvious.
I suggest to get rid of them.
what do you think ?
