[jira] [Commented] (IGNITE-15924) Java thin client: Type name is not cached on client side for OptimizerMarshaller types
[
https://issues.apache.org/jira/browse/IGNITE-15924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447235#comment-17447235
]
Ignite TC Bot commented on IGNITE-15924:
{panel:title=Branch: [pull/9576/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}AWS{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6209954]]
{color:#d04437}GCE{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6209994]]
{panel}
{panel:title=Branch: [pull/9576/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Thin Client: Java{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6210003]]
* {color:#013220}ClientTestSuite:
OptimizedMarshallerClassesCachedTest.testLocalDateTimeMetaCached - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6210048&buildTypeId=IgniteTests24Java8_RunAll]
> Java thin client: Type name is not cached on client side for
> OptimizerMarshaller types
> --
>
> Key: IGNITE-15924
> URL: https://issues.apache.org/jira/browse/IGNITE-15924
> Project: Ignite
> Issue Type: Bug
>Reporter: Alex Plehanov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For JDK marshaller types (for example {{LocalDateTime}} use JDK marshaller)
> type name, requested by {{{}typeId{}}}, is not cached correctly.
> For example, in this fragment, type name requested twice by thin-client
> (after each get request), but should be cached after the first request:
> {code:java}
> try (Ignite srv = Ignition.start(Config.getServerConfiguration())) {
> srv.cache(Config.DEFAULT_CACHE_NAME).put(1, LocalDateTime.now());
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER))) {
> client.cache(Config.DEFAULT_CACHE_NAME).get(1);
> client.cache(Config.DEFAULT_CACHE_NAME).get(1);
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15767) Need to workaround JDK bug JDK-8247750
[
https://issues.apache.org/jira/browse/IGNITE-15767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447238#comment-17447238
]
Ignite TC Bot commented on IGNITE-15767:
{panel:title=Branch: [pull/9498/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9498/head] Base: [master] : New Tests
(218)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=6280574]]
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true,
walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false, walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true, walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=true,
walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=true, walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=true,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true,
walMode=LOG_ONLY,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,
walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/1408549350@dc4a691]
- PASSED{color}
... and 19 new tests
{color:#8b}Data Structures{color} [[tests
88|https://ci.ignite.apache.org/viewLog.html?buildId=6280550]]
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=true, async=true] -
PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
AtomicReadRepairTest.test[getEntry=false, async=false] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
AtomicReadRepairTest.test[getEntry=false, async=true] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=true] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=READ_COMMITTED, getEntry=false, async=false] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=READ_COMMITTED, getEntry=false, async=true] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=READ_COMMITTED, getEntry=true, async=false] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=READ_COMMITTED, getEntry=true, async=true] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=REPEATABLE_READ, getEntry=false, async=false] - PASSED{color}
* {color:#013220}IgniteCacheDataStructuresSelfTestSuite:
ExplicitTransactionalReadRepairTest.test[concurrency=OPTIMISTIC,
isolation=REPEATABLE_READ, getEntry=false, asy
[jira] [Updated] (IGNITE-15924) Java thin client: Type name is not cached on client side for OptimizerMarshaller types
[
https://issues.apache.org/jira/browse/IGNITE-15924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15924:
-
Fix Version/s: 2.12
> Java thin client: Type name is not cached on client side for
> OptimizerMarshaller types
> --
>
> Key: IGNITE-15924
> URL: https://issues.apache.org/jira/browse/IGNITE-15924
> Project: Ignite
> Issue Type: Bug
>Reporter: Alex Plehanov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For JDK marshaller types (for example {{LocalDateTime}} use JDK marshaller)
> type name, requested by {{{}typeId{}}}, is not cached correctly.
> For example, in this fragment, type name requested twice by thin-client
> (after each get request), but should be cached after the first request:
> {code:java}
> try (Ignite srv = Ignition.start(Config.getServerConfiguration())) {
> srv.cache(Config.DEFAULT_CACHE_NAME).put(1, LocalDateTime.now());
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER))) {
> client.cache(Config.DEFAULT_CACHE_NAME).get(1);
> client.cache(Config.DEFAULT_CACHE_NAME).get(1);
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15924) Java thin client: Type name is not cached on client side for OptimizerMarshaller types
[
https://issues.apache.org/jira/browse/IGNITE-15924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447242#comment-17447242
]
Nikolay Izhikov commented on IGNITE-15924:
--
Cherry-picked to 2.12.
> Java thin client: Type name is not cached on client side for
> OptimizerMarshaller types
> --
>
> Key: IGNITE-15924
> URL: https://issues.apache.org/jira/browse/IGNITE-15924
> Project: Ignite
> Issue Type: Bug
>Reporter: Alex Plehanov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For JDK marshaller types (for example {{LocalDateTime}} use JDK marshaller)
> type name, requested by {{{}typeId{}}}, is not cached correctly.
> For example, in this fragment, type name requested twice by thin-client
> (after each get request), but should be cached after the first request:
> {code:java}
> try (Ignite srv = Ignition.start(Config.getServerConfiguration())) {
> srv.cache(Config.DEFAULT_CACHE_NAME).put(1, LocalDateTime.now());
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses(Config.SERVER))) {
> client.cache(Config.DEFAULT_CACHE_NAME).get(1);
> client.cache(Config.DEFAULT_CACHE_NAME).get(1);
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15966) [Security] Node can hang with authentication enabled after user drop operation
Mikhail Petrov created IGNITE-15966:
---
Summary: [Security] Node can hang with authentication enabled
after user drop operation
Key: IGNITE-15966
URL: https://issues.apache.org/jira/browse/IGNITE-15966
Project: Ignite
Issue Type: Bug
Environment:
Reporter: Mikhail Petrov
Reproducer:
{code:java}
/** */
public class UserDropTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setAuthenticationEnabled(true);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setPersistenceEnabled(true)));
return cfg;
}
/** */
@Test
public void test() throws Exception {
startGrid(0);
startGrid(1);
grid(0).cluster().state(ClusterState.ACTIVE);
grid(0).createCache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
grid(0).context().security().createUser("cli", "pwd".toCharArray());
}
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
grid(0).context().security().dropUser("cli");
}
Map entries = new HashMap<>();
for (int i = 0; i < 1; i++)
entries.put(i, i);
cache.putAll(entries);
}
/** {@inheritDoc} */
@Override protected void beforeTest() throws Exception {
super.beforeTest();
cleanPersistenceDir();
}
}
{code}
Exception:
{code:java}
[2021-11-22
11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to
find security context for subject with given ID :
0898b227-30d5-3afc-9394-d8e4889ece4a]]
java.lang.IllegalStateException: Failed to find security context for subject
with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
at
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
{code}
The main problem is:
Implementation of authentication plugin ties security user with the subject ID
that is propagated through cluster nodes.
If some node receives operation initiated by the deleted user, it fails to
obtain security context via subject id since it was deleted and hangs with
mentioned above exception.
Here we are faced with a security implementation problem - we have no mechanism
to determine that a security subject is no longer needed and can be safely
removed and at the same time we throw unrecoverable exception in case security
subject is not found that kills system worker and hangs node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15966) [Security] Node can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15966:
Description:
Reproducer:
{code:java}
/** */
public class UserDropTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setAuthenticationEnabled(true);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setPersistenceEnabled(true)));
return cfg;
}
/** */
@Test
public void test() throws Exception {
startGrid(0);
startGrid(1);
grid(0).cluster().state(ClusterState.ACTIVE);
grid(0).createCache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
grid(0).context().security().createUser("cli", "pwd".toCharArray());
}
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
grid(0).context().security().dropUser("cli");
}
Map entries = new HashMap<>();
for (int i = 0; i < 1; i++)
entries.put(i, i);
cache.putAll(entries);
}
/** {@inheritDoc} */
@Override protected void beforeTest() throws Exception {
super.beforeTest();
cleanPersistenceDir();
}
}
{code}
Exception:
{code:java}
[2021-11-22
11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to
find security context for subject with given ID :
0898b227-30d5-3afc-9394-d8e4889ece4a]]
java.lang.IllegalStateException: Failed to find security context for subject
with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
at
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
{code}
The main problem is:
Implementation of authentication plugin ties security user with the subject ID
that is propagated through cluster nodes.
If some node receives operation initiated by the deleted user, it fails to
obtain security context via subject id since it was deleted and hangs with
mentioned above exception.
Here we are faced with a security implementation problem - we have no mechanism
to determine that a security subject is no longer needed and can be safely
removed and at the same time we throw unrecoverable exception in case security
subject is not found that kills system worker that hangs node.
was:
Reproducer:
{code:java}
/** */
public class UserDropTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setAuthenticationEnabled(true);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setPersistenceEnabled(true)));
return cfg;
}
/** */
@Test
public void test() throws Exception {
startGrid(0);
startGrid(1);
grid(0).cluster().state(ClusterState.ACTIVE);
grid(0).createCache(DEFAULT_CACHE_NAME);
try (AutoCloseab
[jira] [Updated] (IGNITE-15966) [Security] Node can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15966:
Description:
Reproducer:
{code:java}
/** */
public class UserDropTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setAuthenticationEnabled(true);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setPersistenceEnabled(true)));
return cfg;
}
/** */
@Test
public void test() throws Exception {
startGrid(0);
startGrid(1);
grid(0).cluster().state(ClusterState.ACTIVE);
grid(0).createCache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
grid(0).context().security().createUser("cli", "pwd".toCharArray());
}
IgniteClient client = Ignition.startClient(new
ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
grid(0).context().security().dropUser("cli");
}
Map entries = new HashMap<>();
for (int i = 0; i < 1; i++)
entries.put(i, i);
cache.putAll(entries);
}
/** {@inheritDoc} */
@Override protected void beforeTest() throws Exception {
super.beforeTest();
cleanPersistenceDir();
}
}
{code}
Exception:
{code:java}
[2021-11-22
11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed to
find security context for subject with given ID :
0898b227-30d5-3afc-9394-d8e4889ece4a]]
java.lang.IllegalStateException: Failed to find security context for subject
with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
at
org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at java.lang.Thread.run(Thread.java:748)
{code}
The main problem is:
Implementation of authentication plugin ties security user with the subject ID
that is propagated through cluster nodes.
If some node receives operation initiated by the deleted user, it fails to
obtain its security context via subject id and hangs with mentioned above
exception.
Here we are faced with a security implementation problem - we have no mechanism
to determine that a security subject is no longer needed and can be safely
removed and at the same time we throw unrecoverable exception in case security
subject is not found that kills system worker and hangs node.
was:
Reproducer:
{code:java}
/** */
public class UserDropTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setAuthenticationEnabled(true);
cfg.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new DataRegionConfiguration()
.setPersistenceEnabled(true)));
return cfg;
}
/** */
@Test
public void test() throws Exception {
startGrid(0);
startGrid(1);
grid(0).cluster().state(ClusterState.ACTIVE);
grid(0).createCache(DEFAULT_CACHE_NAME);
try (AutoCloseable ignored =
withS
[jira] [Updated] (IGNITE-15966) [Security] Nodes can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15966:
Summary: [Security] Nodes can hang with authentication enabled after user
drop operation (was: [Security] Node can hang with authentication enabled
after user drop operation)
> [Security] Nodes can hang with authentication enabled after user drop
> operation
> ---
>
> Key: IGNITE-15966
> URL: https://issues.apache.org/jira/browse/IGNITE-15966
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>
> Reproducer:
> {code:java}
> /** */
> public class UserDropTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid(0);
> startGrid(1);
> grid(0).cluster().state(ClusterState.ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser("cli",
> "pwd".toCharArray());
> }
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().dropUser("cli");
> }
> Map entries = new HashMap<>();
> for (int i = 0; i < 1; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> }
> {code}
> Exception:
> {code:java}
> [2021-11-22
> 11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID :
> 0898b227-30d5-3afc-9394-d8e4889ece4a]]
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The main problem is:
> Implementation of authentication plugin ties security user with the subject
> ID that is propagated through cluster nodes.
> If some node receives operation initiated by the deleted user, it fails to
> obtain its security context via subject id and hangs with mentioned above
> exception.
> Here we are faced with a security implementation problem - we have no
> mechanism to determine that a security subject is no longer needed and can be
> safely removed and at the same time we throw unrecoverable exception in case
> security subject is not found that kills system worker and hangs node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15953) Simultaneous atomic cache destroy and continuous cache operations may cause the cluster to hang.
[ https://issues.apache.org/jira/browse/IGNITE-15953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15953: Summary: Simultaneous atomic cache destroy and continuous cache operations may cause the cluster to hang. (was: Simultaneous cache destroy and implicit tx operations may cause the cluster to hang. ) > Simultaneous atomic cache destroy and continuous cache operations may cause > the cluster to hang. > - > > Key: IGNITE-15953 > URL: https://issues.apache.org/jira/browse/IGNITE-15953 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.11 >Reporter: Evgeny Stanilovsky >Priority: Major > Attachments: Test.java > > > Reproducer attached. > cache.put gets rwLock.readLock() here GridCacheGateway#enter and blocks on > active exchange, while exchange waits GridCacheGateway#onStopped > and can`t get rwLock.writeLock(). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15965) Cluster has not been started invariant is broken
[
https://issues.apache.org/jira/browse/IGNITE-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-15965:
Assignee: Aleksandr Polovtcev
> Cluster has not been started invariant is broken
>
>
> Key: IGNITE-15965
> URL: https://issues.apache.org/jira/browse/IGNITE-15965
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
>
> If [1] is called from a message handler just after the cluster start, it will
> trigger the assertion:
> {code:java}
> assert localMember != null : "Cluster has not been started";{code}
> This is possible because local member is assigned after a
> {_}cluster.startAwait(){_}, but messages start to process a bit earlier.
> Suggested fix - always delegate localMember() call to ClusterImpl.
> [1] org.apache.ignite.network.scalecube.ScaleCubeTopologyService#localMember
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15951) Node fails on startup if service is configured through IgniteConfiguration and Authentication is enabled
[
https://issues.apache.org/jira/browse/IGNITE-15951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15951:
-
Fix Version/s: 2.12
> Node fails on startup if service is configured through IgniteConfiguration
> and Authentication is enabled
> -
>
> Key: IGNITE-15951
> URL: https://issues.apache.org/jira/browse/IGNITE-15951
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.12
>
>
> Node fails on startup if service is configured through IgniteConfiguration
> and Authentication is enabled.
> Reproducer:
> {code:java}
> /** */
> public class ServiceAuthenticationTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> ServiceConfiguration srvcCfg = new ServiceConfiguration();
> srvcCfg.setMaxPerNodeCount(1);
> srvcCfg.setTotalCount(1);
> srvcCfg.setName("TestService");
> srvcCfg.setService(new TestService());
> cfg.setServiceConfiguration(srvcCfg);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid();
> }
> /** */
> public static class TestService implements Service {
> // No-op.
> }
> } {code}
> Exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.checkPermissions(IgniteServiceProcessor.java:633)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.prepareServiceConfigurations(IgniteServiceProcessor.java:593)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.staticallyConfiguredServices(IgniteServiceProcessor.java:1556)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.collectJoiningNodeData(IgniteServiceProcessor.java:361)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.collect(GridDiscoveryManager.java:1009)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.collectExchangeData(TcpDiscoverySpi.java:2143)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1107)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:474)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2210)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1091)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1953)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:629)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1252)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1169)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1145)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:823)
> at org.apache.ignite.test.TestClass.test(TestClass.java:54)
> 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.Framew
[jira] [Updated] (IGNITE-15966) [Security] Nodes can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15966:
-
Priority: Blocker (was: Major)
> [Security] Nodes can hang with authentication enabled after user drop
> operation
> ---
>
> Key: IGNITE-15966
> URL: https://issues.apache.org/jira/browse/IGNITE-15966
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Blocker
> Fix For: 2.12
>
>
> Reproducer:
> {code:java}
> /** */
> public class UserDropTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid(0);
> startGrid(1);
> grid(0).cluster().state(ClusterState.ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser("cli",
> "pwd".toCharArray());
> }
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().dropUser("cli");
> }
> Map entries = new HashMap<>();
> for (int i = 0; i < 1; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> }
> {code}
> Exception:
> {code:java}
> [2021-11-22
> 11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID :
> 0898b227-30d5-3afc-9394-d8e4889ece4a]]
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The main problem is:
> Implementation of authentication plugin ties security user with the subject
> ID that is propagated through cluster nodes.
> If some node receives operation initiated by the deleted user, it fails to
> obtain its security context via subject id and hangs with mentioned above
> exception.
> Here we are faced with a security implementation problem - we have no
> mechanism to determine that a security subject is no longer needed and can be
> safely removed and at the same time we throw unrecoverable exception in case
> security subject is not found that kills system worker and hangs node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15966) [Security] Nodes can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15966:
-
Fix Version/s: 2.12
> [Security] Nodes can hang with authentication enabled after user drop
> operation
> ---
>
> Key: IGNITE-15966
> URL: https://issues.apache.org/jira/browse/IGNITE-15966
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Fix For: 2.12
>
>
> Reproducer:
> {code:java}
> /** */
> public class UserDropTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid(0);
> startGrid(1);
> grid(0).cluster().state(ClusterState.ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser("cli",
> "pwd".toCharArray());
> }
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().dropUser("cli");
> }
> Map entries = new HashMap<>();
> for (int i = 0; i < 1; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> }
> {code}
> Exception:
> {code:java}
> [2021-11-22
> 11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID :
> 0898b227-30d5-3afc-9394-d8e4889ece4a]]
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The main problem is:
> Implementation of authentication plugin ties security user with the subject
> ID that is propagated through cluster nodes.
> If some node receives operation initiated by the deleted user, it fails to
> obtain its security context via subject id and hangs with mentioned above
> exception.
> Here we are faced with a security implementation problem - we have no
> mechanism to determine that a security subject is no longer needed and can be
> safely removed and at the same time we throw unrecoverable exception in case
> security subject is not found that kills system worker and hangs node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15951) Node fails on startup if service is configured through IgniteConfiguration and Authentication is enabled
[
https://issues.apache.org/jira/browse/IGNITE-15951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15951:
-
Priority: Blocker (was: Major)
> Node fails on startup if service is configured through IgniteConfiguration
> and Authentication is enabled
> -
>
> Key: IGNITE-15951
> URL: https://issues.apache.org/jira/browse/IGNITE-15951
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Blocker
> Fix For: 2.12
>
>
> Node fails on startup if service is configured through IgniteConfiguration
> and Authentication is enabled.
> Reproducer:
> {code:java}
> /** */
> public class ServiceAuthenticationTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> ServiceConfiguration srvcCfg = new ServiceConfiguration();
> srvcCfg.setMaxPerNodeCount(1);
> srvcCfg.setTotalCount(1);
> srvcCfg.setName("TestService");
> srvcCfg.setService(new TestService());
> cfg.setServiceConfiguration(srvcCfg);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid();
> }
> /** */
> public static class TestService implements Service {
> // No-op.
> }
> } {code}
> Exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.checkPermissions(IgniteServiceProcessor.java:633)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.prepareServiceConfigurations(IgniteServiceProcessor.java:593)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.staticallyConfiguredServices(IgniteServiceProcessor.java:1556)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.collectJoiningNodeData(IgniteServiceProcessor.java:361)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.collect(GridDiscoveryManager.java:1009)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.collectExchangeData(TcpDiscoverySpi.java:2143)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1107)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:474)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2210)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1091)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1953)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:629)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1252)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1169)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1145)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:823)
> at org.apache.ignite.test.TestClass.test(TestClass.java:54)
> 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.runner
[jira] [Updated] (IGNITE-15785) POJO validation against the schema.
[
https://issues.apache.org/jira/browse/IGNITE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15785:
--
Description:
Let's verify POJO class is compatible with the current schema.
* Mapper must bind all the key columns with the object fields, because missed
key-column may lead to error/data loss.
* Key and value columns must have different names, because otherwise these
columns can't be mapped to a Record class.
NB: Mapper result may not match the full schema for truncated objects.
{code:java}
class BillingDetails {
String owner;
}
class CreditCard extends BillingDetails {
long cardNumber;
int expYear;
int expMonth;
}
KeyValueView credCardKvView = table.keyValueView(Long.class,
CreditCard.class);
// Truncated view.
KeyValueView billingDetailsKVView =
table.keyValueView(Long.class, BillingDetails.class);
{code}
was:
Let's verify POJO class is compatible with the current schema.
NB: Mapper result may not match the full schema for truncated objects.
{code:java}
class BillingDetails {
String owner;
}
class CreditCard extends BillingDetails {
long cardNumber;
int expYear;
int expMonth;
}
KeyValueView credCardKvView = table.keyValueView(Long.class,
CreditCard.class);
// Truncated view.
KeyValueView billingDetailsKVView =
table.keyValueView(Long.class, BillingDetails.class);
{code}
> POJO validation against the schema.
> ---
>
> Key: IGNITE-15785
> URL: https://issues.apache.org/jira/browse/IGNITE-15785
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Alexander Belyak
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Let's verify POJO class is compatible with the current schema.
> * Mapper must bind all the key columns with the object fields, because missed
> key-column may lead to error/data loss.
> * Key and value columns must have different names, because otherwise these
> columns can't be mapped to a Record class.
> NB: Mapper result may not match the full schema for truncated objects.
> {code:java}
> class BillingDetails {
> String owner;
> }
> class CreditCard extends BillingDetails {
>long cardNumber;
>int expYear;
>int expMonth;
> }
> KeyValueView credCardKvView =
> table.keyValueView(Long.class, CreditCard.class);
>
> // Truncated view.
> KeyValueView billingDetailsKVView =
> table.keyValueView(Long.class, BillingDetails.class);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15951) Node fails on startup if service is configured through IgniteConfiguration and Authentication is enabled
[
https://issues.apache.org/jira/browse/IGNITE-15951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15951:
-
Labels: ise (was: )
> Node fails on startup if service is configured through IgniteConfiguration
> and Authentication is enabled
> -
>
> Key: IGNITE-15951
> URL: https://issues.apache.org/jira/browse/IGNITE-15951
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Blocker
> Labels: ise
> Fix For: 2.12
>
>
> Node fails on startup if service is configured through IgniteConfiguration
> and Authentication is enabled.
> Reproducer:
> {code:java}
> /** */
> public class ServiceAuthenticationTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> ServiceConfiguration srvcCfg = new ServiceConfiguration();
> srvcCfg.setMaxPerNodeCount(1);
> srvcCfg.setTotalCount(1);
> srvcCfg.setName("TestService");
> srvcCfg.setService(new TestService());
> cfg.setServiceConfiguration(srvcCfg);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid();
> }
> /** */
> public static class TestService implements Service {
> // No-op.
> }
> } {code}
> Exception:
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:232)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.checkPermissions(IgniteServiceProcessor.java:633)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.prepareServiceConfigurations(IgniteServiceProcessor.java:593)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.staticallyConfiguredServices(IgniteServiceProcessor.java:1556)
> at
> org.apache.ignite.internal.processors.service.IgniteServiceProcessor.collectJoiningNodeData(IgniteServiceProcessor.java:361)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$5.collect(GridDiscoveryManager.java:1009)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.collectExchangeData(TcpDiscoverySpi.java:2143)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1107)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:474)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2210)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1091)
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1953)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1300)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1798)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1720)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1159)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:629)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1252)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1169)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:1145)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:823)
> at org.apache.ignite.test.TestClass.test(TestClass.java:54)
> 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
>
[jira] [Updated] (IGNITE-15966) [Security] Nodes can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-15966:
-
Labels: ise (was: )
> [Security] Nodes can hang with authentication enabled after user drop
> operation
> ---
>
> Key: IGNITE-15966
> URL: https://issues.apache.org/jira/browse/IGNITE-15966
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Blocker
> Labels: ise
> Fix For: 2.12
>
>
> Reproducer:
> {code:java}
> /** */
> public class UserDropTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid(0);
> startGrid(1);
> grid(0).cluster().state(ClusterState.ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser("cli",
> "pwd".toCharArray());
> }
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().dropUser("cli");
> }
> Map entries = new HashMap<>();
> for (int i = 0; i < 1; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> }
> {code}
> Exception:
> {code:java}
> [2021-11-22
> 11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID :
> 0898b227-30d5-3afc-9394-d8e4889ece4a]]
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The main problem is:
> Implementation of authentication plugin ties security user with the subject
> ID that is propagated through cluster nodes.
> If some node receives operation initiated by the deleted user, it fails to
> obtain its security context via subject id and hangs with mentioned above
> exception.
> Here we are faced with a security implementation problem - we have no
> mechanism to determine that a security subject is no longer needed and can be
> safely removed and at the same time we throw unrecoverable exception in case
> security subject is not found that kills system worker and hangs node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15916) "Any" listeners do not get notified for subclass-specific keys in Polymorphic Configurations
[ https://issues.apache.org/jira/browse/IGNITE-15916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-15916: -- Assignee: Roman Puchkovskiy > "Any" listeners do not get notified for subclass-specific keys in Polymorphic > Configurations > > > Key: IGNITE-15916 > URL: https://issues.apache.org/jira/browse/IGNITE-15916 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Roman Puchkovskiy >Priority: Minor > Labels: ignite-3 > > Polymorphic configuration allows having multiple inheritors of a base schema. > There also exists a feature that allows to add listeners for changes to "any" > configuration keys. This is implemented using a dummy configuration inside > the generated classes, where all such listeners get registered. However, this > does not work for Polymorphic schemas, because there's no way to know the > full set of configuration keys in advance, since the actual type of a > Polymorphic configuration instance is not known at the start. This leads to a > limitation: changes to subclass-specific keys are not propagated to "any" > listeners. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15967) Copying the remote index from the snapshot if the node has the same partition distribution
Maxim Muzafarov created IGNITE-15967: Summary: Copying the remote index from the snapshot if the node has the same partition distribution Key: IGNITE-15967 URL: https://issues.apache.org/jira/browse/IGNITE-15967 Project: Ignite Issue Type: Improvement Affects Versions: 2.12 Reporter: Maxim Muzafarov Fix For: 2.13 During a snapshot restore procedure, the data (cache group partitions) is copied from a remote node to the local node according to affinity partition distribution on the local node. If a cache group has the distribution of the same partition as the snapshot on a remote node does it may be necessary to copy all the data right with the indexes (index partition) and avoid the index rebuild this way. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15967) Copying the remote index from the snapshot if the node has the same partition distribution
[ https://issues.apache.org/jira/browse/IGNITE-15967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-15967: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Copying the remote index from the snapshot if the node has the same partition > distribution > -- > > Key: IGNITE-15967 > URL: https://issues.apache.org/jira/browse/IGNITE-15967 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.12 >Reporter: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.13 > > > During a snapshot restore procedure, the data (cache group partitions) is > copied from a remote node to the local node according to affinity partition > distribution on the local node. If a cache group has the distribution of the > same partition as the snapshot on a remote node does it may be necessary to > copy all the data right with the indexes (index partition) and avoid the > index rebuild this way. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15897) ServiceLoader integration into configuration
[
https://issues.apache.org/jira/browse/IGNITE-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-15897:
---
Summary: ServiceLoader integration into configuration (was: [Ignite 3]
ServiceLoader integration into configuration)
> ServiceLoader integration into configuration
>
>
> Key: IGNITE-15897
> URL: https://issues.apache.org/jira/browse/IGNITE-15897
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha3
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In order to decouple modules and provide more flexibility, it would be
> helpful to provide certain extension points using standard ServiceLoader Java
> API.
> For example, currently there's an explicit list of configuration roots,
> extensions, validators, etc. in {{org.apache.ignite.internal.app.IgniteImpl}}
> code. This can become a mess and is not extensible.
> New service interface should provide following objects:
> * collection of configuration roots;
> * collection of validators;
> * collection of internal extensions;
> * collection of polymorphic extensions.
> That's probably enough.
> There should be a piece of code in {{runner}} module or somewhere else that
> aggregates this information from all available service loader of given
> interface. Aggregated information can then be used to initialize
> {{{}ConfigurationManager{}}}.
> Local and Distributed roots/extensions should be provided in different
> instances, it's much easier this way for individual developers who will
> implement these services.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15950) Ability to hide sensitive argument for external tools
[
https://issues.apache.org/jira/browse/IGNITE-15950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15950:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Ability to hide sensitive argument for external tools
> -
>
> Key: IGNITE-15950
> URL: https://issues.apache.org/jira/browse/IGNITE-15950
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.9.1
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now days, we have the static method
> {code:java}
> CommonArgParser.isSensitiveArgument(arg); {code}
> that checks sensitivity of an argument, but we can't extend this list
> outside.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15950) Ability to hide sensitive argument for external tools
[
https://issues.apache.org/jira/browse/IGNITE-15950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15950:
-
Reviewer: Vyacheslav Koptilin
> Ability to hide sensitive argument for external tools
> -
>
> Key: IGNITE-15950
> URL: https://issues.apache.org/jira/browse/IGNITE-15950
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh
>Affects Versions: 2.9.1
>Reporter: Stepachev Maksim
>Assignee: Stepachev Maksim
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now days, we have the static method
> {code:java}
> CommonArgParser.isSensitiveArgument(arg); {code}
> that checks sensitivity of an argument, but we can't extend this list
> outside.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15968) Index de-fragmentation fails on DECIMAL and VARCHAR columns
Semyon Danilov created IGNITE-15968:
---
Summary: 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
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] [Created] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
Ilya Shishkov created IGNITE-15969:
--
Summary: Enabling authentication requires the client node to
enable persistence in the configuration
Key: IGNITE-15969
URL: https://issues.apache.org/jira/browse/IGNITE-15969
Project: Ignite
Issue Type: Bug
Affects Versions: 2.11
Reporter: Ilya Shishkov
Assignee: Ilya Shishkov
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:150)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Links:
https://ignite.apache.org/docs/latest/security/authentication
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Description:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Links:
https://ignite.apache.org/docs/latest/security/authentication
was:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:150)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Links:
https://ignite.apache.org/docs/latest/security/authentication
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without pesistence client node would fail during start up
> with below error:
> {code}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Links:
> https://ignite.apache.org/docs/latest/security/authentication
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Attachment: ClientNodeAuthFailureReproducer.patch
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without pesistence client node would fail during start up
> with below error:
> {code}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Links:
> https://ignite.apache.org/docs/latest/security/authentication
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Description:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
Links:
https://ignite.apache.org/docs/latest/security/authentication
was:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Links:
https://ignite.apache.org/docs/latest/security/authentication
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without pesistence client node would fail during start up
> with below error:
> {code}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> Links:
> https://ignite.apache.org/docs/latest/security/authentication
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Description:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
Links:
https://ignite.apache.org/docs/latest/security/authentication
was:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
Links:
https://ignite.apache.org/docs/latest/security/authentication
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without pesistence client node would fail during start up
> with below error:
> {code}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> Links:
> https://ignite.apache.org/docs/latest/security/authentication
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Description:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code:java}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
It seems that here [2] we should add check whether starting node is client or
not:
{code:java}
/** Starts processor. */
public void startProcessor() throws IgniteCheckedException {
if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
client node fails
throw new IgniteCheckedException("Authentication can be enabled
only for cluster with enabled persistence."
+ " Check the DataRegionConfiguration");
}
{code}
Links:
# [https://ignite.apache.org/docs/latest/security/authentication]
#
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165
was:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
Links:
https://ignite.apache.org/docs/latest/security/authentication
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without pesistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$Ignit
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Description:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without persistence client node would fail during start up
with below error:
{code:java}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
It seems that here [2] we should add check whether starting node is client or
not:
{code:java}
/** Starts processor. */
public void startProcessor() throws IgniteCheckedException {
if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
client node fails
throw new IgniteCheckedException("Authentication can be enabled
only for cluster with enabled persistence."
+ " Check the DataRegionConfiguration");
}
{code}
Links:
# [https://ignite.apache.org/docs/latest/security/authentication]
#
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
was:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without pesistence client node would fail during start up with
below error:
{code:java}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
It seems that here [2] we should add check whether starting node is client or
not:
{code:java}
/** Starts processor. */
public void startProcessor() throws IgniteCheckedException {
if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
client node fails
throw new IgniteCheckedException("Authentication can be enabled
only for cluster with enabled persistence."
+ " Check the DataRegionConfiguration");
}
{code}
Links:
# [https://ignite.apache.org/docs/latest/security/authentication]
#
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> per
[jira] [Commented] (IGNITE-15965) Cluster has not been started invariant is broken
[
https://issues.apache.org/jira/browse/IGNITE-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447379#comment-17447379
]
Semyon Danilov commented on IGNITE-15965:
-
Looks good to me!
> Cluster has not been started invariant is broken
>
>
> Key: IGNITE-15965
> URL: https://issues.apache.org/jira/browse/IGNITE-15965
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If [1] is called from a message handler just after the cluster start, it will
> trigger the assertion:
> {code:java}
> assert localMember != null : "Cluster has not been started";{code}
> This is possible because local member is assigned after a
> {_}cluster.startAwait(){_}, but messages start to process a bit earlier.
> Suggested fix - always delegate localMember() call to ClusterImpl.
> [1] org.apache.ignite.network.scalecube.ScaleCubeTopologyService#localMember
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15838) Integrate plugin system in current SQL engine
[ https://issues.apache.org/jira/browse/IGNITE-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-15838: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Integrate plugin system in current SQL engine > - > > Key: IGNITE-15838 > URL: https://issues.apache.org/jira/browse/IGNITE-15838 > Project: Ignite > Issue Type: Sub-task >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > Need to connect the plugin system and the current SQL engine together. > The aspects should be covered: > # Implement gateway node > # Handle for the node should be added to RelImplementor, FragmentMapping and > other visitors > # Rules provided by plugin should be injected into the planner > # Implement SchemaUpdateListener -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15733) Eventually failure of baseline registration.
[ https://issues.apache.org/jira/browse/IGNITE-15733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447391#comment-17447391 ] Evgeny Stanilovsky commented on IGNITE-15733: - [~ibessonov] can u help with additional review here ? thanks ! > Eventually failure of baseline registration. > > > Key: IGNITE-15733 > URL: https://issues.apache.org/jira/browse/IGNITE-15733 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.11 >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Attachments: _Community_Edition_Cache_9_18998_cut.log > > Time Spent: 1h 40m > Remaining Estimate: 0h > > All info can be found in attached log: > briefly: Cluster of 2 nodes with persistence, sequentially start nodes, > activate, stop nodes using org.apache.ignite.Ignite#close, start nodes, > activate: > expected : > 1 node : Cluster ID and tag has been read from metastorage: null > 2 node : Cluster ID and tag has been read from metastorage: null > stop > start > 1 node: Cluster ID and tag has been read from metastorage: ClusterIdAndTag > [id=some_id, tag=some_tag] > 2 node: Cluster ID and tag has been read from metastorage: ClusterIdAndTag > [id=some_id, tag=some_tag] > but obtained (check attach) > > 1 node : Cluster ID and tag has been read from metastorage: null > 2 node : Cluster ID and tag has been read from metastorage: null > stop > start > 1 node: Cluster ID and tag has been read from metastorage: null > 2 node: Cluster ID and tag has been read from metastorage: ClusterIdAndTag > [id=some_id, tag=some_tag] > and as a result : > _Joining node has conflicting distributed metastorage data_ > [^_Community_Edition_Cache_9_18998_cut.log] > this test MetricsConfigurationTest.testNodeRestart [1] is flaky > [1][https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache9/6220901?buildTab=tests&name=MetricsConfigurationTes&view=tests&status=passed&suite=org.apache.ignite.testsuites.IgniteCacheTestSuite9%3A+&package=org.apache.ignite.internal.metric&expandedTest=build%3A%28id%3A6220901%29%2Cid%3A576406] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14541) Calcite engine. HAVING fails on scalar
[
https://issues.apache.org/jira/browse/IGNITE-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-14541:
---
Priority: Minor (was: Major)
> Calcite engine. HAVING fails on scalar
> ---
>
> Key: IGNITE-14541
> URL: https://issues.apache.org/jira/browse/IGNITE-14541
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Konstantin Orlov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
>
> Query to reproduce:
> {{SELECT 42 HAVING 42 > 20}}
> Test: {{aggregate/having/test_scalar_having.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-15970) Lack of Azure credentials for TcpDiscoveryAzureBlobStoreIpFinderSelfTest to pass
Maxim Muzafarov created IGNITE-15970:
Summary: Lack of Azure credentials for
TcpDiscoveryAzureBlobStoreIpFinderSelfTest to pass
Key: IGNITE-15970
URL: https://issues.apache.org/jira/browse/IGNITE-15970
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Currently the TcpDiscoveryAzureBlobStoreIpFinderSelfTest is used to test the
{{TcpDiscoveryAzureBlobStoreIpFinder}}. However, some credentials still
available for this test to become `green`:
{code}
test.azure.account.name
test.azure.account.key
test.azure.endpoint
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15004) Calcite engine. LIKE ESCAPE fails with empty escape string
[
https://issues.apache.org/jira/browse/IGNITE-15004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15004:
---
Priority: Minor (was: Major)
> Calcite engine. LIKE ESCAPE fails with empty escape string
> --
>
> Key: IGNITE-15004
> URL: https://issues.apache.org/jira/browse/IGNITE-15004
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Priority: Minor
>
> {{SELECT '%_' LIKE '%_' ESCAPE ''}}
> error:
> {code}
> class org.apache.ignite.IgniteException: Unexpected exception
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:244)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.RuntimeException: Invalid escape character ''
> at org.apache.calcite.runtime.Like.invalidEscapeCharacter(Like.java:104)
> at org.apache.calcite.runtime.Like.sqlToRegexLike(Like.java:56)
> at org.apache.calcite.runtime.SqlFunctions.like(SqlFunctions.java:594)
> at SC.execute(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ProjectNode.push(ProjectNode.java:63)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:239)
> ... 4 more
> {code}
> Test:
> {{function/string/test_like_escape.test}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14539) Calcite engine. Support DISTINCT ON expression
[
https://issues.apache.org/jira/browse/IGNITE-14539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-14539:
---
Priority: Minor (was: Major)
> Calcite engine. Support DISTINCT ON expression
> --
>
> Key: IGNITE-14539
> URL: https://issues.apache.org/jira/browse/IGNITE-14539
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
>
> Now DISTINCT ON expression isn't supported.
> e.g.:
> {{SELECT DISTINCT ON (lastName) firstName, lastName FROM Person WHERE ...}}
> Test:
> {{aggregate/distinct/test_distinct_on.test_ignored}}
> {{modules/calcite/src/test/sql/types/string/test_unicode.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15075) Calcite. TRIM function doesn't support multicharacter trim
[
https://issues.apache.org/jira/browse/IGNITE-15075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15075:
---
Priority: Minor (was: Major)
> Calcite. TRIM function doesn't support multicharacter trim
> ---
>
> Key: IGNITE-15075
> URL: https://issues.apache.org/jira/browse/IGNITE-15075
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Minor
> Labels: calcite2-required, calcite3-required
>
> Most databases support syntaxis with a few characters for trimming, like a
> {code:sql}
> SELECT trim(both '123' from '123PostgreSQL123');
> {code}
> Currently, we support only a single character for trimming. Will be good to
> support it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15916) "Any" listeners do not get notified for subclass-specific keys in Polymorphic Configurations
[ https://issues.apache.org/jira/browse/IGNITE-15916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-15916: -- Assignee: (was: Roman Puchkovskiy) > "Any" listeners do not get notified for subclass-specific keys in Polymorphic > Configurations > > > Key: IGNITE-15916 > URL: https://issues.apache.org/jira/browse/IGNITE-15916 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Priority: Minor > Labels: ignite-3 > > Polymorphic configuration allows having multiple inheritors of a base schema. > There also exists a feature that allows to add listeners for changes to "any" > configuration keys. This is implemented using a dummy configuration inside > the generated classes, where all such listeners get registered. However, this > does not work for Polymorphic schemas, because there's no way to know the > full set of configuration keys in advance, since the actual type of a > Polymorphic configuration instance is not known at the start. This leads to a > limitation: changes to subclass-specific keys are not propagated to "any" > listeners. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15971) Fix problems with dynamic configuration
Roman Puchkovskiy created IGNITE-15971: -- Summary: Fix problems with dynamic configuration Key: IGNITE-15971 URL: https://issues.apache.org/jira/browse/IGNITE-15971 Project: Ignite Issue Type: Bug Components: general Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy The following problems were found with dynamic configuration. If configuration schema class name does not end with 'ConfigurationSchema' suffix, configuration annotation processor fails a build like this: [ERROR] Failed to process configuration: org.apache.ignite.internal.configuration.processor.ProcessorException: Failed to generate class org.apache.ignite.internal.configuration.notifications.StringPolyVariant [ERROR] at org.apache.ignite.internal.configuration.processor.Processor.buildClass(Processor.java:485) [ERROR] at org.apache.ignite.internal.configuration.processor.Processor.createPojoBindings(Processor.java:475) [ERROR] at org.apache.ignite.internal.configuration.processor.Processor.process0(Processor.java:209) [ERROR] at org.apache.ignite.internal.configuration.processor.Processor.process(Processor.java:103) [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:980) [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:896) [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1222) [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1335) [ERROR] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1258) [ERROR] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:936) [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104) [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147) [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100) [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94) [ERROR] at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) [ERROR] at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174) [ERROR] at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1134) [ERROR] at org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:180) [ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) [ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) [ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) [ERROR] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) [ERROR] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:972) [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293) [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:196) [ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:566) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406) [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347) [ERROR]
[jira] [Commented] (IGNITE-15348) Checkstyle should check whitespace after cast token.
[ https://issues.apache.org/jira/browse/IGNITE-15348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447442#comment-17447442 ] Maksim Timonin commented on IGNITE-15348: - Hi [~andydem] ! There are merge conflicts in your patch, could you please resolve them? > Checkstyle should check whitespace after cast token. > - > > Key: IGNITE-15348 > URL: https://issues.apache.org/jira/browse/IGNITE-15348 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Andrei Demidov >Priority: Major > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > According to Ignite code style [1] there shouldn't a whitespace after the > ")" token. Let's add check for that. > > Solution is add the TYPECAST token to the NoWhitespaceAfter module > > > > > Also it is required to fix all issues within repo. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447457#comment-17447457
]
Vyacheslav Koptilin commented on IGNITE-15666:
--
Hell [~NSAmelchev], [~PetrovMikhail],
It seems to me, this fix is arguable and contradicts the specification JCache
API.
In accordance with specification *12.4. Statistics Effects of Cache Operations*
the `remove(K key)` method should update statistics _if the method returns
true._ Yep, it explicitly mentions the "Number of Removals", however, I think
the average time is assumed as well.
Let's consider the following situation:
- cache.put(key, value);// removals = 0, averageTime = 0
- cache.remove(key);// removals = 1, averageTime = 100ms
- cache.remove(notExistingKey1); // removals = 1, averageTime = 200ms (in your
pull-request, this metric is always updated)
- cache.remove(notExistingKey1); // removals = 1, averageTime = 300ms
(---//---)
In my understanding, this behavior does not seem correct.
Yes, I see that your pull request passed the TCK (as the previous version of
code as well), however, it speaks about the quality of the TCK itself :)
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15348) Checkstyle should check whitespace after cast token.
[ https://issues.apache.org/jira/browse/IGNITE-15348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447459#comment-17447459 ] Andrei Demidov commented on IGNITE-15348: - Hi, [~timonin.maksim]! Resolved, waiting for TravisCI check. > Checkstyle should check whitespace after cast token. > - > > Key: IGNITE-15348 > URL: https://issues.apache.org/jira/browse/IGNITE-15348 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Andrei Demidov >Priority: Major > Labels: newbie > Time Spent: 10m > Remaining Estimate: 0h > > According to Ignite code style [1] there shouldn't a whitespace after the > ")" token. Let's add check for that. > > Solution is add the TYPECAST token to the NoWhitespaceAfter module > > > > > Also it is required to fix all issues within repo. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-Whitespacesandemptylines -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17447471#comment-17447471
]
Ignite TC Bot commented on IGNITE-15964:
{panel:title=Branch: [pull/9579/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9579/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6282181]]
* {color:#013220}IgnitePdsTestSuite:
IgnitePdsDestroyCacheTest.cacheDestroyWithConcImplicitTx - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6282203&buildTypeId=IgniteTests24Java8_RunAll]
> 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
> Attachments: Test.java
>
> Time Spent: 10m
> 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.GridFutur
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17447473#comment-17447473
]
Evgeny Stanilovsky commented on IGNITE-15964:
-
[~v.pyatkov] [~sk0x50] guys can you make a review plz ?
> 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
> Attachments: Test.java
>
> Time Spent: 10m
> 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
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFu
[jira] [Commented] (IGNITE-15960) Ignite#getOrCreateNearCache appears to be broken?
[
https://issues.apache.org/jira/browse/IGNITE-15960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447483#comment-17447483
]
Pavel Tupitsyn commented on IGNITE-15960:
-
* getOrCreateNearCache starts a near cache on a client node. It starts a near
cache only on that specific client node. It does not work on server nodes.
* CacheConfiguration.NearConfiguration property defines a near cache on the
server side. It starts on all server nodes. Once started, it cannot be changed
or removed.
We should at least document this better, both in Javadoc and on the website.
I'm not sure how to improve this API.
> Ignite#getOrCreateNearCache appears to be broken?
> -
>
> Key: IGNITE-15960
> URL: https://issues.apache.org/jira/browse/IGNITE-15960
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Priority: Minor
>
> I have my Ignite server running a connect a thick-client running some code.
> If I don't create any caches in advance and run this code:
> {{client.getOrCreateNearCache(CACHE_NAME, new NearCacheConfiguration Integer>()}}
> {{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>()));}}
> The error I get is:
> {{Failed to start client cache (a cache with the given name is not started)}}
> Okay, so I create my cache in advance:
> {{client.getOrCreateCache(CACHE_NAME);}}
> {{client.getOrCreateNearCache(CACHE_NAME, new NearCacheConfiguration Integer>()}}
> {{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>()));}}
> This time I get the following error:
> {{Failed to start near cache (a cache with the same name without near cache
> is already started)}}
> Okay, so I'll create a cache with a near cache:
> {{client.getOrCreateCache(new CacheConfiguration<>()}}
> {{.setName(CACHE_NAME)}}
> {{.setNearConfiguration(new NearCacheConfiguration()}}
> {{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>(;}}
> {{client.getOrCreateNearCache(CACHE_NAME, new NearCacheConfiguration Integer>()}}
> {{.setNearEvictionPolicyFactory(new LruEvictionPolicyFactory<>()));}}
> Still the same error:
> {{Failed to start near cache (a cache with the same name without near cache
> is already started)}}
> So however the cache is created or configured, it appears not to work.
> One possibility is that it's only supposed to work on a server where the near
> cache already exists. If so, this is not mentioned anywhere in the
> documentation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447487#comment-17447487
]
Amelchev Nikita commented on IGNITE-15666:
--
Hello, [~slava.koptilin].
This metric is about the time of "API call on the initiator", but not remove
time on affinity node.
The {{removals}} metric is updated on an affinity node. There is no metric to
calculate remove time on affinity node now (it should be updated as well as
{{removals}}, as you pointed it).
We can't calculate the average time and this is the known issue
([IGNITE-3495|https://issues.apache.org/jira/browse/IGNITE-3495]).
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-12194) [Phase-2] Calculate expected rebalancing cache group keys
[ https://issues.apache.org/jira/browse/IGNITE-12194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12194: - Fix Version/s: 2.13 (was: 2.12) > [Phase-2] Calculate expected rebalancing cache group keys > - > > Key: IGNITE-12194 > URL: https://issues.apache.org/jira/browse/IGNITE-12194 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Assignee: Nikolai Kulagin >Priority: Critical > Labels: IEP-35 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to implement expected to be rebalanced cache group keys and total > bytes. Currently, 'estimatedKeysCount' cache metric returns '-1' for some of > the cases (see comments IGNITE-11330). > * rebalancingExpectedKeys long metric > * rebalancingExpectedBytes long metric > * rebalancingEvictedPartitionsLeft long metric -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12852: - Fix Version/s: 2.13 (was: 2.12) > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.13 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14922) IGNITE-14922 Change protocol from HTTP to HTTPS in url: http://ignite.apache.org
[
https://issues.apache.org/jira/browse/IGNITE-14922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14922:
-
Fix Version/s: 2.13
(was: 2.12)
> IGNITE-14922 Change protocol from HTTP to HTTPS in url:
> http://ignite.apache.org
>
>
> Key: IGNITE-14922
> URL: https://issues.apache.org/jira/browse/IGNITE-14922
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.11
>Reporter: Victor Alen'kov
>Priority: Trivial
> Labels: maven
> Fix For: 2.13
>
>
> Currently Maven configuration uses an insecure protocol:
>
> {code:xml}
>
> http://ignite.apache.org
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15862) Fix kubernetes ConfigMap docs on site
[ https://issues.apache.org/jira/browse/IGNITE-15862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15862: - Fix Version/s: 2.13 (was: 2.10) (was: 2.11) (was: 2.12) > Fix kubernetes ConfigMap docs on site > - > > Key: IGNITE-15862 > URL: https://issues.apache.org/jira/browse/IGNITE-15862 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Fix For: 2.13 > > Time Spent: 50m > Remaining Estimate: 0h > > There is an error in the configuration file on the site > node-configuration.xml for ConfigMap in the installation instructions in > kybernetes: > > > although if you follow the instructions, the following values should be > namespace =ignite and serviceName=ignite-service > https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14750:
-
Fix Version/s: 2.13
(was: 2.12)
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
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:
-
Fix Version/s: 2.13
(was: 2.12)
> 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: 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:
> {noformat}
> start time
> partitions (processed/total)
> bytes (processed/total)
> end time
> {noformat}
>
> Suggested status command output.
> [in progress]
> {noformat}
> Restore operation for snapshot "snapshot_25052021" is still in progress
> (requestId=0e2d8c06-d44a-4ade-91bf-2b84b367499a).
> Progress: 100% completed (66/66 partitions, 3.8/3.8 MB)
> Started: 2021-10-05 15:47:47.942
> Cache groups: default
> Node test1: 100% completed (33/33 partitions, 1.9/1.9 MB)
> Node test0: 100% completed (33/33 partitions, 1.9/1.9 MB)
> {noformat}
> [error]
> {noformat}
> Restore operation for snapshot "snapshot_25052021" failed
> (requestId=b9b312f5-ba34-40e9-bb94-35daacd552c0).
> Error: Operation has been canceled by the user.
> Started: 2021-10-05 15:51:52.255
> Finished: 2021-10-05 15:51:52.782
> Cache groups: default
> Node test1: 100% completed (33/33 partitions, 1.9/1.9 MB)
> Node test0: 100% completed (33/33 partitions, 1.9/1.9 MB){noformat}
> [finished]
> {noformat}
> Restore operation for snapshot "snapshot_25052021" completed successfully
> (requestId=6adeea86-1ee2-4664-8d7d-3383a484a00a).
> Progress: 100% completed (66/66 partitions, 3.8/3.8 MB)
> Started: 2021-10-05 15:53:03.352
> Finished: 2021-10-05 15:53:03.443
> Cache groups: default
> Node test1: 100% completed (33/33 partitions, 1.9/1.9 MB)
> Node test0: 100% completed (33/33 partitions, 1.9/1.9 MB){noformat}
> [missing snapshot name]
> {noformat}
> No information about restoring snapshot "snapshot_MISSING" is
> available.{noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14459) Affinity call may fail if called upon merged exchanges
[
https://issues.apache.org/jira/browse/IGNITE-14459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14459:
-
Fix Version/s: 2.13
(was: 2.12)
> Affinity call may fail if called upon merged exchanges
> --
>
> Key: IGNITE-14459
> URL: https://issues.apache.org/jira/browse/IGNITE-14459
> Project: Ignite
> Issue Type: Improvement
> Components: compute
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When exchanges are merged, intermediate affinity assignments are not filled.
> At the same time, when a client chooses topology to run affinity call on, it
> may take a non-completed exchange version. As a result, when the affinity
> fetch task arrives on a node, it will look up a non-existing assignment,
> resulting in "Getting affinity for topology version earlier than affinity is
> calculated" exception.
> {{CacheAffinityCallSelfTest.testAffinityCallNoServerNode}} is flaky because
> of this bug.
> The following test case for {{CacheAffinityCallSelfTest}} demonstrates the
> issue:
> {code}
> /**
> * @throws Exception if failed.
> */
> @Test
> public void testAffinityCallMergedExchanges() throws Exception {
> startGrids(SRVS);
> final Integer key = 1;
> final IgniteEx client = startClientGrid(SRVS);
> assertTrue(client.configuration().isClientMode());
> assertNull(client.context().cache().cache(CACHE_NAME));
> try {
>
> grid(0).context().cache().context().exchange().mergeExchangesTestWaitVersion(
> new AffinityTopologyVersion(SRVS + 3, 0),
> null
> );
> IgniteInternalFuture fut1 = GridTestUtils.runAsync(()
> -> startGrid(SRVS + 1));
> assertTrue(GridTestUtils.waitForCondition(() ->
> client.context().cache().context()
> .exchange().lastTopologyFuture()
> .initialVersion().equals(new AffinityTopologyVersion(SRVS +
> 2, 0)), 5_000));
> assertFalse(fut1.isDone());
> // The future should not complete until second node is started.
> IgniteInternalFuture fut2 = GridTestUtils.runAsync(() ->
> client.compute().affinityCall(CACHE_NAME, key, new
> CheckCallable(key, null)));
> startGrid(SRVS + 2);
> fut1.get();
> fut2.get();
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15147) Possible leak in metrics in PageLockTracker
[
https://issues.apache.org/jira/browse/IGNITE-15147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15147:
-
Fix Version/s: 2.13
(was: 2.12)
> Possible leak in metrics in PageLockTracker
> ---
>
> Key: IGNITE-15147
> URL: https://issues.apache.org/jira/browse/IGNITE-15147
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.10
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.13
>
>
> In one of PageHandler#readPage methods there is the following code:
> {code:java}
> long pageAddr = readLock(pageMem, cacheId, pageId, page, lsnr);
> if (pageAddr == 0L)
> return lockFailed;
> try {
> PageIO io = pageIoRslvr.resolve(pageAddr);
> return h.run(cacheId, pageId, page, pageAddr, io, null, arg, intArg,
> statHolder);
> }
> finally {
> readUnlock(pageMem, cacheId, pageId, page, pageAddr, lsnr);
> }
> {code}
> Here we obtain a read lock on a page by calling {{readLock}} method, its
> implementation is as following:
> {code:java}
> lsnr.onBeforeReadLock(cacheId, pageId, page);
> long pageAddr = pageMem.readLock(cacheId, pageId, page);
> lsnr.onReadLock(cacheId, pageId, page, pageAddr);
> return pageAddr;
> {code}
> And here is a problem: in {{readLock}} we always call {{onReadLock}} for the
> page but {{onReadUnlock}} is called *only if lock was acquired successfully*.
> Otherwise lock counters end up in incorrect state: {{onReadLock}} called
> although no lock was actually acqured.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-13578) Update ignite-kafka dependencies to get rid of reported CVEs
[ https://issues.apache.org/jira/browse/IGNITE-13578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-13578: - Fix Version/s: 2.13 (was: 2.12) > Update ignite-kafka dependencies to get rid of reported CVEs > > > Key: IGNITE-13578 > URL: https://issues.apache.org/jira/browse/IGNITE-13578 > Project: Ignite > Issue Type: Bug > Components: integrations >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > The libraries to update: > connect-api-2.1.1.jar > kafka-clients-2.1.1.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15268) Maintenance mode log messages need to be more informative
[
https://issues.apache.org/jira/browse/IGNITE-15268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15268:
-
Fix Version/s: 2.13
(was: 2.12)
> Maintenance mode log messages need to be more informative
> -
>
> Key: IGNITE-15268
> URL: https://issues.apache.org/jira/browse/IGNITE-15268
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.13
>
>
> When a node enters maintenance mode (for any reason), only basic information
> is printed to the logs:
> {code:java}
> [INFO] Node requires maintenance, non-empty set of maintenance tasks is
> found: [corrupted-cache-data-files-task]
> {code}
> It would be better for end-user to provide a link to some documentation about
> maintenance mode or some help for the particular maintenance situation.
> Right now users may be confused what to do next and how to make Ignite node
> leave maintenance mode and restore normal operations.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15537) PersistenceBasicCompatibilityTest must be updated to use previous releases
[ https://issues.apache.org/jira/browse/IGNITE-15537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15537: - Fix Version/s: 2.13 (was: 2.12) > PersistenceBasicCompatibilityTest must be updated to use previous releases > -- > > Key: IGNITE-15537 > URL: https://issues.apache.org/jira/browse/IGNITE-15537 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Add the 2.9.1, 2.10.0, 2.11.0 versions to the > PersistenceBasicCompatibilityTest test. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14966) Java thin: ClientFieldsQueryCursor fails to return columns before the first row gets accessed
[ https://issues.apache.org/jira/browse/IGNITE-14966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14966: - Fix Version/s: 2.13 (was: 2.12) > Java thin: ClientFieldsQueryCursor fails to return columns before the first > row gets accessed > - > > Key: IGNITE-14966 > URL: https://issues.apache.org/jira/browse/IGNITE-14966 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.10 >Reporter: Ivan Fedorenkov >Priority: Major > Fix For: 2.13 > > > When user issues a SQL query using the IgniteClient instance and wants to > access the resulting list of columns as well as their total count he gets > nothing and zero before the first row gets accessed. This behavior is > incompatible with "fat" client nodes and server nodes that get this > information right away. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14266) System views for page statistics must include the buckets sizes
[ https://issues.apache.org/jira/browse/IGNITE-14266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14266: - Fix Version/s: 2.13 (was: 2.12) > System views for page statistics must include the buckets sizes > --- > > Key: IGNITE-14266 > URL: https://issues.apache.org/jira/browse/IGNITE-14266 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > > Affected system views: CACHE_GROUP_PAGE_LISTS, DATA_REGION_PAGE_LISTS > The bucket index corresponds to the interval of free space on pages it > contains. We must add this info to the system views. > [1] > https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#page_lists -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13726) Add an ability to view count of hot and cold pages in page memory
[ https://issues.apache.org/jira/browse/IGNITE-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-13726: - Fix Version/s: 2.13 (was: 2.12) > Add an ability to view count of hot and cold pages in page memory > - > > Key: IGNITE-13726 > URL: https://issues.apache.org/jira/browse/IGNITE-13726 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, iep-62 > Fix For: 2.13 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, we can't determine how many hot (touched recently) and cold pages > we have in the page-memory. This information can be helpful for data region > size tuning and can show the effectiveness of the page replacement algorithm. > Such information can be represented as a histogram showing the count of pages > last touched in each time interval. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.
[
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13348:
-
Fix Version/s: 2.13
(was: 2.12)
> Creating IgniteAtomicLong from the client node may hang.
>
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.13
>
> Attachments: DataStructuresInitializationTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when
> a client node connects to a cluster that changes its own state (state
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
> msg) {
> DiscoveryDataClusterState discoClusterState = globalState;
> if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
> ...
> TransitionOnJoinWaitFuture joinFut = this.joinFut;
> if (joinFut != null)
> joinFut.onDone(false);
> ...
> }
> else
> U.warn(log, "Received state finish message with unexpected ID: "
> + msg);
> }
> {code}
> On the other hand, this value is used to determine the state of the cluster
> when a new node joins the cluster
> {code:java|title=IgniteKernal.java}
> public void start(
> DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
> IgniteInternalFuture transitionWaitFut =
> joinData.transitionWaitFuture();
> ...
> boolean active;
> if (transitionWaitFut != null) {
> if (log.isInfoEnabled()) {
> log.info("Join cluster while cluster state transition is
> in progress, waiting when transition finish.");
> }
> active = transitionWaitFut.get();
> }
> else
> active = joinData.active();
> startTimer.finishGlobalStage("Await transition");
> ...
> }
> {code}
> User list discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-node-hangs-while-IgniteAtomicLong-is-created-tp33537.html
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15318) Cache (Restarts) 1 still flaky
[ https://issues.apache.org/jira/browse/IGNITE-15318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15318: - Fix Version/s: 2.13 (was: 2.12) > Cache (Restarts) 1 still flaky > -- > > Key: IGNITE-15318 > URL: https://issues.apache.org/jira/browse/IGNITE-15318 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Priority: Major > Fix For: 2.13 > > > This is a follow up ticket to [1] > There were various fixes implemented but it seems a root cause still not > determined, see TC history [2] > Most likely the issue is caused by buggy near tx protocol. > [1] https://issues.apache.org/jira/browse/IGNITE-13441 > [2] > [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1&tab=buildTypeStatusDiv&branch_IgniteTests24Java8=%3Cdefault%3E&fromExperimentalUI=true] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14548) BinaryThreadLocalContext must be cleaned when client is closed
[
https://issues.apache.org/jira/browse/IGNITE-14548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14548:
-
Fix Version/s: 2.13
(was: 2.12)
> BinaryThreadLocalContext must be cleaned when client is closed
> --
>
> Key: IGNITE-14548
> URL: https://issues.apache.org/jira/browse/IGNITE-14548
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.13
>
>
> ThreadLocal {{BinaryThreadLocalContext#CTX}} must be cleaned when thin client
> and JDBC thin client are closed.
> Fail case: [Stack
> overflow|https://stackoverflow.com/questions/67086723/unable-to-remove-org-apache-ignite-internal-binary-binarythreadlocal-error-in-we?noredirect=1#comment118615654_67086723]
> Previous discussion: IGNITE-967
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15067) Add custom destination path to the snapshost API
[
https://issues.apache.org/jira/browse/IGNITE-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15067:
-
Fix Version/s: 2.13
(was: 2.12)
> Add custom destination path to the snapshost API
>
>
> Key: IGNITE-15067
> URL: https://issues.apache.org/jira/browse/IGNITE-15067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.13
>
>
> The default configuration path obtains from the IgniteConfiguration. However,
> in some circumstances, it is good to set this destination path at runtime.
> This path must be configured relatively in the node working directory and
> must be accessible from the security point of view.
> Proposed API:
> {code}
> public IgniteFuture createSnapshot(String name, Path locPath);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14515) Support MissingSwitchDefaultCheck checkstyle check
[ https://issues.apache.org/jira/browse/IGNITE-14515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14515: - Fix Version/s: 2.13 (was: 2.12) > Support MissingSwitchDefaultCheck checkstyle check > -- > > Key: IGNITE-14515 > URL: https://issues.apache.org/jira/browse/IGNITE-14515 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: checkstyle > Fix For: 2.13 > > > Every switch statement should include a default case. The break in the > default case is redundant, but it prevents a fall-through error if later > another case is added. > https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#468 -- 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: - Fix Version/s: 2.13 (was: 2.12) > 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: 10m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.5.5 to 3.5.9 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15636) CPP: Run tests and build ODBC driver using MS Visual Studio 2017
[ https://issues.apache.org/jira/browse/IGNITE-15636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15636: - Fix Version/s: 2.13 (was: 2.12) > CPP: Run tests and build ODBC driver using MS Visual Studio 2017 > > > Key: IGNITE-15636 > URL: https://issues.apache.org/jira/browse/IGNITE-15636 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinsky >Priority: Major > Fix For: 2.13 > > > Since VS2015, 2017 and 2019 share same redistributables and old > redistributables are deprecated, lets upgrade VS. > Currently, bundled ODBC driver are quite hard to install correctly since it > is hard to find vs2010 redist for windows 10 and seems that old resitrs are > to be deleted. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15342) Fix partition eviction process logging
[
https://issues.apache.org/jira/browse/IGNITE-15342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15342:
-
Fix Version/s: 2.13
(was: 2.12)
> Fix partition eviction process logging
> --
>
> Key: IGNITE-15342
> URL: https://issues.apache.org/jira/browse/IGNITE-15342
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.13
>
>
> There is unnecessary logging during the eviction process.
> {code}
> [2021-08-19 18:07:08,483][INFO
> ][exchange-worker-#63%snapshot.IgniteClusterSnapshotRestoreSelfTest0%][PartitionsEvictManager]
> Eviction in progress [groups=1, remainingPartsToEvict=0]
> [2021-08-19 18:07:08,483][INFO
> ][exchange-worker-#131%snapshot.IgniteClusterSnapshotRestoreSelfTest1%][PartitionsEvictManager]
> Eviction in progress [groups=1, remainingPartsToEvict=0]
> [2021-08-19 18:07:08,484][INFO
> ][exchange-worker-#131%snapshot.IgniteClusterSnapshotRestoreSelfTest1%][PartitionsEvictManager]
> Group eviction in progress [grpName=default, grpId=1544803905,
> remainingPartsToEvict=1, partsEvictInProgress=0, totalParts=4]
> [2021-08-19 18:07:08,484][INFO
> ][exchange-worker-#63%snapshot.IgniteClusterSnapshotRestoreSelfTest0%][PartitionsEvictManager]
> Group eviction in progress [grpName=shared, grpId=-903566235,
> remainingPartsToEvict=1, partsEvictInProgress=0, totalParts=4]
> [2021-08-19 18:07:08,485][INFO
> ][exchange-worker-#63%snapshot.IgniteClusterSnapshotRestoreSelfTest0%][PartitionsEvictManager]
> Partitions have been scheduled for eviction: [grpId=-903566235,
> grpName=shared, clearing=[0]]
> [2021-08-19 18:07:08,485][INFO
> ][exchange-worker-#131%snapshot.IgniteClusterSnapshotRestoreSelfTest1%][PartitionsEvictManager]
> Partitions have been scheduled for eviction: [grpId=1544803905,
> grpName=default, eviction=[2]]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-12970) Cluster snapshot must support encryption caches
[
https://issues.apache.org/jira/browse/IGNITE-12970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-12970:
-
Fix Version/s: (was: 2.12)
> Cluster snapshot must support encryption caches
> ---
>
> Key: IGNITE-12970
> URL: https://issues.apache.org/jira/browse/IGNITE-12970
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, a cluster snapshot operation not supports including encrypted
> caches to the snapshot. The {{EncryptionFileIO}} must be added for coping
> cache partition files and its deltas (see IEP-43 for details about copying
> cache partition files).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15221) Investigate and fix flaky testClusterSnapshotWithRebalancing
[ https://issues.apache.org/jira/browse/IGNITE-15221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15221: - Fix Version/s: 2.13 (was: 2.12) > Investigate and fix flaky testClusterSnapshotWithRebalancing > > > Key: IGNITE-15221 > URL: https://issues.apache.org/jira/browse/IGNITE-15221 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Critical > Labels: iep-43 > Fix For: 2.13 > > > Test testClusterSnapshotWithRebalancing hangs during the snapshot creation. > The cause needs to be investigated and fixed. > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-321293767845540479&branch=%3Cdefault%3E&tab=testDetails] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14099) CPP: Remove 32-bit configs
[ https://issues.apache.org/jira/browse/IGNITE-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14099: - Fix Version/s: 2.13 (was: 2.12) > CPP: Remove 32-bit configs > -- > > Key: IGNITE-14099 > URL: https://issues.apache.org/jira/browse/IGNITE-14099 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.9.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.13 > > > 32-bit test config files are not needed anymore, as we do not run them > anyway. Remove them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15647) -e parameter of sqlline command does not work properly
[
https://issues.apache.org/jira/browse/IGNITE-15647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15647:
-
Fix Version/s: 2.13
(was: 2.12)
> -e parameter of sqlline command does not work properly
> --
>
> Key: IGNITE-15647
> URL: https://issues.apache.org/jira/browse/IGNITE-15647
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
> Environment: CentOS7.8.2003
>Reporter: Anton Kondratev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SQL query specified in -e parameter of sqlline command does not get parsed
> properly and therefore not executed.
> I'm trying to use it like this:
> {code:java}
> ./sqlline.sh -u jdbc:ignite:thin://1.2.3.4 -n login -p password -e 'select *
> from \"sys\".\"tables\";'{code}
> and output is:
> {code:java}
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> include (Is a directory)
> Property "url" is required
> Property "url" is required
> from (No such file or directory)
> \"sys\".\"tables\"; (No such file or directory)
> Error: Failed to parse query. Syntax error in SQL statement "SELECT [*]";
> expected "TOP, LIMIT, DISTINCT, ALL, *, NOT, EXISTS, INTERSECTS"; SQL
> statement:
> select [42001-197] (state=42000,code=1001)
> java.sql.SQLException: Failed to parse query. Syntax error in SQL statement
> "SELECT [*]"; expected "TOP, LIMIT, DISTINCT, ALL, *, NOT, EXISTS,
> INTERSECTS"; SQL statement:
> select [42001-197]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
> at sqlline.Commands.executeSingleQuery(Commands.java:1054)
> at sqlline.Commands.execute(Commands.java:1003)
> at sqlline.Commands.sql(Commands.java:967)
> at sqlline.SqlLine.dispatch(SqlLine.java:734)
> at sqlline.SqlLine.initArgs(SqlLine.java:449)
> at sqlline.SqlLine.begin(SqlLine.java:515)
> at sqlline.SqlLine.start(SqlLine.java:267)
> at sqlline.SqlLine.main(SqlLine.java:206)
> sqlline version 1.9.0{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-9005:
Fix Version/s: 2.13
(was: 2.12)
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Pavlov
>Assignee: Nikolai Kulagin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7246907407546697403&branch=%3Cdefault%3E&tab=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15502) NullPointerException during a snapshot check
[
https://issues.apache.org/jira/browse/IGNITE-15502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15502:
-
Fix Version/s: 2.13
(was: 2.12)
> NullPointerException during a snapshot check
>
>
> Key: IGNITE-15502
> URL: https://issues.apache.org/jira/browse/IGNITE-15502
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Critical
> Fix For: 2.13
>
>
> {code}
> java.lang.NullPointerException
> at java.util.HashSet.(HashSet.java:119)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:106)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:70)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:2038)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:1976)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotHandlerRestoreTask$SnapshotHandlerRestoreJob.execute(SnapshotHandlerRestoreTask.java:132)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotHandlerRestoreTask$SnapshotHandlerRestoreJob.execute(SnapshotHandlerRestoreTask.java:93)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:601)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7270)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:595)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:522)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1379)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2155)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-9386: Fix Version/s: 2.13 (was: 2.12) > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Assignee: Rodion Smolnikov >Priority: Major > Fix For: 2.13 > > Time Spent: 1.5h > Remaining Estimate: 0h > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447519#comment-17447519
]
Vyacheslav Koptilin commented on IGNITE-15666:
--
Hello [~NSAmelchev],
Let's consider the following simple scenario: we have only one server node
which is an affinity node and initiator as well. In that case, both metrics
will be calculated on that server node. And so, metrics value will be broken, I
think.
Moreover, if you have a cluster you can aggregate these metrics across all
nodes, and therefore, it is possible to calculate the number of _removals_ and
_averageTime_.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447519#comment-17447519
]
Vyacheslav Koptilin edited comment on IGNITE-15666 at 11/22/21, 4:34 PM:
-
Hello [~NSAmelchev],
Let's consider the following simple scenario: we have only one server node
which is an affinity node and initiator as well. In that case, both metrics
will be calculated on that server node. And so, metrics value will be broken, I
think.
Moreover, if you have a cluster, you always can aggregate these metrics across
nodes, and therefore, it is possible to calculate the number of _removals_ and
_averageTime_ (see {_}ClusterGroup#metrics(){_})
was (Author: slava.koptilin):
Hello [~NSAmelchev],
Let's consider the following simple scenario: we have only one server node
which is an affinity node and initiator as well. In that case, both metrics
will be calculated on that server node. And so, metrics value will be broken, I
think.
Moreover, if you have a cluster you can aggregate these metrics across all
nodes, and therefore, it is possible to calculate the number of _removals_ and
_averageTime_ (see _ClusterGroup#metrics()_)
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447519#comment-17447519
]
Vyacheslav Koptilin edited comment on IGNITE-15666 at 11/22/21, 4:34 PM:
-
Hello [~NSAmelchev],
Let's consider the following simple scenario: we have only one server node
which is an affinity node and initiator as well. In that case, both metrics
will be calculated on that server node. And so, metrics value will be broken, I
think.
Moreover, if you have a cluster you can aggregate these metrics across all
nodes, and therefore, it is possible to calculate the number of _removals_ and
_averageTime_ (see _ClusterGroup#metrics()_)
was (Author: slava.koptilin):
Hello [~NSAmelchev],
Let's consider the following simple scenario: we have only one server node
which is an affinity node and initiator as well. In that case, both metrics
will be calculated on that server node. And so, metrics value will be broken, I
think.
Moreover, if you have a cluster you can aggregate these metrics across all
nodes, and therefore, it is possible to calculate the number of _removals_ and
_averageTime_.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447530#comment-17447530
]
Amelchev Nikita commented on IGNITE-15666:
--
[~slava.koptilin], I think this metric should not be used to calculate the
average time. We can have several backups, unstable topology, clients reconnect
etc that will lead to a wrong value. (in addition, batch remove time also count
missed removals but by the JCache API specification should not)
I think we should implement a correct time metric for that purpose.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447530#comment-17447530
]
Amelchev Nikita edited comment on IGNITE-15666 at 11/22/21, 5:12 PM:
-
[~slava.koptilin], I think this metric should not be used to calculate the
average time. We can have several backups, unstable topology, network delays
etc that will lead to a wrong value. (in addition, batch remove time also count
missed removals but by the JCache API specification should not)
I think we should implement a correct time metric for that purpose.
was (Author: nsamelchev):
[~slava.koptilin], I think this metric should not be used to calculate the
average time. We can have several backups, unstable topology, clients reconnect
etc that will lead to a wrong value. (in addition, batch remove time also count
missed removals but by the JCache API specification should not)
I think we should implement a correct time metric for that purpose.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447535#comment-17447535
]
Vyacheslav Koptilin commented on IGNITE-15666:
--
Hi Nikita,
??I think this metric should not be used to calculate the average time. ??
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
??batch remove time also count missed removals but by the JCache API
specification should not??
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447535#comment-17447535
]
Vyacheslav Koptilin edited comment on IGNITE-15666 at 11/22/21, 5:32 PM:
-
Hi Nikita,
> think this metric should not be used to calculate the average time.
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
was (Author: slava.koptilin):
Hi Nikita,
??I think this metric should not be used to calculate the average time. ??
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
??batch remove time also count missed removals but by the JCache API
specification should not??
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447535#comment-17447535
]
Vyacheslav Koptilin edited comment on IGNITE-15666 at 11/22/21, 5:33 PM:
-
Hi Nikita,
> I think this metric should not be used to calculate the average time. We can
> have several backups, unstable topology, etc ...
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
was (Author: slava.koptilin):
Hi Nikita,
> I think this metric should not be used to calculate the average time.
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447535#comment-17447535
]
Vyacheslav Koptilin edited comment on IGNITE-15666 at 11/22/21, 5:33 PM:
-
Hi Nikita,
> I think this metric should not be used to calculate the average time.
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
was (Author: slava.koptilin):
Hi Nikita,
> think this metric should not be used to calculate the average time.
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-15666) The remove metric value is different for sync and async methods
[
https://issues.apache.org/jira/browse/IGNITE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447535#comment-17447535
]
Vyacheslav Koptilin edited comment on IGNITE-15666 at 11/22/21, 5:34 PM:
-
Hi Nikita,
> I think this metric should not be used to calculate the average time. We can
> have several backups, unstable topology, etc that will lead to a wrong value.
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
was (Author: slava.koptilin):
Hi Nikita,
> I think this metric should not be used to calculate the average time. We can
> have several backups, unstable topology, etc ...
I think it does not matter, only one source of truth should be used and this
source is the JCache API specification.
> batch remove time also count missed removals but by the JCache API
> specification should not
And this is an issue that should be fixed instead of breaking the
Cache#remove(Key) method, IMHO.
> The remove metric value is different for sync and async methods
> ---
>
> Key: IGNITE-15666
> URL: https://issues.apache.org/jira/browse/IGNITE-15666
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The remove metric value is different for sync and async methods.
> The following metrics are updated only if the key was exist for the sync
> version:
> {noformat}
> RemoveTimeTotal
> RemoveTime
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Description:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without persistence client node would fail during start up
with below error:
{code:java}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
It seems that here [2] we should add check whether starting up node is client
or not:
{code:java}
/** Starts processor. */
public void startProcessor() throws IgniteCheckedException {
if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
client node fails
throw new IgniteCheckedException("Authentication can be enabled
only for cluster with enabled persistence."
+ " Check the DataRegionConfiguration");
}
{code}
Links:
# [https://ignite.apache.org/docs/latest/security/authentication]
#
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
was:
When you start cluster with turned on built-in authentication it requires to
enable persistence too [1].
This requirement seems to be useless for client nodes, because they has no
persistence, but without persistence client node would fail during start up
with below error:
{code:java}
class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
only for cluster with enabled persistence. Check the DataRegionConfiguration
at
org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
{code}
Reproducer: [^ClientNodeAuthFailureReproducer.patch]
It slightly modifies AuthenticationConfigurationClusterTest an it leads to
failure of tests: the existing #testClientNodeJoinDisabled and added in the
patch #testEnabledAuthenticationOnClientNode.
It seems that here [2] we should add check whether starting node is client or
not:
{code:java}
/** Starts processor. */
public void startProcessor() throws IgniteCheckedException {
if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
client node fails
throw new IgniteCheckedException("Authentication can be enabled
only for cluster with enabled persistence."
+ " Check the DataRegionConfiguration");
}
{code}
Links:
# [https://ignite.apache.org/docs/latest/security/authentication]
#
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has n
[jira] [Updated] (IGNITE-15969) Enabling authentication requires the client node to enable persistence in the configuration
[
https://issues.apache.org/jira/browse/IGNITE-15969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-15969:
---
Labels: newbie (was: )
> Enabling authentication requires the client node to enable persistence in the
> configuration
> ---
>
> Key: IGNITE-15969
> URL: https://issues.apache.org/jira/browse/IGNITE-15969
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: newbie
> Attachments: ClientNodeAuthFailureReproducer.patch
>
>
> When you start cluster with turned on built-in authentication it requires to
> enable persistence too [1].
> This requirement seems to be useless for client nodes, because they has no
> persistence, but without persistence client node would fail during start up
> with below error:
> {code:java}
> class org.apache.ignite.IgniteCheckedException: Authentication can be enabled
> only for cluster with enabled persistence. Check the DataRegionConfiguration
> at
> org.apache.ignite.internal.processors.authentication.IgniteAuthenticationProcessor.startProcessor(IgniteAuthenticationProcessor.java:166)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1259)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> {code}
> Reproducer: [^ClientNodeAuthFailureReproducer.patch]
> It slightly modifies AuthenticationConfigurationClusterTest an it leads to
> failure of tests: the existing #testClientNodeJoinDisabled and added in the
> patch #testEnabledAuthenticationOnClientNode.
> It seems that here [2] we should add check whether starting up node is client
> or not:
> {code:java}
> /** Starts processor. */
> public void startProcessor() throws IgniteCheckedException {
> if (!GridCacheUtils.isPersistenceEnabled(ctx.config())) { // here
> client node fails
> throw new IgniteCheckedException("Authentication can be enabled
> only for cluster with enabled persistence."
> + " Check the DataRegionConfiguration");
> }
> {code}
> Links:
> # [https://ignite.apache.org/docs/latest/security/authentication]
> #
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/authentication/IgniteAuthenticationProcessor.java#L165]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-12695) Calcite integration. DML support. MERGE support
[ https://issues.apache.org/jira/browse/IGNITE-12695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447550#comment-17447550 ] Aleksey Plekhanov commented on IGNITE-12695: [~korlov], [~tledkov-gridgain], [~zstan] can you please review the patch? > Calcite integration. DML support. MERGE support > --- > > Key: IGNITE-12695 > URL: https://issues.apache.org/jira/browse/IGNITE-12695 > Project: Ignite > Issue Type: New Feature >Reporter: Igor Seliverstov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15972) Improve network processor error message
Aleksandr Polovtcev created IGNITE-15972: Summary: Improve network processor error message Key: IGNITE-15972 URL: https://issues.apache.org/jira/browse/IGNITE-15972 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev When generation Network Message implementations, we use a special per-module class called a Message Group. When this class is not present, a corresponding error is thrown. However, when using IDEA, it is possible to get this error during the incremental compilation, because the Message Group class might not be passed to the annotation processor amongst the Network Message classes. Current error message is not very descriptive and does not indicate, which package or module failed to compile. It is proposed to at least add package names of the processed elements. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15891) Configuration does not concerned global state when handling a consumer
[ https://issues.apache.org/jira/browse/IGNITE-15891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-15891: Assignee: Kirill Tkalenko > Configuration does not concerned global state when handling a consumer > -- > > Key: IGNITE-15891 > URL: https://issues.apache.org/jira/browse/IGNITE-15891 > Project: Ignite > Issue Type: Test >Reporter: Vladislav Pyatkov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > A code into Configuration changer: > 1) Cannot use a configuration view, because it is just a local cache (the > global value may have changed in the past) > 2) Can throw an exception (IllegalArgumentException) when cached > configuration does not support the change, but global state different (and > does not conflict to the change). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15973) Make "checkpoint pages were not written" log INFO
Kirill Tkalenko created IGNITE-15973: Summary: Make "checkpoint pages were not written" log INFO Key: IGNITE-15973 URL: https://issues.apache.org/jira/browse/IGNITE-15973 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.13 The following warning confuses users [2021-10-25T09:40:03,555][WARN ][checkpoint-runner-IO-#78][CheckpointPagesWriterFactory] 1 checkpoint pages were not written yet due to unsuccessful page write lock acquisition and will be retried It is not actionable for a regular user and doesn't really indicate a problem that needs to be taken care of. Let's change it from WARN to INFO -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15729) RecordViewExample fails with two remote nodes
[
https://issues.apache.org/jira/browse/IGNITE-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-15729:
Assignee: Mirza Aliev
> RecordViewExample fails with two remote nodes
> -
>
> Key: IGNITE-15729
> URL: https://issues.apache.org/jira/browse/IGNITE-15729
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Affects Versions: 3.0.0-alpha3
>Reporter: Valentin Kulichenko
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha4
>
>
> To reproduce:
> # Start *two* nodes using the CLI tool.
> # Run the {{RecordViewExample}} (need to check other examples as well).
> # Observe the exception shown below.
> {noformat}
> Exception in thread "main" java.util.concurrent.CompletionException: class
> org.apache.ignite.client.IgniteClientException: class
> org.apache.ignite.client.IgniteClientException: class
> org.apache.ignite.raft.jraft.rpc.impl.RaftException: ENOENT:No nodes in group
> 1-40f121ca-81e4-4929-8ad3-24f5742c81af_part_6
> at
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
> at
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.ReliableChannel.lambda$handleServiceAsync$3(ReliableChannel.java:213)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:260)
> at
> org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:109)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:85)
> at
> org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:33)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
> at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: cla
