Re: TC build queue stall
Also I cleaned up a build queue on TC a little bit removing builds
which cannot make any progress more than 10 hours. Please check your
recent builds.
Most of them was ZooKeeper (Discovery) 3 [1]. It claims that there is
no compatible agents? Could not we run it on any Linux agent?
Also it seems that there is a compatible agent trouble for a GCE [2]
build. Seems it need a special file on an agent
Caused by: java.io.FileNotFoundException:
/home/teamcity/test_keys/gridgain-gce-key.p12 (No such file or
directory)
[1]
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ZooKeeperDiscovery3=compatibilityList_IgniteTests24Java8=%3Cdefault%3E
[2]
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Gce_IgniteTests24Java8=%3Cdefault%3E=buildTypeStatusDiv
сб, 27 апр. 2019 г. в 07:21, Павлухин Иван :
>
> Igniters,
>
> Indeed it seems that an incident yesterday was caused by Russian
> characters in commit details. I think that following could be done:
> 1. File a bug against TC.
> 2. Do not use Russian characters in git user info, commit messages and
> other commit details.
>
> сб, 27 апр. 2019 г. в 07:20, Павлухин Иван :
> >
> > Igniters,
> >
> > Indeed it seems that an incident yesterday was caused by Russian
> > characters in commit details. I think that following could be done:
> > 1. File a bug against TC.
> > 2. Do not use Russian characters in git user info, commit messages and
> > other commit details.
> >
> > пт, 26 апр. 2019 г. в 10:19, Дмитрий Сорокин :
> > >
> > > Hi Ivan!
> > >
> > > Thanks for investigation!
> > > I decided to try second your proposal first, and force pushed the
> > > squashed commits just now. Let’s look whether it helped or not.
> > >
> > > пт, 26 апр. 2019 г. в 8:57, Павлухин Иван :
> > >>
> > >> I digged a little bit deeper into causes of the VCS problem reported
> > >> by TC. It looks like Russian characters in commit details (an author
> > >> name here) drive TC crazy. Still not sure that it is the root cause
> > >> (quite weird if so).
> > >>
> > >> I found a PR with problematic commits [1]. Dmitrii Ryabov, Dmitriy
> > >> Sorokin and Mikhail Petrov commited to that PR. Guys could you please
> > >> close the PR in order to check that it makes TC mad? It seems that
> > >> closing PR makes no harm because it can be easily reopened after. Or,
> > >> for example squash commits and force push to PR avoiding Russian
> > >> characters.
> > >>
> > >> Need your assistance here.
> > >>
> > >> [1] https://github.com/apache/ignite/pull/6223/commits
> > >>
> > >> пт, 26 апр. 2019 г. в 06:10, Павлухин Иван :
> > >> >
> > >> > Hi Igniters,
> > >> >
> > >> > Right now I am observing that many builds cannot make progress for
> > >> > many hours so far. TC shows that the majority of agents is free [1].
> > >> > But new builds seems fail to start.
> > >> >
> > >> > Does anyone know what is it and how to resolve it? Perhaps simple
> > >> > reboot can help here. Also new codestyle check is a recent change and
> > >> > might be somehow related.
> > >> >
> > >> > Also I see problem with git checkout in some logs:
> > >> > [13:45:12] Collecting changes in 1 VCS root (7s)
> > >> > [13:45:12] [Collecting changes in 1 VCS root] VCS Root details
> > >> > [13:45:18] [Collecting changes in 1 VCS root] Compute revision for
> > >> > 'GitHub [apache/ignite]'
> > >> > [14:36:57] The build is removed from the queue to be prepared for the
> > >> > start
> > >> > [14:36:57] Starting the build on the agent aitc-lin12:06
> > >> > [14:36:58] Clearing temporary directory: /opt/buildagent/temp/buildTmp
> > >> > [14:36:58] Publishing internal artifacts
> > >> > [14:36:58] Clean build enabled: removing old files from
> > >> > /opt/buildagent/work/69588afcb2ab3382
> > >> > [14:36:58] Checkout directory: /opt/buildagent/work/69588afcb2ab3382
> > >> > [14:36:58] Updating sources: server side checkout (running for
> > >> > 15h:17m:37s)
> > >> > [14:36:58] [Updating sources] Building clean patch for VCS root:
> > >> > GitHub [apache/ignite]
> > >> > [14:39:20] [Updating sources] Failed to build patch for build #11255
> > >> > {build id=3698721, buildTypeId=IgniteTests24Java8_CacheFailover2}, VCS
> > >> > root: "GitHub [apache/ignite]" {instance id=296, parent internal
> > >> > id=77, parent id=GitHubApacheIgnite, description:
> > >> > "https://github.com/apache/ignite.git#refs/heads/master"}, due to
> > >> > error: Patch building failed:
> > >> > org.apache.catalina.connector.ClientAbortException:
> > >> > java.net.SocketTimeoutException
> > >> > [14:39:20] [Updating sources] Transferring repository sources: 36.93
> > >> > MB so far...
> > >> > [02:40:02] [Updating sources] Transferring repository sources: 36.95
> > >> > MB so far...
> > >> >
> > >> > And a reported problem in "Overview" tab:
> > >> > Error collecting changes for VCS repository '"GitHub [apache/ignite]"
> > >> > {instance id=296, parent internal id=77, parent id=GitHubApacheIgnite,
> > >> > description:
Re: TC build queue stall
Igniters,
Indeed it seems that an incident yesterday was caused by Russian
characters in commit details. I think that following could be done:
1. File a bug against TC.
2. Do not use Russian characters in git user info, commit messages and
other commit details.
пт, 26 апр. 2019 г. в 10:19, Дмитрий Сорокин :
>
> Hi Ivan!
>
> Thanks for investigation!
> I decided to try second your proposal first, and force pushed the squashed
> commits just now. Let’s look whether it helped or not.
>
> пт, 26 апр. 2019 г. в 8:57, Павлухин Иван :
>>
>> I digged a little bit deeper into causes of the VCS problem reported
>> by TC. It looks like Russian characters in commit details (an author
>> name here) drive TC crazy. Still not sure that it is the root cause
>> (quite weird if so).
>>
>> I found a PR with problematic commits [1]. Dmitrii Ryabov, Dmitriy
>> Sorokin and Mikhail Petrov commited to that PR. Guys could you please
>> close the PR in order to check that it makes TC mad? It seems that
>> closing PR makes no harm because it can be easily reopened after. Or,
>> for example squash commits and force push to PR avoiding Russian
>> characters.
>>
>> Need your assistance here.
>>
>> [1] https://github.com/apache/ignite/pull/6223/commits
>>
>> пт, 26 апр. 2019 г. в 06:10, Павлухин Иван :
>> >
>> > Hi Igniters,
>> >
>> > Right now I am observing that many builds cannot make progress for
>> > many hours so far. TC shows that the majority of agents is free [1].
>> > But new builds seems fail to start.
>> >
>> > Does anyone know what is it and how to resolve it? Perhaps simple
>> > reboot can help here. Also new codestyle check is a recent change and
>> > might be somehow related.
>> >
>> > Also I see problem with git checkout in some logs:
>> > [13:45:12] Collecting changes in 1 VCS root (7s)
>> > [13:45:12] [Collecting changes in 1 VCS root] VCS Root details
>> > [13:45:18] [Collecting changes in 1 VCS root] Compute revision for
>> > 'GitHub [apache/ignite]'
>> > [14:36:57] The build is removed from the queue to be prepared for the start
>> > [14:36:57] Starting the build on the agent aitc-lin12:06
>> > [14:36:58] Clearing temporary directory: /opt/buildagent/temp/buildTmp
>> > [14:36:58] Publishing internal artifacts
>> > [14:36:58] Clean build enabled: removing old files from
>> > /opt/buildagent/work/69588afcb2ab3382
>> > [14:36:58] Checkout directory: /opt/buildagent/work/69588afcb2ab3382
>> > [14:36:58] Updating sources: server side checkout (running for 15h:17m:37s)
>> > [14:36:58] [Updating sources] Building clean patch for VCS root:
>> > GitHub [apache/ignite]
>> > [14:39:20] [Updating sources] Failed to build patch for build #11255
>> > {build id=3698721, buildTypeId=IgniteTests24Java8_CacheFailover2}, VCS
>> > root: "GitHub [apache/ignite]" {instance id=296, parent internal
>> > id=77, parent id=GitHubApacheIgnite, description:
>> > "https://github.com/apache/ignite.git#refs/heads/master"}, due to
>> > error: Patch building failed:
>> > org.apache.catalina.connector.ClientAbortException:
>> > java.net.SocketTimeoutException
>> > [14:39:20] [Updating sources] Transferring repository sources: 36.93
>> > MB so far...
>> > [02:40:02] [Updating sources] Transferring repository sources: 36.95
>> > MB so far...
>> >
>> > And a reported problem in "Overview" tab:
>> > Error collecting changes for VCS repository '"GitHub [apache/ignite]"
>> > {instance id=296, parent internal id=77, parent id=GitHubApacheIgnite,
>> > description: "https://github.com/apache/ignite.git#refs/heads/master"}'
>> > jetbrains.buildServer.serverSide.db.MySQL.MySqlIncorrectStringValueException:
>> > Incorrect string value: '\xD0\xB4\xD0\xBC\xD0\xB8...' for column
>> > 'user_name' at row 1 while performing SQL query: SQL DML: insert into
>> > vcs_history (modification_id, user_name, description, change_date,
>> > vcs_root_id, version, display_version, changes_count, register_date)
>> > values (?, ?, ?, ?, ?, ?, ?, ?, ?) | PARAMETERS: 882649, "дмитрий
>> > рябов ", "fix warming up throttle test\n",
>> > 1551457143000, 296, "06127b70b2060dade9bd652abc71f2b949508245",
>> > "06127b70b2060dade9bd652abc71f2b949508245", 1, 1556247859429:
>> > java.sql.SQLException: Incorrect string value:
>> > '\xD0\xB4\xD0\xBC\xD0\xB8...' for column 'user_name' at row 1
>> >
>> > [1]
>> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll=buildTypeBranches
>> >
>> > --
>> > Best regards,
>> > Ivan Pavlukhin
>>
>>
>>
>> --
>> Best regards,
>> Ivan Pavlukhin
--
Best regards,
Ivan Pavlukhin
Re: TC build queue stall
Igniters,
Indeed it seems that an incident yesterday was caused by Russian
characters in commit details. I think that following could be done:
1. File a bug against TC.
2. Do not use Russian characters in git user info, commit messages and
other commit details.
сб, 27 апр. 2019 г. в 07:20, Павлухин Иван :
>
> Igniters,
>
> Indeed it seems that an incident yesterday was caused by Russian
> characters in commit details. I think that following could be done:
> 1. File a bug against TC.
> 2. Do not use Russian characters in git user info, commit messages and
> other commit details.
>
> пт, 26 апр. 2019 г. в 10:19, Дмитрий Сорокин :
> >
> > Hi Ivan!
> >
> > Thanks for investigation!
> > I decided to try second your proposal first, and force pushed the squashed
> > commits just now. Let’s look whether it helped or not.
> >
> > пт, 26 апр. 2019 г. в 8:57, Павлухин Иван :
> >>
> >> I digged a little bit deeper into causes of the VCS problem reported
> >> by TC. It looks like Russian characters in commit details (an author
> >> name here) drive TC crazy. Still not sure that it is the root cause
> >> (quite weird if so).
> >>
> >> I found a PR with problematic commits [1]. Dmitrii Ryabov, Dmitriy
> >> Sorokin and Mikhail Petrov commited to that PR. Guys could you please
> >> close the PR in order to check that it makes TC mad? It seems that
> >> closing PR makes no harm because it can be easily reopened after. Or,
> >> for example squash commits and force push to PR avoiding Russian
> >> characters.
> >>
> >> Need your assistance here.
> >>
> >> [1] https://github.com/apache/ignite/pull/6223/commits
> >>
> >> пт, 26 апр. 2019 г. в 06:10, Павлухин Иван :
> >> >
> >> > Hi Igniters,
> >> >
> >> > Right now I am observing that many builds cannot make progress for
> >> > many hours so far. TC shows that the majority of agents is free [1].
> >> > But new builds seems fail to start.
> >> >
> >> > Does anyone know what is it and how to resolve it? Perhaps simple
> >> > reboot can help here. Also new codestyle check is a recent change and
> >> > might be somehow related.
> >> >
> >> > Also I see problem with git checkout in some logs:
> >> > [13:45:12] Collecting changes in 1 VCS root (7s)
> >> > [13:45:12] [Collecting changes in 1 VCS root] VCS Root details
> >> > [13:45:18] [Collecting changes in 1 VCS root] Compute revision for
> >> > 'GitHub [apache/ignite]'
> >> > [14:36:57] The build is removed from the queue to be prepared for the
> >> > start
> >> > [14:36:57] Starting the build on the agent aitc-lin12:06
> >> > [14:36:58] Clearing temporary directory: /opt/buildagent/temp/buildTmp
> >> > [14:36:58] Publishing internal artifacts
> >> > [14:36:58] Clean build enabled: removing old files from
> >> > /opt/buildagent/work/69588afcb2ab3382
> >> > [14:36:58] Checkout directory: /opt/buildagent/work/69588afcb2ab3382
> >> > [14:36:58] Updating sources: server side checkout (running for
> >> > 15h:17m:37s)
> >> > [14:36:58] [Updating sources] Building clean patch for VCS root:
> >> > GitHub [apache/ignite]
> >> > [14:39:20] [Updating sources] Failed to build patch for build #11255
> >> > {build id=3698721, buildTypeId=IgniteTests24Java8_CacheFailover2}, VCS
> >> > root: "GitHub [apache/ignite]" {instance id=296, parent internal
> >> > id=77, parent id=GitHubApacheIgnite, description:
> >> > "https://github.com/apache/ignite.git#refs/heads/master"}, due to
> >> > error: Patch building failed:
> >> > org.apache.catalina.connector.ClientAbortException:
> >> > java.net.SocketTimeoutException
> >> > [14:39:20] [Updating sources] Transferring repository sources: 36.93
> >> > MB so far...
> >> > [02:40:02] [Updating sources] Transferring repository sources: 36.95
> >> > MB so far...
> >> >
> >> > And a reported problem in "Overview" tab:
> >> > Error collecting changes for VCS repository '"GitHub [apache/ignite]"
> >> > {instance id=296, parent internal id=77, parent id=GitHubApacheIgnite,
> >> > description: "https://github.com/apache/ignite.git#refs/heads/master"}'
> >> > jetbrains.buildServer.serverSide.db.MySQL.MySqlIncorrectStringValueException:
> >> > Incorrect string value: '\xD0\xB4\xD0\xBC\xD0\xB8...' for column
> >> > 'user_name' at row 1 while performing SQL query: SQL DML: insert into
> >> > vcs_history (modification_id, user_name, description, change_date,
> >> > vcs_root_id, version, display_version, changes_count, register_date)
> >> > values (?, ?, ?, ?, ?, ?, ?, ?, ?) | PARAMETERS: 882649, "дмитрий
> >> > рябов ", "fix warming up throttle test\n",
> >> > 1551457143000, 296, "06127b70b2060dade9bd652abc71f2b949508245",
> >> > "06127b70b2060dade9bd652abc71f2b949508245", 1, 1556247859429:
> >> > java.sql.SQLException: Incorrect string value:
> >> > '\xD0\xB4\xD0\xBC\xD0\xB8...' for column 'user_name' at row 1
> >> >
> >> > [1]
> >> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll=buildTypeBranches
> >> >
> >> > --
> >> > Best regards,
> >> > Ivan Pavlukhin
> >>
> >>
> >>
> >> --
[jira] [Created] (IGNITE-11819) Add query timeouts support for JDBC statement
Mikhail Cherkasov created IGNITE-11819: -- Summary: Add query timeouts support for JDBC statement Key: IGNITE-11819 URL: https://issues.apache.org/jira/browse/IGNITE-11819 Project: Ignite Issue Type: Improvement Components: sql Reporter: Mikhail Cherkasov statement.setQueryTimeout(5_000); - this timeout doesn't have any effect for ignite, it ignores it, event if we have delays in network for minutes, it will wait all this time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11818) Support JMX/control.sh for debug page info
Anton Kalashnikov created IGNITE-11818: -- Summary: Support JMX/control.sh for debug page info Key: IGNITE-11818 URL: https://issues.apache.org/jira/browse/IGNITE-11818 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Support JMX/control.sh for debug page info -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11817) org.apache.ignite.client.ClientCache#removeAll() and org.apache.ignite.client.ClientCache#clear missed Java Doc
kcheng.mvp created IGNITE-11817: --- Summary: org.apache.ignite.client.ClientCache#removeAll() and org.apache.ignite.client.ClientCache#clear missed Java Doc Key: IGNITE-11817 URL: https://issues.apache.org/jira/browse/IGNITE-11817 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.7 Reporter: kcheng.mvp Assignee: kcheng.mvp Fix For: 2.8 Use would be confused about the these api, need to address the difference in the java doc. please see the mail list http://apache-ignite-users.70518.x6.nabble.com/What-s-the-difference-between-ClientCache-removeAll-and-ClientCache-clear-td28002.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11816) Debug processor for dump page history info
Anton Kalashnikov created IGNITE-11816: -- Summary: Debug processor for dump page history info Key: IGNITE-11816 URL: https://issues.apache.org/jira/browse/IGNITE-11816 Project: Ignite Issue Type: Improvement Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Debug processor for dump page history info -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan P., Good catch, thanks. I was wrong, test scenario is correct. The problem was in atomicityMode() method - it could have returned null (which was okay for config generation, but wasn't expected in the test code). Please take a look at tx_out_test_fixed.patch (attached to IGNITE-11708). To sum it up, both issues should be fixed now. Best Regards, Ivan Rakov On 26.04.2019 14:40, Павлухин Иван wrote: Ivan R., As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does not expect lock/unlock events due to line: if (atomicityMode() == ATOMIC) return lockEvtCnt.get() == 0; Could you please elaborate? пт, 26 апр. 2019 г. в 13:32, Ivan Rakov : Ivan, Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test scenario assumes that even after expiration entry will be present in IgniteCache as per it will be loaded from CacheStore. However, CacheStore is not specified in node config. I've added patch that enables cache store factory, please check IGNITE-11708 attachments. Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* tests: from my point of view, test scenarios make no sense. We perform get() operation from ATOMIC caches and expect that entries will be locked. I don't understand why we should lock entries on ATOMIC get, therefore I suppose to remove part of code where we listen and check EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. Best Regards, Ivan Rakov On 17.04.2019 22:05, Ivan Rakov wrote: Hi Ivan, I've checked your branch. Seems like these tests fail due to real issue in functionality. I'll take a look. Best Regards, Ivan Rakov On 17.04.2019 13:54, Ivan Fedotov wrote: Hi, Igniters! During work on iep-30[1] I discovered that IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 tests[2] - do not work. You can check it just run one of the tests with log output, for example ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. There is no warning notification in the console. The same situation with other IgniteConfigVariationsAbstractTest subclasses - tests run, but they simply represent empty code. So, I created a ticket on such issue [4] and it turned out that the problem is with ruleChain in IgniteConfigVariationsAbstractTest [5]. The rule that is responsible for running a test statement does not start indeed [6] under ruleChain runRule. I suggested a solution - move testsCfg initialization to IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such changes ruleChain becomes not necessary. But I faced another problem - multiple failures on TeamCity [7]. From logs, it seems that failures are related to what tests check, but not JUnit error. I can not track TeamCity history on that fact were tests failed or not on the previous JUnit version - the oldest log is dated the start of the March when JUnit4 already was implemented (for example, this [8] test). Moreover, there are not so much failed tests, but because of running with multiple configurations (InterceptorCacheConfigVariationsFullApiTestSuite_0 ..._95) it turns out about 400 failed tests. TeamCity results also confirm that tests do not work in the master branch - duration time is less than 1ms. Now all tests are green and that is not surprising - under @Test annotation, nothing happens. Could some of us confirm or disprove my guess that tests are red because of its functionality, but not JUnit implementation? And if it is true, how should I take such fact into account in this ticket? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java [3] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 [4] https://issues.apache.org/jira/browse/IGNITE-11708 [5] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 [6] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 [7] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest [8] https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8
[IEP-35] Monitoring & Profiling. Proof of concept
Hello, Igniters.
I've prepared Proof of Concept for IEP-35 [1]
PR can be found here - https://github.com/apache/ignite/pull/6510
I've done following changes:
1. `GridMonitoringManager` [2] - simple implementation of manager to
store all monitoring info
2. `HttpPullExposerSpi` [3] - pull exposer implementation that can
respond with JSON from http://localhost:8080/ignite/monitoring. JSON content
can be veiwed in gist [4]
3. Compute task start and finish monitoring in "compute" list [5]
4. Service registration are monitored in "service" list - [6]
5. Current `IgniteSpiMBeanAdapter` rewritten using
`GridMonitoringManager` [7]
Design principles, monitoring subsystem details and new Ignite entities can be
found in IEP [1].
My next steps will be:
1. Implementation of JMX exposer
2. Registration of all "lists" and "sensor groups" as a SQL System view.
3. Add monitoring for all unmonitoring Ignite API. (described in IEP).
4. Rewrite existing jmx metrics using GridMonitoringManager.
Please, share you thoughts.
Part of JSON file:
```
"COMPUTE": {
"tasks": {
"name": "tasks",
"rows": [
{
"id": "0798817a-eeec-4386-9af7-94edb39ffced",
"sessionId": "a1814f95a61-912451ff-ca7b-4764-a7fd-728f6a90",
"data": {
"taskClasName":
"org.apache.ignite.monitoring.MonitoringSelfTest$$Lambda$145/1500885480",
"startTime": 1556287337944,
"timeout": 9223372036854776000,
"execName": null
},
"name": "anotherBroadcast"
}
```
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=112820392
[2]
https://github.com/apache/ignite/pull/6510/files#diff-ec7d5cf5e35b99303deb9accee153c50R34
[3]
https://github.com/apache/ignite/pull/6510/files#diff-32239c45e0ae3b692af2eae7078e1436R47
[4] https://gist.github.com/nizhikov/aa1e6222e6a3456472b881b8deb0e24d
[5]
https://github.com/apache/ignite/pull/6510/files#diff-d651ed29d07bd0c5ce291654a3254cc0R749
[6]
https://github.com/apache/ignite/pull/6510/files#diff-0b4e54fbda2b0da1c10eff48416336f6R1606
[7]
https://github.com/apache/ignite/pull/6510/files#diff-4398bf118150500e059069b3a1638ec7R61
signature.asc
Description: This is a digitally signed message part
Re: Brainstorm: Make TC Run All faster
Folks, +1 for merging all these suites into the single one. All these suites (Build Apache Ignite, Javadoc, Licenses Header, Checkstyle) required to be `green` all the time. So, we can consider making them a part of build Apache Ignite procedure. Also, I'd suggest going deeper. We can try to merge `Licenses Header` into the `Code style checker` [1]. This will simplify the code checking process. [1] http://checkstyle.sourceforge.net/config_header.html On Fri, 26 Apr 2019 at 13:17, Vyacheslav Daradur wrote: > > Ivan, you are right, I meant to combine them into one. > > Here is a build [1], with enabled profiles (check-licenses, > checkstyle) and check of javadoc to show the idea. > > Seems it takes ~15 minutes. > > [1] > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ExperimentalBuildApacheIgniteJavadocLicensesHeaderCheckstyle_IgniteTests24Java8= > > On Fri, Apr 26, 2019 at 12:06 PM Павлухин Иван wrote: > > > > Hi Vyacheslav, > > > > What do you mean by uniting? > > > > For me it looks like [Javadocs] and [Check Code Style] are not so time > > consuming comparing to tests, are not they? Do you suggest to combine > > mentioned 4 jobs into one? How long will it run in a such case? > > > > чт, 25 апр. 2019 г. в 10:50, Vyacheslav Daradur : > > > > > > Hi Igniters, > > > > > > At the moment we have several separated test suites: > > > * ~Build Apache Ignite~ _ ~10..20mins > > > * [Javadocs] _ ~10mins > > > * [Licenses Headers] _ ~1min > > > * [Check Code Style] _ ~7min > > > The most time of each build (except Licenses Headers) is taken by > > > dependency resolving. > > > > > > Their main goal is a check that the project is built properly. > > > > > > Also, profiles of [Javadocs], [Licenses Headers] uses at the step of > > > preparing release (see DEVNOTES.txt) that means they are important. > > > > > > I'd suggest uniting the builds, this should reduce the time of tests > > > on ~15 minutes and releases agents. > > > > > > What do you think? > > > > > > On Tue, Nov 27, 2018 at 3:56 PM Павлухин Иван wrote: > > > > > > > > Roman, > > > > > > > > Do you have some expectations how faster "correlated" tests > > > > elimination will make Run All? Also do you have a vision how can we > > > > determine such "correlated" tests, can we do it relatively fast? > > > > > > > > But all in all, I am not sure that reducing a group of correlated > > > > tests to only one test can show good stability. > > > > пн, 26 нояб. 2018 г. в 17:48, aplatonov : > > > > > > > > > > It should be noticed that additional parameter TEST_SCALE_FACTOR was > > > > > added. > > > > > This parameter with ScaleFactorUtil methods can be used for test size > > > > > scaling for different runs (like ordinary and nightly RunALLs). If > > > > > someone > > > > > want to distinguish these builds he/she can apply scaling methods from > > > > > ScaleFactorUtil in own tests. For nightly test TEST_SCALE_FACTOR=1.0, > > > > > for > > > > > non-nightly builds TEST_SCALE_FACTOR<1.0. For example in > > > > > GridAbstractCacheInterceptorRebalanceTest test ScaleFactorUtil was > > > > > used for > > > > > scaling count of iterations. I guess that TEST_SCALE_FACTOR support > > > > > will be > > > > > added to runs at the same time with RunALL (nightly) runs. > > > > > > > > > > > > > > > > > > > > -- > > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > Ivan Pavlukhin > > > > > > > > > > > > -- > > > Best Regards, Vyacheslav D. > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best Regards, Vyacheslav D.
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan R., As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does not expect lock/unlock events due to line: if (atomicityMode() == ATOMIC) return lockEvtCnt.get() == 0; Could you please elaborate? пт, 26 апр. 2019 г. в 13:32, Ivan Rakov : > > Ivan, > > Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test > scenario assumes that even after expiration entry will be present in > IgniteCache as per it will be loaded from CacheStore. However, > CacheStore is not specified in node config. I've added patch that > enables cache store factory, please check IGNITE-11708 attachments. > Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* tests: > from my point of view, test scenarios make no sense. We perform get() > operation from ATOMIC caches and expect that entries will be locked. I > don't understand why we should lock entries on ATOMIC get, therefore I > suppose to remove part of code where we listen and check > EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. > > Best Regards, > Ivan Rakov > > On 17.04.2019 22:05, Ivan Rakov wrote: > > Hi Ivan, > > > > I've checked your branch. Seems like these tests fail due to real > > issue in functionality. > > I'll take a look. > > > > Best Regards, > > Ivan Rakov > > > > On 17.04.2019 13:54, Ivan Fedotov wrote: > >> Hi, Igniters! > >> > >> During work on iep-30[1] I discovered that > >> IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 > >> tests[2] > >> - do not work. > >> You can check it just run one of the tests with log output, for example > >> ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. > >> There is no warning notification in the console. The same situation with > >> other IgniteConfigVariationsAbstractTest subclasses - tests run, but > >> they > >> simply represent empty code. > >> > >> So, I created a ticket on such issue [4] and it turned out that the > >> problem > >> is with ruleChain in IgniteConfigVariationsAbstractTest [5]. > >> The rule that is responsible for running a test statement does not start > >> indeed [6] under ruleChain runRule. I suggested a solution - move > >> testsCfg > >> initialization to > >> IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such > >> changes ruleChain becomes not necessary. > >> > >> But I faced another problem - multiple failures on TeamCity [7]. From > >> logs, > >> it seems that failures are related to what tests check, but not JUnit > >> error. > >> I can not track TeamCity history on that fact were tests failed or > >> not on > >> the previous JUnit version - the oldest log is dated the start of the > >> March > >> when JUnit4 > >> already was implemented (for example, this [8] test). > >> Moreover, there are not so much failed tests, but because of running > >> with > >> multiple configurations > >> (InterceptorCacheConfigVariationsFullApiTestSuite_0 > >> ..._95) it turns out about 400 failed tests. TeamCity results also > >> confirm > >> that tests do not work in the master branch - duration time is less than > >> 1ms. Now all tests are green and that is not surprising - under @Test > >> annotation, nothing happens. > >> > >> Could some of us confirm or disprove my guess that tests are red > >> because of > >> its functionality, but not JUnit implementation? > >> And if it is true, how should I take such fact into account in this > >> ticket? > >> > >> [1] > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 > >> > >> [2] > >> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java > >> > >> [3] > >> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 > >> > >> [4] https://issues.apache.org/jira/browse/IGNITE-11708 > >> [5] > >> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 > >> > >> [6] > >> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 > >> > >> [7] > >> https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest > >> > >> [8] > >> https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8 > >> > >> -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-11815) Get rid of GridTestUtils.retryAssert method.
Andrew Mashenkov created IGNITE-11815: - Summary: Get rid of GridTestUtils.retryAssert method. Key: IGNITE-11815 URL: https://issues.apache.org/jira/browse/IGNITE-11815 Project: Ignite Issue Type: Test Reporter: Andrew Mashenkov For now we have GridTestUtils.retryAssert() method which runs a closure 'n' times to check if some invariantes become ok, eventually. This method catch assertions and can print them to log many times even if assertion is acceptable for the moment. Also, it is possible to miss an assertion is not related to those ones that closure checks (e.g. assertion error thrown from ignite internals). Let's replace retryAssert with GridTestUtils.waitForCondition() usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11814) Log finish rebuilding all indexes
Sergey Antonov created IGNITE-11814:
---
Summary: Log finish rebuilding all indexes
Key: IGNITE-11814
URL: https://issues.apache.org/jira/browse/IGNITE-11814
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
For detecting finish of rebuilding all indexes we should find in logs all
messages:
1) {{Started indexes rebuilding for cache [name=}}
2) {{Finished indexes rebuilding for cache [name=}}
3) {{Failed to rebuild indexes for cache [name=}}
And check, that number of messages (1) equal sum of number of messages (2) and
(3).
We should log message about finish rebuilding indexes for all caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan, Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test scenario assumes that even after expiration entry will be present in IgniteCache as per it will be loaded from CacheStore. However, CacheStore is not specified in node config. I've added patch that enables cache store factory, please check IGNITE-11708 attachments. Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* tests: from my point of view, test scenarios make no sense. We perform get() operation from ATOMIC caches and expect that entries will be locked. I don't understand why we should lock entries on ATOMIC get, therefore I suppose to remove part of code where we listen and check EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. Best Regards, Ivan Rakov On 17.04.2019 22:05, Ivan Rakov wrote: Hi Ivan, I've checked your branch. Seems like these tests fail due to real issue in functionality. I'll take a look. Best Regards, Ivan Rakov On 17.04.2019 13:54, Ivan Fedotov wrote: Hi, Igniters! During work on iep-30[1] I discovered that IgniteConfigVariationsAbstractTest subclasses - it is about 15_000 tests[2] - do not work. You can check it just run one of the tests with log output, for example ConfigVariationsTestSuiteBuilderTest#LegacyLifecycleTest#test1 [3]. There is no warning notification in the console. The same situation with other IgniteConfigVariationsAbstractTest subclasses - tests run, but they simply represent empty code. So, I created a ticket on such issue [4] and it turned out that the problem is with ruleChain in IgniteConfigVariationsAbstractTest [5]. The rule that is responsible for running a test statement does not start indeed [6] under ruleChain runRule. I suggested a solution - move testsCfg initialization to IgniteConfigVariationsAbstractTest#beforeTestsStarted method. After such changes ruleChain becomes not necessary. But I faced another problem - multiple failures on TeamCity [7]. From logs, it seems that failures are related to what tests check, but not JUnit error. I can not track TeamCity history on that fact were tests failed or not on the previous JUnit version - the oldest log is dated the start of the March when JUnit4 already was implemented (for example, this [8] test). Moreover, there are not so much failed tests, but because of running with multiple configurations (InterceptorCacheConfigVariationsFullApiTestSuite_0 ..._95) it turns out about 400 failed tests. TeamCity results also confirm that tests do not work in the master branch - duration time is less than 1ms. Now all tests are green and that is not surprising - under @Test annotation, nothing happens. Could some of us confirm or disprove my guess that tests are red because of its functionality, but not JUnit implementation? And if it is true, how should I take such fact into account in this ticket? [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-30%3A+Migration+to+JUnit+5 [2] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testsuites/InterceptorCacheConfigVariationsFullApiTestSuite.java [3] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/test/ConfigVariationsTestSuiteBuilderTest.java#L434 [4] https://issues.apache.org/jira/browse/IGNITE-11708 [5] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 [6] https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L181 [7] https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6434/head=Latest [8] https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=-9037806478172035481=8
Re: Brainstorm: Make TC Run All faster
Ivan, you are right, I meant to combine them into one. Here is a build [1], with enabled profiles (check-licenses, checkstyle) and check of javadoc to show the idea. Seems it takes ~15 minutes. [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ExperimentalBuildApacheIgniteJavadocLicensesHeaderCheckstyle_IgniteTests24Java8= On Fri, Apr 26, 2019 at 12:06 PM Павлухин Иван wrote: > > Hi Vyacheslav, > > What do you mean by uniting? > > For me it looks like [Javadocs] and [Check Code Style] are not so time > consuming comparing to tests, are not they? Do you suggest to combine > mentioned 4 jobs into one? How long will it run in a such case? > > чт, 25 апр. 2019 г. в 10:50, Vyacheslav Daradur : > > > > Hi Igniters, > > > > At the moment we have several separated test suites: > > * ~Build Apache Ignite~ _ ~10..20mins > > * [Javadocs] _ ~10mins > > * [Licenses Headers] _ ~1min > > * [Check Code Style] _ ~7min > > The most time of each build (except Licenses Headers) is taken by > > dependency resolving. > > > > Their main goal is a check that the project is built properly. > > > > Also, profiles of [Javadocs], [Licenses Headers] uses at the step of > > preparing release (see DEVNOTES.txt) that means they are important. > > > > I'd suggest uniting the builds, this should reduce the time of tests > > on ~15 minutes and releases agents. > > > > What do you think? > > > > On Tue, Nov 27, 2018 at 3:56 PM Павлухин Иван wrote: > > > > > > Roman, > > > > > > Do you have some expectations how faster "correlated" tests > > > elimination will make Run All? Also do you have a vision how can we > > > determine such "correlated" tests, can we do it relatively fast? > > > > > > But all in all, I am not sure that reducing a group of correlated > > > tests to only one test can show good stability. > > > пн, 26 нояб. 2018 г. в 17:48, aplatonov : > > > > > > > > It should be noticed that additional parameter TEST_SCALE_FACTOR was > > > > added. > > > > This parameter with ScaleFactorUtil methods can be used for test size > > > > scaling for different runs (like ordinary and nightly RunALLs). If > > > > someone > > > > want to distinguish these builds he/she can apply scaling methods from > > > > ScaleFactorUtil in own tests. For nightly test TEST_SCALE_FACTOR=1.0, > > > > for > > > > non-nightly builds TEST_SCALE_FACTOR<1.0. For example in > > > > GridAbstractCacheInterceptorRebalanceTest test ScaleFactorUtil was used > > > > for > > > > scaling count of iterations. I guess that TEST_SCALE_FACTOR support > > > > will be > > > > added to runs at the same time with RunALL (nightly) runs. > > > > > > > > > > > > > > > > -- > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > -- > > Best Regards, Vyacheslav D. > > > > -- > Best regards, > Ivan Pavlukhin -- Best Regards, Vyacheslav D.
[jira] [Created] (IGNITE-11813) Remove deprecated parameters from Kuberenetes configuration templates.
Ilya Murchenko created IGNITE-11813: --- Summary: Remove deprecated parameters from Kuberenetes configuration templates. Key: IGNITE-11813 URL: https://issues.apache.org/jira/browse/IGNITE-11813 Project: Ignite Issue Type: Task Components: examples Reporter: Ilya Murchenko Assignee: Ilya Murchenko Need to remove "zones" parameter from Kuberenetes configuration templates for Storage Classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Brainstorm: Make TC Run All faster
Hi Vyacheslav, What do you mean by uniting? For me it looks like [Javadocs] and [Check Code Style] are not so time consuming comparing to tests, are not they? Do you suggest to combine mentioned 4 jobs into one? How long will it run in a such case? чт, 25 апр. 2019 г. в 10:50, Vyacheslav Daradur : > > Hi Igniters, > > At the moment we have several separated test suites: > * ~Build Apache Ignite~ _ ~10..20mins > * [Javadocs] _ ~10mins > * [Licenses Headers] _ ~1min > * [Check Code Style] _ ~7min > The most time of each build (except Licenses Headers) is taken by > dependency resolving. > > Their main goal is a check that the project is built properly. > > Also, profiles of [Javadocs], [Licenses Headers] uses at the step of > preparing release (see DEVNOTES.txt) that means they are important. > > I'd suggest uniting the builds, this should reduce the time of tests > on ~15 minutes and releases agents. > > What do you think? > > On Tue, Nov 27, 2018 at 3:56 PM Павлухин Иван wrote: > > > > Roman, > > > > Do you have some expectations how faster "correlated" tests > > elimination will make Run All? Also do you have a vision how can we > > determine such "correlated" tests, can we do it relatively fast? > > > > But all in all, I am not sure that reducing a group of correlated > > tests to only one test can show good stability. > > пн, 26 нояб. 2018 г. в 17:48, aplatonov : > > > > > > It should be noticed that additional parameter TEST_SCALE_FACTOR was > > > added. > > > This parameter with ScaleFactorUtil methods can be used for test size > > > scaling for different runs (like ordinary and nightly RunALLs). If someone > > > want to distinguish these builds he/she can apply scaling methods from > > > ScaleFactorUtil in own tests. For nightly test TEST_SCALE_FACTOR=1.0, for > > > non-nightly builds TEST_SCALE_FACTOR<1.0. For example in > > > GridAbstractCacheInterceptorRebalanceTest test ScaleFactorUtil was used > > > for > > > scaling count of iterations. I guess that TEST_SCALE_FACTOR support will > > > be > > > added to runs at the same time with RunALL (nightly) runs. > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > > -- > Best Regards, Vyacheslav D. -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-11812) control.sh ignores quotes in passed arguments
Sergey Antonov created IGNITE-11812:
---
Summary: control.sh ignores quotes in passed arguments
Key: IGNITE-11812
URL: https://issues.apache.org/jira/browse/IGNITE-11812
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Fix For: 2.8
Control.sh should consider quotes in incoming arguments. i.e. I expect that
{{control.sh --baseline set "p1,p2,p3","p4,p5,p6" --yes}} set BLT with two
nodes with consistent ids: {{p1,p2,p3}} and {{p4,p5,p6}}, but now it tries to
set BLT with six nodes {{p1}}, {{p2}}, {{p3}}, {{p4}}, {{p5}}, {{p6}}
Reproducer. (Add this test to {{CommandHandlerParsingTest}})
{code:java}
@Test
public void testQuotesWillNotIgnored() throws Exception {
CommandHandler hnd = new CommandHandler();
Arguments args = hnd.parseAndValidate(
Arrays.asList(
BASELINE.text(),
BaselineCommand.SET.text(),
"\"1,2,3\",\"3,2,1\""
)
);
assertEquals(BASELINE, args.command());
assertEquals(BaselineCommand.SET, args.baselineArguments().getCmd());
// FIx me: expected 2, actual 6
assertEquals(2, args.baselineArguments().getConsistentIds().size());
assertEquals("1,2,3",
args.baselineArguments().getConsistentIds().get(0));
assertEquals("3,2,1",
args.baselineArguments().getConsistentIds().get(1));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11811) Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest failed on TC.
Andrew Mashenkov created IGNITE-11811:
-
Summary: Cache 2 suite test GridCacheDhtPreloadDelayedSelfTest
failed on TC.
Key: IGNITE-11811
URL: https://issues.apache.org/jira/browse/IGNITE-11811
Project: Ignite
Issue Type: Test
Components: cache
Reporter: Andrew Mashenkov
{code:java}
[2019-04-26 08:00:37,500][WARN
][test-runner-#27151%dht.GridCacheDhtPreloadDelayedSelfTest%][root] Check
failed (will retry in 500ms).
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:465)
at
org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:34)
at
org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:442)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2044)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11810) Cache2 suite timeouts due to broken IgniteClientCacheStartFailoverTest.
Andrew Mashenkov created IGNITE-11810:
-
Summary: Cache2 suite timeouts due to broken
IgniteClientCacheStartFailoverTest.
Key: IGNITE-11810
URL: https://issues.apache.org/jira/browse/IGNITE-11810
Project: Ignite
Issue Type: Test
Components: cache
Reporter: Andrew Mashenkov
{code:java}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:492)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userPrepare(IgniteTxLocalAdapter.java:433)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:402)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:366)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:177)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:155)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:117)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:197)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:195)
7][INFO
][exchange-worker-#71756%cache.IgniteClientCacheStartFailoverTest7%][GridCacheProcessor]
Started cache [name=tx-1, id=3572520, dataRegionName=null, mode=PARTITIONED,
atomicity=TRANSACTIONAL, backu
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1140)
6][INFO
][exchange-worker-#71662%cache.IgniteClientCacheStartFailoverTest5%][GridCacheProcessor]
Started cache [name=tx-0, id=3572519, dataRegionName=null, mode=PARTITIONED,
atomicity=TRANSACTIONAL, backu
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:590)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:391)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:317)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:108)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:307)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1560)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1188)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1085)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:549)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: TC build queue stall
Hi Ivan!
Thanks for investigation!
I decided to try second your proposal first, and force pushed the squashed
commits just now. Let’s look whether it helped or not.
пт, 26 апр. 2019 г. в 8:57, Павлухин Иван :
> I digged a little bit deeper into causes of the VCS problem reported
> by TC. It looks like Russian characters in commit details (an author
> name here) drive TC crazy. Still not sure that it is the root cause
> (quite weird if so).
>
> I found a PR with problematic commits [1]. Dmitrii Ryabov, Dmitriy
> Sorokin and Mikhail Petrov commited to that PR. Guys could you please
> close the PR in order to check that it makes TC mad? It seems that
> closing PR makes no harm because it can be easily reopened after. Or,
> for example squash commits and force push to PR avoiding Russian
> characters.
>
> Need your assistance here.
>
> [1] https://github.com/apache/ignite/pull/6223/commits
>
> пт, 26 апр. 2019 г. в 06:10, Павлухин Иван :
> >
> > Hi Igniters,
> >
> > Right now I am observing that many builds cannot make progress for
> > many hours so far. TC shows that the majority of agents is free [1].
> > But new builds seems fail to start.
> >
> > Does anyone know what is it and how to resolve it? Perhaps simple
> > reboot can help here. Also new codestyle check is a recent change and
> > might be somehow related.
> >
> > Also I see problem with git checkout in some logs:
> > [13:45:12] Collecting changes in 1 VCS root (7s)
> > [13:45:12] [Collecting changes in 1 VCS root] VCS Root details
> > [13:45:18] [Collecting changes in 1 VCS root] Compute revision for
> > 'GitHub [apache/ignite]'
> > [14:36:57] The build is removed from the queue to be prepared for the
> start
> > [14:36:57] Starting the build on the agent aitc-lin12:06
> > [14:36:58] Clearing temporary directory: /opt/buildagent/temp/buildTmp
> > [14:36:58] Publishing internal artifacts
> > [14:36:58] Clean build enabled: removing old files from
> > /opt/buildagent/work/69588afcb2ab3382
> > [14:36:58] Checkout directory: /opt/buildagent/work/69588afcb2ab3382
> > [14:36:58] Updating sources: server side checkout (running for
> 15h:17m:37s)
> > [14:36:58] [Updating sources] Building clean patch for VCS root:
> > GitHub [apache/ignite]
> > [14:39:20] [Updating sources] Failed to build patch for build #11255
> > {build id=3698721, buildTypeId=IgniteTests24Java8_CacheFailover2}, VCS
> > root: "GitHub [apache/ignite]" {instance id=296, parent internal
> > id=77, parent id=GitHubApacheIgnite, description:
> > "https://github.com/apache/ignite.git#refs/heads/master"}, due to
> > error: Patch building failed:
> > org.apache.catalina.connector.ClientAbortException:
> > java.net.SocketTimeoutException
> > [14:39:20] [Updating sources] Transferring repository sources: 36.93
> > MB so far...
> > [02:40:02] [Updating sources] Transferring repository sources: 36.95
> > MB so far...
> >
> > And a reported problem in "Overview" tab:
> > Error collecting changes for VCS repository '"GitHub [apache/ignite]"
> > {instance id=296, parent internal id=77, parent id=GitHubApacheIgnite,
> > description: "https://github.com/apache/ignite.git#refs/heads/master"}'
> >
> jetbrains.buildServer.serverSide.db.MySQL.MySqlIncorrectStringValueException:
> > Incorrect string value: '\xD0\xB4\xD0\xBC\xD0\xB8...' for column
> > 'user_name' at row 1 while performing SQL query: SQL DML: insert into
> > vcs_history (modification_id, user_name, description, change_date,
> > vcs_root_id, version, display_version, changes_count, register_date)
> > values (?, ?, ?, ?, ?, ?, ?, ?, ?) | PARAMETERS: 882649, "дмитрий
> > рябов ", "fix warming up throttle test\n",
> > 1551457143000, 296, "06127b70b2060dade9bd652abc71f2b949508245",
> > "06127b70b2060dade9bd652abc71f2b949508245", 1, 1556247859429:
> > java.sql.SQLException: Incorrect string value:
> > '\xD0\xB4\xD0\xBC\xD0\xB8...' for column 'user_name' at row 1
> >
> > [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll=buildTypeBranches
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
[jira] [Created] (IGNITE-11809) Missing help for control.sh --baseline collect command.
Sergey Antonov created IGNITE-11809:
---
Summary: Missing help for control.sh --baseline collect command.
Key: IGNITE-11809
URL: https://issues.apache.org/jira/browse/IGNITE-11809
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
I found enum value {{BaselineCommand#COLLECT}}, but I don't see this option in
help output. We should add example with {{BaselineCommand#COLLECT}} to
{{control.sh --help output}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
