[jira] [Commented] (IGNITE-16745) ODBC: SQLGetStmtAttr with SQL_ATTR_ROW_ARRAY_SIZE always returns 1
[
https://issues.apache.org/jira/browse/IGNITE-16745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514291#comment-17514291
]
Ignite TC Bot commented on IGNITE-16745:
{panel:title=Branch: [pull/9908/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI (Discovery){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6491303]]
* IgniteSpiDiscoverySelfTestSuite:
IgniteClientReconnectMassiveShutdownSslTest.testMassiveServersShutdown3 - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Windows){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6491201]]
* exe: BinaryBuilderSelfTestFullFooter.TestRemoteBinaryMode - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 2 (lazy=true){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6491308]]
* IgniteBinaryCacheQueryLazyTestSuite2:
DynamicIndexReplicatedAtomicConcurrentSelfTest.testQueryConsistencyMultithreaded
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6491196]]
{panel}
{panel:title=Branch: [pull/9908/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6491287]]
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite:
TestSQLSetStmtAttrGetStmtAttr - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6491286]]
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite:
TestSQLSetStmtAttrGetStmtAttr - PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6491285]]
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite:
TestSQLSetStmtAttrGetStmtAttr - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6491431buildTypeId=IgniteTests24Java8_RunAll]
> ODBC: SQLGetStmtAttr with SQL_ATTR_ROW_ARRAY_SIZE always returns 1
> --
>
> Key: IGNITE-16745
> URL: https://issues.apache.org/jira/browse/IGNITE-16745
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.12
>Reporter: Igor Sapego
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> SQLGetStmtAttr(SQL_ATTR_ROW_ARRAY_SIZE) returning the wrong value for row
> array size.
> Details here: https://github.com/apache/ignite/pull/9908
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16763) TableManager doesn't throw exception on table create, if something goes wrong in configuration listener
Denis Chudov created IGNITE-16763: - Summary: TableManager doesn't throw exception on table create, if something goes wrong in configuration listener Key: IGNITE-16763 URL: https://issues.apache.org/jira/browse/IGNITE-16763 Project: Ignite Issue Type: Bug Reporter: Denis Chudov For now, there is no way to complete the table create future exceptionally if exception was thrown in the listener of configuration updates, so that the table hasn't been actually created. For example, exception is thrown inside of TableManager#updateAssignments. Table creation completes anyway, as it depends only on update of versioned values in table manager, which will be completed in any case on storage revision update, and then the table creation future will be completed successfully. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16745) ODBC: SQLGetStmtAttr with SQL_ATTR_ROW_ARRAY_SIZE always returns 1
[ https://issues.apache.org/jira/browse/IGNITE-16745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514200#comment-17514200 ] Xi Li commented on IGNITE-16745: Thanks [~isapego]! I have made the change in the PR > ODBC: SQLGetStmtAttr with SQL_ATTR_ROW_ARRAY_SIZE always returns 1 > -- > > Key: IGNITE-16745 > URL: https://issues.apache.org/jira/browse/IGNITE-16745 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.12 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.13 > > Time Spent: 40m > Remaining Estimate: 0h > > SQLGetStmtAttr(SQL_ATTR_ROW_ARRAY_SIZE) returning the wrong value for row > array size. > Details here: https://github.com/apache/ignite/pull/9908 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16749) .NET: EntryPointNotFoundException on Alpine Linux
[
https://issues.apache.org/jira/browse/IGNITE-16749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-16749:
Release Note: .NET: Fixed EntryPointNotFoundException on Alpine Linux.
(was: .NET: Fix EntryPointNotFoundException on Alpine Linux)
> .NET: EntryPointNotFoundException on Alpine Linux
> -
>
> Key: IGNITE-16749
> URL: https://issues.apache.org/jira/browse/IGNITE-16749
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite.NET does not start on Alpine Linux:
> {code}
> Unhandled exception. System.EntryPointNotFoundException: Unable to find an
> entry point named 'dlopen' in shared library 'libcoreclr.so'.
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at Apache.Ignite.Docker.Program.Main() in /app/Program.cs:line 15
> {code}
> See https://github.com/ptupitsyn/ignite-net-docker/tree/alpine-test to
> reproduce with Docker.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16751) ItColocationTest#colocationOneColumn sometimes fails with StorageException: Exception when closing a Meta Storage cursor
[
https://issues.apache.org/jira/browse/IGNITE-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-16751:
-
Description:
{code:java}
org.apache.ignite.internal.configuration.storage.StorageException: Exception
when closing a Meta Storage cursor at
org.apache.ignite.internal.configuration.storage.DistributedConfigurationStorage.readAllLatest(DistributedConfigurationStorage.java:144)
at
org.apache.ignite.internal.configuration.ConfigurationChanger.getLatest(ConfigurationChanger.java:384)
at
org.apache.ignite.internal.configuration.direct.DirectPropertyProxy.value(DirectPropertyProxy.java:65)
at
org.apache.ignite.internal.table.distributed.TableManager.directTableIds(TableManager.java:1110)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
Caused by: class org.apache.ignite.lang.IgniteInternalException: class
org.apache.ignite.lang.IgniteInternalException:
java.util.concurrent.TimeoutException
at
org.apache.ignite.internal.metastorage.MetaStorageManager$CursorWrapper$InnerIterator.hasNext(MetaStorageManager.java:1047)
at
org.apache.ignite.internal.configuration.storage.DistributedConfigurationStorage.readAllLatest(DistributedConfigurationStorage.java:124)
... 10 more
Caused by: java.util.concurrent.ExecutionException: class
org.apache.ignite.lang.IgniteInternalException:
java.util.concurrent.TimeoutException
at
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at
org.apache.ignite.internal.metastorage.MetaStorageManager$CursorWrapper$InnerIterator.hasNext(MetaStorageManager.java:1045)
... 11 more {code}
h4. Update 1
Seems that the reason for such exceptions and unexpected behaviour is that
Timeout expcetion could be both wrapped with
ExecutionException/CompltetionException and thrown as is. So in addition to
considering TimeoutException as recoverable with corresponding retrial we
should also treat ExecutionException/CompltetionException with TimeoutException
cause the same way.
{code:java}
private boolean recoverable(Throwable t) {
return t instanceof TimeoutException || t.getCause() instanceof
IOException;
} {code}
might be changes with
{code:java}
private boolean recoverable(Throwable t) {
return t instanceof TimeoutException ||
((t instanceof ExecutionException || t instanceof
CompletionException) && t.getCause()
instanceof TimeoutException || t.getCause() instanceof
IOException);
} {code}
was:
{code:java}
org.apache.ignite.internal.configuration.storage.StorageException: Exception
when closing a Meta Storage cursor at
org.apache.ignite.internal.configuration.storage.DistributedConfigurationStorage.readAllLatest(DistributedConfigurationStorage.java:144)
at
org.apache.ignite.internal.configuration.ConfigurationChanger.getLatest(ConfigurationChanger.java:384)
at
org.apache.ignite.internal.configuration.direct.DirectPropertyProxy.value(DirectPropertyProxy.java:65)
at
org.apache.ignite.internal.table.distributed.TableManager.directTableIds(TableManager.java:1110)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:177)
Caused by: class org.apache.ignite.lang.IgniteInternalException: class
org.apache.ignite.lang.IgniteInternalException:
java.util.concurrent.TimeoutException
at
org.apache.ignite.internal.metastorage.MetaStorageManager$CursorWrapper$InnerIterator.hasNext(MetaStorageManager.java:1047)
at
org.apache.ignite.internal.configuration.storage.DistributedConfigurationStorage.readAllLatest(DistributedConfigurationStorage.java:124)
... 10 more
[jira] [Commented] (IGNITE-16749) .NET: EntryPointNotFoundException on Alpine Linux
[
https://issues.apache.org/jira/browse/IGNITE-16749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514163#comment-17514163
]
Pavel Tupitsyn commented on IGNITE-16749:
-
Merged to master: 6fa06587ca31083e1f714ba285e5b18fde88995d
> .NET: EntryPointNotFoundException on Alpine Linux
> -
>
> Key: IGNITE-16749
> URL: https://issues.apache.org/jira/browse/IGNITE-16749
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ignite.NET does not start on Alpine Linux:
> {code}
> Unhandled exception. System.EntryPointNotFoundException: Unable to find an
> entry point named 'dlopen' in shared library 'libcoreclr.so'.
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at Apache.Ignite.Docker.Program.Main() in /app/Program.cs:line 15
> {code}
> See https://github.com/ptupitsyn/ignite-net-docker/tree/alpine-test to
> reproduce with Docker.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16749) .NET: EntryPointNotFoundException on Alpine Linux
[
https://issues.apache.org/jira/browse/IGNITE-16749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-16749:
Release Note: .NET: Fix EntryPointNotFoundException on Alpine Linux
> .NET: EntryPointNotFoundException on Alpine Linux
> -
>
> Key: IGNITE-16749
> URL: https://issues.apache.org/jira/browse/IGNITE-16749
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
>
> Ignite.NET does not start on Alpine Linux:
> {code}
> Unhandled exception. System.EntryPointNotFoundException: Unable to find an
> entry point named 'dlopen' in shared library 'libcoreclr.so'.
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at Apache.Ignite.Docker.Program.Main() in /app/Program.cs:line 15
> {code}
> See https://github.com/ptupitsyn/ignite-net-docker/tree/alpine-test to
> reproduce with Docker.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16749) .NET: EntryPointNotFoundException on Alpine Linux
[
https://issues.apache.org/jira/browse/IGNITE-16749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514161#comment-17514161
]
Ignite TC Bot commented on IGNITE-16749:
{panel:title=Branch: [pull/9916/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9916/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6489962buildTypeId=IgniteTests24Java8_RunAll]
> .NET: EntryPointNotFoundException on Alpine Linux
> -
>
> Key: IGNITE-16749
> URL: https://issues.apache.org/jira/browse/IGNITE-16749
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
>
> Ignite.NET does not start on Alpine Linux:
> {code}
> Unhandled exception. System.EntryPointNotFoundException: Unable to find an
> entry point named 'dlopen' in shared library 'libcoreclr.so'.
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at Apache.Ignite.Docker.Program.Main() in /app/Program.cs:line 15
> {code}
> See https://github.com/ptupitsyn/ignite-net-docker/tree/alpine-test to
> reproduce with Docker.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (IGNITE-16749) .NET: EntryPointNotFoundException on Alpine Linux
[ https://issues.apache.org/jira/browse/IGNITE-16749 ]
Pavel Tupitsyn deleted comment on IGNITE-16749:
-
was (Author: ignitetcbot):
{panel:title=Branch: [pull/9916/head] Base: [master] : Possible Blockers
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Continuous Query 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6489886]]
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6489921]]
* IgniteBinaryCacheQueryTestSuite2:
DynamicEnableIndexingBasicSelfTest.testEnableDynamicIndexing[hasNear=true,nodeIdx=1,cacheMode=PARTITIONED,atomicityMode=ATOMIC]
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}JDBC Driver{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6489901]]
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testIntDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=false,
useBinaryArrays=false] - Test has low fail rate in base branch 0,0% and is not
flaky
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testBinaryDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=true,
useBinaryArrays=false] - Test has low fail rate in base branch 0,0% and is not
flaky
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testIntDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=EternalExpiryPolicy, backups=2,
evictionFactory=null, onheapCacheEnabled=false, writeSyncMode=FULL_SYNC,
persistenceEnabled=false, useBinaryArrays=false] - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=6489938]]
{panel}
{panel:title=Branch: [pull/9916/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6489962buildTypeId=IgniteTests24Java8_RunAll]
> .NET: EntryPointNotFoundException on Alpine Linux
> -
>
> Key: IGNITE-16749
> URL: https://issues.apache.org/jira/browse/IGNITE-16749
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
>
> Ignite.NET does not start on Alpine Linux:
> {code}
> Unhandled exception. System.EntryPointNotFoundException: Unable to find an
> entry point named 'dlopen' in shared library 'libcoreclr.so'.
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at Apache.Ignite.Docker.Program.Main() in /app/Program.cs:line 15
> {code}
> See https://github.com/ptupitsyn/ignite-net-docker/tree/alpine-test to
> reproduce with Docker.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16760) Performance degradation of configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-16760:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Performance degradation of configuration changes
>
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> DROP TABLE TEST
> {code}
> An iteration on the begin has about 1.7 sec. The time is grown.
> The time after ~170 iteration is about 70 sec.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16760) Performance degradation of configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-16760:
-
Fix Version/s: (was: 3.0.0-alpha5)
> Performance degradation of configuration changes
>
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> DROP TABLE TEST
> {code}
> An iteration on the begin has about 1.7 sec. The time is grown.
> The time after ~170 iteration is about 70 sec.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16762) Test ItRaftGroupServiceTest#testTransferLeadership is unstable
[
https://issues.apache.org/jira/browse/IGNITE-16762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16762:
--
Fix Version/s: (was: 3.0.0-alpha5)
> Test ItRaftGroupServiceTest#testTransferLeadership is unstable
> --
>
> Key: IGNITE-16762
> URL: https://issues.apache.org/jira/browse/IGNITE-16762
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
>
> The test [fails
> periodically|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6490252?showLog=6490244_610_338.607.608=debug]
> with the error:
> {code}
> java.util.concurrent.ExecutionException: class
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
> configuration
> at
> org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
> EBUSY:Changing the configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16762) Test ItRaftGroupServiceTest#testTransferLeadership is unstable
[
https://issues.apache.org/jira/browse/IGNITE-16762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16762:
--
Description:
The test [fails
periodically|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6490252?showLog=6490244_610_338.607.608=debug]
with the error:
{code}
java.util.concurrent.ExecutionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
configuration
at
org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
EBUSY:Changing the configuration
{code}
was:
The test fails periodically with the error:
{code}
java.util.concurrent.ExecutionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
configuration
at
org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
EBUSY:Changing the configuration
{code}
> Test ItRaftGroupServiceTest#testTransferLeadership is unstable
> --
>
> Key: IGNITE-16762
> URL: https://issues.apache.org/jira/browse/IGNITE-16762
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> The test [fails
> periodically|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6490252?showLog=6490244_610_338.607.608=debug]
> with the error:
> {code}
> java.util.concurrent.ExecutionException: class
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
> configuration
> at
> org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
> EBUSY:Changing the configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16762) Test ItRaftGroupServiceTest#testTransferLeadership is unstable
[
https://issues.apache.org/jira/browse/IGNITE-16762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16762:
--
Summary: Test ItRaftGroupServiceTest#testTransferLeadership is unstable
(was: Test ItRaftGroupServiceTest#testTransferLeadership flukes )
> Test ItRaftGroupServiceTest#testTransferLeadership is unstable
> --
>
> Key: IGNITE-16762
> URL: https://issues.apache.org/jira/browse/IGNITE-16762
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> The test fails periodically with the error:
> {code}
> java.util.concurrent.ExecutionException: class
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
> configuration
> at
> org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
> EBUSY:Changing the configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16762) Test ItRaftGroupServiceTest#testTransferLeadership flukes
[
https://issues.apache.org/jira/browse/IGNITE-16762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-16762:
--
Description:
The test fails periodically with the error:
{code}
java.util.concurrent.ExecutionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
configuration
at
org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
EBUSY:Changing the configuration
{code}
was:
The test fails periodically with the error:
{code}
java.util.concurrent.ExecutionException
15:42:08 java.util.concurrent.ExecutionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
configuration
at
org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
EBUSY:Changing the configuration
{code}
> Test ItRaftGroupServiceTest#testTransferLeadership flukes
> --
>
> Key: IGNITE-16762
> URL: https://issues.apache.org/jira/browse/IGNITE-16762
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> The test fails periodically with the error:
> {code}
> java.util.concurrent.ExecutionException: class
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
> configuration
> at
> org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
> Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
> EBUSY:Changing the configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16762) Test ItRaftGroupServiceTest#testTransferLeadership flukes
Taras Ledkov created IGNITE-16762:
-
Summary: Test ItRaftGroupServiceTest#testTransferLeadership flukes
Key: IGNITE-16762
URL: https://issues.apache.org/jira/browse/IGNITE-16762
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha4
Reporter: Taras Ledkov
Fix For: 3.0.0-alpha5
The test fails periodically with the error:
{code}
java.util.concurrent.ExecutionException
15:42:08 java.util.concurrent.ExecutionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: EBUSY:Changing the
configuration
at
org.apache.ignite.internal.raft.ItRaftGroupServiceTest.testTransferLeadership(ItRaftGroupServiceTest.java:153)
Caused by: org.apache.ignite.raft.jraft.rpc.impl.RaftException:
EBUSY:Changing the configuration
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16761) Sql. Join with correlated subqueries returns wrong result.
[ https://issues.apache.org/jira/browse/IGNITE-16761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16761: Labels: calcite ignite-3 (was: ) > Sql. Join with correlated subqueries returns wrong result. > -- > > Key: IGNITE-16761 > URL: https://issues.apache.org/jira/browse/IGNITE-16761 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite, ignite-3 > Fix For: 3.0.0-alpha5 > > > Need to adopt > [IGNITE-15566|https://issues.apache.org/jira/browse/IGNITE-15566] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16761) Sql. Join with correlated subqueries returns wrong result.
Evgeny Stanilovsky created IGNITE-16761: --- Summary: Sql. Join with correlated subqueries returns wrong result. Key: IGNITE-16761 URL: https://issues.apache.org/jira/browse/IGNITE-16761 Project: Ignite Issue Type: Bug Components: sql Reporter: Evgeny Stanilovsky Assignee: Evgeny Stanilovsky Fix For: 3.0.0-alpha5 Need to adopt [IGNITE-15566|https://issues.apache.org/jira/browse/IGNITE-15566] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16759) Fix .NET tests of dotnet services for Windows platform.
[ https://issues.apache.org/jira/browse/IGNITE-16759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16759: -- Description: IGNITE-15650 caused .NET test failure on Windows platform. Reason: wrong runtime binding. Solution: simplified method calls. Dynamic and ordinary service object are now separated. was: IGNITE-15650 caused .NET test failure on Windows platform. Reason: wrong runtime binding. Solution: simplified method calls: separated dynamic and ordinary service object. > Fix .NET tests of dotnet services for Windows platform. > --- > > Key: IGNITE-16759 > URL: https://issues.apache.org/jira/browse/IGNITE-16759 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-15650 caused .NET test failure on Windows platform. > Reason: wrong runtime binding. > Solution: simplified method calls. Dynamic and ordinary service object are > now separated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16759) Fix .NET tests of dotnet services for Windows platform.
[ https://issues.apache.org/jira/browse/IGNITE-16759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16759: -- Summary: Fix .NET tests of dotnet services for Windows platform. (was: Fix .NET tests for platform service) > Fix .NET tests of dotnet services for Windows platform. > --- > > Key: IGNITE-16759 > URL: https://issues.apache.org/jira/browse/IGNITE-16759 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-15650 caused .NET test failure on Windows platform. > Reason: wrong runtime binding. > Solution: simplified method calls: separated dynamic and ordinary service > object. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16759) Fix .NET tests for platform service
[ https://issues.apache.org/jira/browse/IGNITE-16759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16759: -- Description: IGNITE-15650 caused .NET test failure on Windows platform. Reason: wrong runtime binding. Solution: simplified method calls: separated dynamic and ordinary service object. was: IGNITE-15650 caused .NET test failure. Reason: wrong runtime binding. Solution: simplified method calls: separated dynamic and ordinary service object. > Fix .NET tests for platform service > --- > > Key: IGNITE-16759 > URL: https://issues.apache.org/jira/browse/IGNITE-16759 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IGNITE-15650 caused .NET test failure on Windows platform. > Reason: wrong runtime binding. > Solution: simplified method calls: separated dynamic and ordinary service > object. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16759) Fix .NET tests for platform service
[ https://issues.apache.org/jira/browse/IGNITE-16759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-16759: -- Description: IGNITE-15650 caused .NET test failure. Reason: wrong runtime binding. Solution: simplified method calls: separated dynamic and ordinary service object. was:https://issues.apache.org/jira/browse/IGNITE-15650 causes .NET test failure. > Fix .NET tests for platform service > --- > > Key: IGNITE-16759 > URL: https://issues.apache.org/jira/browse/IGNITE-16759 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > IGNITE-15650 caused .NET test failure. > Reason: wrong runtime binding. > Solution: simplified method calls: separated dynamic and ordinary service > object. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16742) Extend calcite module documentation and config.
[ https://issues.apache.org/jira/browse/IGNITE-16742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16742: Fix Version/s: 2.13 (was: 2.14) > Extend calcite module documentation and config. > --- > > Key: IGNITE-16742 > URL: https://issues.apache.org/jira/browse/IGNITE-16742 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Fix For: 2.13 > > Time Spent: 40m > Remaining Estimate: 0h > > After calcite engine was merged into master branch [1], seems it would > helpful to update some documentation. > [1] https://issues.apache.org/jira/browse/IGNITE-15436 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16733) [extensions] Fail CDC AbstractReplicationTest
[
https://issues.apache.org/jira/browse/IGNITE-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16733:
-
Component/s: extensions
> [extensions] Fail CDC AbstractReplicationTest
> -
>
> Key: IGNITE-16733
> URL: https://issues.apache.org/jira/browse/IGNITE-16733
> Project: Ignite
> Issue Type: Test
> Components: extensions
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: ise
>
> After changing the API in IGNITE-15117 the CDC tests stopped compiling
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project ignite-cdc-ext: Compilation failure
> [ERROR]
> /Users/sega/work/ignite-extensions/modules/cdc-ext/src/test/java/org/apache/ignite/cdc/AbstractReplicationTest.java:[186,17]
> cannot find symbol
> [ERROR] symbol: method setCdcEnabled(boolean)
> [ERROR] location: class
> org.apache.ignite.configuration.DataStorageConfiguration
> this field has been moved to DataRegionConfiguration
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Release Note: Fixed a rare issue with updating the TTL in the
near-cache/backup if the request was initiated from another backup. (was:
Fixed a rare issue with updating the TTL in the near-cache/backup if the
request was initiated from another backup node.)
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: IgniteCacheAtomicExpiryPolicyReadTest.java,
> ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction.
> This situation is currently not handled correctly, resulting in a hidden
> NullPointerException that aborts TTL updates.
> Due to the nature of the TTL updates in Ignite, this problem can only occur
> when the TTL is updated from the backup node.
> !ttl-updates.png!
> Thus, in a very rare case, we may notice a lack of updates in the near-cache
> and/or on "non-initiator" backups
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Ignite Flags: Release Notes Required
Release Note: Fixed a rare issue with updating the TTL in the
near-cache/backup if the request was initiated from another backup node.
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: IgniteCacheAtomicExpiryPolicyReadTest.java,
> ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction.
> This situation is currently not handled correctly, resulting in a hidden
> NullPointerException that aborts TTL updates.
> Due to the nature of the TTL updates in Ignite, this problem can only occur
> when the TTL is updated from the backup node.
> !ttl-updates.png!
> Thus, in a very rare case, we may notice a lack of updates in the near-cache
> and/or on "non-initiator" backups
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Attachment: IgniteCacheAtomicExpiryPolicyReadTest.java
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: IgniteCacheAtomicExpiryPolicyReadTest.java,
> ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction.
> This situation is currently not handled correctly, resulting in a hidden
> NullPointerException that aborts TTL updates.
> Due to the nature of the TTL updates in Ignite, this problem can only occur
> when the TTL is updated from the backup node.
> !ttl-updates.png!
> Thus, in a very rare case, we may notice a lack of updates in the near-cache
> and/or on "non-initiator" backups
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16749) .NET: EntryPointNotFoundException on Alpine Linux
[
https://issues.apache.org/jira/browse/IGNITE-16749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514075#comment-17514075
]
Ignite TC Bot commented on IGNITE-16749:
{panel:title=Branch: [pull/9916/head] Base: [master] : Possible Blockers
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Continuous Query 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6489886]]
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6489921]]
* IgniteBinaryCacheQueryTestSuite2:
DynamicEnableIndexingBasicSelfTest.testEnableDynamicIndexing[hasNear=true,nodeIdx=1,cacheMode=PARTITIONED,atomicityMode=ATOMIC]
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}JDBC Driver{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6489901]]
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testIntDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=false,
useBinaryArrays=false] - Test has low fail rate in base branch 0,0% and is not
flaky
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testBinaryDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=true,
useBinaryArrays=false] - Test has low fail rate in base branch 0,0% and is not
flaky
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testIntDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=EternalExpiryPolicy, backups=2,
evictionFactory=null, onheapCacheEnabled=false, writeSyncMode=FULL_SYNC,
persistenceEnabled=false, useBinaryArrays=false] - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=6489938]]
{panel}
{panel:title=Branch: [pull/9916/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6489962buildTypeId=IgniteTests24Java8_RunAll]
> .NET: EntryPointNotFoundException on Alpine Linux
> -
>
> Key: IGNITE-16749
> URL: https://issues.apache.org/jira/browse/IGNITE-16749
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.13
>
>
> Ignite.NET does not start on Alpine Linux:
> {code}
> Unhandled exception. System.EntryPointNotFoundException: Unable to find an
> entry point named 'dlopen' in shared library 'libcoreclr.so'.
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at Apache.Ignite.Docker.Program.Main() in /app/Program.cs:line 15
> {code}
> See https://github.com/ptupitsyn/ignite-net-docker/tree/alpine-test to
> reproduce with Docker.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16730) Eliminate usage of FileLock in MarshallerMappingFileStore
[ https://issues.apache.org/jira/browse/IGNITE-16730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514068#comment-17514068 ] Vyacheslav Koptilin commented on IGNITE-16730: -- Hi [~nizhikov], Could you please specify the right fixVersion? It helps a lot to understand which release contains the fix. > Eliminate usage of FileLock in MarshallerMappingFileStore > - > > Key: IGNITE-16730 > URL: https://issues.apache.org/jira/browse/IGNITE-16730 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Trivial > Labels: IEP-59 > Time Spent: 1h > Remaining Estimate: 0h > > CDC application needs to reuse marshaller files. > Currenlty, `FileLock` used to protect access to marshaller files. > But, it seems we can use temp file and ATOMIC_MOVE to eliminate `FileLock` > usage. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16730) Eliminate usage of FileLock in MarshallerMappingFileStore
[ https://issues.apache.org/jira/browse/IGNITE-16730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-16730: - Fix Version/s: 2.13 > Eliminate usage of FileLock in MarshallerMappingFileStore > - > > Key: IGNITE-16730 > URL: https://issues.apache.org/jira/browse/IGNITE-16730 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Trivial > Labels: IEP-59 > Fix For: 2.13 > > Time Spent: 1h > Remaining Estimate: 0h > > CDC application needs to reuse marshaller files. > Currenlty, `FileLock` used to protect access to marshaller files. > But, it seems we can use temp file and ATOMIC_MOVE to eliminate `FileLock` > usage. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
!ttl-updates.png!
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and/or on "non-initiator" backups
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
!ttl-updates.png!
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and on "non-initiator" backups
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL
[jira] [Commented] (IGNITE-16754) [Extensions] Change external repository for deleted from maven central dependencies.
[ https://issues.apache.org/jira/browse/IGNITE-16754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514070#comment-17514070 ] Mikhail Petrov commented on IGNITE-16754: - [~NSAmelchev] Thank you a lot for the review! > [Extensions] Change external repository for deleted from maven central > dependencies. > > > Key: IGNITE-16754 > URL: https://issues.apache.org/jira/browse/IGNITE-16754 > Project: Ignite > Issue Type: Improvement > Components: extensions >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > Currently we use origin-maven.repository.redhat repository to download > dependencies that were deleted from maven central repository. > It does not work any more because of expired certificates problem - > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=6483968&_focus=4815 > It is proposed to use maven.repository.redhat instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514069#comment-17514069
]
Pavel Pereslegin commented on IGNITE-16118:
---
[~alapin], thank you for the review.
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction.
> This situation is currently not handled correctly, resulting in a hidden
> NullPointerException that aborts TTL updates.
> Due to the nature of the TTL updates in Ignite, this problem can only occur
> when the TTL is updated from the backup node.
> !ttl-updates.png!
> Thus, in a very rare case, we may notice a lack of updates in the near-cache
> and on "non-initiator" backups
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
!ttl-updates.png!
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and on "non-initiator" backups
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and on "non-initiator" backups
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Attachment: ttl-updates.png
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Attachments: ttl-updates.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction.
> This situation is currently not handled correctly, resulting in a hidden
> NullPointerException that aborts TTL updates.
> Due to the nature of the TTL updates in Ignite, this problem can only occur
> when the TTL is updated from the backup node.
> Thus, in a very rare case, we may notice a lack of updates in the near-cache
> and on "non-initiator" backups
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16733) [extensions] Fail CDC AbstractReplicationTest
[
https://issues.apache.org/jira/browse/IGNITE-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17514066#comment-17514066
]
Vyacheslav Koptilin commented on IGNITE-16733:
--
Hi [~RyzhovSV], [~xtern],
Could you please specify the right fixVersion? It helps a lot to understand
which release contains the fix.
> [extensions] Fail CDC AbstractReplicationTest
> -
>
> Key: IGNITE-16733
> URL: https://issues.apache.org/jira/browse/IGNITE-16733
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: ise
>
> After changing the API in IGNITE-15117 the CDC tests stopped compiling
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:testCompile
> (default-testCompile) on project ignite-cdc-ext: Compilation failure
> [ERROR]
> /Users/sega/work/ignite-extensions/modules/cdc-ext/src/test/java/org/apache/ignite/cdc/AbstractReplicationTest.java:[186,17]
> cannot find symbol
> [ERROR] symbol: method setCdcEnabled(boolean)
> [ERROR] location: class
> org.apache.ignite.configuration.DataStorageConfiguration
> this field has been moved to DataRegionConfiguration
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16754) [Extensions] Change external repository for deleted from maven central dependencies.
[ https://issues.apache.org/jira/browse/IGNITE-16754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16754: - Ignite Flags: (was: Docs Required,Release Notes Required) > [Extensions] Change external repository for deleted from maven central > dependencies. > > > Key: IGNITE-16754 > URL: https://issues.apache.org/jira/browse/IGNITE-16754 > Project: Ignite > Issue Type: Improvement > Components: extensions >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > Currently we use origin-maven.repository.redhat repository to download > dependencies that were deleted from maven central repository. > It does not work any more because of expired certificates problem - > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=6483968&_focus=4815 > It is proposed to use maven.repository.redhat instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and on "non-initiator" backups
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
!image(1).png!
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and on "non-initiator" backups
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired*
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Attachment: (was: image(1).png)
> Near cache entry can miss a TTL update if an NPE occurs on the primary node.
>
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Labels: ise
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction.
> This situation is currently not handled correctly, resulting in a hidden
> NullPointerException that aborts TTL updates.
> Due to the nature of the TTL updates in Ignite, this problem can only occur
> when the TTL is updated from the backup node.
> Thus, in a very rare case, we may notice a lack of updates in the near-cache
> and on "non-initiator" backups
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) Near cache entry can miss a TTL update if an NPE occurs on the primary node.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Attachment: image(1).png
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction.
This situation is currently not handled correctly, resulting in a hidden
NullPointerException that aborts TTL updates.
Due to the nature of the TTL updates in Ignite, this problem can only occur
when the TTL is updated from the backup node.
!image(1).png!
Thus, in a very rare case, we may notice a lack of updates in the near-cache
and on "non-initiator" backups
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction. In this case, the
keys-loop is interrupted by the NPE ( which is currently not outputting
anywhere).
Reproducer:
{code:java}
public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
private final ListeningTestLogger log = new
ListeningTestLogger(GridAbstractTest.log);
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setGridLogger(log)
.setCacheConfiguration(new CacheConfiguration(DEFAULT_CACHE_NAME)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setCacheMode(REPLICATED)
);
}
@Test
public void test() throws Exception {
LogListener lsnr = LogListener.matches("Failed to send TTL update
request").build();
log.registerListener(lsnr);
startGridsMultiThreaded(4);
Map vals = new TreeMap<>();
for (int i = 1; i < 10; i++)
vals.put(i, i);
[jira] [Updated] (IGNITE-16760) Performance degradation of configuration changes
[
https://issues.apache.org/jira/browse/IGNITE-16760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16760:
-
Labels: ignite-3 (was: )
> Performance degradation of configuration changes
>
>
> Key: IGNITE-16760
> URL: https://issues.apache.org/jira/browse/IGNITE-16760
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha4
>Reporter: Taras Ledkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> Performance degradation of configuration changes:
> Steps to reproduce:
> 1. Start cluster with 3 nodes
> 2. Run in the loop
> {code}
> CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
> DROP TABLE TEST
> {code}
> An iteration on the begin has about 1.7 sec. The time is grown.
> The time after ~170 iteration is about 70 sec.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16754) [Extensions] Change external repository for deleted from maven central dependencies.
[ https://issues.apache.org/jira/browse/IGNITE-16754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16754: - Component/s: extensions > [Extensions] Change external repository for deleted from maven central > dependencies. > > > Key: IGNITE-16754 > URL: https://issues.apache.org/jira/browse/IGNITE-16754 > Project: Ignite > Issue Type: Improvement > Components: extensions >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > Currently we use origin-maven.repository.redhat repository to download > dependencies that were deleted from maven central repository. > It does not work any more because of expired certificates problem - > https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=6483968&_focus=4815 > It is proposed to use maven.repository.redhat instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16742) Extend calcite module documentation and config.
[ https://issues.apache.org/jira/browse/IGNITE-16742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16742: - Fix Version/s: 2.14 > Extend calcite module documentation and config. > --- > > Key: IGNITE-16742 > URL: https://issues.apache.org/jira/browse/IGNITE-16742 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > After calcite engine was merged into master branch [1], seems it would > helpful to update some documentation. > [1] https://issues.apache.org/jira/browse/IGNITE-15436 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16727) Add an option to turn off metadata synchronization
[ https://issues.apache.org/jira/browse/IGNITE-16727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16727: - Labels: ignite-3 (was: ) > Add an option to turn off metadata synchronization > -- > > Key: IGNITE-16727 > URL: https://issues.apache.org/jira/browse/IGNITE-16727 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > While the synchronization protocol of metadata between cluster node have not > been implemented. We use direct access to Metastorage in the places where the > most actual metadata required. But the approach increases a latency on the > operations dramatically. > Let’s add an option (JVM property) for tests and benchmarks, which allow > skipping the direct metadata request. This will unblock some activities for > QA, and generally sounds like a sensible option for debug and tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15673) Update Ignite dependency zookeeper
[ https://issues.apache.org/jira/browse/IGNITE-15673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15673: - Ignite Flags: (was: Docs Required,Release Notes Required) > Update Ignite dependency zookeeper > -- > > Key: IGNITE-15673 > URL: https://issues.apache.org/jira/browse/IGNITE-15673 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: newbie > Fix For: 2.13 > > Time Spent: 40m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.5.5 to 3.7.0 and curator 4.2.0 to 5.2.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16673) Update Ignite dependency zookeeper
[ https://issues.apache.org/jira/browse/IGNITE-16673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16673: - Release Note: Updated zookeeper dependency to 3.8.0 (was: Update zookeeper dependency to 3.8.0) > Update Ignite dependency zookeeper > -- > > Key: IGNITE-16673 > URL: https://issues.apache.org/jira/browse/IGNITE-16673 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.7.0 to 3.8.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Ignite Flags: Release Notes Required
Release Note: Added a ServiceCallContext that allows implicitly pass
additional parameters on every service call.
> Ability to set custom execution context for Ignite service.
> ---
>
> Key: IGNITE-15572
> URL: https://issues.apache.org/jira/browse/IGNITE-15572
> Project: Ignite
> Issue Type: New Feature
> Components: managed services
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ise
> Fix For: 2.13
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In traditional microservices, we have the ability to set a custom execution
> context. For example, a REST service may obtain the session ID from the
> request. We can say that each client request, in this case, has a set of
> explicit and implicit parameters. One of the implicit parameters is a session
> identifier that can be passed to the service using request headers. It would
> be nice to have a similar feature in Ignite services.
> The basic idea behind the implementation:
> 1. Allow the user to bind the "execution context" to the service proxy
> object.
> 2. Pass this context as an additional implicit parameter each time the user
> service method is called.
> h3. API proposal.
> h4. 1. Using a custom annotation (ServiceRequestContextResource) and reading
> context attributes with a function.
> {code:java}
> MyService proxy = ignite.services().serviceProxy("svc", ...
> Collections.singletonMap("login", "user1"));
> public class MyServiceImpl implements MyService {
> @ServiceRequestContextResource
> private Function ctxFunc;
> @Override public void serviceMethod() {
> String login = (String)ctxFunc.apply("login");
> }
> ...
> }{code}
> h4. 2. Using a new method of the existing ServiceContext.
> {code:java}
> MyService proxy = ignite.services().serviceProxy("svc", ...
> Collections.singletonMap("login", "user1"));
> public class MyServiceImpl implements MyService {
> private ServiceContext svcCtx;
> @Override public void init(ServiceContext svcCtx) {
> this.svcCtx = svcCtx;
> }
> @Override public void serviceMethod() {
> String user = svcCtx.attribute("login");
> // and/or
> String user = (String)svcCtx.attributes().get("login");
> }
> ...
> }{code}
> h4. The next two options require wrapping Map into a new
> ServiceRequestContext class.
> h4. 3. Read context "wrapper" using special annotation and supplier.
> {code:java}
> MyService proxy = ignite.services().serviceProxy("svc", ... new
> ServiceRequestContext("login", "user1"), 0);
> public class MyServiceImpl implements MyService {
> @ServiceRequestContextResource
> Supplier ctxSupplier;
>
> @Override public void serviceMethod() {
> String login = ctxSupplier.get().attribute("login");
> }
> ...
> }
> {code}
> h4. 4. Using the special static method of the "wrapper" class.
> {code:java}
> MyService proxy = ignite.services().serviceProxy("svc", ... new
> ServiceRequestContext("login", "user1"), 0);
> public class MyServiceImpl implements MyService {
> @Override public void serviceMethod() {
> String login = ServiceRequestContext.current().attribute("login");
> }
> ...
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15829) Request attributes for a service in thin clients.
[ https://issues.apache.org/jira/browse/IGNITE-15829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-15829: -- Ignite Flags: (was: Release Notes Required) Release Note: (was: Thin client: Added ServiceCallContext support) > Request attributes for a service in thin clients. > - > > Key: IGNITE-15829 > URL: https://issues.apache.org/jira/browse/IGNITE-15829 > Project: Ignite > Issue Type: Sub-task > Components: managed services, thin client >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-79, ise > Fix For: 2.13 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Implement support for passing implicit "request" attributes from thin clients > to the service. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15795) .NET: Request attributes for a .NET service
[
https://issues.apache.org/jira/browse/IGNITE-15795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15795:
--
Ignite Flags: (was: Release Notes Required)
Release Note: (was: .NET: Added ServiceCallContext that provides a way to
implicitly pass additional data with every service call.)
> .NET: Request attributes for a .NET service
> ---
>
> Key: IGNITE-15795
> URL: https://issues.apache.org/jira/browse/IGNITE-15795
> Project: Ignite
> Issue Type: Sub-task
> Components: managed services
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: .NET, iep-79, ise
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Implement support for passing implicit "request" attributes from the proxy to
> the .NET service.
> {*}Implementation notes{*}.
> # If no caller attributes are passed - there should be no performance
> overhead when executing service methods.
> # Attributes allow only {{string}} and {{byte[]}} values and does not permit
> nulls in key/values.
> # Currently, the context should be immutable, but in the future, it should
> be possible to change it through the interceptor.
> # Context is bound to the NET proxy invocation handler (not to java
> invocation handler) and passed as an implicit parameter on every method call.
> *Public API changes:*
> _API changes are very similar to java part._
> New methods in {{IServices}} to pass caller context to service proxy.
> {code:c#}
> T GetServiceProxy(string name, bool sticky, IServiceCallContext callCtx)
> where T : class;
> dynamic GetDynamicServiceProxy(string name, bool sticky, IServiceCallContext
> callCtx);
> {code}
> New method in {{IServiceContext}} for getting caller context inside the
> service method.
> {code:c#}
> IServiceCallContext CurrentCallContext();
> {code}
> New interface {{IServiceCallContext}}.
> {code:c#}
> public interface IServiceCallContext
> {
> string Attribute(string name);
> byte[] BinaryAttribute(string name)
> }
> {code}
> And the builder {{ServiceCallContextBuilder}} to create
> {{IServiceCallContext}} instance.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15964) NPE in case of simultaneous cache destroy and active tx.
[
https://issues.apache.org/jira/browse/IGNITE-15964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15964:
-
Docs Text: (was: Fixed NPE in case of simultaneous cache destroy and
active tx)
Release Note: Fixed NPE in case of simultaneous cache destroy and active tx
> NPE in case of simultaneous cache destroy and active tx.
>
>
> Key: IGNITE-15964
> URL: https://issues.apache.org/jira/browse/IGNITE-15964
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.11
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Fix For: 2.13
>
> Attachments: Test.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Simultaneous cache destroy and tx activity may lead to NPE. Reproducer
> attached.
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.notifyEvictions(IgniteTxManager.java:1937)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1705)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3902)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:468)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:4195)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:4171)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:298)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:274)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:79)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:192)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.lambda$prepareOnTopology$27f50bf2$1(GridNearOptimisticTxPrepareFutureAdapter.java:224)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$2.apply(GridTimeoutProcessor.java:181)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$2.apply(GridTimeoutProcessor.java:173)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2588)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:4057)
> at
>
[jira] [Updated] (IGNITE-15117) Support CDC for in-memory caches
[ https://issues.apache.org/jira/browse/IGNITE-15117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15117: - Release Note: Implemented CDC for in-memory caches Environment: (was: Implemented CDC for in-memory caches) > Support CDC for in-memory caches > > > Key: IGNITE-15117 > URL: https://issues.apache.org/jira/browse/IGNITE-15117 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59, important > Fix For: 2.13 > > Time Spent: 13h > Remaining Estimate: 0h > > Right now CDC is supported only for persistent caches. > To support CDC feature for in-memory caches we should support enabling WAL > for in-memory caches. > Only DataRecord is required for CDC so we can write only specific that types > of records to the WAL. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14742) Store array component type in binary object
[
https://issues.apache.org/jira/browse/IGNITE-14742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14742:
-
Docs Text: (was: Implemented array component type in binary object)
Release Note: Implemented array component type in binary object
> Store array component type in binary object
> ---
>
> Key: IGNITE-14742
> URL: https://issues.apache.org/jira/browse/IGNITE-14742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: important
> Fix For: 2.13
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Currently, an array of custom objects can't be retrieved from the cache
> {code:java}
> public class BinaryObjectTest extends GridCommonAbstractTest {
> /** */
> @Test
> public void testArray() throws Exception {
> Ignite ign = startGrid();
> IgniteCache cache =
> ign.createCache("my-cache");
> cache.put(1, new TestClass1[] {new TestClass1(), new TestClass1()});
> TestClass1[] obj = cache.get(1);
> assertEquals(TestClass1[].class, obj.getClass());
> }
> }
> {code}
> The fix should preserve backward compatibility.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16673) Update Ignite dependency zookeeper
[ https://issues.apache.org/jira/browse/IGNITE-16673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16673: - Ignite Flags: Release Notes Required > Update Ignite dependency zookeeper > -- > > Key: IGNITE-16673 > URL: https://issues.apache.org/jira/browse/IGNITE-16673 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.7.0 to 3.8.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16385) Update Ignite dependency JNR POSIX
[ https://issues.apache.org/jira/browse/IGNITE-16385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16385: - Ignite Flags: Release Notes Required > Update Ignite dependency JNR POSIX > --- > > Key: IGNITE-16385 > URL: https://issues.apache.org/jira/browse/IGNITE-16385 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency JNR POSIX -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16385) Update Ignite dependency JNR POSIX
[ https://issues.apache.org/jira/browse/IGNITE-16385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16385: - Release Note: Updated JNR POSIX dependency up to 3.1.15 (was: Updated JNR POSIX up to 3.1.15) > Update Ignite dependency JNR POSIX > --- > > Key: IGNITE-16385 > URL: https://issues.apache.org/jira/browse/IGNITE-16385 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency JNR POSIX -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16383) Update Ignite dependency hadoop-yarn-client
[ https://issues.apache.org/jira/browse/IGNITE-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16383: - Ignite Flags: Release Notes Required Release Note: Updated hadoop-yarn-client dependency to 3.3.1 (was: Updated hadoop-yarn-client to 3.3.1) > Update Ignite dependency hadoop-yarn-client > --- > > Key: IGNITE-16383 > URL: https://issues.apache.org/jira/browse/IGNITE-16383 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency hadoop-yarn-client -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16352) Update Ignite dependency Mesos
[ https://issues.apache.org/jira/browse/IGNITE-16352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16352: - Ignite Flags: Release Notes Required Release Note: Updated Mesos dependency to 1.11.0 (was: Updated Mesos 1.11.0) > Update Ignite dependency Mesos > -- > > Key: IGNITE-16352 > URL: https://issues.apache.org/jira/browse/IGNITE-16352 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency Mesos 1.5.0 to 1.11.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16760) Performance degradation of configuration changes
Taras Ledkov created IGNITE-16760:
-
Summary: Performance degradation of configuration changes
Key: IGNITE-16760
URL: https://issues.apache.org/jira/browse/IGNITE-16760
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha4
Reporter: Taras Ledkov
Fix For: 3.0.0-alpha5
Performance degradation of configuration changes:
Steps to reproduce:
1. Start cluster with 3 nodes
2. Run in the loop
{code}
CREATE TABLE TEST(ID INTEGER PRIMARY KEY, V INTEGER)
DROP TABLE TEST
{code}
An iteration on the begin has about 1.7 sec. The time is grown.
The time after ~170 iteration is about 70 sec.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16673) Update Ignite dependency zookeeper
[ https://issues.apache.org/jira/browse/IGNITE-16673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16673: - Release Note: Update zookeeper dependency to 3.8.0 > Update Ignite dependency zookeeper > -- > > Key: IGNITE-16673 > URL: https://issues.apache.org/jira/browse/IGNITE-16673 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.7.0 to 3.8.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16383) Update Ignite dependency hadoop-yarn-client
[ https://issues.apache.org/jira/browse/IGNITE-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16383: - Release Note: Updated hadoop-yarn-client to 3.3.1 > Update Ignite dependency hadoop-yarn-client > --- > > Key: IGNITE-16383 > URL: https://issues.apache.org/jira/browse/IGNITE-16383 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency hadoop-yarn-client -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16385) Update Ignite dependency JNR POSIX
[ https://issues.apache.org/jira/browse/IGNITE-16385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16385: - Release Note: Updated JNR POSIX up to 3.1.15 > Update Ignite dependency JNR POSIX > --- > > Key: IGNITE-16385 > URL: https://issues.apache.org/jira/browse/IGNITE-16385 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update Ignite dependency JNR POSIX -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16352) Update Ignite dependency Mesos
[ https://issues.apache.org/jira/browse/IGNITE-16352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16352: - Release Note: Updated Mesos 1.11.0 > Update Ignite dependency Mesos > -- > > Key: IGNITE-16352 > URL: https://issues.apache.org/jira/browse/IGNITE-16352 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency Mesos 1.5.0 to 1.11.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16499) Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option
[ https://issues.apache.org/jira/browse/IGNITE-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16499: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) Release Note: Added support of IGNITE_TO_STRING_INCLUDE_SENSITIVE option by Сonsistency check command > Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE > option > -- > > Key: IGNITE-16499 > URL: https://issues.apache.org/jira/browse/IGNITE-16499 > Project: Ignite > Issue Type: Sub-task >Reporter: Stepanov Ilya >Assignee: Anton Vinogradov >Priority: Blocker > Labels: iep-31, important, ise > Fix For: 2.13 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Because keys and values are sensitive data, we need to provide for disabling > the possible output of these data to the log. > > Suggestion: add support for the "IGNITE_TO_STRING_INCLUDE_SENSITIVE" option > in the consistency command(Read Repair). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16324) wal-reader can't parse negative groupId/cacheId
[
https://issues.apache.org/jira/browse/IGNITE-16324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16324:
-
Release Note: Fixed negative groupId/cacheId parsing by wal-reader
> wal-reader can't parse negative groupId/cacheId
> ---
>
> Key: IGNITE-16324
> URL: https://issues.apache.org/jira/browse/IGNITE-16324
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Wal-reader cannot parse negative groupId/cacheId, example:
> *-1831596270:844420635541925*
> {noformat}
> ./bin/wal-reader.sh --wal-dir /data/wal/backup/wal/ --wal-archive-dir
> /data/wal/backup/P4HandaThePanda --page-size 16384 --pages
> /data/gdde/work/diagnostic/corruptedPages_2022-01-18_02-32-19_069.txt >>
> outputwalreader.txt
> Exception in thread "main" java.lang.IllegalArgumentException: Error parsing
> value "-1831596270:844420635541925" on 0 line of the file:
> /data/gdde/work/diagnostic/corruptedPages_2022-01-18_02-32-19_069.txt
> at
> org.apache.ignite.internal.commandline.walconverter.IgniteWalConverterArguments.parsePageIds(IgniteWalConverterArguments.java:552)
> at
> org.apache.ignite.internal.commandline.walconverter.IgniteWalConverterArguments.pages(IgniteWalConverterArguments.java:527)
> at
> org.apache.ignite.internal.commandline.walconverter.IgniteWalConverterArguments.parse(IgniteWalConverterArguments.java:410)
> at
> org.apache.ignite.internal.commandline.walconverter.IgniteWalConverter.main(IgniteWalConverter.java:66)
> Caused by: java.lang.IllegalArgumentException: Incorrect value
> -1831596270:844420635541925, valid format: grpId:pageId. Example: 123:456
> at
> org.apache.ignite.internal.commandline.walconverter.IgniteWalConverterArguments.parsePageId(IgniteWalConverterArguments.java:584)
> at
> org.apache.ignite.internal.commandline.walconverter.IgniteWalConverterArguments.parsePageIds(IgniteWalConverterArguments.java:548)
> ... 3 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15698) SQL query may hangs where table is dropped concurrently
[
https://issues.apache.org/jira/browse/IGNITE-15698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15698:
-
Release Note: Fixed hang query when table is dropped concurrently
> SQL query may hangs where table is dropped concurrently
>
>
> Key: IGNITE-15698
> URL: https://issues.apache.org/jira/browse/IGNITE-15698
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> SQL query may hangs where table is dropped concurrently.
> *Root cause:*
> Unhanded exception at the query thread at:
> {{GridMapQueryExecutor#onQueryRequest}} when a cache is destroyed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16043) AssertionError in BinaryObjectBuilder
[
https://issues.apache.org/jira/browse/IGNITE-16043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16043:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> AssertionError in BinaryObjectBuilder
> -
>
> Key: IGNITE-16043
> URL: https://issues.apache.org/jira/browse/IGNITE-16043
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.11
>Reporter: Ilya Kazakov
>Assignee: Andrey Belyaev
>Priority: Minor
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> AssertionError in this code (run java with -ea key):
> {{}}
>
>
> {code:java}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.binary.BinaryObjectBuilder;
> public class Ae {
> public static void main(String[] args) {
> try(Ignite ignite = Ignition.start()){
> BinaryObjectBuilder builder =
> ignite.binary().builder(Ae.class.getName()).setField("w", "wewe");
> String f = builder.getField("field");
> System.out.println(f);
> }
> }
> } {code}
>
>
> {code:java}
> Exception in thread "main" java.lang.AssertionError
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.ensureReadCacheInit(BinaryObjectBuilderImpl.java:481)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.getField(BinaryObjectBuilderImpl.java:543)
> at org.apache.ignite.examples.Ae.main(Ae.java:11){code}
> {{}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16569) Add ability to customize the test context for ducktest
[
https://issues.apache.org/jira/browse/IGNITE-16569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16569:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add ability to customize the test context for ducktest
> --
>
> Key: IGNITE-16569
> URL: https://issues.apache.org/jira/browse/IGNITE-16569
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Fix For: 2.13
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently the ducktests can be customized only via the providing of external
> implentations of _IgniteNodeSpec_ and _IgniteApplicationSpec_ classes. These
> classes specify the enviroment (java command line options, specific ignite
> configuration, extra libraries in the classpath) in which client and server
> ignite nodes should be started. Names of actual classes to be used during the
> test run are passed as _NodeSpec_ and _AppSpec_ globals parameters.
> The goal of this work is to add ability to add extra procedures to be invoked
> _before_ and _after_ each testcase transparently via the globals parameters
> in a way similar to described above for ignite nodes. It should be possible
> to invoke of extra ducktape services in these procedures on the same testing
> cluster.
> *User API:*
> User optionally passes the name of custom implementation of
> _IgniteTestContext_ class via the _globals_ parameter as
> {code:java}
> > ducktape --globals
> > '{"IgniteTestContext":"utils.test_context.CustomTestContext"}' ... {code}
>
> The custom implementaiton of _IgniteTestContext_ may override the following
> member functions:
> * _before(self)_ - Actions to be done before any testcase start.
> * {_}after(self, test_result) - A{_}ctions to be done after testcase finish.
> The result of the original test is passed to this function for additional
> analysis if needed. The _after()_ implementation may either return result
> without modifications or return the customized one. The final test result
> would be the one returned from this function.
> * _available_cluster_size(self) -_ if customization invokes any ducktape
> services in the _before()_ it must provide implementation of this function to
> let the testcase know actual number of cluster nodes still available.
> Notes:
> The original ducktape's _TestContext_ is replaced with the
> _IgniteTestContext_ (or its customized variant) during the application of the
> _@ignitetest.utils.cluster_ decorator. So any ignite test MUST BE decorated
> with the @{_}ignitetest.utils.cluster{_} decorator. It is already so anyway.
> Any ignite test should use the _IgniteTest::available_cluster_size_ property
> to determine the number of available cluster nodes. In particular it MUST
> NOT use the _IgniteTest::test_context.cluster_ property directly since some
> nodes may be already occupied by services invoked in customization.
>
> ***
> In scope of this task some modifications were also done to let tests run
> smoothly in presence of the customization:
> # The *persistence_upgrade_test.py::PersistenceUpgradeTest* fails if SSL is
> enabled via the --globals options. The immediate reason is that control.sh
> doesn't support the SSL options (like key_store_path) in the 2.7.6 version
> which is the starting point for the test incremental migrations of the PDS.
> Solution is to ignore test if SSL is enabled.
> # The framework was modified to let customization to extend set of listening
> ignite events. The test affected is
> {*}control_utility/consistency_test.py::ConsistencyTest{*}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16629) Wrong calculation of replies count for queries with partition pruning and enabled parallelism
[
https://issues.apache.org/jira/browse/IGNITE-16629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16629:
-
Release Note: Fixed wrong calculation of replies count for queries with
partition pruning and enabled parallelism
> Wrong calculation of replies count for queries with partition pruning and
> enabled parallelism
> -
>
> Key: IGNITE-16629
> URL: https://issues.apache.org/jira/browse/IGNITE-16629
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Critical
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently a simple query is freezing forever if query parallelism is enabled
> and partition pruning extracts more than one partition. This caused by wrong
> replies count estimation made on a reducer node.
> The problematic query looks like this: {{{}select * from t where aff_key in
> ('a', 'b', 'c'){}}}.
> Please note that field _aff_key_ should be an affinity key and be a part of
> the compound PK.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15887) Improve wording for setCheckpointFrequency method in JavaDoc
[ https://issues.apache.org/jira/browse/IGNITE-15887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15887: - Ignite Flags: (was: Docs Required,Release Notes Required) > Improve wording for setCheckpointFrequency method in JavaDoc > - > > Key: IGNITE-15887 > URL: https://issues.apache.org/jira/browse/IGNITE-15887 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Minor > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > setCheckpointFrequency method states that "If the rate is high, checkpoint > will be triggered more frequently." > This is confusing because high number means low rate, so we should improve > wording. > See: > [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/DataStorageConfiguration.html] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16330) Update slf4j to the latest version
[
https://issues.apache.org/jira/browse/IGNITE-16330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16330:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
Release Note: Updated sfl4j version to 1.7.33
> Update slf4j to the latest version
> --
>
> Key: IGNITE-16330
> URL: https://issues.apache.org/jira/browse/IGNITE-16330
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Some of the extenal Ignite dependencies like Kafka uses more recent version
> of slf4j which is not compatible with the 1.7.7
> {noformat}
> [data-plane-kafka-request-handler-5] ERROR state.change.logger - [Broker
> id=0] Error while processing LeaderAndIsr request correlationId 1 received
> from controller 0 epoch 1 for partition source-dest-3
> java.lang.NoClassDefFoundError: org/slf4j/event/Level
> {noformat}
> We should update sfl4j to the latest version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15868) Unexpected command: PROBE when authorization is enabled
[
https://issues.apache.org/jira/browse/IGNITE-15868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15868:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Unexpected command: PROBE when authorization is enabled
> ---
>
> Key: IGNITE-15868
> URL: https://issues.apache.org/jira/browse/IGNITE-15868
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Affects Versions: 2.12
>Reporter: Dmitriy Borunov
>Assignee: Dmitriy Borunov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Rest API Probe is not working when Control Center authorisation is enabled
> {noformat}
> [2021-11-01T13:35:33,550][ERROR][rest-#125%nebula-node%][GridRestProcessor]
> Runtime error caught during grid runnable execution: GridWorker
> [name=rest-proc-work
> er, igniteInstanceName=nebula-node, finished=false,
> heartbeatTs=1635773733544, hashCode=1386655371, interrupted=false,
> runner=rest-#125%nebula-node%]
> java.lang.AssertionError: Unexpected command: PROBE
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.authorize(GridRestProcessor.java:968)
> ~[ignite-core-8.8.10.jar:8.8.10]
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:286)
> ~[ignite-core-8.8.10.jar:8.8.10]
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:108)
> ~[ignite-core-8.8.10.jar:8.8.10]
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:183)
> ~[ignite-core-8.8.10.jar:8.8.10]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> [ignite-core-8.8.10.jar:8.8.10]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15673) Update Ignite dependency zookeeper
[ https://issues.apache.org/jira/browse/IGNITE-15673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15673: - Release Note: Updated zookeeper dependency up to 3.7.0 > Update Ignite dependency zookeeper > -- > > Key: IGNITE-15673 > URL: https://issues.apache.org/jira/browse/IGNITE-15673 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: newbie > Fix For: 2.13 > > Time Spent: 40m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.5.5 to 3.7.0 and curator 4.2.0 to 5.2.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15829) Request attributes for a service in thin clients.
[ https://issues.apache.org/jira/browse/IGNITE-15829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15829: - Release Note: Thin client: Added ServiceCallContext support > Request attributes for a service in thin clients. > - > > Key: IGNITE-15829 > URL: https://issues.apache.org/jira/browse/IGNITE-15829 > Project: Ignite > Issue Type: Sub-task > Components: managed services, thin client >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-79, ise > Fix For: 2.13 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Implement support for passing implicit "request" attributes from thin clients > to the service. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14366) Support separate JVM options for ignite-cdc.sh and ignite.sh
[
https://issues.apache.org/jira/browse/IGNITE-14366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14366:
-
Release Note: Added separate JVM options for ignite-cdc.sh and ignite.sh
> Support separate JVM options for ignite-cdc.sh and ignite.sh
>
>
> Key: IGNITE-14366
> URL: https://issues.apache.org/jira/browse/IGNITE-14366
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, ignite-cdc.sh just reuse ignite.sh with it's own main class name
> ({{org.apache.ignite.cdc.CommandLineStartup}})
> Should fix it and provide a way to separate configuration ignite and cdc
> applications.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15308) Parameters that can be configured via TransactionsMXBean do not propagate to newly joined nodes
[ https://issues.apache.org/jira/browse/IGNITE-15308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15308: - Release Note: Added saving settings for transactions monitoring to disk > Parameters that can be configured via TransactionsMXBean do not propagate to > newly joined nodes > --- > > Key: IGNITE-15308 > URL: https://issues.apache.org/jira/browse/IGNITE-15308 > Project: Ignite > Issue Type: Bug >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If we change some parameter using TransactionsMXBean, i.e. > TxTimeoutOnPartitionMapExchange or TxOwnerDumpRequestsAllowed, and then start > a new node that will join the cluster, changed settings will not propagate to > new node. > We need write this settings to distributed metastorage to implement settings > propagation for TransactionsMXBean. For example, working case using > distributed metastorage is BaselineAutoAdjustMXBean. > Also changed JMX settings should survive cluster reboot, if cluster has PDS. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-12313) Unable to update value via sql update query if a key is a byte array within non-mvcc mode.
[
https://issues.apache.org/jira/browse/IGNITE-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-12313:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Unable to update value via sql update query if a key is a byte array within
> non-mvcc mode.
> --
>
> Key: IGNITE-12313
> URL: https://issues.apache.org/jira/browse/IGNITE-12313
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> {code:java}
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
> [B cannot be cast to java.lang.Comparable
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2350)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2283)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2210)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2183)
> at
> org.apache.ignite.sqltests.SqlDataTypesCoverageTests.checkCRUD(SqlDataTypesCoverageTests.java:381)
> at
> org.apache.ignite.sqltests.SqlDataTypesCoverageTests.checkBasicSqlOperations(SqlDataTypesCoverageTests.java:335)
> at
> org.apache.ignite.sqltests.SqlDataTypesCoverageTests.testBinaryDataType(SqlDataTypesCoverageTests.java:269)
> 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:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2075)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.IgniteCheckedException: [B cannot be cast
> to java.lang.Comparable
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2828)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$1(GridQueryProcessor.java:2309)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2347)
> ... 17 more
> Caused by: java.lang.ClassCastException: [B cannot be cast to
> java.lang.Comparable
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.compareForDml(BinaryObjectImpl.java:863)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender$BatchEntryComparator.compare(DmlBatchSender.java:423)
> at java.util.TreeMap.compare(TreeMap.java:1295)
> at java.util.TreeMap.put(TreeMap.java:538)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender$Batch.put(DmlBatchSender.java:368)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlBatchSender.add(DmlBatchSender.java:118)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.doUpdate(DmlUtils.java:252)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:168)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2765)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2625)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2555)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1167)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1093)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$3.applyx(GridQueryProcessor.java:2293)
> at
>
[jira] [Updated] (IGNITE-14829) Save DataEntry index inside CDC state
[ https://issues.apache.org/jira/browse/IGNITE-14829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14829: - Release Note: Fixed CDC state restore when record contains multiple DataEntry. > Save DataEntry index inside CDC state > - > > Key: IGNITE-14829 > URL: https://issues.apache.org/jira/browse/IGNITE-14829 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-59 > Fix For: 2.13 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > CDC state should contain an index of DataEntry inside DataRecord to correctly > failover. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16523) WALForceArchiveTimeout lead to node fails to restart
[
https://issues.apache.org/jira/browse/IGNITE-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16523:
-
Release Note: Fixed rollover by timeout that leads to node restart fail
> WALForceArchiveTimeout lead to node fails to restart
>
>
> Key: IGNITE-16523
> URL: https://issues.apache.org/jira/browse/IGNITE-16523
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: IEP-59
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When WALForceArchiveTimeout set node failed to restart.
> {code:java}
> /** */
> @RunWith(Parameterized.class)
> public class RestartWithWalForceArchiveTimeoutTest extends
> GridCommonAbstractTest {
> /** */
> @Parameterized.Parameter
> public WALMode walMode;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setConsistentId(igniteInstanceName);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setWalMode(walMode)
> .setWalForceArchiveTimeout(60 * 60 * 1000) // 1 hour to make sure
> auto archive will not work.
> .setDefaultDataRegionConfiguration(new
> DataRegionConfiguration().setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Parameterized.Parameters(name = "walMode={0}")
> public static Collection parameters() {
> return EnumSet.of(WALMode.FSYNC, WALMode.LOG_ONLY,
> WALMode.BACKGROUND);
> }
> /** */
> @Test
> public void testRestart() throws Exception {
> stopAllGrids(true);
> cleanPersistenceDir();
> Supplier restart = () -> {
> stopAllGrids(true);
> try {
> IgniteEx ign = startGrid(getConfiguration("ignite-0"));
> ign.cluster().state(ACTIVE);
> return ign;
> }
> catch (Exception e) {
> throw new RuntimeException(e);
> }
> };
> IgniteEx ign = restart.get();
> IgniteCache cache =
> ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 0, 100);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 100, 200);
> ign = restart.get();
> cache = ign.getOrCreateCache(DEFAULT_CACHE_NAME);
> addData(cache, 200, 300);
> restart.get();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-11402) SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE
[ https://issues.apache.org/jira/browse/IGNITE-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-11402: - Release Note: SQL: Added ability to specify inline size of PK and affinity key indexes from CREATE TABLE > SQL: Add ability to specify inline size of PK and affinity key indexes from > CREATE TABLE > > > Key: IGNITE-11402 > URL: https://issues.apache.org/jira/browse/IGNITE-11402 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > Labels: newbie > Fix For: 2.13 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > Currently it is not possible to set inline size for automatically created > indexes easily. We need to make sure that user has a convenient way to set > them both programmatically and from DDL. > Start point for automatically created indexes is > org.apache.ignite.internal.processors.query.h2.H2TableDescriptor#createSystemIndexes > where passed parameter inlineSize as -1 for > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#createSortedIndex -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15330) Read Repair should support strategies
[
https://issues.apache.org/jira/browse/IGNITE-15330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15330:
-
Release Note: Implemented Read Repair strategies
> Read Repair should support strategies
> -
>
> Key: IGNITE-15330
> URL: https://issues.apache.org/jira/browse/IGNITE-15330
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31, important
> Fix For: 2.13
>
> Time Spent: 7h 20m
> Remaining Estimate: 0h
>
> Possible strategies:
> {noformat}
> LWW, // Currently implemented
> PRIMARY,
> MAJORITY,
> REMOVE,
> CHECK_ONLY;
> {noformat}
> The strategy should not fix entries when impossible, eg LWW when versions are
> the same but values differ.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16225) Read Repair control.sh command should have named params
[
https://issues.apache.org/jira/browse/IGNITE-16225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16225:
-
Release Note: Implemented named params to Read Repair control.sh command
> Read Repair control.sh command should have named params
> ---
>
> Key: IGNITE-16225
> URL: https://issues.apache.org/jira/browse/IGNITE-16225
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.13
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Current syntax is
> {noformat}
> --consistency repair consistencyCacheName consistencyCachePartition
> readRepairStrategy
> {noformat}
> while it can be more readable like
> {noformat}
> --consistency repair -c/--cache consistencyCacheName -p/--partition
> consistencyCachePartition -s/--strategy readRepairStrategy
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16071) Read Repair futures should be rewritten to use wait-free sync instead of synchronized
[ https://issues.apache.org/jira/browse/IGNITE-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16071: - Ignite Flags: (was: Docs Required,Release Notes Required) > Read Repair futures should be rewritten to use wait-free sync instead of > synchronized > - > > Key: IGNITE-16071 > URL: https://issues.apache.org/jira/browse/IGNITE-16071 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.13 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Read Repair was implemented as a PoC, so synchronized sync was suitable, but > now this should be replaced with CompoundFuture logic. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16261) Query with 'in' condition with a sub-query returns multiplicative data.
[
https://issues.apache.org/jira/browse/IGNITE-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16261:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
Release Note: Fixed an issue when query with 'in' condition with a
sub-query returns multiplicative data.
> Query with 'in' condition with a sub-query returns multiplicative data.
> ---
>
> Key: IGNITE-16261
> URL: https://issues.apache.org/jira/browse/IGNITE-16261
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A query like
> {code:java}
> select * from T1 where T1.col1 > 0 or T1.col1 in (select T2.col1 from T2)
> {code}
> where T1 is replicated and T2 is partitioned, may return duplicate rows on
> the multinode cluster.
>
> Ket's treat Replicated cache as Partitioned one, like we do when joining
> replicated cache to a partitioned.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16732) Add configurable Ignite logo and Ignite metrics log messages
[
https://issues.apache.org/jira/browse/IGNITE-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-16732:
-
Description:
For some of the deployments it may be necessary do customize the output Ignite
messages. For instance,
{code}
>>> ++
>>> Ignite ver.
>>> 2.13.0-SNAPSHOT#20220321-sha1:86e91596680009b498991421d161229b178896c6
>>> ++
>>> OS name: Mac OS X 10.16 x86_64
>>> CPU(s): 12
>>> Heap: 6.0GB
>>> VM name: 94661@CAB-WSM-0004852
>>> Ignite instance name: snapshot.IgniteClusterSnapshotSelfTest0
>>> Local node [ID=FCCB81D4-1A83-4771-926A-B5A01AF0, order=1,
>>> clientMode=false]
>>> Local node addresses: [127.0.0.1]
>>> Local ports: TCP:10800 TCP:47100 TCP:47500
{code}
This message may be extended with plugins of some custom environment specific
variables.
was:
Currently IgniteProductVersion has the structure below and can be construct
from the following line:
{{1.2.3-rc1-4-18e5a7ec9e3202126a69bc231a6b965bc1d73dee}}
Where
* {{1.2.3}} - major, minor and maintenance versions
* {{rc1}} - stage
* {{4}} - timestamp
* {{18e5a7ec9e3202126a69bc231a6b965bc1d73dee}} - hash commit
It is possible to add a {{nameTag}} for the product version structure, so the
Ignite will be named the same way as one of the part of the complex solution.
> Add configurable Ignite logo and Ignite metrics log messages
>
>
> Key: IGNITE-16732
> URL: https://issues.apache.org/jira/browse/IGNITE-16732
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For some of the deployments it may be necessary do customize the output
> Ignite messages. For instance,
> {code}
> >>> ++
> >>> Ignite ver.
> >>> 2.13.0-SNAPSHOT#20220321-sha1:86e91596680009b498991421d161229b178896c6
> >>> ++
> >>> OS name: Mac OS X 10.16 x86_64
> >>> CPU(s): 12
> >>> Heap: 6.0GB
> >>> VM name: 94661@CAB-WSM-0004852
> >>> Ignite instance name: snapshot.IgniteClusterSnapshotSelfTest0
> >>> Local node [ID=FCCB81D4-1A83-4771-926A-B5A01AF0, order=1,
> >>> clientMode=false]
> >>> Local node addresses: [127.0.0.1]
> >>> Local ports: TCP:10800 TCP:47100 TCP:47500
> {code}
> This message may be extended with plugins of some custom environment specific
> variables.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16732) Add configurable Ignite logo and Ignite metrics log messages
[
https://issues.apache.org/jira/browse/IGNITE-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-16732:
-
Summary: Add configurable Ignite logo and Ignite metrics log messages
(was: Add build name tag for Ignite product version)
> Add configurable Ignite logo and Ignite metrics log messages
>
>
> Key: IGNITE-16732
> URL: https://issues.apache.org/jira/browse/IGNITE-16732
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently IgniteProductVersion has the structure below and can be construct
> from the following line:
> {{1.2.3-rc1-4-18e5a7ec9e3202126a69bc231a6b965bc1d73dee}}
> Where
> * {{1.2.3}} - major, minor and maintenance versions
> * {{rc1}} - stage
> * {{4}} - timestamp
> * {{18e5a7ec9e3202126a69bc231a6b965bc1d73dee}} - hash commit
> It is possible to add a {{nameTag}} for the product version structure, so the
> Ignite will be named the same way as one of the part of the complex solution.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16640) Peer class loading failure should not be treated as a critical node failure
[ https://issues.apache.org/jira/browse/IGNITE-16640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16640: - Release Note: Fixed peer class loading failure handling > Peer class loading failure should not be treated as a critical node failure > --- > > Key: IGNITE-16640 > URL: https://issues.apache.org/jira/browse/IGNITE-16640 > Project: Ignite > Issue Type: Bug > Components: compute, persistence >Affects Versions: 2.12 >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > The problematic scenario: > # Enable p2p class-loading in the cluster > # Create a cache > # From a client, obtain a dataStreamer on that cache and set a receiver() > which class is only present on the client (so that it is forced to be loaded > using p2p) > # The receiver class, during its operation (inside its receive() method), > should initiate loading of another class only present on the client > # If at the moment, when an attempt is made to load the class mentioned in > item 4, the client is not available anymore, a class-loading exception > happens on the server node, which is manifested as a NoClassDefFoundError, > which is caught and processed by its Failure Handler. If the handler is > 'stop-or-halt', the node is stopped. > So the scenario might cause a node failure, even though the original problem > is local and transient. We should distinguish between p2p class load errors > (which are non-critical) and non-p2p class load errors (which are critical). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16028) Node failure with ClassNotFoundException: wrong validation for Object type
[
https://issues.apache.org/jira/browse/IGNITE-16028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16028:
-
Release Note: Fixed node failure with ClassNotFoundException: wrong
validation for Object type
> Node failure with ClassNotFoundException: wrong validation for Object type
> --
>
> Key: IGNITE-16028
> URL: https://issues.apache.org/jira/browse/IGNITE-16028
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Vladimir Ermakov
>Assignee: Vladimir Ermakov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> After implementing the fix for IGNITE-13553, we have an issue that Object
> type can't be used for any other type except the Object one.
>
> The cache object type can be declared as java.lang.Object. For example,
> {code:java}
> .addQueryField("val_obj", Object.class.getName(), null){code}
> But, we can use BinaryObjectBuilder to build BinaryObject and put it as
> 'val_obj'.
> For example,
> {code:java}
> BinaryObjectBuilder bobInner = grid().binary().builder("inner");
> ///
> bob.setField("val_obj", bobInner.build());{code}
> So, we will have an object with 'inner' class name. But a class with that
> name never existed.
> During type validation (introduced in IGNITE-13553) the binaryObject's typeId
> and the java.lang.Object typeId will not match. Then we will try to get the
> class of the object by 'inner' class name, and will definitely face with
> ClassNotFoundException.
> QueryTypeDescriptorImpl#730 line of code.
>
> Please, see BasicIndexTest#testCacheSecondaryCompositeIndex reproducer for
> more details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15777) Specific issues when transaction stuck
[
https://issues.apache.org/jira/browse/IGNITE-15777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15777:
-
Release Note: Fixed PME hanging on client due to implicit transaction
committing.
> Specific issues when transaction stuck
> --
>
> Key: IGNITE-15777
> URL: https://issues.apache.org/jira/browse/IGNITE-15777
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 1) Exchange hangs on client node, because implicit transaction stay in the
> deadlock.
> {noformat}
> sys-#111494%GRID%" #139376 prio=5 os_prio=0 cpu=838.82ms elapsed=2482.84s
> allocated=165M defined_classes=0 tid=0x7fe8ac30d000 nid=0x9b19 sleeping
> [0x7fe892eec000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(java.base@11.0.10/Native Method)
> at
> org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:8156)
> at
> org.apache.ignite.internal.processors.cache.GridCacheGateway.onStopped(GridCacheGateway.java:323)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopGateway(GridCacheProcessor.java:2601)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$processCacheStopRequestOnExchangeDone$629e8679$1(GridCacheProcessor.java:2797)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$$Lambda$1602/0x000840a49040.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11572)
> at
> org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:11474)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCacheStopRequestOnExchangeDone(GridCacheProcessor.java:2776)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2906)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2514)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4765)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1500(GridDhtPartitionsExchangeFuture.java:160)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$4.apply(GridDhtPartitionsExchangeFuture.java:4434)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$4.apply(GridDhtPartitionsExchangeFuture.java:4422)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:407)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:4422)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:2017)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:472)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:459)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3875)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:3854)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
>
[jira] [Updated] (IGNITE-15964) NPE in case of simultaneous cache destroy and active tx.
[
https://issues.apache.org/jira/browse/IGNITE-15964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15964:
-
Docs Text: Fixed NPE in case of simultaneous cache destroy and active tx
> NPE in case of simultaneous cache destroy and active tx.
>
>
> Key: IGNITE-15964
> URL: https://issues.apache.org/jira/browse/IGNITE-15964
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.11
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Fix For: 2.13
>
> Attachments: Test.java
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Simultaneous cache destroy and tx activity may lead to NPE. Reproducer
> attached.
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.notifyEvictions(IgniteTxManager.java:1937)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.rollbackTx(IgniteTxManager.java:1705)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userRollback(IgniteTxLocalAdapter.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.localFinish(GridNearTxLocal.java:3902)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:468)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:4195)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$25.apply(GridNearTxLocal.java:4171)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:298)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:274)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:79)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:478)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:192)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.lambda$prepareOnTopology$27f50bf2$1(GridNearOptimisticTxPrepareFutureAdapter.java:224)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$2.apply(GridTimeoutProcessor.java:181)
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$2.apply(GridTimeoutProcessor.java:173)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:399)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:511)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:490)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2588)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:4057)
> at
>
[jira] [Updated] (IGNITE-15911) Move IGNITE_THROTTLE_INLINE_SIZE_CALCULATION to IgniteSystemProperties
[ https://issues.apache.org/jira/browse/IGNITE-15911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15911: - Ignite Flags: (was: Docs Required,Release Notes Required) > Move IGNITE_THROTTLE_INLINE_SIZE_CALCULATION to IgniteSystemProperties > -- > > Key: IGNITE-15911 > URL: https://issues.apache.org/jira/browse/IGNITE-15911 > Project: Ignite > Issue Type: Task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > All IgniteSystem properties should be specified in single place - > IgniteSystemProperties, to be correctly write down when running help with > 'ignite.sh' -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16150) Get rid of redundant copying of files after downloading when restoring a snapshot.
[
https://issues.apache.org/jira/browse/IGNITE-16150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16150:
-
Release Note: Improved snapshot partitions move
> Get rid of redundant copying of files after downloading when restoring a
> snapshot.
> ---
>
> Key: IGNITE-16150
> URL: https://issues.apache.org/jira/browse/IGNITE-16150
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During the snapshot restore procedure after retrieving the partition file
> from the remote node, we create an additional copy of this file.
> {code:java}
> for (Map.Entry>> m : snpAff.entrySet())
> {
> ctx.cache().context().snapshotMgr()
> .requestRemoteSnapshotFiles(m.getKey(),
> opCtx0.snpName,
> m.getValue(),
> opCtx0.stopChecker,
> (snpFile, t) -> {
> ...
> Path partFile =
> Paths.get(tmpCacheDir.getAbsolutePath(), snpFile.getName());
> try {
>
> IgniteSnapshotManager.copy(snpMgr.ioFactory(),
> snpFile,
> partFile.toFile(),
> snpFile.length());
> ...
> {code}
> File copying is redundant here and can have significant performance overhead.
> Instead, we have to download the file to the target directory (and rename it
> to the desired name if necessary).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15715) Missed values should be checked by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15715: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) Release Note: Fixed missed values check by Read Repair > Missed values should be checked by Read Repair > -- > > Key: IGNITE-15715 > URL: https://issues.apache.org/jira/browse/IGNITE-15715 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.13 > > Time Spent: 40m > Remaining Estimate: 0h > > If one node contains some value but the other has no value at all this should > be considered as a consistency violation. > Removals should be checked as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16661) Rebuild corrupted indexes in case we started in maintenance mode after corruption
[ https://issues.apache.org/jira/browse/IGNITE-16661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16661: - Release Note: Added Maintenance task to rebuild corrupted indexes > Rebuild corrupted indexes in case we started in maintenance mode after > corruption > -- > > Key: IGNITE-16661 > URL: https://issues.apache.org/jira/browse/IGNITE-16661 > Project: Ignite > Issue Type: Improvement >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > If we failed after a B+Tree corruption in an index tree we could trigger a > maintenance mode for the next start. > After that we'll need to repair the index (recreate I believe), in the > meantime we won't be serving requests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16223) Log query id for long running query.
[ https://issues.apache.org/jira/browse/IGNITE-16223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16223: - Ignite Flags: (was: Docs Required,Release Notes Required) > Log query id for long running query. > > > Key: IGNITE-16223 > URL: https://issues.apache.org/jira/browse/IGNITE-16223 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.13 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the long running query warning does not have a query ID. > Therefore, it is not possible to run the KILL QUERY command because of this. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14794) Add JMX command and metrics for automatic snapshot restore operation.
[
https://issues.apache.org/jira/browse/IGNITE-14794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14794:
-
Release Note: Added JMX management and metrics for snapshot restore
operation
> Add JMX command and metrics for automatic snapshot restore operation.
> --
>
> Key: IGNITE-14794
> URL: https://issues.apache.org/jira/browse/IGNITE-14794
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: iep-43, ise
> Fix For: 2.13
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add JMX command to restore a cache group from the snapshot.
> Suggested methods
> {code:java}
> @MXBeanDescription("Restore cluster-wide snapshot.")
> public void restoreSnapshot(
> @MXBeanParameter(name = "snpName", description = "Snapshot name.")
> String name,
> @MXBeanParameter(name = "cacheGroupNames", description = "Optional
> comma-separated list of cache group names.") String cacheGroupNames);
> @MXBeanDescription("Cancel previously started snapshot restore
> operation.")
> public void cancelSnapshotRestore(@MXBeanParameter(name = "snpName",
> description = "Snapshot name.") String name);
> {code}
> Since the automatic snapshot restore operation can take a long time, we must
> be able to track its progress using metrics.
> Suggested metrics:
> ||Name||Type||
> |start time|long|
> |end time|long|
> |request ID|string|
> |snapshot name|string|
> |total partitions|int|
> |processed partitions|int|
> |error message|string|
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14945) IndexQuery should use inline IO for internal filtering.
[ https://issues.apache.org/jira/browse/IGNITE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14945: - Release Note: Improved IndexQuery for index rows filtering > IndexQuery should use inline IO for internal filtering. > --- > > Key: IGNITE-14945 > URL: https://issues.apache.org/jira/browse/IGNITE-14945 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > For comparison of index keys it's required: > # to init cache data row > # access fields with BinaryObject API > So, it's possible to use inline IO for filtering. It can help: > # speed up comparison (Inline IO access is faster than BinaryObject API). > # to avoid init cache data rows for filtered items (in case there are more > filtered items). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15968) Index de-fragmentation fails on DECIMAL and VARCHAR columns
[
https://issues.apache.org/jira/browse/IGNITE-15968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15968:
-
Release Note: Fixed index de-fragmentation fails on DECIMAL and VARCHAR
columns
> Index de-fragmentation fails on DECIMAL and VARCHAR columns
> ---
>
> Key: IGNITE-15968
> URL: https://issues.apache.org/jira/browse/IGNITE-15968
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.11
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.13
>
> Attachments: screenshot-1.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Index de-fragmentation fails on:
> * DECIMAL column because DecimalInlineIndexColumn#get0 returns null
> * VARCHAR column with unexpected error when the string is larger than
> INLINE_SIZE
> *{color:#ff5630}NB:{color}* re-writing an index of varlen field must preserve
> the flag: 0x8000 that marks trim the original value.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14358) Regression when referencing aliased constant from derived table
[
https://issues.apache.org/jira/browse/IGNITE-14358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14358:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Regression when referencing aliased constant from derived table
> ---
>
> Key: IGNITE-14358
> URL: https://issues.apache.org/jira/browse/IGNITE-14358
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Lukas Eder
>Assignee: Vladimir Ermakov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> This used to work in 2.9.1 but no longer does in 2.10.0:
>
> {code:java}
> CREATE TABLE t (i int PRIMARY KEY, j int);
> INSERT INTO t VALUES (1, 1);
> SELECT u.x
> FROM (
> SELECT 1 AS x
> FROM t
> ) u;
> {code}
>
> The error I'm getting is:
> {noformat}
> SQL Error [1001] [42000]: Failed to parse query. Column "U__Z0.X" not found;
> SQL statement:
> SELECT
> U__Z0.X
> FROM PUBLIC.T U__Z0 [42122-197]{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16387) Improve CDC logging and monitoring
[
https://issues.apache.org/jira/browse/IGNITE-16387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16387:
-
Release Note: Improved CDC monitoring and logging
> Improve CDC logging and monitoring
> --
>
> Key: IGNITE-16387
> URL: https://issues.apache.org/jira/browse/IGNITE-16387
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, it's hard to debug and monitor CDC state and settings.
> We need to provide some additional logging and metrics.
> * Debug {{CacheVersionConflictResolverImpl}} implementation which will log
> all conflict resolution
> * Log {{clusterId}} value and creation of
> {{CacheVersionConflictResolverImpl}} with cache name.
> * Log {{clusterId}} value int {{GridCacheVersion#toString}}
> * Add {{conflictResolver}} value in {{CacheView}}.
> * Add {{clusterId}} metric.
> * etc.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15987) PK index inline size is not calculated correctly for keys with a single field
[ https://issues.apache.org/jira/browse/IGNITE-15987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15987: - Release Note: Implemented generate create table sql key type by original column type > PK index inline size is not calculated correctly for keys with a single field > - > > Key: IGNITE-15987 > URL: https://issues.apache.org/jira/browse/IGNITE-15987 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.11 >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Example: > CREATE TABLE IF NOT EXISTS TABLE1 ( > col1 varchar(15), > col2 varchar(100), > PRIMARY KEY(col1) > ); > In this case PK inline size would be default 10. > CREATE TABLE IF NOT EXISTS TABLE2 ( > col1 varchar(15), > col2 varchar(100), > PRIMARY KEY(col1) > ) WITH "WRAP_KEY=true"; > This one works correctly, inline size is 18. > It seems that it works as expected only for WRAP_KEY=true. -- This message was sent by Atlassian Jira (v8.20.1#820001)
