Re: Hello Apache Ignite Community
Hi Kevin, Welcome to the community! I do believe Ignite will benefit a lot by having you as a contributor. I’ll share with you social media credentials privately. Denis On Wednesday, August 18, 2021, Kevin Corbett wrote: > Dear Team, > > Hi all! I am a social media manager looking to help contribute to the > Ignite community. > > A little about me: I recently got my degree in computer science and I have > a lot of experience with running the social media channels for my personal > YouTube channel as well as a gaming community outside of my professional > work experience. > > I think that Ignite could use some love on that front. We can ramp up > awareness through social media, especially Twitter which I feel has not yet > been used to it’s greatest potential. > > Is there any way I could get access to the Apache Ignite Twitter account? > :) > I feel that there’s a lot of great stuff that can be shared there and we > can reach a large audience of developers on Twitter to engage with. > > Thanks! > Kevin -- - Denis
Hello Apache Ignite Community
Dear Team, Hi all! I am a social media manager looking to help contribute to the Ignite community. A little about me: I recently got my degree in computer science and I have a lot of experience with running the social media channels for my personal YouTube channel as well as a gaming community outside of my professional work experience. I think that Ignite could use some love on that front. We can ramp up awareness through social media, especially Twitter which I feel has not yet been used to it’s greatest potential. Is there any way I could get access to the Apache Ignite Twitter account? :) I feel that there’s a lot of great stuff that can be shared there and we can reach a large audience of developers on Twitter to engage with. Thanks! Kevin
Re: [DISCUSSION] Send documentation feedback notifications to dev list
I guess we haven't seen a notification for this issue because messages from Bugyard need to be moderated. Thanks for catching that. Igor, Nikita, could you please step in and look into the reported ticket and the notification delivery issue. As for other services, I meant that we usually link our accounts on the services below to the dev@ or private@ lists. They don't send notifications regularly, but I saw a few when accounts were created. https://svn.apache.org/repos/private/pmc/ignite/credentials/ - Denis On Sun, Aug 15, 2021 at 4:02 PM Ivan Pavlukhin wrote: > 1. Unfortunately Bugyard notifications support looks not great. I see > a first real feedback item in app [1] but do not see it on dev list. > Actually I suppose documentation feedback digest would solve all > problems (if delivery works fine) but they do not have such feature. > 2. It looks sane to see how it goes first. Unfortunately I have time > to follow discussions occasionally, so I started this when I had time. > 3. What other feedback services message to dev list? > > [1] > https://app.bugyard.io/public/app/rycqZJDyY/f/6114c25933d82400145d8adc?sort=recent=new,in%20progress,implemented > > 2021-08-15 20:33 GMT+03:00, Denis Magda : > > I would leave everything as is and come back to this question if the > volume > > mounts. The notifications@ and issues@ are too busy - it will be easy to > > miss doc feedback that is shared once in a while. Plus, apart from the > > notifications, it's better to have a single dev@ account on this > service so > > that any community member can log in and handle feedback (we already > follow > > this practice for other services). > > > > - > > Denis > > > > > > On Monday, August 9, 2021, Ivan Pavlukhin wrote: > > > >> Igniters, > >> > >> Recently documentation feedback notifications were set up. And > >> currently destination for such notifications is dev list > >> dev@ignite.apache.org. It was announced in [1]. A notification message > >> itself looks as [2]. > >> > >> Let's discuss if we all are fine with this notifications on dev list > >> as much effort was spent for keeping dev list clean, e.g. [3]. For me > >> personally these notifications are some kind of "noice" as I read the > >> list on spare time. > >> > >> Please share your opinion! Formal vote will be started if needed. > >> > >> [1] > >> > https://lists.apache.org/thread.html/rf6b0ee140239ae119c97fe4022316b4e2f5c9f06a677bace5033e313%40%3Cdev.ignite.apache.org%3E > >> [2] > >> > https://lists.apache.org/thread.html/rbd7c06f76559f46bc2872484529bc4fa1c503d705b6cc379156f0bb0%40%3Cdev.ignite.apache.org%3E > >> [3] > >> > https://lists.apache.org/thread.html/rbd7c06f76559f46bc2872484529bc4fa1c503d705b6cc379156f0bb0%40%3Cdev.ignite.apache.org%3E > >> > >> -- > >> > >> Best regards, > >> Ivan Pavlukhin > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: Secondary TeamCity instance: ci2.ignite.apache.org
Hi Folks, Thanks to Vitaly Osipov, to infra , and to Peter Ivanov https://ci2.ignite.apache.org/ is working now. You can use your current account credentials from ci to log in. Final setup is not finished, so RunAll can't be executed there, but some test steps you can do now. At least, check login, check some separate suite execution (excepting .net) Sincerely, Dmitriy Pavlov On 2021/08/03 15:33:04, 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 > >
Re: [Discussion] Race on heartbeat update in checkpoint thread
Alexey, Ilya, I took a look at the problem and corresponding fixes. It seems that you are both right. But Alexey's fix looks like some kind of hack to me. We have two problems: 1. Heartbeat update from thread that will complete a future. I agree with Ilya and Andrey. Only a critical worker itself can update heartbeat. So, removal of `res.listen(fut -> heartbeatUpdater.updateHeartbeat());` from CheckpointContextImpl#executor() method is a good idea. It will avoid a race and makes Alexey's fix redundant. 2. blockingSection in checkpointer thread really can never detect the lack of pending tasks progress. Alexey is right. It is a problem. But what I actually see: checkpointWritePageThreads and checkpointCollectInfoThreads which execute pending tasks, are actually critical themselves and should be also monitored by WorkersRegistry. In such a case the checkpointer thread can safely use blocking sections at places designated by Ilya and forementioned threads should also use blocking sections on IO operations. So proposal: - Remove Alexey's fix - Remove asynchronous heartbeat update - Add blocking sections (fix of Ilya) - Monitor checkpointWritePageThreads and checkpointCollectInfoThreads if they exist (it depends on configuration) WDYT? On Thu, Jul 29, 2021 at 5:48 AM Ilya Kazakov wrote: > > Guys. I have discussed just these changes. Look at my PR, please. What do > you think? > > https://issues.apache.org/jira/browse/IGNITE-15192 > https://github.com/apache/ignite/pull/9280/files > > чт, 22 июл. 2021 г. в 22:30, Andrey Mashenkov : > > > Hi guys, > > > > I think updateHeartBeat() method was misused in the future listener and > > this must be fixed. > > > > Actually, GridWorker.heartbeatTs Javadoc says that field is updated by the > > worker itself. > > It is consistent with WorkProgressDispatcher.updateHearbeat() javadoc, > > which said "Notifying dispatcher that work is in progress and thread didn't > > freeze." > > GridWorker.heartbeatTs field is marked volatile just to provide consistent > > visibility guarantee to a watcher. > > > > So, CheckpointPagesWriter violates this contract, when runs in another > > thread(s). > > But it works fine just because the main (Checkpointer) thread waits for > > all the Writers to finish their work before it can fall into the blocking > > section, therefore there is no race possible. > > > > As for the broken case, there are 2 possible solutions, > > 1. Main thread must wait for all children's tasks to finish before going > > into the blocking section. > > 2. Or make updateHeartbeat consistent with the blockingSectionBegin/End. > > Seems, there is no need to mark the method as synchronized, but use call > > AtomicLongFieldUpdater.getAndUpdate(this, v -> v == Long.MAX_VALUE ? v : > > U.currentTimeMillis()). > > > > I'd suggest > > * Remove the "thread" mentioning from WorkProgressDispatcher interface to > > avoid confusion with the current usage and make WorkProgressDispatcher more > > general. > > * Avoid unsafe heartbeatUpdater leak to the outside via wrapping > > CheckpointContextImpl.heartbeatUpdater instance to perform consistent > > heartbeat update from p.2 above. > > > > Does it make sense? > > > > On Wed, Jul 21, 2021 at 11:12 AM Alex Plehanov > > wrote: > > > >> Ilya, > >> > >> Race only affects the future listener (which only updates heartbeat), but > >> not checkpoint listeners, so no other bugs possible caused by this race > >> except wrong heartbeat update. > >> > >> As I've written before, I think it's not a good idea to wait for other > >> threads by the critical thread in the blocking section. If these threads > >> are not monitored we can never detect lack of progress and never trigger > >> the failure handler. Perhaps a good solution will be to register async > >> threads as critical threads (additionally to waiting for these threads in > >> the blocing section) and update their own heartbeat. But the current fix > >> is > >> required too, to avoid such problems for other critical threads in the > >> future. > >> > >> ср, 21 июл. 2021 г. в 06:29, Ilya Kazakov : > >> > >> > 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
