[MTCGA]: new failures in builds [3036589] 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. *Recently contributed test failed in master http.GridHttpDeploymentSelfTest https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8313984068492573325=%3Cdefault%3E=testDetails Changes may lead to failure were done by - vozerov https://ci.ignite.apache.org/viewModification.html?modId=875229 - ygerzhedovich https://ci.ignite.apache.org/viewModification.html?modId=875221 - aplatonovv https://ci.ignite.apache.org/viewModification.html?modId=875234 - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=875218 - 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:41:48 08-02-2019
Re: [DISCUSSION] Fixed test order to reduce flakyness
I mean changing parameter http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runOrder which is fileSystem by default. It is not about hiding. If a problematic test affects other test is will continue to affect. The main point here is only about the test, which will be affected. With unpredictable order, testA may break testB, testC, testD. But for predictive & fixed order test affected by a failure of testA will be always testC, and B will not be considered flaky because of the randomized nature of execution. It will help for building at least good statistics in the TC Bot. ср, 6 февр. 2019 г. в 17:37, Eduard Shangareev : > Dmitriy, > > Please, clarify the idea. > What do we want to achieve by this? Making tests more stable by hiding some > issues in our tests/codebase? > > > On Tue, Feb 5, 2019 at 6:57 PM Павлухин Иван wrote: > > > Dmitriy, > > > > Sounds like a good idea to me. Problems related to tests isolation are > > very common in practice. And things can be complicated when order > > varies. > > > > But by the way does the order of Ignite tests vary today? Junit 4 > > javadocs claims something about "default deterministic order" [1]. > > > > [1] > https://junit.org/junit4/javadoc/latest/org/junit/FixMethodOrder.html > > > > вт, 5 февр. 2019 г. в 17:40, Dmitriy Pavlov : > > > > > > Dear Ignite Developers, > > > > > > The original idea came from our recent habr.ru post related to Apache > > > Ignite TeamCity Bot (for Russian native speakers, you can read an > > original > > > https://habr.com/ru/company/sberbank/blog/436070/#comment_19616976 ) > > > > > > It is a known phenomenon when tests have an influence on each other. > The > > > simplest case when Ignite Native persistence is used, and not properly > > > cleared after a test run. This can make some test failed afterward. > > > > > > So, what if we will set predictable, for example, alphabetical tests > > > execution order (maven-surefire-plugin/runOrder/alphabetical). This may > > > have the following effect: the set of tests failed because of being > > > affected by the previous run will be constant, will be exactly the same > > > each run. > > > > > > At some point, when we stabilize flaky tests enough, we may select > random > > > order, but for now, this solution seems valid to me. > > > > > > What do you think? > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
[jira] [Created] (IGNITE-11273) IgniteCassandraStoreTestSuite failed under Java 11
Dmitriy Pavlov created IGNITE-11273:
---
Summary: IgniteCassandraStoreTestSuite failed under Java 11
Key: IGNITE-11273
URL: https://issues.apache.org/jira/browse/IGNITE-11273
Project: Ignite
Issue Type: Bug
Reporter: Dmitriy Pavlov
https://ci.ignite.apache.org/viewLog.html?buildId=3027678=IgniteTests24Java8_CassandraStore
store.IgniteCassandraStoreTestSuite
{noformat}
java.lang.RuntimeException: Failed to start embedded Cassandra instance
at
org.apache.ignite.testsuites.cassandra.store.IgniteCassandraStoreTestSuite.setUpClass(IgniteCassandraStoreTestSuite.java:59)
Caused by: java.lang.ExceptionInInitializerError
at
org.apache.ignite.testsuites.cassandra.store.IgniteCassandraStoreTestSuite.setUpClass(IgniteCassandraStoreTestSuite.java:56)
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 5
at
org.apache.ignite.testsuites.cassandra.store.IgniteCassandraStoreTestSuite.setUpClass(IgniteCassandraStoreTestSuite.java:56)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11272) Investigate race between local node promotion to the first node in topology and NodeAddedMessage
Alexey Goncharuk created IGNITE-11272:
-
Summary: Investigate race between local node promotion to the
first node in topology and NodeAddedMessage
Key: IGNITE-11272
URL: https://issues.apache.org/jira/browse/IGNITE-11272
Project: Ignite
Issue Type: Improvement
Reporter: Alexey Goncharuk
The following race is possible - a node sends join request, succeeds, but does
not receive {{NodeAddFinishedMessage}} on time, after that due to a short-time
connection break it fails to send join request and decides to promote itself to
a first node in the topology. At the same time, the network may be restored and
{{NodeAddedMessage}} may be received by the local node. The behavior is
currently undefined.
This should be tested and fixed if needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11271) Investigate setting discardCustomMsgId to null in prepareNodeAddedMessage
Alexey Goncharuk created IGNITE-11271: - Summary: Investigate setting discardCustomMsgId to null in prepareNodeAddedMessage Key: IGNITE-11271 URL: https://issues.apache.org/jira/browse/IGNITE-11271 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk >From debugging IGNITE-10935 it was discovered that NodeAddedMessage contains >wrong state: pending messages are already filtered out by discard ID, but at >the same time discardId and customDiscardId are set to non-null values. This >resulted in a broken pending messages iterator on a newly added node: >SkipIterator was skipping all pending messages until a valid discardId was >received. The fix made in IGNITE-10935 was incomplete because we should have set both discardId and customDiscardId to null. However, after running TC tests it turned out that setting discardCustomMsgId to null resulted in duplicate custom events (the particular failed test is AuthenticationProcessorNodeRestartTest#testConcurrentAddUpdateRemoveNodeRestartServer) The reason behind the failed test is that some of the fired custom events are delivered multiple times. This should be investigated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11270) Batch join to topology
Vladislav Pyatkov created IGNITE-11270: -- Summary: Batch join to topology Key: IGNITE-11270 URL: https://issues.apache.org/jira/browse/IGNITE-11270 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov In first cluster start many nodes will trying to join. This case leed to many time consuming join process (TcpDiscoveryJoinRequestMessage -> TcpDiscoveryNodeAddedMessage -> TcpDiscoveryNodeAddFinishedMessage). Finally, collect of topology required to much time. We can to merge some of TcpDiscoveryJoinRequestMessage and join to topology as one batch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11269) Optimize node join to topology
Vladislav Pyatkov created IGNITE-11269: -- Summary: Optimize node join to topology Key: IGNITE-11269 URL: https://issues.apache.org/jira/browse/IGNITE-11269 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov When coordinator recived TcpDiscoveryJoinRequestMessage appropriate TcpDiscoveryNodeAddedMessage had been sent in should not to process new recived TcpDiscoveryJoinRequestMessage until first joined node does not complitly joined (TcpDiscoveryNodeAddFinishedMessage was sented). This solution allow to faster join node to topology without blocking ring of huge TcpDiscoveryNodeAddedMessage's. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11268) Unable to run control.bat or ignite.bat from Ignite source tree with compiled classes
Andrey Kuznetsov created IGNITE-11268:
-
Summary: Unable to run control.bat or ignite.bat from Ignite
source tree with compiled classes
Key: IGNITE-11268
URL: https://issues.apache.org/jira/browse/IGNITE-11268
Project: Ignite
Issue Type: Bug
Reporter: Andrey Kuznetsov
Under Windows, {{control}} and {{ignite}} scripts collect Java classpath value
from {{%IGNITE_HOME%\modules\*\target}} directories into a variable. Batch
script variable length is limited to 8k characters, and this leads to error
when there are many compiled/packaged modules in a source tree.
Possible (yet imperfect) solutions:
- Limit modules list to some minimal required sublist.
- Create Class-Path-header-only jar "on the fly".
- (Java 9+ only) Generate command-line arguments file, see [1].
[1]
https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-4856361B-8BFD-4964-AE84-121F5F6CF111
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11267) Print Warn user when keystore password arguments
Andrey Kuznetsov created IGNITE-11267: - Summary: Print Warn user when keystore password arguments Key: IGNITE-11267 URL: https://issues.apache.org/jira/browse/IGNITE-11267 Project: Ignite Issue Type: Bug Reporter: Andrey Kuznetsov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Root readme.md update
+1 Can you file a ticket? Then notify me or Dmitriy for review? Regards, -- Ilya Kasnacheev пт, 8 февр. 2019 г. в 16:02, Dmitriy Pavlov : > ++1 > > пт, 8 февр. 2019 г. в 15:58, Yuriy Babak : > > > Igniters, > > > > I noticed that our root readme.md outdated. So I suggest remove sections > > about hadoop accelerator and IGFS. > > > > Also, I want to add a section about ML. > > > > Any thoughts? > > > > Best regards, > > Yuriy Babak > > >
Re: Root readme.md update
++1 пт, 8 февр. 2019 г. в 15:58, Yuriy Babak : > Igniters, > > I noticed that our root readme.md outdated. So I suggest remove sections > about hadoop accelerator and IGFS. > > Also, I want to add a section about ML. > > Any thoughts? > > Best regards, > Yuriy Babak >
Root readme.md update
Igniters, I noticed that our root readme.md outdated. So I suggest remove sections about hadoop accelerator and IGFS. Also, I want to add a section about ML. Any thoughts? Best regards, Yuriy Babak
[jira] [Created] (IGNITE-11266) Platform .NET test failed with Java 11 warning
Dmitriy Pavlov created IGNITE-11266:
---
Summary: Platform .NET test failed with Java 11 warning
Key: IGNITE-11266
URL: https://issues.apache.org/jira/browse/IGNITE-11266
Project: Ignite
Issue Type: Bug
Reporter: Dmitriy Pavlov
Following warning is unavoidable, because Java always warns about illegal
reflective access (at least for the first time). Probably we can change some
settings to avoid "The active test run was aborted. Reason".
{noformat}
[17:32:56][test] The active test run was aborted. Reason: WARNING: An illegal
reflective access operation has occurred
[17:32:56][test] WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/data/teamcity/work/9198da4c51c3e112/modules/core/target/classes/) to
field java.nio.Buffer.address
[17:32:56][test] WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
[17:32:56][test] WARNING: Use --illegal-access=warn to enable warnings of
further illegal reflective access operations
[17:32:56][test] WARNING: All illegal access operations will be denied in a
future release
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11265) JVM Crash is often on TeamCity for Java 11 runs
Dmitriy Pavlov created IGNITE-11265: --- Summary: JVM Crash is often on TeamCity for Java 11 runs Key: IGNITE-11265 URL: https://issues.apache.org/jira/browse/IGNITE-11265 Project: Ignite Issue Type: Bug Reporter: Dmitriy Pavlov All crash dumps complain about the same method org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writeLock Data Structures (https://ci.ignite.apache.org/viewLog.html?buildId=3007882) https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_DataStructures/3007882:id/hs_err_pid2674225.log Other recent examples Queries 1 https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_Queries1/3027655:id/hs_err_pid2458635.log Client Nodes https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ClientNodes/3027569:id/hs_err_pid2431080.log Zookeeper Discovery https://ci.ignite.apache.org/repository/download/IgniteTests24Java8_ZooKeeperDiscovery1/3027601:id/hs_err_pid3473289.log -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11264) JVM crash in OffheapReadWriteLock#tryWriteLock
Ivan Bessonov created IGNITE-11264: -- Summary: JVM crash in OffheapReadWriteLock#tryWriteLock Key: IGNITE-11264 URL: https://issues.apache.org/jira/browse/IGNITE-11264 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Eduard Shangareev Attachments: hs_err_pid19407.log JVM crash in the end of IgniteClusterActivateDeactivateTest#testClientReconnectClusterActivateInProgress. Test was invoked using "Until Failure" mode in IDEA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11263) If host in TcpDiscoveryVmIpFinder is unreachable - server hang on start
ARomantsov created IGNITE-11263:
---
Summary: If host in TcpDiscoveryVmIpFinder is unreachable - server
hang on start
Key: IGNITE-11263
URL: https://issues.apache.org/jira/browse/IGNITE-11263
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: ARomantsov
Fix For: 2.8
If one of servers in discovery ipFinder is unreachable - server hang on start
repeat locally with commands
sudo iptables -A INPUT DROP
sudo iptables -A OUTPUT DROP
{code:java}
{code}
Server logs end with
{code:java}
[14:39:44,668][INFO][main][GridCacheDatabaseSharedManager] Read checkpoint
status [startMarker=null, endMarker=null]
[14:39:44,669][INFO][main][GridCacheDatabaseSharedManager] Applying lost cache
updates since last checkpoint record [lastMarked=FileWALPointer [idx=0,
fileOff=0, len=0], lastCheckpointId=----]
[14:39:44,700][INFO][main][GridCacheDatabaseSharedManager] Finished applying
WAL changes [updatesApplied=0, time=30 ms]
[14:39:44,700][INFO][main][GridCacheDatabaseSharedManager] Restoring partition
state for local groups.
[14:39:44,705][INFO][main][GridCacheDatabaseSharedManager] Finished restoring
partition state for local groups [groupsProcessed11partitionsProcessed=0,
time=10ms]
[14:39:45,252][INFO][main][TcpDiscoverySpi] Successfully bound to TCP port
[port=47500, localHost=0.0.0.0/0.0.0.0,
locNodeId=6621cfd7-26a8-4bc0-a80a-88c6281aa118]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11262) Compression on Discovery data bag
Vladislav Pyatkov created IGNITE-11262:
--
Summary: Compression on Discovery data bag
Key: IGNITE-11262
URL: https://issues.apache.org/jira/browse/IGNITE-11262
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
Size of GridComponetns data may increase significantly in large deployment.
Examples:
1) In case of more then 3K caches with QueryEntry configured - size of
{{DiscoveryDataBag}}{{GridCacheProcessor}} data bag consume more then 20 Mb
2) If cluster contain more then 13K objects -
{{GridMarshallerMappingProcessor}} size more then 1 Mb
3) Cluster with more then 3К types in binary format -
{{CacheObjectBinaryProcessorImpl}} size can grow to 10Mb
The data in most cases contain duplicated structure and simple zip compression
can led to seriously reduce size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11261) [ML] Flaky test(testNaiveBaggingLogRegression)
Yury Babak created IGNITE-11261: --- Summary: [ML] Flaky test(testNaiveBaggingLogRegression) Key: IGNITE-11261 URL: https://issues.apache.org/jira/browse/IGNITE-11261 Project: Ignite Issue Type: Bug Components: ml Reporter: Yury Babak Assignee: Artem Malykh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11260) Document new system view for running queries
Yury Gerzhedovich created IGNITE-11260: -- Summary: Document new system view for running queries Key: IGNITE-11260 URL: https://issues.apache.org/jira/browse/IGNITE-11260 Project: Ignite Issue Type: Task Components: documentation, sql Reporter: Yury Gerzhedovich Assignee: Artem Budnikov Fix For: 2.8 We need to document new SQL system views with running queries - LOCAL_SQL_RUNNING_QUERIES. see org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewRunningQueries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11259) Web console: Actualize grid configurator BinaryTypeConfiguration
Vasiliy Sisko created IGNITE-11259: -- Summary: Web console: Actualize grid configurator BinaryTypeConfiguration Key: IGNITE-11259 URL: https://issues.apache.org/jira/browse/IGNITE-11259 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Vasiliy Sisko Assignee: Vasiliy Sisko Result for class: org.apache.ignite.binary.BinaryTypeConfiguration Missed enumValues -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11258) JDBC: update connection setup logic.
Alexander Lapin created IGNITE-11258: Summary: JDBC: update connection setup logic. Key: IGNITE-11258 URL: https://issues.apache.org/jira/browse/IGNITE-11258 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Lapin # On thin client startup it connects to *all* *nodes* provided by user by client configuration. # Upon handshake server returns its UUID to client. # By the end of the startup procedure, client have open connections to all available server nodes and the following mapping (*nodeMap*): [UUID => Connection]. Connection to all nodes helps to identify available nodes, but can lead to significant delay, when thin client is used on a large cluster with a long IP list provided by user. To lower this delay, asynchronous establishment of connections can be used. For more information see [IEP-23: Best Effort Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11257) JDBC: update handshake protocol so that the node returns its UUID.
Alexander Lapin created IGNITE-11257: Summary: JDBC: update handshake protocol so that the node returns its UUID. Key: IGNITE-11257 URL: https://issues.apache.org/jira/browse/IGNITE-11257 Project: Ignite Issue Type: Task Components: sql Reporter: Alexander Lapin Fix For: 2.8 Add node UUID to successful handshake response. For more information see [IEP-23: Best Effort Affinity|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11256) Implement read-only mode for grid
Alexei Scherbakov created IGNITE-11256: -- Summary: Implement read-only mode for grid Key: IGNITE-11256 URL: https://issues.apache.org/jira/browse/IGNITE-11256 Project: Ignite Issue Type: Improvement Reporter: Alexei Scherbakov Fix For: 2.8 Should be triggered from control.sh utility. Useful for maintenance work, for example checking partition consistency (idle_verify) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11255) Fix test failure after IGNITE-7648
Pavel Voronkin created IGNITE-11255: --- Summary: Fix test failure after IGNITE-7648 Key: IGNITE-11255 URL: https://issues.apache.org/jira/browse/IGNITE-11255 Project: Ignite Issue Type: Bug Reporter: Pavel Voronkin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[MTCGA]: new failures in builds [3028157] 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 IgniteTwoRegionsRebuildIndexTest.testRebuildIndexes https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1615645003194028350=%3Cdefault%3E=testDetails Changes may lead to failure were done by - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=875117 - mr.weider https://ci.ignite.apache.org/viewModification.html?modId=875101 - vololo100 https://ci.ignite.apache.org/viewModification.html?modId=875100 - lapin1702 https://ci.ignite.apache.org/viewModification.html?modId=875134 - gvvinblade https://ci.ignite.apache.org/viewModification.html?modId=875115 - pudov.max https://ci.ignite.apache.org/viewModification.html?modId=875108 - andrey.mashenkov https://ci.ignite.apache.org/viewModification.html?modId=875127 - ivandasch https://ci.ignite.apache.org/viewModification.html?modId=875063 - kondakov87 https://ci.ignite.apache.org/viewModification.html?modId=875110 - andrey.mashenkov https://ci.ignite.apache.org/viewModification.html?modId=875123 - pvoronkin https://ci.ignite.apache.org/viewModification.html?modId=875106 - 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 10:56:57 08-02-2019
