[jira] [Created] (IGNITE-10839) Web Console: Email confirmation
Alexey Kuznetsov created IGNITE-10839: - Summary: Web Console: Email confirmation Key: IGNITE-10839 URL: https://issues.apache.org/jira/browse/IGNITE-10839 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.8 Any user can register on Web Console, but it may be not desired behavior. Lets add an option to enable registration via e-mail confirmation. This will also ensure that e-mail is correct and can be used for password reset. By default, this option should be disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [MTCGA]: new failures in builds [2662229, 2662228] needs to be handled
Nikolay, thank you for fixing чт, 27 дек. 2018 г. в 23:00, Dmitriy Pavlov : > Thanks to Michail Petrov we have now TC Bot notifications on compilation > failures. > > > чт, 27 дек. 2018 г. в 22:07, : > >> Hi Igniters, >> >> I've detected some new issue on TeamCity to be handled. You are more >> than welcomed to help. >> >> If your changes can lead to this failure(s): We're grateful that you >> were a volunteer to make the contribution to this project, but things >> change and you may no longer be able to finalize your contribution. >> Could you respond to this email and indicate if you wish to continue and >> fix test failures or step down and some committer may revert you commit. >> >> *New Critical Failure in master _Javadoc_ >> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc&branch=%3Cdefault%3E&tab=buildTypeStatusDiv >> Changes may lead to failure were done by >> - eshangareev >> https://ci.ignite.apache.org/viewModification.html?modId=855404 >> - oignatenko >> https://ci.ignite.apache.org/viewModification.html?modId=855401 >> - oignatenko >> https://ci.ignite.apache.org/viewModification.html?modId=855397 >> >> *New Critical Failure in master ~Build Apache Ignite~ >> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite&branch=%3Cdefault%3E&tab=buildTypeStatusDiv >> Changes may lead to failure were done by >> - eshangareev >> https://ci.ignite.apache.org/viewModification.html?modId=855404 >> - oignatenko >> https://ci.ignite.apache.org/viewModification.html?modId=855401 >> - oignatenko >> https://ci.ignite.apache.org/viewModification.html?modId=855397 >> >> - 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 22:07:01 27-12-2018 >> >
Re: [MTCGA]: new failures in builds [2662229, 2662228] needs to be handled
Thanks to Michail Petrov we have now TC Bot notifications on compilation failures. чт, 27 дек. 2018 г. в 22:07, : > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were > a volunteer to make the contribution to this project, but things change and > you may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and > fix test failures or step down and some committer may revert you commit. > > *New Critical Failure in master _Javadoc_ > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc&branch=%3Cdefault%3E&tab=buildTypeStatusDiv > Changes may lead to failure were done by > - eshangareev > https://ci.ignite.apache.org/viewModification.html?modId=855404 > - oignatenko > https://ci.ignite.apache.org/viewModification.html?modId=855401 > - oignatenko > https://ci.ignite.apache.org/viewModification.html?modId=855397 > > *New Critical Failure in master ~Build Apache Ignite~ > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite&branch=%3Cdefault%3E&tab=buildTypeStatusDiv > Changes may lead to failure were done by > - eshangareev > https://ci.ignite.apache.org/viewModification.html?modId=855404 > - oignatenko > https://ci.ignite.apache.org/viewModification.html?modId=855401 > - oignatenko > https://ci.ignite.apache.org/viewModification.html?modId=855397 > > - 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 22:07:01 27-12-2018 >
[jira] [Created] (IGNITE-10838) Ignite wrap byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array
Evgenii Zhuravlev created IGNITE-10838: -- Summary: Ignite wrap byte[] value with UserCacheObjectByteArrayImpl before saving it and copying the whole array Key: IGNITE-10838 URL: https://issues.apache.org/jira/browse/IGNITE-10838 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev I assume it was created for heap cache before 2.0, while it doesn't make sense for off-heap cache since it will be copied in any case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10837) control.sh --baseline should output node IP addresses
Max Shonichev created IGNITE-10837: -- Summary: control.sh --baseline should output node IP addresses Key: IGNITE-10837 URL: https://issues.apache.org/jira/browse/IGNITE-10837 Project: Ignite Issue Type: Improvement Affects Versions: 2.5, 2.8 Reporter: Max Shonichev Fix For: 2.8 control.sh --baseline outputs node's consistent IDs it would be very useful, if it also output node's IP addresses. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[MTCGA]: new failures in builds [2662229, 2662228] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. If your changes can lead to this failure(s): We're grateful that you were a volunteer to make the contribution to this project, but things change and you may no longer be able to finalize your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master _Javadoc_ https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc&branch=%3Cdefault%3E&tab=buildTypeStatusDiv Changes may lead to failure were done by - eshangareev https://ci.ignite.apache.org/viewModification.html?modId=855404 - oignatenko https://ci.ignite.apache.org/viewModification.html?modId=855401 - oignatenko https://ci.ignite.apache.org/viewModification.html?modId=855397 *New Critical Failure in master ~Build Apache Ignite~ https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite&branch=%3Cdefault%3E&tab=buildTypeStatusDiv Changes may lead to failure were done by - eshangareev https://ci.ignite.apache.org/viewModification.html?modId=855404 - oignatenko https://ci.ignite.apache.org/viewModification.html?modId=855401 - oignatenko https://ci.ignite.apache.org/viewModification.html?modId=855397 - 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 22:07:01 27-12-2018
Re: System Worker Failure Handler on local laptop
Folks, What are the current timeouts? We need to know the probability of failures in dev environment. This affect usability. -- Denis On Thu, Dec 27, 2018 at 4:59 AM Alexey Goncharuk wrote: > Nikolay, > > Yes, the fix is already in master. Looks like I was wrong, in your case > failure handler is triggered by 'Node is stopping: grid-2'. Can you please > share the full trace? > > > > чт, 27 дек. 2018 г. в 12:41, Nikolay Izhikov : > > > Alexey > > > > Fix for this issue already in master? > > I run tests on current master. > > > > > Should we somehow announce it on the user-list or highlight on > readme.io > > ? > > > > I don't think our users will be happy to users stuck with this behavior > in > > production. > > > > Am I understand you correctly: > > If someone use 2.7. release and Ignite process slowing for a few seconds > > for any reason(low-end hardwre, VM pause, other processes grab the > > resources) then Ignite node will be stopped? > > > > > This is the issue I mentioned in "Critical worker threads liveness > > checking > > drawbacks" topic > > > > Thanks for the link, I will check it out. > > > > чт, 27 дек. 2018 г. в 12:24, Alexey Goncharuk < > alexey.goncha...@gmail.com > > >: > > > > > Hi Nikolay, > > > > > > This is the issue I mentioned in "Critical worker threads liveness > > checking > > > drawbacks" topic which I was expecting to be included to Ignite 2.7, > but > > it > > > was not. To workaround the issue, you should set > > > DataStorageConfiguration#setCheckpointReadLockTimeout to 0. > > > > > > Should we somehow announce it on the user-list or highlight on > readme.io > > ? > > > > > > чт, 27 дек. 2018 г. в 11:57, Nikolay Izhikov : > > > > > > > Hello, Igniters. > > > > > > > > I run into issue with critical system worker failure handler. > > > > I just run `IgniteDataFrameSuite` and it terminates on random test. > > > > My laptop doesn't have bleeding edge hardware, so tests can take > > > > significant amount of time. > > > > Looks like our watch dog too aggressive on development environment > > > > > > > > Can you please, help me. What should I do to configure or turn off > > watch > > > > dog? > > > > Should we relax it a little bit? At least for a test environment. > > > > > > > > Error message contains following message: > > > > > > > > ``` > > > > [2018-12-27 11:40:23,597][ERROR][exchange-worker-#5547%grid-2%][root] > > > > Critical system error detected. Will be handled accordingly to > > configured > > > > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > > > > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > > > > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > > > > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class > > > > o.a.i.IgniteCheckedException: Node is stopping: grid-2]] > > > > class org.apache.ignite.IgniteCheckedException: Node is stopping: > > grid-2 > > > > ``` > > > > > > > > > >
Re: Some problem with execution ignite.bat in master
Ilya, Why do we use -J in general? Is it used to pass a specific type of parameters? I know -D or - X but can't recall what -J is supposed to be used for. -- Denis On Thu, Dec 27, 2018 at 6:34 AM Ilya Kasnacheev wrote: > Hello! > > I have debugged this issue. It seems to be a JVM bug on Windows, where JVM > will silently fail to run program's main class: > > java HelloWorld -v -J1 -J2 - works > java HelloWorld -v -J1 -J2 -J3 - fails > java -Dfile.encoding=UTF-8 HelloWorld -v -J1 -J2 -J3 - works > java -Dfile.encoding=UTF-8 HelloWorld -v -J1 -J2 -J3 -J4 - fails > > It seems to be fixed on Java 11. > > I don't think we should fix it (and can close the issue), but if we really > wanted we could replace -J with, let's say, -W > java HelloWorld -v -W1 -W2 -W3 -W4 works. > > Regards, > -- > Ilya Kasnacheev > > > пн, 27 авг. 2018 г. в 11:33, Anton Vinogradov : > > > Dmitry, > > Not sure I understand the issue, but I see no reason to rollback > anything. > > In case we have some issues, let's just fix them. > > > > сб, 25 авг. 2018 г. в 0:53, Dmitriy Pavlov : > > > > > Hi Anton, > > > > > > Do you have objections about a partial rollback of changes? > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пт, 24 авг. 2018 г. в 14:24, ARomantsov : > > > > > >> Hello, Igniters. > > >> > > >> I'm testing some java keys with ignite.bat and notice that using more > > that > > >> four keys lead to internal problem and ignite.bat ignoring them all. > > >> > > >> So I created issue https://issues.apache.org/jira/browse/IGNITE-8837 > > and > > >> investigated , below what i founded > > >> > > >> 1) inside file ignite.bat happen call bin/include/parseargs.bat with > > next > > >> code to parse arguments > > >> set convertArgsCmd="!JAVA_HOME!\bin\java.exe" -cp "%CP%" > > >> org.apache.ignite.startup.cmdline.CommandLineTransformer %* > > >> > > >> 2) call of org.apache.ignite.startup.cmdline.CommandLineTransformer > > >> correct > > >> parsing JVM arguments only if they count less five > > >> > > >> 3) This problem (2) easy fix by add to set in convertArgsCmd one of > next > > >> Java key ( -Dfile.encoding=IBM866 or -Dfile.encoding=UTF-8) > > >> > > >> 4) Like part of issue > https://issues.apache.org/jira/browse/IGNITE-7135 > > >> it > > >> already had fix (3) and included in Ignite 2.4 > > >> > > >> 5) Unfortunately, when fix issue > > >> https://issues.apache.org/jira/browse/IGNITE-898 that key was removed > > >> and > > >> that lead to problem in 2.5 , 2.6, master > > >> > > >> What correct steps to back ignite.bat working correct on windows in > > >> master / > > >> 2.7? Both of ticket in (4) / (5) fix another problems , is correct to > > >> reopen > > >> one of them? > > >> > > >> > > >> > > >> -- > > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > >> > > > > > >
Re: Replace Cron4J with Quartz for ignite-schedule module.
Hi, Ilya! It looks like Spring *ThreadPoolTaskScheduler* is bounded to JDK's *ScheduledThreadPoolExecutor*, so to launch scheduled tasks on public pool we need provide *ScheduledThreadPoolExecutor* for Public pool. Currently I see we create Public pool executor as *IgniteThreadPoolExecutor* and it extends *ThreadPoolExecutor*. It seems we can easily introduce *IgniteScheduledThreadPoolExecutor* and extend it from *ScheduledThreadPoolExecutor* for public pool. How do you like it? Your idea about delegating tasks from Spring 1-threaded pool to Public pool looks also workable. Best regards, Sergey Kosarev. вт, 25 дек. 2018 г. в 18:19, Ilya Kasnacheev : > Hello! > > I have started reviewing your pull request. > I will expect that scheduled tasks are executed on Public pool. Is it > possible that tasks are launched on Public pool? If Spring Scheduler > insists on its own thread pool, we can have single-thread pool which will > execute put of tasks to public pool and immediately return. Is it possible > to do that? > > Regards, > -- > Ilya Kasnacheev > > > вт, 25 дек. 2018 г. в 17:46, Alexey Kuznetsov : > > > Hi, Sergey! > > > > I think we should keep compatibility as much as possible for Ignite 2.x. > > And we can do breaking changes in Ignite 3.x > > > > What do you think? > > > > > > On Mon, Dec 24, 2018 at 11:58 PM Sergey wrote: > > > > > HI, Igniters! > > > > > > I've updated and rebased implementation to master branch and made some > > > fixes. > > > Also I have a question regarding current implementation. > > > > > > As I found Cron4J source code this implementation checks schedule every > > > minute (seconds not supported) but spawns a thread for every task which > > > scheduling pattern matches the current time. There no any limits to the > > > number of tasks launched silmultaneously. > > > > > > New implementation is based on > > > org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler > > > with its default parameters currently, i.e thread pool size is 1. > > > > > > Could you advise me, do we need to add some system property or > introduce > > > some attribute to IgniteConfiguration to configure Scheduler thread > pool > > > size? And what should be default value? > > > > > > > > > Best regards, > > > Sergey Kosarev. > > > > > > > > > чт, 10 мая 2018 г. в 20:23, Dmitry Pavlov : > > > > > > > Hi Anton, > > > > > > > > Thank you for joining and review. > > > > I hope all proposals will be applied. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пт, 4 мая 2018 г. в 16:04, Anton Vinogradov : > > > > > > > > > Folks, > > > > > > > > > > How can it be at PATCH AVAILABLE since *none* of my latest comments > > > (made > > > > > Feb 8) are resolved at Upsource? > > > > > Changed state to IP. > > > > > > > > > > пн, 23 апр. 2018 г. в 20:00, Dmitry Pavlov >: > > > > > > > > > > > Hi Andrey, > > > > > > > > > > > > Could you please pick up review? > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > пн, 23 апр. 2018 г. в 17:39, Dmitriy Setrakyan < > > > dsetrak...@apache.org > > > > >: > > > > > > > > > > > > > Dmitriy, who is a good candidate within the community to review > > > this > > > > > > > ticket? > > > > > > > > > > > > > > On Mon, Apr 23, 2018 at 6:10 AM, Dmitry Pavlov < > > > > dpavlov@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > > > > > it seems ticket > > > https://issues.apache.org/jira/browse/IGNITE-5565 > > > > is > > > > > > > still > > > > > > > > in PA state. What are our next steps? > > > > > > > > > > > > > > > > Who did review of this patch? > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > ср, 28 июн. 2017 г. в 1:40, Denis Magda : > > > > > > > > > > > > > > > > > Yakov, > > > > > > > > > > > > > > > > > > No, the mentioned discussion didn’t turn into a JIRA > ticket. > > > > > > > > > > > > > > > > > > Alex K., please follow to some thoughts from there and wrap > > > them > > > > up > > > > > > in > > > > > > > a > > > > > > > > > form of the ticket. > > > > > > > > > > > > > > > > > > — > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > On Jun 26, 2017, at 2:58 AM, Yakov Zhdanov < > > > > yzhda...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Guys, I remember we discussed this some time ago. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble. > > > > > > > > com/Tasks-Scheduling-and-Chaining-td14293.html > > > > > > > > > > > > > > > > > > > > Denis, do you have any ticket or SoW? > > > > > > > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Alexey Kuznetsov > > >
Re: Some problem with execution ignite.bat in master
Hello! I have debugged this issue. It seems to be a JVM bug on Windows, where JVM will silently fail to run program's main class: java HelloWorld -v -J1 -J2 - works java HelloWorld -v -J1 -J2 -J3 - fails java -Dfile.encoding=UTF-8 HelloWorld -v -J1 -J2 -J3 - works java -Dfile.encoding=UTF-8 HelloWorld -v -J1 -J2 -J3 -J4 - fails It seems to be fixed on Java 11. I don't think we should fix it (and can close the issue), but if we really wanted we could replace -J with, let's say, -W java HelloWorld -v -W1 -W2 -W3 -W4 works. Regards, -- Ilya Kasnacheev пн, 27 авг. 2018 г. в 11:33, Anton Vinogradov : > Dmitry, > Not sure I understand the issue, but I see no reason to rollback anything. > In case we have some issues, let's just fix them. > > сб, 25 авг. 2018 г. в 0:53, Dmitriy Pavlov : > > > Hi Anton, > > > > Do you have objections about a partial rollback of changes? > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 24 авг. 2018 г. в 14:24, ARomantsov : > > > >> Hello, Igniters. > >> > >> I'm testing some java keys with ignite.bat and notice that using more > that > >> four keys lead to internal problem and ignite.bat ignoring them all. > >> > >> So I created issue https://issues.apache.org/jira/browse/IGNITE-8837 > and > >> investigated , below what i founded > >> > >> 1) inside file ignite.bat happen call bin/include/parseargs.bat with > next > >> code to parse arguments > >> set convertArgsCmd="!JAVA_HOME!\bin\java.exe" -cp "%CP%" > >> org.apache.ignite.startup.cmdline.CommandLineTransformer %* > >> > >> 2) call of org.apache.ignite.startup.cmdline.CommandLineTransformer > >> correct > >> parsing JVM arguments only if they count less five > >> > >> 3) This problem (2) easy fix by add to set in convertArgsCmd one of next > >> Java key ( -Dfile.encoding=IBM866 or -Dfile.encoding=UTF-8) > >> > >> 4) Like part of issue https://issues.apache.org/jira/browse/IGNITE-7135 > >> it > >> already had fix (3) and included in Ignite 2.4 > >> > >> 5) Unfortunately, when fix issue > >> https://issues.apache.org/jira/browse/IGNITE-898 that key was removed > >> and > >> that lead to problem in 2.5 , 2.6, master > >> > >> What correct steps to back ignite.bat working correct on windows in > >> master / > >> 2.7? Both of ticket in (4) / (5) fix another problems , is correct to > >> reopen > >> one of them? > >> > >> > >> > >> -- > >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > >> > > >
Re: System Worker Failure Handler on local laptop
Nikolay, Yes, the fix is already in master. Looks like I was wrong, in your case failure handler is triggered by 'Node is stopping: grid-2'. Can you please share the full trace? чт, 27 дек. 2018 г. в 12:41, Nikolay Izhikov : > Alexey > > Fix for this issue already in master? > I run tests on current master. > > > Should we somehow announce it on the user-list or highlight on readme.io > ? > > I don't think our users will be happy to users stuck with this behavior in > production. > > Am I understand you correctly: > If someone use 2.7. release and Ignite process slowing for a few seconds > for any reason(low-end hardwre, VM pause, other processes grab the > resources) then Ignite node will be stopped? > > > This is the issue I mentioned in "Critical worker threads liveness > checking > drawbacks" topic > > Thanks for the link, I will check it out. > > чт, 27 дек. 2018 г. в 12:24, Alexey Goncharuk >: > > > Hi Nikolay, > > > > This is the issue I mentioned in "Critical worker threads liveness > checking > > drawbacks" topic which I was expecting to be included to Ignite 2.7, but > it > > was not. To workaround the issue, you should set > > DataStorageConfiguration#setCheckpointReadLockTimeout to 0. > > > > Should we somehow announce it on the user-list or highlight on readme.io > ? > > > > чт, 27 дек. 2018 г. в 11:57, Nikolay Izhikov : > > > > > Hello, Igniters. > > > > > > I run into issue with critical system worker failure handler. > > > I just run `IgniteDataFrameSuite` and it terminates on random test. > > > My laptop doesn't have bleeding edge hardware, so tests can take > > > significant amount of time. > > > Looks like our watch dog too aggressive on development environment > > > > > > Can you please, help me. What should I do to configure or turn off > watch > > > dog? > > > Should we relax it a little bit? At least for a test environment. > > > > > > Error message contains following message: > > > > > > ``` > > > [2018-12-27 11:40:23,597][ERROR][exchange-worker-#5547%grid-2%][root] > > > Critical system error detected. Will be handled accordingly to > configured > > > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > > > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > > > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > > > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class > > > o.a.i.IgniteCheckedException: Node is stopping: grid-2]] > > > class org.apache.ignite.IgniteCheckedException: Node is stopping: > grid-2 > > > ``` > > > > > >
[jira] [Created] (IGNITE-10835) Test failure in IgnitePdsReplacementNativeIoTest
Namrata Bhave created IGNITE-10835: -- Summary: Test failure in IgnitePdsReplacementNativeIoTest Key: IGNITE-10835 URL: https://issues.apache.org/jira/browse/IGNITE-10835 Project: Ignite Issue Type: Bug Affects Versions: 2.7, 2.6 Environment: Linux Ubuntu 16.04 big endian Reporter: Namrata Bhave Hi, `IgnitePdsReplacementNativeIoTest.testPageReplacement` from `direct-io` fails with below error on big endian platform: _[ERROR] IgnitePdsReplacementNativeIoTest>GridAbstractTest.access$000:143->GridAbstractTest.runTestInternal:2177->testPageReplacement:42->IgnitePdsPageReplacementTest.testPageReplacement:123->IgnitePdsPageReplacementTest.writeData:144 Page buffer order LITTLE_ENDIAN should be same with BIG_ENDIAN_ The error is thrown from [FilePageStore.java|https://github.com/apache/ignite/blob/2.7.0/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/file/FilePageStore.java#L548 ] during write function. This is happening since header order is set to LITTLE_ENDIAN in code. How to handle this functionality on Big endian? Could someone please help in resolving this error? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10836) Add documentation for jdbc thin query cancel
Alexander Lapin created IGNITE-10836: Summary: Add documentation for jdbc thin query cancel Key: IGNITE-10836 URL: https://issues.apache.org/jira/browse/IGNITE-10836 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Alexander Lapin Fix For: 2.8 Query cancel for jdbc thin was implemented. At least error codes page ([https://apacheignite-sql.readme.io/docs/error-codes-27)] should be updated, cause new error code (57014 Query cancelled) was added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10833) Web Console: Implement query cancel
Alexey Kuznetsov created IGNITE-10833: - Summary: Web Console: Implement query cancel Key: IGNITE-10833 URL: https://issues.apache.org/jira/browse/IGNITE-10833 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.8 Web Console lacks query cancel functionality. Lets add this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10834) [ML] Add NamedVectors to replace HashMap in Model
Anton Dmitriev created IGNITE-10834: --- Summary: [ML] Add NamedVectors to replace HashMap in Model Key: IGNITE-10834 URL: https://issues.apache.org/jira/browse/IGNITE-10834 Project: Ignite Issue Type: Improvement Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Assignee: Anton Dmitriev Fix For: 2.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10832) [TC Bot] Auto-trigger check win agents availability before triggering a build
Dmitriy Pavlov created IGNITE-10832: --- Summary: [TC Bot] Auto-trigger check win agents availability before triggering a build Key: IGNITE-10832 URL: https://issues.apache.org/jira/browse/IGNITE-10832 Project: Ignite Issue Type: Task Reporter: Dmitriy Pavlov Assignee: Dmitriy Pavlov Currently, Win Agents may be a bottle-neck in TC throughput. So it is reasonable to check constraint availability, but not only overall pool of agents -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10831) Document update/delete queries in Spring Data 2.0
Ilya Kasnacheev created IGNITE-10831: Summary: Document update/delete queries in Spring Data 2.0 Key: IGNITE-10831 URL: https://issues.apache.org/jira/browse/IGNITE-10831 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.8 Reporter: Ilya Kasnacheev Assignee: Prachi Garg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10830) Return back semantic of GridServiceProcessor#ServiceTopologyCallable to avoid possible serialization issues
Vyacheslav Daradur created IGNITE-10830:
---
Summary: Return back semantic of
GridServiceProcessor#ServiceTopologyCallable to avoid possible serialization
issues
Key: IGNITE-10830
URL: https://issues.apache.org/jira/browse/IGNITE-10830
Project: Ignite
Issue Type: Task
Components: managed services
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Fix For: 2.8
It's necessary to revert changes of
{{GridServiceProcessor#ServiceTopologyCallable}} introduced within IGNITE-9607.
This may lead to serialization issues in some cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: System Worker Failure Handler on local laptop
Alexey Fix for this issue already in master? I run tests on current master. > Should we somehow announce it on the user-list or highlight on readme.io? I don't think our users will be happy to users stuck with this behavior in production. Am I understand you correctly: If someone use 2.7. release and Ignite process slowing for a few seconds for any reason(low-end hardwre, VM pause, other processes grab the resources) then Ignite node will be stopped? > This is the issue I mentioned in "Critical worker threads liveness checking drawbacks" topic Thanks for the link, I will check it out. чт, 27 дек. 2018 г. в 12:24, Alexey Goncharuk : > Hi Nikolay, > > This is the issue I mentioned in "Critical worker threads liveness checking > drawbacks" topic which I was expecting to be included to Ignite 2.7, but it > was not. To workaround the issue, you should set > DataStorageConfiguration#setCheckpointReadLockTimeout to 0. > > Should we somehow announce it on the user-list or highlight on readme.io? > > чт, 27 дек. 2018 г. в 11:57, Nikolay Izhikov : > > > Hello, Igniters. > > > > I run into issue with critical system worker failure handler. > > I just run `IgniteDataFrameSuite` and it terminates on random test. > > My laptop doesn't have bleeding edge hardware, so tests can take > > significant amount of time. > > Looks like our watch dog too aggressive on development environment > > > > Can you please, help me. What should I do to configure or turn off watch > > dog? > > Should we relax it a little bit? At least for a test environment. > > > > Error message contains following message: > > > > ``` > > [2018-12-27 11:40:23,597][ERROR][exchange-worker-#5547%grid-2%][root] > > Critical system error detected. Will be handled accordingly to configured > > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class > > o.a.i.IgniteCheckedException: Node is stopping: grid-2]] > > class org.apache.ignite.IgniteCheckedException: Node is stopping: grid-2 > > ``` > > >
Re: System Worker Failure Handler on local laptop
Hi Nikolay, This is the issue I mentioned in "Critical worker threads liveness checking drawbacks" topic which I was expecting to be included to Ignite 2.7, but it was not. To workaround the issue, you should set DataStorageConfiguration#setCheckpointReadLockTimeout to 0. Should we somehow announce it on the user-list or highlight on readme.io? чт, 27 дек. 2018 г. в 11:57, Nikolay Izhikov : > Hello, Igniters. > > I run into issue with critical system worker failure handler. > I just run `IgniteDataFrameSuite` and it terminates on random test. > My laptop doesn't have bleeding edge hardware, so tests can take > significant amount of time. > Looks like our watch dog too aggressive on development environment > > Can you please, help me. What should I do to configure or turn off watch > dog? > Should we relax it a little bit? At least for a test environment. > > Error message contains following message: > > ``` > [2018-12-27 11:40:23,597][ERROR][exchange-worker-#5547%grid-2%][root] > Critical system error detected. Will be handled accordingly to configured > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], > failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class > o.a.i.IgniteCheckedException: Node is stopping: grid-2]] > class org.apache.ignite.IgniteCheckedException: Node is stopping: grid-2 > ``` >
[jira] [Created] (IGNITE-10829) MVCC TX: Lazy query execution for query enlists.
Igor Seliverstov created IGNITE-10829: - Summary: MVCC TX: Lazy query execution for query enlists. Key: IGNITE-10829 URL: https://issues.apache.org/jira/browse/IGNITE-10829 Project: Ignite Issue Type: Improvement Components: mvcc Affects Versions: 2.7 Reporter: Igor Seliverstov Fix For: 2.8 Implement lazy query execution using semantic goes from IGNITE-9171. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
System Worker Failure Handler on local laptop
Hello, Igniters. I run into issue with critical system worker failure handler. I just run `IgniteDataFrameSuite` and it terminates on random test. My laptop doesn't have bleeding edge hardware, so tests can take significant amount of time. Looks like our watch dog too aggressive on development environment Can you please, help me. What should I do to configure or turn off watch dog? Should we relax it a little bit? At least for a test environment. Error message contains following message: ``` [2018-12-27 11:40:23,597][ERROR][exchange-worker-#5547%grid-2%][root] Critical system error detected. Will be handled accordingly to configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteCheckedException: Node is stopping: grid-2]] class org.apache.ignite.IgniteCheckedException: Node is stopping: grid-2 ```
