[jira] [Resolved] (IGNITE-12457) Cache 6 test suite fails with exit code 137
[ https://issues.apache.org/jira/browse/IGNITE-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin resolved IGNITE-12457. - Fix Version/s: 2.9 Resolution: Fixed Merged to master. > Cache 6 test suite fails with exit code 137 > --- > > Key: IGNITE-12457 > URL: https://issues.apache.org/jira/browse/IGNITE-12457 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.9 > > > Recently Cache 6 test suite started failing with uplesantly with exit code > 137. Whole suite fails with no details about passed and failed tests. > IgniteCache150ClientsTest seems to be a root cause. > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E=overview -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12120) Change log level in GridCacheWritebehindStore
[
https://issues.apache.org/jira/browse/IGNITE-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000670#comment-17000670
]
Sunny Chan edited comment on IGNITE-12120 at 12/20/19 6:49 AM:
---
I have also added an extra patch for CassandraSessionImpl which I believe
should be a warning rather than an error - this is due to the fact that when
the exception occurs is throw it will get retried by
GridCacheWriteBehindStore::updateStore and therefore it is not strictly an
"error". But I am happy to restore it if we have decided that it should be an
error.
was (Author: sunnychanclsa):
I have also added an extra patch for CassandraSessionImpl which also seems to
be a warning rather than an error - this is due to the fact that when the
exception occurs is throw it will get retried by
GridCacheWriteBehindStore::updateStore and therefore it is not strictly an
"error". But I am happy to restore it if we have decided that it should be an
error.
> Change log level in GridCacheWritebehindStore
> -
>
> Key: IGNITE-12120
> URL: https://issues.apache.org/jira/browse/IGNITE-12120
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.5
>Reporter: Sunny Chan
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the
> [GridCacheWriteBehindStore|https://github.com/apache/ignite/blob/7e73098d4d6e3d5f78326cb11dac7e083a2312dd/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L893],
> when the updateStore failed to write to underlying store, it logs this as
> error:
> {{LT.error(log, e, "Unable to update underlying store: " + store);}}
> After this line logged the error, it would return false so that it would
> retry the store (by returning false).
> While later on in the updatStore function, when the writeCache overflows, it
> would log this:
> {{log.warning("Failed to update store (value will be lost as current buffer
> size is greater " + …}}
> then it will remove the failed entry.
> I think the severity of the log messages is not right, as the fail update
> would still be retried.
> So I propose to change the log severity level so that the first one would be
> a warn, and second one would be error
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12120) Change log level in GridCacheWritebehindStore
[
https://issues.apache.org/jira/browse/IGNITE-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000670#comment-17000670
]
Sunny Chan commented on IGNITE-12120:
-
I have also added an extra patch for CassandraSessionImpl which also seems to
be a warning rather than an error - this is due to the fact that when the
exception occurs is throw it will get retried by
GridCacheWriteBehindStore::updateStore and therefore it is not strictly an
"error". But I am happy to restore it if we have decided that it should be an
error.
> Change log level in GridCacheWritebehindStore
> -
>
> Key: IGNITE-12120
> URL: https://issues.apache.org/jira/browse/IGNITE-12120
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.5
>Reporter: Sunny Chan
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the
> [GridCacheWriteBehindStore|https://github.com/apache/ignite/blob/7e73098d4d6e3d5f78326cb11dac7e083a2312dd/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L893],
> when the updateStore failed to write to underlying store, it logs this as
> error:
> {{LT.error(log, e, "Unable to update underlying store: " + store);}}
> After this line logged the error, it would return false so that it would
> retry the store (by returning false).
> While later on in the updatStore function, when the writeCache overflows, it
> would log this:
> {{log.warning("Failed to update store (value will be lost as current buffer
> size is greater " + …}}
> then it will remove the failed entry.
> I think the severity of the log messages is not right, as the fail update
> would still be retried.
> So I propose to change the log severity level so that the first one would be
> a warn, and second one would be error
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12474) Fix boost compatibility for cpp thin-client-test.
Stanilovsky Evgeny created IGNITE-12474: --- Summary: Fix boost compatibility for cpp thin-client-test. Key: IGNITE-12474 URL: https://issues.apache.org/jira/browse/IGNITE-12474 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.7.6 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Current teamcity_boost implementation leads to errors like: "src/teamcity/teamcity_boost.cpp:22:10: fatal error: boost/test/unit_test_suite_impl.hpp: No such file or catalog. #include " dev list discussion [1] [1] http://apache-ignite-developers.2346864.n4.nabble.com/Can-t-run-CPP-tests-locally-on-linux-machine-td29597.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12442) Fix unnecessary synchronized on PagesCache#add.
[ https://issues.apache.org/jira/browse/IGNITE-12442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000644#comment-17000644 ] Stanilovsky Evgeny commented on IGNITE-12442: - [~alexpl] check it plz ? > Fix unnecessary synchronized on PagesCache#add. > --- > > Key: IGNITE-12442 > URL: https://issues.apache.org/jira/browse/IGNITE-12442 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.7.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > After [IGNITE-6930|https://issues.apache.org/jira/browse/IGNITE-6930] was > implemented, there are some synchronization extra usage found. > 1. > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#add > 2. > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#emptyFlushCnt > hope need to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12442) Fix unnecessary synchronized on PagesCache#add.
[
https://issues.apache.org/jira/browse/IGNITE-12442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000638#comment-17000638
]
Ignite TC Bot commented on IGNITE-12442:
{panel:title=Branch: [pull/7147/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4855098buildTypeId=IgniteTests24Java8_RunAll]
> Fix unnecessary synchronized on PagesCache#add.
> ---
>
> Key: IGNITE-12442
> URL: https://issues.apache.org/jira/browse/IGNITE-12442
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: 2.7.6
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After [IGNITE-6930|https://issues.apache.org/jira/browse/IGNITE-6930] was
> implemented, there are some synchronization extra usage found.
> 1.
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#add
> 2.
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#emptyFlushCnt
> hope need to fix it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12385) .NET Thin Client: introduce ClusterGroup API
[
https://issues.apache.org/jira/browse/IGNITE-12385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000461#comment-17000461
]
Ignite TC Bot commented on IGNITE-12385:
{panel:title=Branch: [pull/7168/head] Base: [master] : Possible Blockers
(115)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858747]]
{color:#d04437}Cache 6{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858776]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858800]]
{color:#d04437}Scala (Examples){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858743]]
{color:#d04437}SPI{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858738]]
{color:#d04437}PDS (Indexing){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858786]]
{color:#d04437}PDS (Compatibility){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858785]]
{color:#d04437}Platform .NET{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858792]]
{color:#d04437}Examples{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858719]]
{color:#d04437}Scala (Visor Console){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858744]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858745]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858796]]
{color:#d04437}Cache 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858772]]
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858746]]
{color:#d04437}Cache (Expiry Policy){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858761]]
{color:#d04437}Queries 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858798]]
{color:#d04437}Streamers{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858736]]
{color:#d04437}JCache TCK 1.1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858752]]
{color:#d04437}Start Nodes{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858737]]
{color:#d04437}Cache 5{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858775]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858793]]
{color:#d04437}Continuous Query 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858781]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858801]]
{color:#d04437}Cache 8{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858778]]
{color:#d04437}Thin Client: Java{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858729]]
{color:#d04437}Continuous Query 4{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858782]]
{color:#d04437}PDS 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858788]]
{color:#d04437}Compute (Grid){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858716]]
{color:#d04437}MVCC Queries{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858756]]
{color:#d04437}Basic 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858750]]
{color:#d04437}Cache 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858771]]
{color:#d04437}Cache (Failover) 3{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858765]]
{color:#d04437}MVCC PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858816]]
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858797]]
{color:#d04437}Cache (Restarts) 1{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858768]]
{color:#d04437}Cache 7{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858777]]
{color:#d04437}PDS 2{color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858789]]
{color:#d04437}Cache (Failover SSL){color} [[tests 0
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=4858762]]
{color:#d04437}MVCC Cache 1{color} [[tests 0
[jira] [Updated] (IGNITE-12461) Jdbc Thin: Failover connections support for JDBC thin driver.
[ https://issues.apache.org/jira/browse/IGNITE-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-12461: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Jdbc Thin: Failover connections support for JDBC thin driver. > - > > Key: IGNITE-12461 > URL: https://issues.apache.org/jira/browse/IGNITE-12461 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to to support failover connections for JDBC driver. > In case user defined few connection points and server became unavailable > during request, driver should try send the same request to another server. > Please be aware we can do it only for idempotent requests like a SELECT > without transaction context. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[
https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000260#comment-17000260
]
Ignite TC Bot commented on IGNITE-9913:
---
{panel:title=Branch: [pull/7165/head] Base: [pull/7102/head] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4855614buildTypeId=IgniteTests24Java8_RunAll]
> Prevent data updates blocking in case of backup BLT server node leave
> -
>
> Key: IGNITE-9913
> URL: https://issues.apache.org/jira/browse/IGNITE-9913
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Ivan Rakov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.9
>
> Attachments: 9913_yardstick.png, master_yardstick.png
>
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> Ignite cluster performs distributed partition map exchange when any server
> node leaves or joins the topology.
> Distributed PME blocks all updates and may take a long time. If all
> partitions are assigned according to the baseline topology and server node
> leaves, there's no actual need to perform distributed PME: every cluster node
> is able to recalculate new affinity assigments and partition states locally.
> If we'll implement such lightweight PME and handle mapping and lock requests
> on new topology version correctly, updates won't be stopped (except updates
> of partitions that lost their primary copy).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000255#comment-17000255 ] Ivan Rakov edited comment on IGNITE-12447 at 12/19/19 5:57 PM: --- I'm ok with the changes. New method may be helpful in case we'll suddenly need to print number bigger that Integer.MAX_VALUE or floats. > Let it be at the discretion of the committer. By the way, [~ascherbakov] is committer now. :) was (Author: ivan.glukos): I'm ok with the changes. New method may be helpful in case we'll suddenly need to print number bigger that Integer.MAX_VALUE or floats. > Let it be at the discretion of the committer. [~ascherbakov] By the way, Alexey is committer now. :) > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000255#comment-17000255 ] Ivan Rakov edited comment on IGNITE-12447 at 12/19/19 5:56 PM: --- I'm ok with the changes. New method may be helpful in case we'll suddenly need to print number bigger that Integer.MAX_VALUE or floats. > Let it be at the discretion of the committer. [~ascherbakov] By the way, Alexey is committer now. :) was (Author: ivan.glukos): I'm ok with changes. New method may be helpful in case we'll suddenly need to print number bigger that Integer.MAX_VALUE or floats. > Let it be at the discretion of the committer. [~ascherbakov] By the way, Alexey is committer now. :) > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000255#comment-17000255 ] Ivan Rakov commented on IGNITE-12447: - I'm ok with changes. New method may be helpful in case we'll suddenly need to print number bigger that Integer.MAX_VALUE or floats. > Let it be at the discretion of the committer. [~ascherbakov] By the way, Alexey is committer now. :) > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12472) Checkstyle rule "NewlineAtEndOfFile" is broken on Windows systems.
[ https://issues.apache.org/jira/browse/IGNITE-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-12472: Description: Checkstyle rule "NewlineAtEndOfFile" uses OS EOL character. https://issues.apache.org/jira/browse/MCHECKSTYLE-376 It could be fixed by explicit configuration of LF as EOL. Checked on TC, there are no checkstyle related failures. Also checked on Windows locally. Also there are no problems. Problems are possible for Windows user in case of invalid Git configuration. was: Checkstyle rule "NewlineAtEndOfFile" uses OS EOL character. https://issues.apache.org/jira/browse/MCHECKSTYLE-376 It could be fixed by explicit configuration of LF as EOL. Checked on TC, there are o checkstyle related failures. Also checked on Windows locally. Also there are no problems. Problems are possible for Windows user in case of invalid Git configuration. > Checkstyle rule "NewlineAtEndOfFile" is broken on Windows systems. > -- > > Key: IGNITE-12472 > URL: https://issues.apache.org/jira/browse/IGNITE-12472 > Project: Ignite > Issue Type: Bug >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Checkstyle rule "NewlineAtEndOfFile" uses OS EOL character. > https://issues.apache.org/jira/browse/MCHECKSTYLE-376 > It could be fixed by explicit configuration of LF as EOL. Checked on TC, > there are no checkstyle related failures. Also checked on Windows locally. > Also there are no problems. > Problems are possible for Windows user in case of invalid Git configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12473) .NET: ClientServerCompatibilityTest fails on some agents because of Maven error
Pavel Tupitsyn created IGNITE-12473:
---
Summary: .NET: ClientServerCompatibilityTest fails on some agents
because of Maven error
Key: IGNITE-12473
URL: https://issues.apache.org/jira/browse/IGNITE-12473
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8
We should set language version explicitly in the pom.xml
{code}
[00:04:21] [Apache.Ignite.Core.Tests.exe] >>> 35584 OUT: [ERROR]
COMPILATION ERROR :
[00:04:21] [Apache.Ignite.Core.Tests.exe] >>> 35584 OUT: [INFO]
-
[00:04:21] [Apache.Ignite.Core.Tests.exe] >>> 35584 OUT: [ERROR] Source
option 1.5 is no longer supported. Use 1.6 or later.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12472) Checkstyle rule "NewlineAtEndOfFile" is broken on Windows systems.
[ https://issues.apache.org/jira/browse/IGNITE-12472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura updated IGNITE-12472: Description: Checkstyle rule "NewlineAtEndOfFile" uses OS EOL character. https://issues.apache.org/jira/browse/MCHECKSTYLE-376 It could be fixed by explicit configuration of LF as EOL. Checked on TC, there are o checkstyle related failures. Also checked on Windows locally. Also there are no problems. Problems are possible for Windows user in case of invalid Git configuration. > Checkstyle rule "NewlineAtEndOfFile" is broken on Windows systems. > -- > > Key: IGNITE-12472 > URL: https://issues.apache.org/jira/browse/IGNITE-12472 > Project: Ignite > Issue Type: Bug >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.9 > > > Checkstyle rule "NewlineAtEndOfFile" uses OS EOL character. > https://issues.apache.org/jira/browse/MCHECKSTYLE-376 > It could be fixed by explicit configuration of LF as EOL. Checked on TC, > there are o checkstyle related failures. Also checked on Windows locally. > Also there are no problems. > Problems are possible for Windows user in case of invalid Git configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12472) Checkstyle rule "NewlineAtEndOfFile" is broken on Windows systems.
Andrey N. Gura created IGNITE-12472: --- Summary: Checkstyle rule "NewlineAtEndOfFile" is broken on Windows systems. Key: IGNITE-12472 URL: https://issues.apache.org/jira/browse/IGNITE-12472 Project: Ignite Issue Type: Bug Reporter: Andrey N. Gura Assignee: Andrey N. Gura Fix For: 2.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12471) .NET Thin Client: WithExpiryPolicy crashes client connection on old servers
Pavel Tupitsyn created IGNITE-12471:
---
Summary: .NET Thin Client: WithExpiryPolicy crashes client
connection on old servers
Key: IGNITE-12471
URL: https://issues.apache.org/jira/browse/IGNITE-12471
Project: Ignite
Issue Type: Task
Components: platforms
Affects Versions: 2.8
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.8
ICacheClient.WithExpiryPolicy does not check protocol version and causes
exception and disconnect:
* Run Ignite 2.7.6 server node
* Connect thin client from master branch
* {{cache.WithExpiryPolicy(..).Put(1, 2)}}:
{code}
Unhandled exception. System.Net.Sockets.SocketException (10053): An established
connection was aborted by the software in your host machine.
at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)
at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveMessage()
at Apache.Ignite.Core.Impl.Client.ClientSocket.SendRequest(RequestMessage&
reqMsg)
at Apache.Ignite.Core.Impl.Client.ClientSocket.DoOutInOp[T](ClientOp opId,
Action`1 writeAction, Func`2 readFunc, Func`3 errorFunc)
at
Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.DoOutInOpAffinity[T,TKey](ClientOp
opId, Action`1 writeAction, Func`2 readFunc, Int32 cacheId, TKey key, Func`3
errorFunc)
at
Apache.Ignite.Core.Impl.Client.Cache.CacheClient`2.DoOutInOpAffinity[T](ClientOp
opId, TK key, TV val, Func`2 readFunc)
at
Apache.Ignite.Core.Impl.Client.Cache.CacheClient`2.DoOutOpAffinity(ClientOp
opId, TK key, TV val)
at Apache.Ignite.Core.Impl.Client.Cache.CacheClient`2.Put(TK key, TV val)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12470) Pme-free switch feature should be deactivatable
[ https://issues.apache.org/jira/browse/IGNITE-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov reassigned IGNITE-12470: -- Assignee: Sergei Ryzhov > Pme-free switch feature should be deactivatable > --- > > Key: IGNITE-12470 > URL: https://issues.apache.org/jira/browse/IGNITE-12470 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Sergei Ryzhov >Priority: Major > Labels: newbie > Fix For: 2.9 > > > We should be able to disable this feature by some env/jvm property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12470) Pme-free switch feature should be deactivatable
[ https://issues.apache.org/jira/browse/IGNITE-12470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-12470: -- Fix Version/s: 2.9 > Pme-free switch feature should be deactivatable > --- > > Key: IGNITE-12470 > URL: https://issues.apache.org/jira/browse/IGNITE-12470 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Priority: Major > Labels: newbie > Fix For: 2.9 > > > We should be able to disable this feature by some env/jvm property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12470) Pme-free switch feature should be deactivatable
Anton Vinogradov created IGNITE-12470: - Summary: Pme-free switch feature should be deactivatable Key: IGNITE-12470 URL: https://issues.apache.org/jira/browse/IGNITE-12470 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov We should be able to disable this feature by some env/jvm property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12462) JDBC thin: add timeouts as the parameters for connection string
[
https://issues.apache.org/jira/browse/IGNITE-12462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1694#comment-1694
]
Ignite TC Bot commented on IGNITE-12462:
{panel:title=Branch: [pull/7156/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4852799buildTypeId=IgniteTests24Java8_RunAll]
> JDBC thin: add timeouts as the parameters for connection string
> ---
>
> Key: IGNITE-12462
> URL: https://issues.apache.org/jira/browse/IGNITE-12462
> Project: Ignite
> Issue Type: Task
> Components: thin client
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We've added two new timeouts ([1], [2]) but they're available from java code
> only and both should be add as the connection string parameters.
> 1. https://issues.apache.org/jira/browse/IGNITE-5438
> 2. https://issues.apache.org/jira/browse/IGNITE-5234
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12283) Access restriction to IgniteKernal
[
https://issues.apache.org/jira/browse/IGNITE-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1672#comment-1672
]
Ignite TC Bot commented on IGNITE-12283:
{panel:title=Branch: [pull/7159/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4850327buildTypeId=IgniteTests24Java8_RunAll]
> Access restriction to IgniteKernal
> --
>
> Key: IGNITE-12283
> URL: https://issues.apache.org/jira/browse/IGNITE-12283
> Project: Ignite
> Issue Type: Task
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
> Labels: iep-38
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteKernal allows a user-defined code to get access to the internal
> features of Ignite. That behavior leads to security lack.
> We must encapsulate _IgniteKernal_ to restrict access to it from user-defined
> code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12442) Fix unnecessary synchronized on PagesCache#add.
[ https://issues.apache.org/jira/browse/IGNITE-12442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12442: - Fix Version/s: 2.9 > Fix unnecessary synchronized on PagesCache#add. > --- > > Key: IGNITE-12442 > URL: https://issues.apache.org/jira/browse/IGNITE-12442 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.7.6 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > After [IGNITE-6930|https://issues.apache.org/jira/browse/IGNITE-6930] was > implemented, there are some synchronization extra usage found. > 1. > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#add > 2. > org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.PagesCache#emptyFlushCnt > hope need to fix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12466) Monitor query pool starvation
[
https://issues.apache.org/jira/browse/IGNITE-12466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1640#comment-1640
]
Ignite TC Bot commented on IGNITE-12466:
{panel:title=Branch: [pull/7161/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4851675buildTypeId=IgniteTests24Java8_RunAll]
> Monitor query pool starvation
> -
>
> Key: IGNITE-12466
> URL: https://issues.apache.org/jira/browse/IGNITE-12466
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are having a periodical starvation check ones of
> IGNITE_STARVATION_CHECK_INTERVAL interval.
> But that had by system and public pool only.
> I want to see the same monitor by query pool.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12167) Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1630#comment-1630
]
Andrey Mashenkov edited comment on IGNITE-12167 at 12/19/19 10:19 AM:
--
May be we can
1. avoid pageHndWrapper usage in BTree constructor directly.
2. e.g. introduce wrap() method that will be ok with pageHndWrapper=null value.
3. make pageHndWrapper *non-volatile* as there is no need to have it volatile.
4. rename pageHndWrapper -> testHndWrapper.
5. add an *assert BPlusTree. testHndWrapper==null;* in beforeTestsStarted.
What do you think?
was (Author: amashenkov):
May be we can avoid pageHndWrapper usage in BTree constructor directly.
E.g. introduce wrap() method that will be ok with pageHndWrapper=null value.
Also it make no sense to have *volatile* pageHndWrapper.
What do you think?
> Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
> --
>
> Key: IGNITE-12167
> URL: https://issues.apache.org/jira/browse/IGNITE-12167
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should move logic for clearing custom pageHndWrapperin
> {{afterTestsStopped()}} in {{GridCommonAbstractTest}} or {{GridAbstractTest
> to ensure that we will not have problems in any tests which set custom
> wrapper}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12167) Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1630#comment-1630
]
Andrey Mashenkov commented on IGNITE-12167:
---
May be we can avoid pageHndWrapper usage in BTree constructor directly.
E.g. introduce wrap() method that will be ok with pageHndWrapper=null value.
Also it make no sense to have *volatile* pageHndWrapper.
What do you think?
> Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
> --
>
> Key: IGNITE-12167
> URL: https://issues.apache.org/jira/browse/IGNITE-12167
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should move logic for clearing custom pageHndWrapperin
> {{afterTestsStopped()}} in {{GridCommonAbstractTest}} or {{GridAbstractTest
> to ensure that we will not have problems in any tests which set custom
> wrapper}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[ https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1629#comment-1629 ] Anton Vinogradov commented on IGNITE-9913: -- Merged to master branch. > Prevent data updates blocking in case of backup BLT server node leave > - > > Key: IGNITE-9913 > URL: https://issues.apache.org/jira/browse/IGNITE-9913 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.9 > > Attachments: 9913_yardstick.png, master_yardstick.png > > Time Spent: 10h 20m > Remaining Estimate: 0h > > Ignite cluster performs distributed partition map exchange when any server > node leaves or joins the topology. > Distributed PME blocks all updates and may take a long time. If all > partitions are assigned according to the baseline topology and server node > leaves, there's no actual need to perform distributed PME: every cluster node > is able to recalculate new affinity assigments and partition states locally. > If we'll implement such lightweight PME and handle mapping and lock requests > on new topology version correctly, updates won't be stopped (except updates > of partitions that lost their primary copy). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9913) Prevent data updates blocking in case of backup BLT server node leave
[ https://issues.apache.org/jira/browse/IGNITE-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-9913: - Fix Version/s: (was: 2.8) 2.9 > Prevent data updates blocking in case of backup BLT server node leave > - > > Key: IGNITE-9913 > URL: https://issues.apache.org/jira/browse/IGNITE-9913 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Ivan Rakov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.9 > > Attachments: 9913_yardstick.png, master_yardstick.png > > Time Spent: 10h 20m > Remaining Estimate: 0h > > Ignite cluster performs distributed partition map exchange when any server > node leaves or joins the topology. > Distributed PME blocks all updates and may take a long time. If all > partitions are assigned according to the baseline topology and server node > leaves, there's no actual need to perform distributed PME: every cluster node > is able to recalculate new affinity assigments and partition states locally. > If we'll implement such lightweight PME and handle mapping and lock requests > on new topology version correctly, updates won't be stopped (except updates > of partitions that lost their primary copy). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12167) Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
[
https://issues.apache.org/jira/browse/IGNITE-12167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999890#comment-16999890
]
Andrey Mashenkov commented on IGNITE-12167:
---
It is not clear what benefits is given with this solution.
Why we have to make any actions in AbstractTest to restore smth can be broken
by test?
I believe a test that change pageHndWrapper is responsible to restore it.
> Move resetting of BPlusTree.pageHndWrapper to GridAbstractTest
> --
>
> Key: IGNITE-12167
> URL: https://issues.apache.org/jira/browse/IGNITE-12167
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should move logic for clearing custom pageHndWrapperin
> {{afterTestsStopped()}} in {{GridCommonAbstractTest}} or {{GridAbstractTest
> to ensure that we will not have problems in any tests which set custom
> wrapper}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12469) CorruptedTreeException can hold unmutable sensitive data.
Stanilovsky Evgeny created IGNITE-12469: --- Summary: CorruptedTreeException can hold unmutable sensitive data. Key: IGNITE-12469 URL: https://issues.apache.org/jira/browse/IGNITE-12469 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.7.6 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny System property IGNITE_TO_STRING_INCLUDE_SENSITIVE don`t hide sensitive data while CorruptedTreeException occurred. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11705) Jdbc Thin: add ability to control affinity cache size.
[
https://issues.apache.org/jira/browse/IGNITE-11705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999866#comment-16999866
]
Ignite TC Bot commented on IGNITE-11705:
{panel:title=Branch: [pull/7155/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=4852402buildTypeId=IgniteTests24Java8_RunAll]
> Jdbc Thin: add ability to control affinity cache size.
> --
>
> Key: IGNITE-11705
> URL: https://issues.apache.org/jira/browse/IGNITE-11705
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Reporter: Alexander Lapin
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: iep-24
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Within AffinityCache there are two properties DISTRIBUTIONS_CACHE_LIMIT and
> SQL_CACHE_LIMIT that are hard coded. We should add an ability to control
> given parameters within some sort of configuration. IgniteSystemProperties is
> not an option however.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12468) ClassCastException on thinClient in Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999838#comment-16999838
]
Ivan Pavlukhin commented on IGNITE-12468:
-
[~redcomet], unfortunately it is a bug (actually thin client implementation
seems to be incomplete). And most usual Java container types (List, Set, Map)
are affected.
> ClassCastException on thinClient in Apache Ignite
> -
>
> Key: IGNITE-12468
> URL: https://issues.apache.org/jira/browse/IGNITE-12468
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.6
>Reporter: LEE PYUNG BEOM
>Priority: Major
>
>
> {code:java}
> ClientConfiguration cfg = new
> ClientConfiguration().setAddresses("127.0.0.1:10800");
> try (IgniteClient igniteClient = Ignition.startClient(cfg)) {
> System.out.println(">>> Thin client put-get example started.");
> final String CACHE_NAME = "put-get-example";
> ClientCache cache =
> igniteClient.getOrCreateCache(CACHE_NAME);
> Person p = new Person();
> //put
> HashMap hm = new HashMap();
> hm.put(1, p);
> cache.put(1, hm);
> //get
> HashMap map = (HashMap)cache.get(1);
> Person p2 = map.get(1);
> System.out.format(">>> Loaded [%s] from the cache.\n",p2);
> }
> catch (ClientException e) {
> System.err.println(e.getMessage());
> e.printStackTrace();
> }
> catch (Exception e) {
> System.err.format("Unexpected failure: %s\n", e);
> e.printStackTrace();
> }
> {code}
>
> I use the thin client of apache-ignite.
> I Create a hashmap and put the Person
> class(org.apache.ignite.examples.model.Person) object into it.
> And when I take it out of the hashmap, I get the following exceptions:
>
> {code:java}
> > java.lang.ClassCastException:
> > org.apache.enite.internal.binary.BinaryObjectImpl cannot be cast to
> > org.apache.engite.examples.model.Person.
> {code}
> An exception is given in the code below.
>
> {code:java}
> Person p2 = map.get(1);
> {code}
>
> However, there is no exception if I modify the code as follows:
>
> {code:java}
> BinaryObject bo = (BinaryObject) map.get(1);
> Person p2 = bo.deserialize();
> {code}
> I don't think that's necessary. Is there another solution?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
