[jira] [Created] (IGNITE-11416) DistributedMetaStorage improvements
Ivan Bessonov created IGNITE-11416: -- Summary: DistributedMetaStorage improvements Key: IGNITE-11416 URL: https://issues.apache.org/jira/browse/IGNITE-11416 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov We need following improvements: * do not write the same value twice in a row, this would lead to history pollution; * add "putAll" functionality on binary level, not in public API yet. This would simplify the migration in future; * do not use "*HistoryItem" class for everything, this is not conventional; * retrieve "dmsVer" from cluster on handshake, this would help to reduce joining node DataBag size drastically; * add "isEmpty()" or "long getVersion()" method to metastorage, will be helpful for components that use it; * there has to be an ability to read data on client nodes, maybe write as well, not sure yet. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: New PMC Member: Roman Shtykh
Congrats, Roman! вт, 26 февр. 2019 г. в 04:28, Roman Shtykh : > Thank you! It's always pleasure to work with Ignite community, and I will > keep on working on the project and spreading the Ignite word. > > Best regards, > Roman > > > On Tuesday, February 26, 2019, 7:59:58 a.m. GMT+9, Denis Magda < > dma...@apache.org> wrote: > > The Project Management Committee (PMC) for Apache Ignite > has invited Roman Shtykh to become a PMC member and we are pleased to > announce that he has accepted. Being a PMC member enables assistance with > the management and to guide the direction of the project. > > > Roman is one of the community veterans who is presently popularizing Ignite > in Japan and helping to adopt it in that country. Thanks a lot for this > hard work and let's support Roman in this initiative. > > - > Denis >
Re: New PMC Member: Roman Shtykh
Thank you! It's always pleasure to work with Ignite community, and I will keep on working on the project and spreading the Ignite word. Best regards, Roman On Tuesday, February 26, 2019, 7:59:58 a.m. GMT+9, Denis Magda wrote: The Project Management Committee (PMC) for Apache Ignite has invited Roman Shtykh to become a PMC member and we are pleased to announce that he has accepted. Being a PMC member enables assistance with the management and to guide the direction of the project. Roman is one of the community veterans who is presently popularizing Ignite in Japan and helping to adopt it in that country. Thanks a lot for this hard work and let's support Roman in this initiative. - Denis
New PMC Member: Roman Shtykh
The Project Management Committee (PMC) for Apache Ignite has invited Roman Shtykh to become a PMC member and we are pleased to announce that he has accepted. Being a PMC member enables assistance with the management and to guide the direction of the project. Roman is one of the community veterans who is presently popularizing Ignite in Japan and helping to adopt it in that country. Thanks a lot for this hard work and let's support Roman in this initiative. - Denis
Java 11 maven profile for local builds and testing
Hi Ignite Developers, Maven profile was modified to provide an opportunity to build a project locally using java11 (you can't use results of such local build for java 8). The profile is named 'java-9+'. If it is not enabled by default you will probably need to enable it manually. The ignite-tools problem under java-11 was fixed by providing two versions of this class for Java 8 & java 9+. These files are placed with different source roots. During switching between java versions you may need to re-import maven project. If you use IntelliJ than sometimes you will need to manually remove not needed source root from .iml file. See also "modules/tools/ignite-tools.iml" Sincerely, Dmitriy Pavlov BTW, Teamcity bot is up and running using Ignite 2.7 & java 11 so limited number of functionality is working well: (Apache Ignite Teamcity Bot, V20190218, Powered by Apache Ignite V2.7.0, Java Version: 11.0.1)
[jira] [Created] (IGNITE-11415) Initiator server node writes all transaction entries to WAL instead of local partition ones
Ivan Rakov created IGNITE-11415:
---
Summary: Initiator server node writes all transaction entries to
WAL instead of local partition ones
Key: IGNITE-11415
URL: https://issues.apache.org/jira/browse/IGNITE-11415
Project: Ignite
Issue Type: Bug
Reporter: Ivan Rakov
Fix For: 2.8
IgniteTxLocalAdapter#userCommit assebles allEntries()/writeEntries() and writes
them to WAL:
{code:java}
Collection commitEntries = (near() ||
cctx.snapshot().needTxReadLogging()) ? allEntries() : writeEntries();
{code}
If transaction is initiated by server node, all transaction entries will be
contained in allEntries()/writeEntries(). Thus, we may write entries to WAL
even if local node doesn't own corresponding partition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11414) Remove JUnit3LegacySupport
Ivan Fedotov created IGNITE-11414: - Summary: Remove JUnit3LegacySupport Key: IGNITE-11414 URL: https://issues.apache.org/jira/browse/IGNITE-11414 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov Remove JUnit3LegacySupport class. Remaining methods move to GridAbstractTest class or remove if it is possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
Ivan Fedotov created IGNITE-11413: - Summary: Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport Key: IGNITE-11413 URL: https://issues.apache.org/jira/browse/IGNITE-11413 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov beforeTestsStarted and afterTestsStarted methods are deprecated in context of JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass annotations for such purposes. Methods must be moved in corresponded classes and marked by annotations. It could require changes in start/stop nodes process because methods under @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11412) Remove beforeTest, afterTest from JUnit3TestLegacySupport
Ivan Fedotov created IGNITE-11412: - Summary: Remove beforeTest, afterTest from JUnit3TestLegacySupport Key: IGNITE-11412 URL: https://issues.apache.org/jira/browse/IGNITE-11412 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov Replace beforeTest, afterTest methods in JUnit3TestLegacySupport by annotations @Before, @After in corresponding classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Migration to JUnit 5
Hello Nikolay.
The prime benefits are more comfortable work with flaky tests, Java 8 tests
compatibility, user-friendly syntaxis in parametrized tests and others.
The most significant features list you can find in IEP-30 Motivation
section.
If you have any specific questions about JUnit5 feel free to ask me.
пн, 25 февр. 2019 г. в 16:55, Nikolay Izhikov :
> Hello, Ivan.
>
> May be I miss some mail - if yes, can you repeat it.
> What is advantages of migration from junit 4 to 5?
> Why we should do it?
>
>
> пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
>
> > Ivan,
> > That is my thoughts according to your questions.
> >
> > 1. I tried to implement test suits with JUnit4 compatibility layer. The
> > basic concept is to use @RunWith(JUnitPlatform.class) @SelectClasses
> > ({...})[1] and on
> > CI Ignite it works fine.
> >
> > 2. According to @Rules, there are several ways to solve it:
> > 2.1 Leave JUnit4 code without changes. It will work because of
> Vintage
> > module
> > 2.2 Rewrite the @Rule as an Extension. The work of extension is
> similar
> > to the @Rules work, but it is extracted in an Extension class.
> > For more information about extensions, please, follow the IEP [2].
> > In my opinion, the easiest and the most understandable way is to leave
> > GridAbstractTest in current form. It will work with JUnit5
> > syntaxis and abilities.
> >
> > 3. I faced a couple of problems during dealing with dynamic and static
> > tests in one project with JUnit5. The problem occurs with surefire
> version:
> > static tests work fine with 2.21x and earlier and with dynamic tests, the
> > situation is vice versa, it works with > 2.21x surefire version.
> > We can use helpful surefire dependency to use static tests with the
> newest
> > surefire version [3], but dynamic tests become unavailable from pure
> > Maven and accordingly from CI Ignite (from IDE all is fine).
> > I can suggest leaving this type of tests on JUnit4 on the current stage -
> > they are in the vast minority.
> >
> > Let me comment on your side notes.
> >
> > I am not against the stable and widely-used test library usage. All I
> want
> > to say that it is not necessary in case of the main testing Ignite
> > framework (Junit) already provides the mentioned features.
> >
> > At the initial stage of improvements 3->4 I am planning to remove
> > JUnit3TestLegacyAssert, JUnit3TestLegacySupport classes. I guess that
> > during this work
> > I will face with an issue that you are mentioned - turning instance
> methods
> > to static. It is because of beforeTestsStarted and afterTestsStarted
> > methods - I want to replace them by methods with BeforeAll, AfterAll
> > annotations. But the point is that methods under such annotations must be
> > static. Just now I am not sure about fully removing
> > GridCommonAbstractTest class, but the need for static methods is a fact.
> >
> > [1]
> >
> >
> https://github.com/apache/ignite/blob/85ba3a88d661bb05bbb749bd1feaf60cd9099ddc/examples/src/test/java/org/apache/ignite/testsuites/IgniteExamplesSelfTestSuite.java#L59
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> > [3] https://github.com/junit-team/junit5/issues/1778
> >
> > вс, 24 февр. 2019 г. в 10:15, Павлухин Иван :
> >
> > > Ivan,
> > >
> > > Indeed junit5 has a lot of powerful features which can improve testing
> > > process.
> > >
> > > But first we should go through a migration process. There are several
> > > items which looks quite challenging.
> > > 1. Test suites support. Correct me if I am missed it, but I have not
> > > found a concept of test suites similar to junit3/4 ones. CI in Ignite
> > > heavily depends on test suites. Is there an alternative in junit5?
> > > 2. The majority of our tests extend GridAbstractTest which in fact is
> > > a core class in Ignite testing. Writing a test without extending it is
> > > not a good idea. Currently it employs number of junit4 concepts, e.g.
> > > test rules which as I saw are not supported in junit5. So, it sounds
> > > that some changes in GridAbstractTest need to be done. During
> > > migration from junit 3 to 4 GridAbstractTest used kind of mimicry, it
> > > can be used as a base class for junit3 and junit4 tests at the same
> > > time. How can we address transitional period now?
> > > 3. Also we have bunch of tests using our home-brewed parametrization.
> > > You can find them by searching usages of
> > > ConfigVariationsTestSuiteBuilder. This part was rather tricky during
> > > migration to junit4.
> > >
> > > Do we have a plan for all these items?
> > >
> > >
> > > Couple of side notes.
> > >
> > > Regarding dependencies minimization. Actually, I think it is important
> > > for junit itself as a library. Many libraries try to minimize
> > > dependency. In Ignite we do so as well. But in my opinion it is not
> > > the case in context of libraries used during testing. If we have
> > > useful, stable and widely-used test library
[jira] [Created] (IGNITE-11411) Remove tearDown, setUp from GridAbstractTest
Ivan Fedotov created IGNITE-11411: - Summary: Remove tearDown, setUp from GridAbstractTest Key: IGNITE-11411 URL: https://issues.apache.org/jira/browse/IGNITE-11411 Project: Ignite Issue Type: Improvement Reporter: Ivan Fedotov Assignee: Ivan Fedotov TearDown and setUp methods are deprecated for JUnit 4+ version. It is necessary to replace them with appropriate methods, marked by @Before and @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Migration to JUnit 5
Hello, Ivan.
May be I miss some mail - if yes, can you repeat it.
What is advantages of migration from junit 4 to 5?
Why we should do it?
пн, 25 февр. 2019 г. в 16:33, Ivan Fedotov :
> Ivan,
> That is my thoughts according to your questions.
>
> 1. I tried to implement test suits with JUnit4 compatibility layer. The
> basic concept is to use @RunWith(JUnitPlatform.class) @SelectClasses
> ({...})[1] and on
> CI Ignite it works fine.
>
> 2. According to @Rules, there are several ways to solve it:
> 2.1 Leave JUnit4 code without changes. It will work because of Vintage
> module
> 2.2 Rewrite the @Rule as an Extension. The work of extension is similar
> to the @Rules work, but it is extracted in an Extension class.
> For more information about extensions, please, follow the IEP [2].
> In my opinion, the easiest and the most understandable way is to leave
> GridAbstractTest in current form. It will work with JUnit5
> syntaxis and abilities.
>
> 3. I faced a couple of problems during dealing with dynamic and static
> tests in one project with JUnit5. The problem occurs with surefire version:
> static tests work fine with 2.21x and earlier and with dynamic tests, the
> situation is vice versa, it works with > 2.21x surefire version.
> We can use helpful surefire dependency to use static tests with the newest
> surefire version [3], but dynamic tests become unavailable from pure
> Maven and accordingly from CI Ignite (from IDE all is fine).
> I can suggest leaving this type of tests on JUnit4 on the current stage -
> they are in the vast minority.
>
> Let me comment on your side notes.
>
> I am not against the stable and widely-used test library usage. All I want
> to say that it is not necessary in case of the main testing Ignite
> framework (Junit) already provides the mentioned features.
>
> At the initial stage of improvements 3->4 I am planning to remove
> JUnit3TestLegacyAssert, JUnit3TestLegacySupport classes. I guess that
> during this work
> I will face with an issue that you are mentioned - turning instance methods
> to static. It is because of beforeTestsStarted and afterTestsStarted
> methods - I want to replace them by methods with BeforeAll, AfterAll
> annotations. But the point is that methods under such annotations must be
> static. Just now I am not sure about fully removing
> GridCommonAbstractTest class, but the need for static methods is a fact.
>
> [1]
>
> https://github.com/apache/ignite/blob/85ba3a88d661bb05bbb749bd1feaf60cd9099ddc/examples/src/test/java/org/apache/ignite/testsuites/IgniteExamplesSelfTestSuite.java#L59
> [2]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
> [3] https://github.com/junit-team/junit5/issues/1778
>
> вс, 24 февр. 2019 г. в 10:15, Павлухин Иван :
>
> > Ivan,
> >
> > Indeed junit5 has a lot of powerful features which can improve testing
> > process.
> >
> > But first we should go through a migration process. There are several
> > items which looks quite challenging.
> > 1. Test suites support. Correct me if I am missed it, but I have not
> > found a concept of test suites similar to junit3/4 ones. CI in Ignite
> > heavily depends on test suites. Is there an alternative in junit5?
> > 2. The majority of our tests extend GridAbstractTest which in fact is
> > a core class in Ignite testing. Writing a test without extending it is
> > not a good idea. Currently it employs number of junit4 concepts, e.g.
> > test rules which as I saw are not supported in junit5. So, it sounds
> > that some changes in GridAbstractTest need to be done. During
> > migration from junit 3 to 4 GridAbstractTest used kind of mimicry, it
> > can be used as a base class for junit3 and junit4 tests at the same
> > time. How can we address transitional period now?
> > 3. Also we have bunch of tests using our home-brewed parametrization.
> > You can find them by searching usages of
> > ConfigVariationsTestSuiteBuilder. This part was rather tricky during
> > migration to junit4.
> >
> > Do we have a plan for all these items?
> >
> >
> > Couple of side notes.
> >
> > Regarding dependencies minimization. Actually, I think it is important
> > for junit itself as a library. Many libraries try to minimize
> > dependency. In Ignite we do so as well. But in my opinion it is not
> > the case in context of libraries used during testing. If we have
> > useful, stable and widely-used test library which can improve our
> > processes why should not we use it?
> >
> > Regarding removing leftovers left after junit 3->4 migration.
> > Actually, I think that GridAbstractTest and GridCommonAbstractTest can
> > be refactored in order to simplify further development and migration
> > to new testing framework. For example, there are a lot of instance
> > methods which can be turned to static methods. Various start/stopGrid
> > methods fall into this category. They can be extracted into some
> > utility class and imported statically. Perhaps, after number of
Re: Migration to JUnit 5
Ivan,
That is my thoughts according to your questions.
1. I tried to implement test suits with JUnit4 compatibility layer. The
basic concept is to use @RunWith(JUnitPlatform.class) @SelectClasses
({...})[1] and on
CI Ignite it works fine.
2. According to @Rules, there are several ways to solve it:
2.1 Leave JUnit4 code without changes. It will work because of Vintage
module
2.2 Rewrite the @Rule as an Extension. The work of extension is similar
to the @Rules work, but it is extracted in an Extension class.
For more information about extensions, please, follow the IEP [2].
In my opinion, the easiest and the most understandable way is to leave
GridAbstractTest in current form. It will work with JUnit5
syntaxis and abilities.
3. I faced a couple of problems during dealing with dynamic and static
tests in one project with JUnit5. The problem occurs with surefire version:
static tests work fine with 2.21x and earlier and with dynamic tests, the
situation is vice versa, it works with > 2.21x surefire version.
We can use helpful surefire dependency to use static tests with the newest
surefire version [3], but dynamic tests become unavailable from pure
Maven and accordingly from CI Ignite (from IDE all is fine).
I can suggest leaving this type of tests on JUnit4 on the current stage -
they are in the vast minority.
Let me comment on your side notes.
I am not against the stable and widely-used test library usage. All I want
to say that it is not necessary in case of the main testing Ignite
framework (Junit) already provides the mentioned features.
At the initial stage of improvements 3->4 I am planning to remove
JUnit3TestLegacyAssert, JUnit3TestLegacySupport classes. I guess that
during this work
I will face with an issue that you are mentioned - turning instance methods
to static. It is because of beforeTestsStarted and afterTestsStarted
methods - I want to replace them by methods with BeforeAll, AfterAll
annotations. But the point is that methods under such annotations must be
static. Just now I am not sure about fully removing
GridCommonAbstractTest class, but the need for static methods is a fact.
[1]
https://github.com/apache/ignite/blob/85ba3a88d661bb05bbb749bd1feaf60cd9099ddc/examples/src/test/java/org/apache/ignite/testsuites/IgniteExamplesSelfTestSuite.java#L59
[2]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5
[3] https://github.com/junit-team/junit5/issues/1778
вс, 24 февр. 2019 г. в 10:15, Павлухин Иван :
> Ivan,
>
> Indeed junit5 has a lot of powerful features which can improve testing
> process.
>
> But first we should go through a migration process. There are several
> items which looks quite challenging.
> 1. Test suites support. Correct me if I am missed it, but I have not
> found a concept of test suites similar to junit3/4 ones. CI in Ignite
> heavily depends on test suites. Is there an alternative in junit5?
> 2. The majority of our tests extend GridAbstractTest which in fact is
> a core class in Ignite testing. Writing a test without extending it is
> not a good idea. Currently it employs number of junit4 concepts, e.g.
> test rules which as I saw are not supported in junit5. So, it sounds
> that some changes in GridAbstractTest need to be done. During
> migration from junit 3 to 4 GridAbstractTest used kind of mimicry, it
> can be used as a base class for junit3 and junit4 tests at the same
> time. How can we address transitional period now?
> 3. Also we have bunch of tests using our home-brewed parametrization.
> You can find them by searching usages of
> ConfigVariationsTestSuiteBuilder. This part was rather tricky during
> migration to junit4.
>
> Do we have a plan for all these items?
>
>
> Couple of side notes.
>
> Regarding dependencies minimization. Actually, I think it is important
> for junit itself as a library. Many libraries try to minimize
> dependency. In Ignite we do so as well. But in my opinion it is not
> the case in context of libraries used during testing. If we have
> useful, stable and widely-used test library which can improve our
> processes why should not we use it?
>
> Regarding removing leftovers left after junit 3->4 migration.
> Actually, I think that GridAbstractTest and GridCommonAbstractTest can
> be refactored in order to simplify further development and migration
> to new testing framework. For example, there are a lot of instance
> methods which can be turned to static methods. Various start/stopGrid
> methods fall into this category. They can be extracted into some
> utility class and imported statically. Perhaps, after number of such
> refactoring we will be able to write tests without extending
> GridCommonAbstractTest.
>
> пт, 22 февр. 2019 г. в 18:33, Ivan Fedotov :
> >
> > Hi Ivan!
> >
> > Junit5 differs from JUnit4 not so strong as 4 from 3 version. Of course,
> > we can use AssertJ and other libraries, but it is more comfortable to
> > use functionality from the box. Moreover, the JUnit
[jira] [Created] (IGNITE-11409) Fix Ignite Examples-LGPL pom file
Dmitriy Pavlov created IGNITE-11409: --- Summary: Fix Ignite Examples-LGPL pom file Key: IGNITE-11409 URL: https://issues.apache.org/jira/browse/IGNITE-11409 Project: Ignite Issue Type: Bug Reporter: Dmitriy Pavlov During [~IGINTE-11140] pom-standalone was updated. But we have one more POM file with reference to dependencies: It is necessary to adopt the commit https://github.com/apache/ignite/commit/332103e1997adaba67610ec2e4110cf20d65e406 to pom-standalone-lgpl.xml file -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11408) AssertionError may occurs on client start
Dmitry Sherstobitov created IGNITE-11408:
Summary: AssertionError may occurs on client start
Key: IGNITE-11408
URL: https://issues.apache.org/jira/browse/IGNITE-11408
Project: Ignite
Issue Type: Bug
Reporter: Dmitry Sherstobitov
Scenario from: https://issues.apache.org/jira/browse/IGNITE-11406
AssertionError may occurs on client start:
{code}
2019-02-23T18:26:27,317][DEBUG][tcp-client-disco-msg-worker-#4][TcpDiscoverySpi]
Grid runnable finished normally: tcp-client-disco-msg-worker-#4
Exception in thread “tcp-client-disco-msg-worker-#4” java.lang.AssertionError:
TcpDiscoveryClientReconnectMessage
[routerNodeId=76b33f1b-bef6-4805-bcca-0ea32df641ac, lastMsgId=null,
super=TcpDiscoveryAbstractMessage
[sndNodeId=76b33f1b-bef6-4805-bcca-0ea32df641ac,
id=57c55fa1961-99d3d909-fa44-4b74-aea4-d375ad85e53e,
verifierNodeId=6ba6bd09-4bc0-400c-ba11-a06d2507e983, topVer=0, pendingIdx=0,
failedNodes=null, isClient=false]]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processClientReconnectMessage(ClientImpl.java:2311)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1914)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1798)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}
Other trace
{code:java}
at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
[piclient-2.7.jar:?]
at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
[piclient-2.7.jar:?]
at py4j.Gateway.invoke(Gateway.java:282) [piclient-2.7.jar:?]
at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
[piclient-2.7.jar:?]
at py4j.commands.CallCommand.execute(CallCommand.java:79)
[piclient-2.7.jar:?]
at py4j.GatewayConnection.run(GatewayConnection.java:238)
[piclient-2.7.jar:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, sockTimeout=3, ackTimeout=6,
marsh=JdkMarshaller
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@59f2595b],
reconCnt=2, reconDelay=2000, maxAckTimeout=30, forceSrvMode=false,
clientReconnectDisabled=false, internalLsnr=null, skipAddrsRandomization=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:901)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1672)
~[ignite-core-2.4.15.jar:2.4.15]
... 22 more
Caused by: org.apache.ignite.spi.IgniteSpiException: Some error in join process.
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1809)
~[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
~[ignite-core-2.4.15.jar:2.4.15]
2019-02-23T18:26:27,320][ERROR][tcp-client-disco-sock-reader-#3][TcpDiscoverySpi]
Connection failed [sock=Socket[addr=/172.25.1.34,port=47503,localport=60675],
locNodeId=99d3d909-fa44-4b74-aea4-d375ad85e53e]
2019-02-23T18:26:27,320][ERROR][Thread-2][IgniteKernal] Got exception while
starting (will rollback startup routine).{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11407) AssertionError may occurs on server start
Dmitry Sherstobitov created IGNITE-11407:
Summary: AssertionError may occurs on server start
Key: IGNITE-11407
URL: https://issues.apache.org/jira/browse/IGNITE-11407
Project: Ignite
Issue Type: Bug
Reporter: Dmitry Sherstobitov
See https://issues.apache.org/jira/browse/IGNITE-11406 (same scenario)
On 5th iteration (on each iteration there is 50 round cluster nodes restart)
{code:java}
ava.lang.AssertionError
at
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.stopRoutine(GridContinuousProcessor.java:743)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeQuery0(CacheContinuousQueryManager.java:705)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.executeInternalQuery(CacheContinuousQueryManager.java:542)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.startQuery(DataStructuresProcessor.java:213)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.getAtomic(DataStructuresProcessor.java:541)
at
org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.atomicLong(DataStructuresProcessor.java:457)
at org.apache.ignite.internal.IgniteKernal.atomicLong(IgniteKernal.java:3468)
at org.apache.ignite.internal.IgniteKernal.atomicLong(IgniteKernal.java:3457)
at
org.apache.ignite.piclient.bean.LifecycleAtomicLongBean.onLifecycleEvent(LifecycleAtomicLongBean.java:48)
at
org.apache.ignite.internal.IgniteKernal.notifyLifecycleBeans(IgniteKernal.java:655)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1064)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1062)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:948)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:847)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:717)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:686)
at org.apache.ignite.Ignition.start(Ignition.java:352)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
Failed to start grid: null{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11406) NullPointerException may occurs on client start
Dmitry Sherstobitov created IGNITE-11406:
Summary: NullPointerException may occurs on client start
Key: IGNITE-11406
URL: https://issues.apache.org/jira/browse/IGNITE-11406
Project: Ignite
Issue Type: Bug
Reporter: Dmitry Sherstobitov
During testing fixes for https://issues.apache.org/jira/browse/IGNITE-10878
# Start cluster, create caches with no persistence and load data into it
# Restart each node in cluster by order (coordinator first)
Do not wait until topology message occurs
# Try to run utilities: activate, baseline (to check that cluster is alive)
# Run clients and load data into alive caches
On 4th step one of the clients throw NPE on start
{code:java}
2019-02-23T18:36:24,045][DEBUG][tcp-client-disco-msg-worker-#4][TcpDiscoverySpi]
Connection closed, local node received force fail message, will not try to
restore connection
2019-02-23T18:36:24,045][DEBUG][tcp-client-disco-msg-worker-#4][TcpDiscoverySpi]
Failed to restore closed connection, will try to reconnect
[networkTimeout=5000, joinTimeout=0, failMsg=TcpDiscoveryNodeFailedMessage
[failedNodeId=80f8b6ee-6a6d-4235-86e9-1b66ea310eb6, order=90, warning=Client
node considered as unreachable and will be dropped from cluster, because no
metrics update messages received in interval:
TcpDiscoverySpi.clientFailureDetectionTimeout() ms. It may be caused by network
problems or long GC pause on client node, try to increase this parameter.
[nodeId=80f8b6ee-6a6d-4235-86e9-1b66ea310eb6,
clientFailureDetectionTimeout=3], super=TcpDiscoveryAbstractMessage
[sndNodeId=987d4a03-8233-4130-af5b-c06900bdb6d7,
id=3642cfa1961-987d4a03-8233-4130-af5b-c06900bdb6d7,
verifierNodeId=d9abbff3-4b4d-4a13-9cb1-0ca4d2436164, topVer=167, pendingIdx=0,
failedNodes=null, isClient=false]]]
2019-02-23T18:36:24,046][DEBUG][tcp-client-disco-msg-worker-#4][TcpDiscoverySpi]
Discovery notification [node=TcpDiscoveryNode
[id=80f8b6ee-6a6d-4235-86e9-1b66ea310eb6, addrs=[172.25.1.34],
sockAddrs=[lab34.gridgain.local/172.25.1.34:0], discPort=0, order=165,
intOrder=0, lastExchangeTime=1550936128313, loc=true,
ver=2.4.15#20190222-sha1:36b1d676, isClient=true],
type=CLIENT_NODE_DISCONNECTED, topVer=166]
2019-02-23T18:36:24,049][INFO
][tcp-client-disco-msg-worker-#4][GridDhtPartitionsExchangeFuture] Finish
exchange future [startVer=AffinityTopologyVersion [topVer=165, minorTopVer=0],
resVer=null, err=class
org.apache.ignite.internal.IgniteClientDisconnectedCheckedException: Client
node disconnected: null]
[2019-02-23T18:36:24,061][ERROR][Thread-2][IgniteKernal] Got exception while
starting (will rollback startup routine).
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.internalCacheEx(GridCacheProcessor.java:3886)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.utilityCache(GridCacheProcessor.java:3858)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.updateUtilityCache(GridServiceProcessor.java:290)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart0(GridServiceProcessor.java:233)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.processors.service.GridServiceProcessor.onKernalStart(GridServiceProcessor.java:221)
~[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1038)
[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1062)
[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:948)
[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:847)
[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:717)
[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:686)
[ignite-core-2.4.15.jar:2.4.15]
at org.apache.ignite.Ignition.start(Ignition.java:352)
[ignite-core-2.4.15.jar:2.4.15]
at
org.apache.ignite.piclient.api.IgniteService.startIgniteClientNode(IgniteService.java:86)
[piclient-2.7.jar:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[?:1.8.0_181]
at
[jira] [Created] (IGNITE-11405) [ML] Fix typo in Javadoc of DelegatingNamedVector
Anton Dmitriev created IGNITE-11405: --- Summary: [ML] Fix typo in Javadoc of DelegatingNamedVector Key: IGNITE-11405 URL: https://issues.apache.org/jira/browse/IGNITE-11405 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.8 Reporter: Anton Dmitriev Assignee: Anton Dmitriev Fix For: 2.8 Fix typo in Javadoc of DelegatingNamedVector (NamedValue). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11404) Document CREATE TABLE "parallelism" option
Vladimir Ozerov created IGNITE-11404:
Summary: Document CREATE TABLE "parallelism" option
Key: IGNITE-11404
URL: https://issues.apache.org/jira/browse/IGNITE-11404
Project: Ignite
Issue Type: Task
Components: documentation, sql
Reporter: Vladimir Ozerov
Assignee: Artem Budnikov
Fix For: 2.8
We added new {{PARALLELISM}} option:
{code}
CREATE TABLE ... WITH "parallelism = 4"
{code}
This option affect query parallelism which is otherwise set from
{{CacheConfiguration.queryParallelism}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11403) Web console: 'export all' for scan ignores a filter value
Pavel Konstantinov created IGNITE-11403: --- Summary: Web console: 'export all' for scan ignores a filter value Key: IGNITE-11403 URL: https://issues.apache.org/jira/browse/IGNITE-11403 Project: Ignite Issue Type: Bug Components: wizards Reporter: Pavel Konstantinov Create a new 'scan', set some valid filter, make a scan, make 'Export All' Expected - exported file should contain the filtered data only Actual - all data are exported -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11402) SQL: Add ability to specift inline size of PK and affinity key indexes from CREATE TABLE and QueryEntity
Vladimir Ozerov created IGNITE-11402: Summary: SQL: Add ability to specift inline size of PK and affinity key indexes from CREATE TABLE and QueryEntity Key: IGNITE-11402 URL: https://issues.apache.org/jira/browse/IGNITE-11402 Project: Ignite Issue Type: Task Components: sql Reporter: Vladimir Ozerov Fix For: 2.8 Currently it is not possible to set inline size for automatically created indexes easily. We need to make sure that use has convenient way to set them both programmatically and from DDL. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
