[jira] [Created] (IGNITE-11036) IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master
Sergey Kosarev created IGNITE-11036: --- Summary: IgniteTcpCommunicationHandshakeWaitTest/IgniteTcpCommunicationHandshakeWaitSslTest fail in master Key: IGNITE-11036 URL: https://issues.apache.org/jira/browse/IGNITE-11036 Project: Ignite Issue Type: Bug Reporter: Sergey Kosarev Assignee: Sergey Kosarev -- This message was sent by Atlassian JIRA (v7.6.3#76005)
IgniteCacheTestSuite3 on TeamCity
Hi guys, I need run IgniteCacheTestSuite3 on TeamCity, but can not find related configuration. 'Cache 3' configuration runs only IgniteBinaryObjectsCacheTestSuite3, could you please take a look? Thank you
My first ticket (IGNITE-10742) completed
Hello, Igniters. My ticket https://issues.apache.org/jira/browse/IGNITE-10742 in patch avaliable status. Could someone review my changes? BR, Ramil Timerbaev
[jira] [Created] (IGNITE-11035) Web console: Implemement improvements for query page controller.
Vasiliy Sisko created IGNITE-11035:
--
Summary: Web console: Implemement improvements for query page
controller.
Key: IGNITE-11035
URL: https://issues.apache.org/jira/browse/IGNITE-11035
Project: Ignite
Issue Type: Improvement
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
# Implement processing of query result task without one level recursion.
# Explicit serialization to JSON of Paragraph object. Possible
{{Paragraph.prototype.toJSON }}{{should be implemented.}}
{{# Try to use RXJS operator chain instead of direct usage of subscription
object.}}
{{# On query cancel task unlock UI in Promise.prototype.finally.}}
{{# Check initialization of queryId and resultNodeId on execute of refresh in
auto refresh mode.}}
{{# Some paragraph manipulation methods should be moved into Paragraph class:
_initQueryResult}}{{{color:#00}_, _showLoading._
{color}}}{{{color:#00}Check other methods with paragraph as
argument.{color}}}
{{{color:#00}# Check clearing of data in _initQueryResult method.
{color}}}{{{color:#00}Try to not use direct calling of grid
API{color}}}{{{color:#00}. Possible we should show
“{color}}}{{{color:#00}Query execution{color}}}{{{color:#00}” stub
{color}}}{{{color:#00}instead. {color}}}
{{{color:#00}# {color}}}{{{color:#00}Remove “beforeunload” listener on
leave of Queries page.{color}}}
{{{color:#00}# Possible we should cancel queries when client session is
over.{color}}}
{{{color:#00}# Add docs for return values of queries task in agent manager.
F.e:{color}}}
{{{color:#00}{code}{color}}}
/*
* @returns \{Promise}
*/
{code}
# Confirm on leaving of Queries page when running queries exist:
{code}
You have running queries. Are you sure you want to cancel them?
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11034) Web console: update some dependencies
Ilya Borisov created IGNITE-11034: - Summary: Web console: update some dependencies Key: IGNITE-11034 URL: https://issues.apache.org/jira/browse/IGNITE-11034 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Alexander Kalinin We need to update: 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module loading. 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11033) IllegalStateException in VisorBaselineTask
Vasiliy Sisko created IGNITE-11033: -- Summary: IllegalStateException in VisorBaselineTask Key: IGNITE-11033 URL: https://issues.apache.org/jira/browse/IGNITE-11033 Project: Ignite Issue Type: Bug Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Fix For: 2.8 Thrown when set command executed. The reason that we throw exception instead of setting DetachedClusterNode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IGNITE-8283 CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
Hi??so now I will focus on the JNI approach, thanks for the explanation. iPhone -- Original -- From: Igor Sapego Date: ,1?? 23,2019 1:15 To: dev Subject: Re: IGNITE-8283 CPP: Implement 'varint' solution to be configurable via BinaryConfiguration Yes, we need to add it to all thin clients, actually, and to thin protocol specification. On the second thought, we need to implement second approach anyway, as Ignite can be configured with XML. So, I'd stopped on the second approach for now, as we will need it in any way. Best Regards, Igor On Tue, Jan 22, 2019 at 6:19 PM ppenguin wrote: > Hi??Do we need to add it into the thin cpp client too?If so, I think we??d > better choose the first method,then we can reuse the code. > > > -- Original -- > From: Igor Sapego > Date: ,1?? 21,2019 11:19 > To: dev > Subject: Re: IGNITE-8283 CPP: Implement 'varint' solution to be > configurable via BinaryConfiguration > > > > Hi, > > The obvious solution here is to add IgniteConfiguration class for C++, but > it looks like not an easy task. > > There is another solution which is more easy to implement: it is to add > call > to Java code, something like "isVarintActive()", which is going to be > called > on node startup. > Best Regards, > Igor > > > > On Mon, Jan 21, 2019 at 1:40 PM ppenguin > wrote: > > > Igniters, > > > > I'am beginning with this task. Now the c++ implementation lacks some > parts > > that existed in Java and C#, so the task seems a little complex. I want > to > > discuss the details here.
Re: Contirbution
Hello Ramil, The permissions are granted, welcome to the community! - Denis On Tue, Jan 22, 2019 at 11:32 AM Ramil Timerbaev wrote: > Hello, > > My name is Ramil and I want to participate in the Ignite development > process. Could you please give me permissions to start on it? > My jira account: timerbaev > > BR, Ramil Timerbaev >
Re: Apache Ignite contribution
Hello Ramil, Just added you to the contributors' list in JIRA. Please assign the ticket to yourself. Thanks for the contribution. - Denis On Tue, Jan 22, 2019 at 1:18 PM Ramil Timerbaev wrote: > I fixed IGNITE-10742 but I don't have permissions for assign issue in JIRA. > > 22.01.2019, 23:11, "Ramil Timerbaev" : > > Hello, > > > > My name is Ramil and I want to participate in the Ignite development > process. Could you please give me permissions to start on it? > > My jira account: timerbaev > > > > In previous email i made typo and i afraid, that my could be lose in > other threads. > > > > BR, Ramil Timerbaev >
Re: Apache Ignite contribution
I fixed IGNITE-10742 but I don't have permissions for assign issue in JIRA. 22.01.2019, 23:11, "Ramil Timerbaev" : > Hello, > > My name is Ramil and I want to participate in the Ignite development process. > Could you please give me permissions to start on it? > My jira account: timerbaev > > In previous email i made typo and i afraid, that my could be lose in other > threads. > > BR, Ramil Timerbaev
Re: Apache Ignite contribution
I fixed IGNITE-10742 but I don't have permissions for assigning issue in JIRA. 22.01.2019, 23:11, "Ramil Timerbaev" : > Hello, > > My name is Ramil and I want to participate in the Ignite development process. > Could you please give me permissions to start on it? > My jira account: timerbaev > > In previous email i made typo and i afraid, that my could be lose in other > threads. > > BR, Ramil Timerbaev
[MTCGA]: new failures in builds [2867589] 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 stable failure of a flaky test in master IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryPagesSeveral https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4145688911096802577&branch=%3Cdefault%3E&tab=testDetails *New stable failure of a flaky test in master IgniteCoreTest: CacheQueryTestSuite: TestFieldsQuerySeveral https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7923965190700916819&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - sergi.vladykin https://ci.ignite.apache.org/viewModification.html?modId=872823 - 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 00:02:54 23-01-2019
[MTCGA]: new failures in builds [2867594, 2639452] 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 stable failure of a flaky test in master IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryPagesSeveral https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4145688911096802577&branch=%3Cdefault%3E&tab=testDetails *New stable failure of a flaky test in master IgniteCoreTest: CacheQueryTestSuite: TestFieldsQuerySeveral https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7923965190700916819&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - sergi.vladykin https://ci.ignite.apache.org/viewModification.html?modId=872823 *New stable failure of a flaky test in master IgniteStartStopTest.TestProcessorInit https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-8379686487933741046&branch=%3Cdefault%3E&tab=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 23:32:51 22-01-2019
Contribute to ignite.net
Hi, folks. I'm using ignite.net and I want to try to improve it. I think that I'm able to do this ticket https://issues.apache.org/jira/browse/IGNITE-7128 but I cannot assign it to me in jira. My login is lkhenkin, could you please help me?
Apache Ignite contribution
Hello, My name is Ramil and I want to participate in the Ignite development process. Could you please give me permissions to start on it? My jira account: timerbaev In previous email i made typo and i afraid, that my could be lose in other threads. BR, Ramil Timerbaev
[MTCGA]: new failures in builds [2807830] 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 stable failure of a flaky test in master PartitionLossTest.TestReadOnlyAll https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=5428922878479275743&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - amalykhgh https://ci.ignite.apache.org/viewModification.html?modId=872152 - 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:32:50 22-01-2019
[jira] [Created] (IGNITE-11031) Improve test coverage on ssl and fix existing ssl tcp communication spi tests.
Pavel Voronkin created IGNITE-11031: --- Summary: Improve test coverage on ssl and fix existing ssl tcp communication spi tests. Key: IGNITE-11031 URL: https://issues.apache.org/jira/browse/IGNITE-11031 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11032) Typescript for Node.js Client
Thomas Havlik created IGNITE-11032: -- Summary: Typescript for Node.js Client Key: IGNITE-11032 URL: https://issues.apache.org/jira/browse/IGNITE-11032 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Thomas Havlik So I've started doing this today. My goal is to complete this work quickly so it has a good chance of being merged. I've found it difficult to find whoever the right person would be to get started on this. [https://github.com/thavlik/ignite] Note that I can't get the tests to run because my computer is having issues running Ignite locally, and I have no intention of moving the tests to Typescript. Only the imports for the tests will be changing. Also, I am removing all default exports as per its numerous caveats: [https://blog.neufund.org/why-we-have-banned-default-exports-and-you-should-do-the-same-d51fdc2cf2ad] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Contirbution
Hello, My name is Ramil and I want to participate in the Ignite development process. Could you please give me permissions to start on it? My jira account: timerbaev BR, Ramil Timerbaev
Re: Greeting
Hi Artur, You're in, now you can assign an issue to yourself. Thank you for interest in Apache Ignite and welcome to the Apache Ignite Community. Following is a couple of links should help during joining to the community Short 'How to start' guide https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#contributing-to-apache-ignite and full guide version https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute Should you have any questions please do not hesitate to contact Ignite developers here. Sincerely, Dmitriy Pavlov вт, 22 янв. 2019 г. в 22:21, Artur Muradimov : > Community, > > I am Artur Muradimov and I want to contribute Apache Ignite. > > I had a time to watch the project and I think, already ready to make some > JIRA ticket. > I want to start from the issue IGNITE-10921 > > Please grant me contributer privileges to make possible assign. > My jira login: arturmuradimov77 >
Re: Options naming format in control.sh utility.
Igniters, what do you think about this topic? пт, 11 янв. 2019 г. в 14:17, Sergey Antonov : > Sergey, > > Not quite, I meant: > - boolean argument: *--word1-word2* > - single value argument *--word1-word2 value* > - multiple values argument *--word1-word2 value1,value2* > > пт, 11 янв. 2019 г. в 14:12, Sergey Kozlov : > >> Sergey, >> >> Thanks for raising up the question. >> >> Did you mean following (?): >> - boolean argument: *--word1-word2* >> - single value argument *--word1-word2=value* >> - multiple values argument *--word1-word2=value1 --word1-word2=value2* >> >> >> On Fri, Jan 11, 2019 at 2:05 PM Sergey Antonov > > >> wrote: >> >> > Hi, Igniters! >> > >> > I want discuss and define options naming format in our utilities. I >> found >> > two naming styles in CommandHandler class --excludeCaches and >> > --skip-zeros. >> > I think we should unify it. At this moment almost all options have >> second >> > naming format. I am offering rename --excludeCaches to --exclude-caches >> and >> > define format for future options. How about linux like format i.e. >> > --word1-word2? >> > >> > -- >> > BR, Sergey Antonov >> > >> >> >> -- >> Sergey Kozlov >> GridGain Systems >> www.gridgain.com >> > > > -- > BR, Sergey Antonov > -- BR, Sergey Antonov
Greeting
Community, I am Artur Muradimov and I want to contribute Apache Ignite. I had a time to watch the project and I think, already ready to make some JIRA ticket. I want to start from the issue IGNITE-10921 Please grant me contributer privileges to make possible assign. My jira login: arturmuradimov77
[MTCGA]: new failures in builds [2815416] 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 stable failure of a flaky test in master IgniteConfigurationTest.TestSpringXml https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8068196411489261503&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - zaleslaw.sin https://ci.ignite.apache.org/viewModification.html?modId=872281 - 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:02:52 22-01-2019
[jira] [Created] (IGNITE-11030) Teamcity Bot cache is in unrecoverable state after bot restart: need to check reasons
Dmitriy Pavlov created IGNITE-11030:
---
Summary: Teamcity Bot cache is in unrecoverable state after bot
restart: need to check reasons
Key: IGNITE-11030
URL: https://issues.apache.org/jira/browse/IGNITE-11030
Project: Ignite
Issue Type: Task
Reporter: Dmitriy Pavlov
- TC Bot was stopped with kill command (default signal).
- Shutdown hook calls ignite close
But after updating to V190122 TC Bot DB was became unrecoverable for
"teamcityTestRunHist" cache with exception
{noformat}
Failure periodic check failed: javax.cache.CacheException: class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
Runtime failure on lookup row: SearchRow
[key=org.apache.ignite.ci.teamcity.ignited.runhist.RunHistKey
[idHash=1028871081, hash=1241170874, srvId=1411517106, testOrSuiteName=11924,
branch=281], hash=1241170874, cacheId=0]
com.google.common.util.concurrent.UncheckedExecutionException:
javax.cache.CacheException: class
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
Runtime failure on lookup row: SearchRow
[key=org.apache.ignite.ci.teamcity.ignited.runhist.RunHistKey
[idHash=1028871081, hash=1241170874, srvId=1411517106, testOrSuiteName=11924,
branch=281], hash=1241170874, cacheId=0]
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2050)
at com.google.common.cache.LocalCache.get(LocalCache.java:3952)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4871)
at
org.apache.ignite.ci.di.cache.GuavaCachedInterceptor.invoke(GuavaCachedInterceptor.java:59)
at
org.apache.ignite.ci.teamcity.ignited.TeamcityIgnitedImpl.getTestRunHist(TeamcityIgnitedImpl.java:404)
at
org.apache.ignite.ci.di.AutoProfilingInterceptor.invoke(AutoProfilingInterceptor.java:76)
at
org.apache.ignite.ci.web.model.current.SuiteCurrentStatus.lambda$initFromContext$0(SuiteCurrentStatus.java:155)
at java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
at
java.util.Collections$ReverseComparator2.compare(Collections.java:5178)
at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
at java.util.TimSort.sort(TimSort.java:220)
at java.util.Arrays.sort(Arrays.java:1512)
at java.util.ArrayList.sort(ArrayList.java:1462)
at
org.apache.ignite.ci.web.model.current.SuiteCurrentStatus.initFromContext(SuiteCurrentStatus.java:160)
at
org.apache.ignite.ci.web.model.current.ChainAtServerCurrentStatus.lambda$initFromContext$0(ChainAtServerCurrentStatus.java:171)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.apache.ignite.ci.web.model.current.ChainAtServerCurrentStatus.initFromContext(ChainAtServerCurrentStatus.java:167)
at
org.apache.ignite.ci.tcbot.chain.TrackedBranchChainsProcessor.lambda$getTrackedBranchTestFailures$1(TrackedBranchChainsProcessor.java:121)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.apache.ignite.ci.tcbot.chain.TrackedBranchChainsProcessor.getTrackedBranchTestFailures(TrackedBranchChainsProcessor.java:125)
at
org.apache.ignite.ci.di.AutoProfilingInterceptor.invoke(AutoProfilingInterceptor.java:76)
at
org.apache.ignite.ci.tcbot.issue.IssueDetector.checkFailuresEx(IssueDetector.java:445)
at
org.apache.ignite.ci.di.MonitoredTaskInterceptor.invoke(Monitore
Re: Is it time to move forward to JUnit4 (5)?
...sort of a follow-up. I gave folks a bit more leeway than originally planned week or two. It's been about a month since master was changed in a way that wouldn't allow JUnit 3 tests execute anymore (per IGNITE-10177) and I just started progress on IGNITE-10629 and made a promised inspection for tests that could slip through without required annotation while we were migrating the project to JUnit 4. Results of this check look pretty good, IDEA reported only 6 (six) troublesome test cases (4 of which were by the way annotated @Ignore, meaning that even with added @Test these won't run anyway). Compared to over 11,600 properly annotated test cases this looks really minor. We probably can say that tests in master migrated to JUnit 4 quite smoothly. regards, Oleg Vladimir Ozerov wrote > Hi Oleg, > > Yes, makes perfect sense. Thank you. > > On Mon, Dec 10, 2018 at 10:14 PM oignatenko < > oignatenko@ > > wrote: > >> Hi Vovan, >> >> I just created JIRA ticket to address your concerns: >> - https://issues.apache.org/jira/browse/IGNITE-10629 >> >> In brief, the plan is that a week or two after migration is over we will >> run >> code inspection that detects JUnit 3 style tests that lack @Test >> annotation >> and fix these tests if there are any. >> >> Does that answer your question? >> >> regards, Oleg >> Vladimir Ozerov wrote >> > Ed, >> > >> > Several questions from my side: >> > 1) When the change is expected to be merged? >> > 2) What contributors with opened PRs and new or updated JUnit3 tests >> are >> > supposed to do? Rewrite to JUnit4? >> > >> > If yes, then we should give them time to have a chance to get used to >> new >> > approach and resolve possible conflicts. >> > >> > Vladimir. >> > >> [cut] >> >> -- >> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: IGNITE-8283 CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
Yes, we need to add it to all thin clients, actually, and to thin protocol specification. On the second thought, we need to implement second approach anyway, as Ignite can be configured with XML. So, I'd stopped on the second approach for now, as we will need it in any way. Best Regards, Igor On Tue, Jan 22, 2019 at 6:19 PM ppenguin wrote: > Hi，Do we need to add it into the thin cpp client too?If so, I think we’d > better choose the first method,then we can reuse the code. > > > -- Original -- > From: Igor Sapego > Date: 周一,1月 21,2019 11:19 下午 > To: dev > Subject: Re: IGNITE-8283 CPP: Implement 'varint' solution to be > configurable via BinaryConfiguration > > > > Hi, > > The obvious solution here is to add IgniteConfiguration class for C++, but > it looks like not an easy task. > > There is another solution which is more easy to implement: it is to add > call > to Java code, something like "isVarintActive()", which is going to be > called > on node startup. > Best Regards, > Igor > > > > On Mon, Jan 21, 2019 at 1:40 PM ppenguin > wrote: > > > Igniters, > > > > I'am beginning with this task. Now the c++ implementation lacks some > parts > > that existed in Java and C#, so the task seems a little complex. I want > to > > discuss the details here.
Re: IGNITE-8283 CPP: Implement 'varint' solution to be configurable via BinaryConfiguration
Hi??Do we need to add it into the thin cpp client too?If so, I think we??d better choose the first method,then we can reuse the code. -- Original -- From: Igor Sapego Date: ,1?? 21,2019 11:19 To: dev Subject: Re: IGNITE-8283 CPP: Implement 'varint' solution to be configurable via BinaryConfiguration Hi, The obvious solution here is to add IgniteConfiguration class for C++, but it looks like not an easy task. There is another solution which is more easy to implement: it is to add call to Java code, something like "isVarintActive()", which is going to be called on node startup. Best Regards, Igor On Mon, Jan 21, 2019 at 1:40 PM ppenguin wrote: > Igniters, > > I'am beginning with this task. Now the c++ implementation lacks some parts > that existed in Java and C#, so the task seems a little complex. I want to > discuss the details here.
[jira] [Created] (IGNITE-11029) Public API for edge-chasing deadlock detection configuration
Ivan Pavlukhin created IGNITE-11029:
---
Summary: Public API for edge-chasing deadlock detection
configuration
Key: IGNITE-11029
URL: https://issues.apache.org/jira/browse/IGNITE-11029
Project: Ignite
Issue Type: Task
Components: mvcc
Reporter: Ivan Pavlukhin
Fix For: 2.8
As deadlock detection introduce overhead during transaction processing some
configuration means should be introduced. Following aspects should be addressed:
1. Turning detection on/off.
2. Adjusting a timeout before starting actual detection.
It is proposed to introduce single property in {{TransactionConfiguration}} to
address both items.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11028) [ML] Flaky test(KeepBinaryTest)
Yury Babak created IGNITE-11028: --- Summary: [ML] Flaky test(KeepBinaryTest) Key: IGNITE-11028 URL: https://issues.apache.org/jira/browse/IGNITE-11028 Project: Ignite Issue Type: Bug Components: ml Reporter: Yury Babak Assignee: Yury Babak -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11027) CPP: Add support of compact footer for C++
Igor Sapego created IGNITE-11027: Summary: CPP: Add support of compact footer for C++ Key: IGNITE-11027 URL: https://issues.apache.org/jira/browse/IGNITE-11027 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.7 Reporter: Igor Sapego Currently, compact footers are not supported by Ignite C++ and C++ thin clients. As they both share the same library - binary, we can add this support for both C++ thin and Ignite C++ at the same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: CompactFooter for ClientBinaryMarshaller
Roman, I've filed a ticket for C++: [1] [1] - https://issues.apache.org/jira/browse/IGNITE-11027 Best Regards, Igor On Tue, Jan 22, 2019 at 12:55 PM Roman Shtykh wrote: > Igor, I see. How about having a warning if `BinaryConfiguration` is not > provided explicitly to at least raise attention? And creating a JIRA issue > for C++ clients -- after it resolves we can probably switch it to cluster > default. > > -- > Roman Shtykh > > On Monday, January 21, 2019, 7:04:30 p.m. GMT+9, Igor Sapego < > isap...@apache.org> wrote: > > I believe, it was set to false by default as it was kind of experimental > optimisation. > Also, I've checked right now and it seems that C++ clients (thick and > thin)do not yet support compact footers. It may also be a blocker to set > compactfooters to true by default. > Best Regards,Igor > > On Sat, Jan 19, 2019 at 6:52 AM Roman Shtykh > wrote: > > Thank you for the explanation. But here is the problem is not exactly with > deserialization but with that a user-defined key is being marshalled to a > binary object with the compact footer set to true, while the key for > putting has the footer set to false (which is server default). Thus we have > a different thing for the key when we try to retrieve and getting null. > Therefore, I suppose switching client to server defaults is what has to be > done. If the user decides to switch to full schema mode, at least he/she > will be aware of it. And for deserialization, the schema will be retrieved, > as you explained. What do you think? > > -- Roman > On Friday, January 18, 2019, 10:52:11 p.m. GMT+9, Vladimir Ozerov < > voze...@gridgain.com> wrote: > > "Compact footer" is optimization which saves a lot of space. Object > serialized in this form do not have the full information required for > deserialization. Metadata necessary for deserialization (aka "schema") is > located on cluster nodes. For this client it could be requested through > special command. Pleass see ClientOperation.GET_BINARY_TYPE as a starting > point. > On Fri, Jan 18, 2019 at 1:32 PM Igor Sapego wrote: > > I'm not sure, that such a change should be done in minor release, maybe in > 3.0 > Vova, what do you think? It was you, who designed and developed compact > footer, right? > Best Regards,Igor > > On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh > wrote: > > > I believe it has something to do with backward compatibility.That's what > I would like to know.If there's no strong reason to set it to false, it > should be as Ignite's default -- that's what a user would expect. And if > the user changes the configuration at the cluster, he/she will be aware of > that and change it at thin client.If we cannot set it to Ignite's default, > we can add a log message saying we force it to false. > > -- > Roman > > > On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego < > isap...@apache.org> wrote: > > First of all, I do not like that thin client is silently returns null. It > should be fixed. > For the compact footer being set to false by default - I believe it has > something to do withbackward compatibility. > Best Regards,Igor > > On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh > wrote: > > Igniters, > After putting some data with a user-defined key with a thick client, it's > impossible to retrieve it with a thin client. > https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was > a bug, so I first reported the issue to the user ml, Mikhail thanks for > checking and the jira issue) > That happens because for Ignite `compactFooter` is `true` by default, but > `ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is > not created explicitly (see ClientBinaryMarshaller#createImpl). > Any reason to force it to false? I would like to align it with Ignite > defaults (by setting to true). > > -- Roman > > > > >
[jira] [Created] (IGNITE-11026) Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay.
Pavel Voronkin created IGNITE-11026: --- Summary: Support TcpCommunicationSpi.NeedWaitDelay, TcpCommunicationSpi.MaxNeedWaitDelay. Key: IGNITE-11026 URL: https://issues.apache.org/jira/browse/IGNITE-11026 Project: Ignite Issue Type: Improvement Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11024) PME leave server node -69%
Max Shonichev created IGNITE-11024: -- Summary: PME leave server node -69% Key: IGNITE-11024 URL: https://issues.apache.org/jira/browse/IGNITE-11024 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark leave server node -69% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11025) PME leave 5 server nodes -45%
Max Shonichev created IGNITE-11025: -- Summary: PME leave 5 server nodes -45% Key: IGNITE-11025 URL: https://issues.apache.org/jira/browse/IGNITE-11025 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11023) Processing data bag on GridMarshallerMappingProcessor consume many time
Vladislav Pyatkov created IGNITE-11023:
--
Summary: Processing data bag on GridMarshallerMappingProcessor
consume many time
Key: IGNITE-11023
URL: https://issues.apache.org/jira/browse/IGNITE-11023
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
I have measure a processing data bag time on each join node and discovered what
GridMarshallerMappingProcessor consume more time then others.
It slow down on collecting topology, in particular case if joining some node
simultaneous.
{noformat}
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.207 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.208 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.219 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
242ms
2019-01-11 20:35:01.463 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 252ms
2019-01-11 20:35:01.780 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:01.781 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.791 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridCacheProcessor processed joining node data bag in 10ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridQueryProcessor processed joining node data bag in 0ms
2019-01-11 20:35:01.792 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridContinuousProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component GridMarshallerMappingProcessor processed joining node data bag in
338ms
2019-01-11 20:35:02.134 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Total
time of processing discovery data bag: 348ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager] Starting
processing discovery data bag
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component ClusterProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgnitePluginProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component CacheObjectBinaryProcessorImpl processed joining node data bag in 0ms
2019-01-11 20:35:02.326 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDiscoveryManager]
Component IgniteAuthenticationProcessor processed joining node data bag in 0ms
2019-01-11 20:35:02.337 [INFO
][tcp-disco-msg-worker-#2%NodeName%][o.a.i.i.m.d.GridDis
[jira] [Created] (IGNITE-11022) PME leave server node -31%
Max Shonichev created IGNITE-11022: -- Summary: PME leave server node -31% Key: IGNITE-11022 URL: https://issues.apache.org/jira/browse/IGNITE-11022 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark on server node leave drop -31% -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11021) PME join server node -15%
Max Shonichev created IGNITE-11021: -- Summary: PME join server node -15% Key: IGNITE-11021 URL: https://issues.apache.org/jira/browse/IGNITE-11021 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Max Shonichev Fix For: 2.5 PME benchmark drop -15% on server node join -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: CompactFooter for ClientBinaryMarshaller
Igor, I see. How about having a warning if `BinaryConfiguration` is not provided explicitly to at least raise attention? And creating a JIRA issue for C++ clients -- after it resolves we can probably switch it to cluster default. -- Roman Shtykh On Monday, January 21, 2019, 7:04:30 p.m. GMT+9, Igor Sapego wrote: I believe, it was set to false by default as it was kind of experimental optimisation. Also, I've checked right now and it seems that C++ clients (thick and thin)do not yet support compact footers. It may also be a blocker to set compactfooters to true by default. Best Regards,Igor On Sat, Jan 19, 2019 at 6:52 AM Roman Shtykh wrote: Thank you for the explanation. But here is the problem is not exactly with deserialization but with that a user-defined key is being marshalled to a binary object with the compact footer set to true, while the key for putting has the footer set to false (which is server default). Thus we have a different thing for the key when we try to retrieve and getting null. Therefore, I suppose switching client to server defaults is what has to be done. If the user decides to switch to full schema mode, at least he/she will be aware of it. And for deserialization, the schema will be retrieved, as you explained. What do you think? -- Roman On Friday, January 18, 2019, 10:52:11 p.m. GMT+9, Vladimir Ozerov wrote: "Compact footer" is optimization which saves a lot of space. Object serialized in this form do not have the full information required for deserialization. Metadata necessary for deserialization (aka "schema") is located on cluster nodes. For this client it could be requested through special command. Pleass see ClientOperation.GET_BINARY_TYPE as a starting point. On Fri, Jan 18, 2019 at 1:32 PM Igor Sapego wrote: I'm not sure, that such a change should be done in minor release, maybe in 3.0 Vova, what do you think? It was you, who designed and developed compact footer, right? Best Regards,Igor On Fri, Jan 18, 2019 at 4:20 AM Roman Shtykh wrote: > I believe it has something to do with backward compatibility.That's what I > would like to know.If there's no strong reason to set it to false, it should > be as Ignite's default -- that's what a user would expect. And if the user > changes the configuration at the cluster, he/she will be aware of that and > change it at thin client.If we cannot set it to Ignite's default, we can add > a log message saying we force it to false. -- Roman On Thursday, January 17, 2019, 7:11:05 p.m. GMT+9, Igor Sapego wrote: First of all, I do not like that thin client is silently returns null. It should be fixed. For the compact footer being set to false by default - I believe it has something to do withbackward compatibility. Best Regards,Igor On Thu, Jan 17, 2019 at 7:37 AM Roman Shtykh wrote: Igniters, After putting some data with a user-defined key with a thick client, it's impossible to retrieve it with a thin client.https://issues.apache.org/jira/browse/IGNITE-10960(I was not sure it was a bug, so I first reported the issue to the user ml, Mikhail thanks for checking and the jira issue) That happens because for Ignite `compactFooter` is `true` by default, but `ClientBinaryMarshaller` forces it to `false` if `BinaryConfiguration` is not created explicitly (see ClientBinaryMarshaller#createImpl). Any reason to force it to false? I would like to align it with Ignite defaults (by setting to true). -- Roman
[MTCGA]: new failures in builds [2867588] 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 stable failure of a flaky test in master IgniteCoreTest: CacheQueryTestSuite: TestFieldsQuerySeveral https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7923965190700916819&branch=%3Cdefault%3E&tab=testDetails *New stable failure of a flaky test in master IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryPagesSeveral https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4145688911096802577&branch=%3Cdefault%3E&tab=testDetails Changes may lead to failure were done by - sergi.vladykin https://ci.ignite.apache.org/viewModification.html?modId=872823 - 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 12:34:15 22-01-2019
[jira] [Created] (IGNITE-11020) Document edge-chasing deadlock detection
Ivan Pavlukhin created IGNITE-11020: --- Summary: Document edge-chasing deadlock detection Key: IGNITE-11020 URL: https://issues.apache.org/jira/browse/IGNITE-11020 Project: Ignite Issue Type: Bug Components: documentation, mvcc Reporter: Ivan Pavlukhin Assignee: Artem Budnikov Fix For: 2.8 Documentation for deadlock detection implemented in related ticket is needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11019) SQL: explain plan of a simple query contains merge table
Alexander Lapin created IGNITE-11019:
Summary: SQL: explain plan of a simple query contains merge table
Key: IGNITE-11019
URL: https://issues.apache.org/jira/browse/IGNITE-11019
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Alexander Lapin
Fix For: 2.8
In case of simple* query like following "select * from Organization org where
org._KEY = 1 or org._KEY = 2" explain plan will contain merge table despite the
fact that it's skipped within regular query flow.
{code:java|title=GridReduceQueryExecutor#query}
final boolean skipMergeTbl = !qry.explain() && qry.skipMergeTable()
{code}
Explain plan output:
: [SELECT
ORG__Z0.NAME AS __C0_0,
ORG__Z0.DEBTCAPITAL AS __C0_1,
ORG__Z0.ID AS __C0_2
FROM "orgBetweenTest".ORGANIZATION ORG__Z0
/* "orgBetweenTest"."_key_PK": _KEY IN(1, 2) */
WHERE ORG__Z0._KEY IN(1, 2)]
: [SELECT
__C0_0 AS NAME,
__C0_1 AS DEBTCAPITAL,
__C0_2 AS ID
FROM PUBLIC.__T0
/* "orgBetweenTest"."merge_scan" */]
*simple query by means of GridSqlQuery#simpleQuery
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
