[jira] [Updated] (IGNITE-16979) Add support for load testing via Gatling to ducktests
[ https://issues.apache.org/jira/browse/IGNITE-16979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-16979: - Description: Add ability to perform load testing via the ignite-gatling extention in ducktests framework was: Add ability to perform load testing via the Gatling tool in ducktests framework > Add support for load testing via Gatling to ducktests > - > > Key: IGNITE-16979 > URL: https://issues.apache.org/jira/browse/IGNITE-16979 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 1h 40m > Remaining Estimate: 0h > > Add ability to perform load testing via the ignite-gatling extention in > ducktests framework -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16979) Add support for load testing via Gatling to ducktests
[ https://issues.apache.org/jira/browse/IGNITE-16979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-16979: - Priority: Minor (was: Major) > Add support for load testing via Gatling to ducktests > - > > Key: IGNITE-16979 > URL: https://issues.apache.org/jira/browse/IGNITE-16979 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 1h 40m > Remaining Estimate: 0h > > Add ability to perform load testing via the Gatling tool in ducktests > framework -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-16979) Add support for load testing via Gatling to ducktests
[ https://issues.apache.org/jira/browse/IGNITE-16979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reopened IGNITE-16979: -- > Add support for load testing via Gatling to ducktests > - > > Key: IGNITE-16979 > URL: https://issues.apache.org/jira/browse/IGNITE-16979 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Labels: ducktests > Time Spent: 1h 40m > Remaining Estimate: 0h > > Add ability to perform load testing via the Gatling tool in ducktests > framework -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21769) [ducktests] ignitetest/tests/dns_failure_test.py doesn't start with JDK11 and JDK17
[
https://issues.apache.org/jira/browse/IGNITE-21769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-21769:
-
Summary: [ducktests] ignitetest/tests/dns_failure_test.py doesn't start
with JDK11 and JDK17 (was: [ducktests] ignitetest/tests/dns_failure_test.py
doesn't work with JDK11 and JDK17)
> [ducktests] ignitetest/tests/dns_failure_test.py doesn't start with JDK11 and
> JDK17
> ---
>
> Key: IGNITE-21769
> URL: https://issues.apache.org/jira/browse/IGNITE-21769
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ise
> Attachments: dns_failure_test_jdk11.zip, dns_failure_test_jdk17.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ignitetest/tests/dns_failure_test.py fails on JDK11 and JDK17
> Ignite node can not start with the following exception:
> {noformat}
> Class not found: java.net.BlockingDnsInet4AddressImpl:
> check impl.prefix property in your properties file.
> java.lang.Error: System property impl.prefix incorrect
> at java.base/java.net.InetAddress.loadImpl(InetAddress.java:1734)
> at
> java.base/java.net.InetAddressImplFactory.create(InetAddress.java:1807)
> at java.base/java.net.InetAddress.(InetAddress.java:1141)
> at
> org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:56)
> at
> org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:625)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:625)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:713)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:735)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:260)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:154)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:197)
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.(LogAdapter.java:155)
> at
> org.apache.commons.logging.LogAdapter$Log4jAdapter.createLog(LogAdapter.java:122)
> at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:89)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59)
> at
> org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:164)
> at
> org.springframework.context.support.GenericApplicationContext.(GenericApplicationContext.java:111)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.prepareSpringContext(IgniteSpringHelperImpl.java:458)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:386)
> {noformat}
> Logs attached obtained with the below jdk versions:
> OpenJDK Runtime Environment 11.0.19+7 Eclipse Adoptium OpenJDK 64-Bit Server
> VM 11.0.19+7
> OpenJDK Runtime Environment 17.0.7+7 Eclipse Adoptium OpenJDK 64-Bit Server
> VM 17.0.7+7
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21769) [ducktests] ignitetest/tests/dns_failure_test.py doesn't work with JDK11 and JDK17
[
https://issues.apache.org/jira/browse/IGNITE-21769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov reassigned IGNITE-21769:
Assignee: Sergey Korotkov
> [ducktests] ignitetest/tests/dns_failure_test.py doesn't work with JDK11 and
> JDK17
> --
>
> Key: IGNITE-21769
> URL: https://issues.apache.org/jira/browse/IGNITE-21769
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ise
> Attachments: dns_failure_test_jdk11.zip, dns_failure_test_jdk17.zip
>
>
> ignitetest/tests/dns_failure_test.py fails on JDK11 and JDK17
> Ignite node can not start with the following exception:
> {noformat}
> Class not found: java.net.BlockingDnsInet4AddressImpl:
> check impl.prefix property in your properties file.
> java.lang.Error: System property impl.prefix incorrect
> at java.base/java.net.InetAddress.loadImpl(InetAddress.java:1734)
> at
> java.base/java.net.InetAddressImplFactory.create(InetAddress.java:1807)
> at java.base/java.net.InetAddress.(InetAddress.java:1141)
> at
> org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:56)
> at
> org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:625)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:625)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:713)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:735)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:260)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:154)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:197)
> at
> org.apache.commons.logging.LogAdapter$Log4jLog.(LogAdapter.java:155)
> at
> org.apache.commons.logging.LogAdapter$Log4jAdapter.createLog(LogAdapter.java:122)
> at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:89)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59)
> at
> org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:164)
> at
> org.springframework.context.support.GenericApplicationContext.(GenericApplicationContext.java:111)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.prepareSpringContext(IgniteSpringHelperImpl.java:458)
> at
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:386)
> {noformat}
> Logs attached obtained with the below jdk versions:
> OpenJDK Runtime Environment 11.0.19+7 Eclipse Adoptium OpenJDK 64-Bit Server
> VM 11.0.19+7
> OpenJDK Runtime Environment 17.0.7+7 Eclipse Adoptium OpenJDK 64-Bit Server
> VM 17.0.7+7
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21769) [ducktests] ignitetest/tests/dns_failure_test.py doesn't work with JDK11 and JDK17
[
https://issues.apache.org/jira/browse/IGNITE-21769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-21769:
-
Description:
ignitetest/tests/dns_failure_test.py fails on JDK11 and JDK17
Ignite node can not start with the following exception:
{noformat}
Class not found: java.net.BlockingDnsInet4AddressImpl:
check impl.prefix property in your properties file.
java.lang.Error: System property impl.prefix incorrect
at java.base/java.net.InetAddress.loadImpl(InetAddress.java:1734)
at
java.base/java.net.InetAddressImplFactory.create(InetAddress.java:1807)
at java.base/java.net.InetAddress.(InetAddress.java:1141)
at
org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:56)
at
org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:625)
at
java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:625)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:713)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:735)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:260)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:154)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:197)
at
org.apache.commons.logging.LogAdapter$Log4jLog.(LogAdapter.java:155)
at
org.apache.commons.logging.LogAdapter$Log4jAdapter.createLog(LogAdapter.java:122)
at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:89)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59)
at
org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:164)
at
org.springframework.context.support.GenericApplicationContext.(GenericApplicationContext.java:111)
at
org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.prepareSpringContext(IgniteSpringHelperImpl.java:458)
at
org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:386)
{noformat}
Logs attached obtained with the below jdk versions:
OpenJDK Runtime Environment 11.0.19+7 Eclipse Adoptium OpenJDK 64-Bit Server VM
11.0.19+7
OpenJDK Runtime Environment 17.0.7+7 Eclipse Adoptium OpenJDK 64-Bit Server VM
17.0.7+7
was:
ignitetest/tests/dns_failure_test.py fails on JDK11 and JDK17
Ignite node can not start with the following exception:
{noformat}
Class not found: java.net.BlockingDnsInet4AddressImpl:
check impl.prefix property in your properties file.
java.lang.Error: System property impl.prefix incorrect
at java.base/java.net.InetAddress.loadImpl(InetAddress.java:1734)
at
java.base/java.net.InetAddressImplFactory.create(InetAddress.java:1807)
at java.base/java.net.InetAddress.(InetAddress.java:1141)
at
org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:56)
at
org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:625)
at
java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:625)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:713)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:735)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:260)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:154)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:197)
at
org.apache.commons.logging.LogAdapter$Log4jLog.(LogAdapter.java:155)
at
org.apache.commons.logging.LogAdapter$Log4jAdapter.createLog(LogAdapter.java:122)
at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:89)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59)
at
org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:164)
at
org.springframework.context.support.GenericApplicationContext.(GenericApplicationContext.java:111)
at
[jira] [Created] (IGNITE-21769) [ducktests] ignitetest/tests/dns_failure_test.py doesn't work with JDK11 and JDK17
Sergey Korotkov created IGNITE-21769:
Summary: [ducktests] ignitetest/tests/dns_failure_test.py doesn't
work with JDK11 and JDK17
Key: IGNITE-21769
URL: https://issues.apache.org/jira/browse/IGNITE-21769
Project: Ignite
Issue Type: Task
Reporter: Sergey Korotkov
Attachments: dns_failure_test_jdk11.zip, dns_failure_test_jdk17.zip
ignitetest/tests/dns_failure_test.py fails on JDK11 and JDK17
Ignite node can not start with the following exception:
{noformat}
Class not found: java.net.BlockingDnsInet4AddressImpl:
check impl.prefix property in your properties file.
java.lang.Error: System property impl.prefix incorrect
at java.base/java.net.InetAddress.loadImpl(InetAddress.java:1734)
at
java.base/java.net.InetAddressImplFactory.create(InetAddress.java:1807)
at java.base/java.net.InetAddress.(InetAddress.java:1141)
at
org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:56)
at
org.apache.logging.log4j.core.LoggerContext.lambda$setConfiguration$0(LoggerContext.java:625)
at
java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1705)
at
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:625)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:713)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:735)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:260)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:154)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:46)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:197)
at
org.apache.commons.logging.LogAdapter$Log4jLog.(LogAdapter.java:155)
at
org.apache.commons.logging.LogAdapter$Log4jAdapter.createLog(LogAdapter.java:122)
at org.apache.commons.logging.LogAdapter.createLog(LogAdapter.java:89)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:67)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:59)
at
org.springframework.context.support.AbstractApplicationContext.(AbstractApplicationContext.java:164)
at
org.springframework.context.support.GenericApplicationContext.(GenericApplicationContext.java:111)
at
org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.prepareSpringContext(IgniteSpringHelperImpl.java:458)
at
org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:386)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21679) Add gatling plugin for load testing to extensions
Sergey Korotkov created IGNITE-21679: Summary: Add gatling plugin for load testing to extensions Key: IGNITE-21679 URL: https://issues.apache.org/jira/browse/IGNITE-21679 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21678) IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
[
https://issues.apache.org/jira/browse/IGNITE-21678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-21678:
-
Fix Version/s: 2.17
> IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
> -
>
> Key: IGNITE-21678
> URL: https://issues.apache.org/jira/browse/IGNITE-21678
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The below exception occurs if destination cluster has the explicit
> BinaryConfiguration instance included into the IgniteConfiguration:
> {noformat}
> 2024-03-04T12:14:31,777][INFO ][Thread-0][] Ignite Change Data Capture
> Application stopped.
> [2024-03-04T12:14:31,782][ERROR][Thread-0][] Cdc error
> org.apache.ignite.IgniteException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1163)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:303) ~[classes/:?]
> at
> org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:86)
> ~[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:192)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:360)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:306)
> [classes/:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1777)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
> ... 5 more
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI:
> TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@5f243268],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:280)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1072)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1772)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
> ... 5 more
> Caused by: org.apache.ignite.spi.IgniteSpiException: Local node's binary
> configuration is not equal to remote node's binary configuration
> [locNodeId=6eb40fd6-b20e-4485-a7f7-bb62e7e96abf,
> rmtNodeId=e2f49ba1-6f99-4b75-8476-8bc925639527, locBinaryCfg=null,
> rmtBinaryCfg={globIdMapper=null, compactFooter=true, globSerializer=null}]
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2131)
>
[jira] [Updated] (IGNITE-21678) IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
[
https://issues.apache.org/jira/browse/IGNITE-21678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-21678:
-
Priority: Major (was: Minor)
> IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
> -
>
> Key: IGNITE-21678
> URL: https://issues.apache.org/jira/browse/IGNITE-21678
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The below exception occurs if destination cluster has the explicit
> BinaryConfiguration instance included into the IgniteConfiguration:
> {noformat}
> 2024-03-04T12:14:31,777][INFO ][Thread-0][] Ignite Change Data Capture
> Application stopped.
> [2024-03-04T12:14:31,782][ERROR][Thread-0][] Cdc error
> org.apache.ignite.IgniteException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1163)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:303) ~[classes/:?]
> at
> org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:86)
> ~[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:192)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:360)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:306)
> [classes/:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1777)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
> ... 5 more
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI:
> TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@5f243268],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:280)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1072)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1772)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
> ... 5 more
> Caused by: org.apache.ignite.spi.IgniteSpiException: Local node's binary
> configuration is not equal to remote node's binary configuration
> [locNodeId=6eb40fd6-b20e-4485-a7f7-bb62e7e96abf,
> rmtNodeId=e2f49ba1-6f99-4b75-8476-8bc925639527, locBinaryCfg=null,
> rmtBinaryCfg={globIdMapper=null, compactFooter=true, globSerializer=null}]
> at
>
[jira] [Updated] (IGNITE-21678) IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
[
https://issues.apache.org/jira/browse/IGNITE-21678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-21678:
-
Labels: ise (was: )
> IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
> -
>
> Key: IGNITE-21678
> URL: https://issues.apache.org/jira/browse/IGNITE-21678
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The below exception occurs if destination cluster has the explicit
> BinaryConfiguration instance included into the IgniteConfiguration:
> {noformat}
> 2024-03-04T12:14:31,777][INFO ][Thread-0][] Ignite Change Data Capture
> Application stopped.
> [2024-03-04T12:14:31,782][ERROR][Thread-0][] Cdc error
> org.apache.ignite.IgniteException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1163)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:303) ~[classes/:?]
> at
> org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:86)
> ~[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:192)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:360)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:306)
> [classes/:?]
> at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1777)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
> ... 5 more
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI:
> TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
> ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@5f243268],
> reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
> forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
> skipAddrsRandomization=false]
> at
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:280)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1072)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1772)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> ~[classes/:?]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
> ~[classes/:?]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
> ~[classes/:?]
> at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
> ... 5 more
> Caused by: org.apache.ignite.spi.IgniteSpiException: Local node's binary
> configuration is not equal to remote node's binary configuration
> [locNodeId=6eb40fd6-b20e-4485-a7f7-bb62e7e96abf,
> rmtNodeId=e2f49ba1-6f99-4b75-8476-8bc925639527, locBinaryCfg=null,
> rmtBinaryCfg={globIdMapper=null, compactFooter=true, globSerializer=null}]
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2131)
> ~[classes/:?]
> at
[jira] [Updated] (IGNITE-21678) IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
[
https://issues.apache.org/jira/browse/IGNITE-21678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-21678:
-
Description:
The below exception occurs if destination cluster has the explicit
BinaryConfiguration instance included into the IgniteConfiguration:
{noformat}
2024-03-04T12:14:31,777][INFO ][Thread-0][] Ignite Change Data Capture
Application stopped.
[2024-03-04T12:14:31,782][ERROR][Thread-0][] Cdc error
org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter
[enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1163)
~[classes/:?]
at org.apache.ignite.Ignition.start(Ignition.java:303) ~[classes/:?]
at
org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:86)
~[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:192)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:360)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:306)
[classes/:?]
at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1777)
~[classes/:?]
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
~[classes/:?]
at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
... 5 more
Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
ackTimeout=5000, marsh=JdkMarshaller
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@5f243268],
reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
skipAddrsRandomization=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:280)
~[classes/:?]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1072)
~[classes/:?]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1772)
~[classes/:?]
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
~[classes/:?]
at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
... 5 more
Caused by: org.apache.ignite.spi.IgniteSpiException: Local node's binary
configuration is not equal to remote node's binary configuration
[locNodeId=6eb40fd6-b20e-4485-a7f7-bb62e7e96abf,
rmtNodeId=e2f49ba1-6f99-4b75-8476-8bc925639527, locBinaryCfg=null,
rmtBinaryCfg={globIdMapper=null, compactFooter=true, globSerializer=null}]
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2131)
~[classes/:?]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1993)
~[classes/:?]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
~[classes/:?]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$1.body(ClientImpl.java:317)
~[classes/:?]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
~[classes/:?]
{noformat}
was:
The below exception occurs:
{noformat}
2024-03-04T12:14:31,777][INFO ][Thread-0][] Ignite Change Data Capture
Application stopped.
[2024-03-04T12:14:31,782][ERROR][Thread-0][] Cdc error
org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter
[enabled=true,
[jira] [Created] (IGNITE-21678) IgniteToIgniteCdcStreamer fails if BinaryConfiguration is specified in config
Sergey Korotkov created IGNITE-21678:
Summary: IgniteToIgniteCdcStreamer fails if BinaryConfiguration is
specified in config
Key: IGNITE-21678
URL: https://issues.apache.org/jira/browse/IGNITE-21678
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
Assignee: Sergey Korotkov
The below exception occurs:
{noformat}
2024-03-04T12:14:31,777][INFO ][Thread-0][] Ignite Change Data Capture
Application stopped.
[2024-03-04T12:14:31,782][ERROR][Thread-0][] Cdc error
org.apache.ignite.IgniteException: Failed to start manager: GridManagerAdapter
[enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1163)
~[classes/:?]
at org.apache.ignite.Ignition.start(Ignition.java:303) ~[classes/:?]
at
org.apache.ignite.cdc.IgniteToIgniteCdcStreamer.start(IgniteToIgniteCdcStreamer.java:86)
~[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.start(WalRecordsConsumer.java:192)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:360)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:306)
[classes/:?]
at java.base/java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
GridManagerAdapter [enabled=true,
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1777)
~[classes/:?]
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
~[classes/:?]
at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
... 5 more
Caused by: org.apache.ignite.IgniteCheckedException: Failed to start SPI:
TcpDiscoverySpi [addrRslvr=null, addressFilter=null, sockTimeout=5000,
ackTimeout=5000, marsh=JdkMarshaller
[clsFilter=org.apache.ignite.marshaller.MarshallerUtils$1@5f243268],
reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0,
forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null,
skipAddrsRandomization=false]
at
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:280)
~[classes/:?]
at
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1072)
~[classes/:?]
at
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1772)
~[classes/:?]
at
org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1159)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
~[classes/:?]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:625)
~[classes/:?]
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:547)
~[classes/:?]
at org.apache.ignite.Ignition.start(Ignition.java:300) ~[classes/:?]
... 5 more
Caused by: org.apache.ignite.spi.IgniteSpiException: Local node's binary
configuration is not equal to remote node's binary configuration
[locNodeId=6eb40fd6-b20e-4485-a7f7-bb62e7e96abf,
rmtNodeId=e2f49ba1-6f99-4b75-8476-8bc925639527, locBinaryCfg=null,
rmtBinaryCfg={globIdMapper=null, compactFooter=true, globSerializer=null}]
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.checkFailedError(TcpDiscoverySpi.java:2131)
~[classes/:?]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1993)
~[classes/:?]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
~[classes/:?]
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$1.body(ClientImpl.java:317)
~[classes/:?]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
~[classes/:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21550) ignite-cdc doesn't expose metrics via push metric exporters
[ https://issues.apache.org/jira/browse/IGNITE-21550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-21550: - Labels: ise (was: ) > ignite-cdc doesn't expose metrics via push metric exporters > --- > > Key: IGNITE-21550 > URL: https://issues.apache.org/jira/browse/IGNITE-21550 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ise > Time Spent: 20m > Remaining Estimate: 0h > > For example cdc-related metric are not exposed via the > OpenCensusMetricExporterSpi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21550) ignite-cdc doesn't expose metrics via push metric exporters
[ https://issues.apache.org/jira/browse/IGNITE-21550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-21550: - Summary: ignite-cdc doesn't expose metrics via push metric exporters (was: ignite-cdc doesn't expose metrics via push metric exporters like opencensus one) > ignite-cdc doesn't expose metrics via push metric exporters > --- > > Key: IGNITE-21550 > URL: https://issues.apache.org/jira/browse/IGNITE-21550 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > For example cdc-related metric are not exposed via the > OpenCensusMetricExporterSpi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21550) ignite-cdc doesn't expose metrics via push metric exporters like opencensus one
[ https://issues.apache.org/jira/browse/IGNITE-21550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-21550: - Summary: ignite-cdc doesn't expose metrics via push metric exporters like opencensus one (was: ignite-cdc doesn't expose cdc-related metrics via exporters other then Jmx one) > ignite-cdc doesn't expose metrics via push metric exporters like opencensus > one > --- > > Key: IGNITE-21550 > URL: https://issues.apache.org/jira/browse/IGNITE-21550 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > For example cdc-related metric are not exposed via the > OpenCensusMetricExporterSpi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21550) ignite-cdc doesn't expose cdc-related metrics via exporters other then Jmx one
Sergey Korotkov created IGNITE-21550: Summary: ignite-cdc doesn't expose cdc-related metrics via exporters other then Jmx one Key: IGNITE-21550 URL: https://issues.apache.org/jira/browse/IGNITE-21550 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov For example cdc-related metric are not exposed via the OpenCensusMetricExporterSpi -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20641) Entries added via data streamer to persistent cache are not written to cache dump
[
https://issues.apache.org/jira/browse/IGNITE-20641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov resolved IGNITE-20641.
--
Fix Version/s: 2.17
Resolution: Duplicate
> Entries added via data streamer to persistent cache are not written to cache
> dump
> -
>
> Key: IGNITE-20641
> URL: https://issues.apache.org/jira/browse/IGNITE-20641
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Minor
> Labels: IEP-109, ise
> Fix For: 2.17
>
>
> Steps to reproduce the problem:
> * start ignite with persistence
> * load some entries via the data streamer
> * restart ignite
> * create cache dump
> * check cache dump consistency
> Consistency check would fail with errors like
> {noformat}
> [2023-10-11T12:13:28,711][INFO ][session=427e7c47][CommandHandlerLog] Hash
> conflicts:
> [2023-10-11T12:13:28,721][INFO ][session=427e7c47][CommandHandlerLog]
> Conflict partition: PartitionKeyV2 [grpId=-1988013461, grpName=test-cache-1,
> partId=947]
> [2023-10-11T12:13:28,725][INFO ][session=427e7c47][CommandHandlerLog]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=ducker03, updateCntr=null, partitionState=OWNING, size=0,
> partHash=0, partVerHash=0], PartitionHashRecordV2 [isPrimary=false,
> consistentId=ducker02, updateCntr=null, partitionState=OWNING, size=48,
> partHash=731883010, partVerHash=0]]
> {noformat}
> *.dump files on primary are empty, but on backups are not.
> ---
> Reason is that after ignite restart such records are always considered to be
> added after dump creation start in CreateDumpFutureTask::isAfterStart. That
> is because entries added via the datastreamer have version equal to
> isolatedStreamerVer but isolatedStreamerVer changes on each ignite restart
> and isolatedStreamerVer is always greater than startVer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20816) in-memory server node is crashed by TcpIgniteClient.putAllConflict() if cache objects transformation applied
Sergey Korotkov created IGNITE-20816:
Summary: in-memory server node is crashed by
TcpIgniteClient.putAllConflict() if cache objects transformation applied
Key: IGNITE-20816
URL: https://issues.apache.org/jira/browse/IGNITE-20816
Project: Ignite
Issue Type: Task
Reporter: Sergey Korotkov
The in-memory server node crashes with the below exception if
TcpIgniteClient.putAllConflict() if cache objects transformation is applied.
{noformat}
[2023-11-09T09:34:30,401][ERROR][client-connector-#68%target%][] Critical
system error detected. Will be handled accordingly to configured handler
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
corrupted [groupId=-1407396309, pageIds=[844420635164695], msg=Runtime failure
on search row: SearchRow [key=KeyCacheObjectImpl [part=10, val=52234,
hasValBytes=true], hash=52234, cacheId=0
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
B+Tree is corrupted [groupId=-1407396309, pageIds=[844420635164695],
msg=Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=10,
val=52234, hasValBytes=true], hash=52234, cacheId=0]]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6534)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:2215)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1692)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1675)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:424)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1903)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2536)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1996)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1688)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:791)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:645)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1080)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$21.apply(GridDhtAtomicCache.java:1078)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:752)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1078)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflictAsync(GridDhtAtomicCache.java:679)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflict(GridDhtAtomicCache.java:670)
[classes/:?]
at
org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.putAllConflict(GridCacheProxyImpl.java:536)
[classes/:?]
at
org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutAllConflictRequest.process(ClientCachePutAllConflictRequest.java:81)
[classes/:?]
at
[jira] [Updated] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
[ https://issues.apache.org/jira/browse/IGNITE-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-20719: - Labels: ise (was: ) > [ducktests] CDC ducktests do not work if HTTP metrics export is enabled > --- > > Key: IGNITE-20719 > URL: https://issues.apache.org/jira/browse/IGNITE-20719 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ise > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several problems preventing the CDC ducktests to work correctly if > HTTP metrics exporter (opencensus prometheus) is enabled: > # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh > processes. > # StandaloneGridKernalContext used in ignite-cdc.sh returns null as ignite > instance name but it's needed by the opencensus metrics exporter with the > sendInstanceName=True (which in turn is needed for ducktests to bound metrics > to particular test instance). > # Current ignite_spec overrides the ignite_instance_name if metrics were > enabled preventing using of different custom names. Which is needed for CDC > tests there two ignite configurations are specified in the same XML config > file on the same node (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
[ https://issues.apache.org/jira/browse/IGNITE-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-20719: - Description: There are several problems preventing the CDC ducktests to work correctly if HTTP metrics exporter (opencensus prometheus) is enabled: # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh processes. # StandaloneGridKernalContext used in ignite-cdc.sh returns null as ignite instance name but it's needed by the opencensus metrics exporter with the sendInstanceName=True (which in turn is needed for ducktests to bound metrics to particular test instance). # Current ignite_spec overrides the ignite_instance_name if metrics were enabled preventing using of different custom names. Which is needed for CDC tests there two ignite configurations are specified in the same XML config file on the same node (one for source and another for the target cluster). was: There are several problems preventing the CDC ducktests to work correctly if HTTP metrics exporter (opencensus prometheus) is enabled: # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh processes. # StandaloneGridKernalContext returns null as ignite instance name but it's needed by the opencensus metrics exporter with the sendInstanceName=True (which in turn is needed for ducktests to bound metrics to particular test instance). # Current ignite_spec overrides the ignite_instance_name if metrics were enabled preventing using of different custom names. Which is needed for CDC tests there 2 ignite configurations are specified in the same XML config file (one for source and another for the target cluster). > [ducktests] CDC ducktests do not work if HTTP metrics export is enabled > --- > > Key: IGNITE-20719 > URL: https://issues.apache.org/jira/browse/IGNITE-20719 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > > There are several problems preventing the CDC ducktests to work correctly if > HTTP metrics exporter (opencensus prometheus) is enabled: > # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh > processes. > # StandaloneGridKernalContext used in ignite-cdc.sh returns null as ignite > instance name but it's needed by the opencensus metrics exporter with the > sendInstanceName=True (which in turn is needed for ducktests to bound metrics > to particular test instance). > # Current ignite_spec overrides the ignite_instance_name if metrics were > enabled preventing using of different custom names. Which is needed for CDC > tests there two ignite configurations are specified in the same XML config > file on the same node (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
[ https://issues.apache.org/jira/browse/IGNITE-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-20719: Assignee: Sergey Korotkov > [ducktests] CDC ducktests do not work if HTTP metrics export is enabled > --- > > Key: IGNITE-20719 > URL: https://issues.apache.org/jira/browse/IGNITE-20719 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > > There are several problems preventing the CDC ducktests to work correctly if > HTTP metrics exporter (opencensus prometheus) is enabled: > # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh > processes. > # StandaloneGridKernalContext returns null as ignite instance name but it's > needed by the opencensus metrics exporter with the sendInstanceName=True > (which in turn is needed for ducktests to bound metrics to particular test > instance). > # Current ignite_spec overrides the ignite_instance_name if metrics were > enabled preventing using of different custom names. Which is needed for CDC > tests there 2 ignite configurations are specified in the same XML config file > (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
Sergey Korotkov created IGNITE-20719: Summary: [ducktests] CDC ducktests do not work if HTTP metrics export is enabled Key: IGNITE-20719 URL: https://issues.apache.org/jira/browse/IGNITE-20719 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov There are several problems preventing the CDC ducktests to work correctly if HTTP metrics exporter (opencensus prometheus) is enabled: # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh processes. # StandaloneGridKernalContext returns null as ignite instance name but it's needed by the opencensus metrics exporter with the sendInstanceName=True (which in turn is needed for ducktests to bound metrics to particular test instance). # Current ignite_spec overrides the ignite_instance_name if metrics were enabled preventing using of different custom names. Which is needed for CDC tests there 2 ignite configurations are specified in the same XML config file (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20682) [ducktests] Add extension point to rebalance test
[ https://issues.apache.org/jira/browse/IGNITE-20682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-20682: - Fix Version/s: 2.16 > [ducktests] Add extension point to rebalance test > - > > Key: IGNITE-20682 > URL: https://issues.apache.org/jira/browse/IGNITE-20682 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It's needed to add the extension point to the rebalance ducktests to be able > to create subclasses to test rebalance with some extension modules or plugins > applied. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20682) [ducktests] Add extension point to rebalance test
[ https://issues.apache.org/jira/browse/IGNITE-20682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-20682: - Ignite Flags: (was: Docs Required,Release Notes Required) > [ducktests] Add extension point to rebalance test > - > > Key: IGNITE-20682 > URL: https://issues.apache.org/jira/browse/IGNITE-20682 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > It's needed to add the extension point to the rebalance ducktests to be able > to create subclasses to test rebalance with some extension modules or plugins > applied. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20689) [ducktests] Fix a flaky perf_stat_test
Sergey Korotkov created IGNITE-20689: Summary: [ducktests] Fix a flaky perf_stat_test Key: IGNITE-20689 URL: https://issues.apache.org/jira/browse/IGNITE-20689 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov ignitetest.tests.control_utility.perf_stat_test fails sometimes. It's because ContinuousDataLoadApplication fails sometimes to warmup in default 60 seconds timeout (warmup consists of loading of 100_000 entries). At the same time it postpones the IGNITE_APPLICATION_INITIALIZED event until warmup complete. So test thinks application can not start and fails. As a solution the number of warmup entries can be safely reduced for this test. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20682) [ducktests] Add extension point to rebalance test
Sergey Korotkov created IGNITE-20682: Summary: [ducktests] Add extension point to rebalance test Key: IGNITE-20682 URL: https://issues.apache.org/jira/browse/IGNITE-20682 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov It's needed to add the extension point to the rebalance ducktests to be able to create subclasses to test rebalance with some extension modules or plugins applied. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20642) "control.sh --snapshot check" command returns 0 even if check fails
Sergey Korotkov created IGNITE-20642:
Summary: "control.sh --snapshot check" command returns 0 even if
check fails
Key: IGNITE-20642
URL: https://issues.apache.org/jira/browse/IGNITE-20642
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
Even if snapshot check fails the control.sh returns 0 (which is generally
considered as a success indicator).
Output contains both error messages about the check failures and final success
line
_Command [SNAPSHOT] finished with code: 0_
{noformat}
[2023-10-11T11:32:39,167][INFO ][session=93ebdf33][CommandHandlerLog] The check
procedure has failed, conflict partitions has been found: [counterConflicts=0,
hashConflicts=1024]
[2023-10-11T11:32:39,168][INFO ][session=93ebdf33][CommandHandlerLog] Hash
conflicts:
[2023-10-11T11:32:39,219][INFO ][session=93ebdf33][CommandHandlerLog] Conflict
partition: PartitionKeyV2 [grpId=1845542353, grpName=sql_cache, partId=455]
[2023-10-11T11:32:39,223][INFO ][session=93ebdf33][CommandHandlerLog] Partition
instances: [PartitionHashRecordV2 [isPrimary=false, consistentId=ducker06,
updateCntr=null, partitionState=OWNING, size=960, partHash=371088385,
partVerHash=0], PartitionHashRecordV2 [isPrimary=false, consistentId=ducker09,
updateCntr=null, partitionState=OWNING, size=0, partHash=0, partVerHash=0]]
...
[2023-10-11T11:32:39,486][INFO ][session=93ebdf33][CommandHandlerLog] Command
[SNAPSHOT] finished with code: 0
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20641) Entries added via data streamer to persistent cache are not written to cache dump
[
https://issues.apache.org/jira/browse/IGNITE-20641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20641:
-
Labels: IEP-109 (was: )
> Entries added via data streamer to persistent cache are not written to cache
> dump
> -
>
> Key: IGNITE-20641
> URL: https://issues.apache.org/jira/browse/IGNITE-20641
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Minor
> Labels: IEP-109
>
> Steps to reproduce the problem:
> * start ignite with persistence
> * load some entries via the data streamer
> * restart ignite
> * create cache dump
> * check cache dump consistency
> Consistency check would fail with errors like
> {noformat}
> [2023-10-11T12:13:28,711][INFO ][session=427e7c47][CommandHandlerLog] Hash
> conflicts:
> [2023-10-11T12:13:28,721][INFO ][session=427e7c47][CommandHandlerLog]
> Conflict partition: PartitionKeyV2 [grpId=-1988013461, grpName=test-cache-1,
> partId=947]
> [2023-10-11T12:13:28,725][INFO ][session=427e7c47][CommandHandlerLog]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=ducker03, updateCntr=null, partitionState=OWNING, size=0,
> partHash=0, partVerHash=0], PartitionHashRecordV2 [isPrimary=false,
> consistentId=ducker02, updateCntr=null, partitionState=OWNING, size=48,
> partHash=731883010, partVerHash=0]]
> {noformat}
> *.dump files on primary are empty, but on backups are not.
> ---
> Reason is that after ignite restart such records are always considered to be
> added after dump creation start in CreateDumpFutureTask::isAfterStart. That
> is because entries added via the datastreamer have version equal to
> isolatedStreamerVer but isolatedStreamerVer changes on each ignite restart
> and isolatedStreamerVer is always greater than startVer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20641) Entries added via data streamer to persistent cache are not written to cache dump
[
https://issues.apache.org/jira/browse/IGNITE-20641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20641:
-
Labels: IEP-109 ise (was: IEP-109)
> Entries added via data streamer to persistent cache are not written to cache
> dump
> -
>
> Key: IGNITE-20641
> URL: https://issues.apache.org/jira/browse/IGNITE-20641
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Minor
> Labels: IEP-109, ise
>
> Steps to reproduce the problem:
> * start ignite with persistence
> * load some entries via the data streamer
> * restart ignite
> * create cache dump
> * check cache dump consistency
> Consistency check would fail with errors like
> {noformat}
> [2023-10-11T12:13:28,711][INFO ][session=427e7c47][CommandHandlerLog] Hash
> conflicts:
> [2023-10-11T12:13:28,721][INFO ][session=427e7c47][CommandHandlerLog]
> Conflict partition: PartitionKeyV2 [grpId=-1988013461, grpName=test-cache-1,
> partId=947]
> [2023-10-11T12:13:28,725][INFO ][session=427e7c47][CommandHandlerLog]
> Partition instances: [PartitionHashRecordV2 [isPrimary=false,
> consistentId=ducker03, updateCntr=null, partitionState=OWNING, size=0,
> partHash=0, partVerHash=0], PartitionHashRecordV2 [isPrimary=false,
> consistentId=ducker02, updateCntr=null, partitionState=OWNING, size=48,
> partHash=731883010, partVerHash=0]]
> {noformat}
> *.dump files on primary are empty, but on backups are not.
> ---
> Reason is that after ignite restart such records are always considered to be
> added after dump creation start in CreateDumpFutureTask::isAfterStart. That
> is because entries added via the datastreamer have version equal to
> isolatedStreamerVer but isolatedStreamerVer changes on each ignite restart
> and isolatedStreamerVer is always greater than startVer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20641) Entries added via data streamer to persistent cache are not written to cache dump
Sergey Korotkov created IGNITE-20641:
Summary: Entries added via data streamer to persistent cache are
not written to cache dump
Key: IGNITE-20641
URL: https://issues.apache.org/jira/browse/IGNITE-20641
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
Steps to reproduce the problem:
* start ignite with persistence
* load some entries via the data streamer
* restart ignite
* create cache dump
* check cache dump consistency
Consistency check would fail with errors like
{noformat}
[2023-10-11T12:13:28,711][INFO ][session=427e7c47][CommandHandlerLog] Hash
conflicts:
[2023-10-11T12:13:28,721][INFO ][session=427e7c47][CommandHandlerLog] Conflict
partition: PartitionKeyV2 [grpId=-1988013461, grpName=test-cache-1, partId=947]
[2023-10-11T12:13:28,725][INFO ][session=427e7c47][CommandHandlerLog] Partition
instances: [PartitionHashRecordV2 [isPrimary=false, consistentId=ducker03,
updateCntr=null, partitionState=OWNING, size=0, partHash=0, partVerHash=0],
PartitionHashRecordV2 [isPrimary=false, consistentId=ducker02, updateCntr=null,
partitionState=OWNING, size=48, partHash=731883010, partVerHash=0]]
{noformat}
*.dump files on primary are empty, but on backups are not.
---
Reason is that after ignite restart such records are always considered to be
added after dump creation start in CreateDumpFutureTask::isAfterStart. That is
because entries added via the datastreamer have version equal to
isolatedStreamerVer but isolatedStreamerVer changes on each ignite restart and
isolatedStreamerVer is always greater than startVer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-20572) AssertionError in CDC on metadata deserialize
[ https://issues.apache.org/jira/browse/IGNITE-20572 ]
Sergey Korotkov deleted comment on IGNITE-20572:
--
was (Author: JIRAUSER279895):
Possible solution would be say to change the
BinaryMetadataFileStore.writeMetadata to create file atomically.
The same way as in the MarshallerMappingFileStore.writeMapping using the
ATOMIC_MOVE.
> AssertionError in CDC on metadata deserialize
> -
>
> Key: IGNITE-20572
> URL: https://issues.apache.org/jira/browse/IGNITE-20572
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise
>
> CDC process terminates sometimes with the below error.
> One the cases is cache creation which causes the creation of the .bin file in
> the binary_meta directory. Say if custom indexed types are passed via the
> CacheConfiguration.setIndexedTypes.
> Looks like the race condition. CDC processed the binary meta file which is
> already created but still empty.
> {noformat}
> [2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
> ~[classes/:?]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> ~[?:?]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> ~[?:?]
> at
> java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
> ~[?:?]
> at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
> at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
> [classes/:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> ***
> Possible solution would be to change the
> BinaryMetadataFileStore.writeMetadata to create file atomically.
> The same way as in the MarshallerMappingFileStore.writeMapping using the
> ATOMIC_MOVE.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20572) AssertionError in CDC on metadata deserialize
[
https://issues.apache.org/jira/browse/IGNITE-20572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20572:
-
Description:
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) ~[?:?]
at
java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
~[?:?]
at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
[classes/:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
***
Possible solution would be to change the BinaryMetadataFileStore.writeMetadata
to create file atomically.
The same way as in the MarshallerMappingFileStore.writeMapping using the
ATOMIC_MOVE.
was:
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
[jira] [Commented] (IGNITE-20572) AssertionError in CDC on metadata deserialize
[
https://issues.apache.org/jira/browse/IGNITE-20572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772149#comment-17772149
]
Sergey Korotkov commented on IGNITE-20572:
--
Possible solution would be say to change the
BinaryMetadataFileStore.writeMetadata to create file atomically.
The same way as in the MarshallerMappingFileStore.writeMapping using the
ATOMIC_MOVE.
> AssertionError in CDC on metadata deserialize
> -
>
> Key: IGNITE-20572
> URL: https://issues.apache.org/jira/browse/IGNITE-20572
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise
>
> CDC process terminates sometimes with the below error.
> One the cases is cache creation which causes the creation of the .bin file in
> the binary_meta directory. Say if custom indexed types are passed via the
> CacheConfiguration.setIndexedTypes.
> Looks like the race condition. CDC processed the binary meta file which is
> already created but still empty.
> {noformat}
> [2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
> ~[classes/:?]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> ~[?:?]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> ~[?:?]
> at
> java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
> ~[?:?]
> at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
> at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
> [classes/:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20572) AssertionError in CDC on metadata deserialize
[
https://issues.apache.org/jira/browse/IGNITE-20572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20572:
-
Description:
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) ~[?:?]
at
java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
~[?:?]
at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
[classes/:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
***
Possible solution would be say to change the
BinaryMetadataFileStore.writeMetadata to create file atomically (via
was:
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
[jira] [Updated] (IGNITE-20572) AssertionError in CDC on metadata deserialize
[
https://issues.apache.org/jira/browse/IGNITE-20572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20572:
-
Description:
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) ~[?:?]
at
java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
~[?:?]
at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
[classes/:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
was:
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) ~[?:?]
at
java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:?]
at
[jira] [Updated] (IGNITE-20572) AssertionError in CDC on metadata deserialize
[
https://issues.apache.org/jira/browse/IGNITE-20572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20572:
-
Labels: ise (was: )
> AssertionError in CDC on metadata deserialize
> -
>
> Key: IGNITE-20572
> URL: https://issues.apache.org/jira/browse/IGNITE-20572
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise
>
> CDC process terminates sometimes with the below error.
> One the cases is cache creation which causes the creation of the .bin file in
> the binary_meta directory. Say if custom indexed types are passed via the
> CacheConfiguration.setIndexedTypes.
> Looks like the race condition. CDC processed the binary meta file which is
> already created but still empty.
> {noformat}
> [2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
> ~[classes/:?]
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
> ~[classes/:?]
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> ~[?:?]
> at
> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> ~[?:?]
> at
> java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
> ~[?:?]
> at
> java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
> ~[?:?]
> at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
> at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
> ~[classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
> [classes/:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20572) AssertionError in CDC on metadata deserialize
Sergey Korotkov created IGNITE-20572:
Summary: AssertionError in CDC on metadata deserialize
Key: IGNITE-20572
URL: https://issues.apache.org/jira/browse/IGNITE-20572
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
CDC process terminates sometimes with the below error.
One the cases is cache creation which causes the creation of the .bin file in
the binary_meta directory. Say if custom indexed types are passed via the
CacheConfiguration.setIndexedTypes.
Looks like the race condition. CDC processed the binary meta file which is
already created but still empty.
{noformat}
[2023-10-04T22:29:32,673][ERROR][Thread-0][] Cdc error
java.lang.AssertionError: null
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:302)
~[classes/:?]
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:120)
~[classes/:?]
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:92)
~[classes/:?]
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10761)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:222)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore.restoreMetadata(BinaryMetadataFileStore.java:216)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.cacheMetadataLocally(CacheObjectBinaryProcessorImpl.java:1076)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.lambda$updateTypes$4(CdcMain.java:616)
~[classes/:?]
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at
java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) ~[?:?]
at
java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958) ~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.lambda$initPartialTraversalState$0(StreamSpliterators.java:294)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.fillBuffer(StreamSpliterators.java:206)
~[?:?]
at
java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:161)
~[?:?]
at
java.util.stream.StreamSpliterators$WrappingSpliterator.tryAdvance(StreamSpliterators.java:300)
~[?:?]
at java.util.Spliterators$1Adapter.hasNext(Spliterators.java:681) ~[?:?]
at org.apache.ignite.internal.cdc.CdcMain.updateTypes(CdcMain.java:627)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.updateMetadata(CdcMain.java:588)
~[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:463)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:324)
~[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:266)
[classes/:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20470) Ducktape to check dump performance
[ https://issues.apache.org/jira/browse/IGNITE-20470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-20470: Assignee: Sergey Korotkov > Ducktape to check dump performance > -- > > Key: IGNITE-20470 > URL: https://issues.apache.org/jira/browse/IGNITE-20470 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Sergey Korotkov >Priority: Major > Labels: IEP-109, ise > > Dump creation can affect transactions performance with change listener and > disc operations. We must create ducktape test to check this. > Example test scenario: > * Start nodes > * Start transaction operations: insert, update, remove. > * Create dump > * Check dump consistency. > Measure > * Transaction performance penalty. > * GC utilization. > * Disc utilization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Labels: iep-97 ise (was: ise ise-97)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: iep-97, ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Labels: ise ise-97 (was: ise)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise, ise-97
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Description:
CDC doesn't work If some cache objects transformation is applied (see the
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation]).
ignite_cdc.sh utility produces the NPE (see below). The immediate reason of the
NPE is that ignite_cdc.sh uses the reduced version of the context
(StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
{noformat}
[2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
[CacheObjectImpl [val=null, hasValBytes=true]]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
~[classes/:?]
at
org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
~[classes/:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
[classes/:?]
at
org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344) [classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
{noformat}
was:
CDC doesn't work If some cache objects transformation is applied (see the
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
ignite_cdc.sh utility produces the NPE (see below). The immediate reason of the
NPE is that ignite_cdc.sh uses the reduced version of the context
(StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
{noformat}
[2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
[CacheObjectImpl [val=null, hasValBytes=true]]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
~[classes/:?]
at
org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
~[classes/:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
[classes/:?]
at
[jira] [Updated] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
[
https://issues.apache.org/jira/browse/IGNITE-20528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-20528:
-
Labels: ise (was: iep-97 ise)
> CDC doesn't work if the "Cache objects transformation" is applied
> -
>
> Key: IGNITE-20528
> URL: https://issues.apache.org/jira/browse/IGNITE-20528
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Major
> Labels: ise
>
> CDC doesn't work If some cache objects transformation is applied (see the
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
> ignite_cdc.sh utility produces the NPE (see below). The immediate reason of
> the NPE is that ignite_cdc.sh uses the reduced version of the context
> (StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
>
> {noformat}
> [2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
> [CacheObjectImpl [val=null, hasValBytes=true]]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
> ~[classes/:?]
> at
> org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
> ~[classes/:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
> [classes/:?]
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> [classes/:?]
> at
> org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
> [ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
> [classes/:?]
> at
> org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344)
> [classes/:?]
> at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20528) CDC doesn't work if the "Cache objects transformation" is applied
Sergey Korotkov created IGNITE-20528:
Summary: CDC doesn't work if the "Cache objects transformation" is
applied
Key: IGNITE-20528
URL: https://issues.apache.org/jira/browse/IGNITE-20528
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
CDC doesn't work If some cache objects transformation is applied (see the
[https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation).|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97+Cache+objects+transformation)]
ignite_cdc.sh utility produces the NPE (see below). The immediate reason of the
NPE is that ignite_cdc.sh uses the reduced version of the context
(StandaloneGridKernalContext), which doesn't contain the GridCacheProcessor.
{noformat}
[2023-10-02T10:43:32,017][ERROR][Thread-1][] Unable to convert value
[CacheObjectImpl [val=null, hasValBytes=true]]
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.transformer(CacheObjectTransformerUtils.java:32)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectTransformerUtils.restoreIfNecessary(CacheObjectTransformerUtils.java:120)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectAdapter.valueFromValueBytes(CacheObjectAdapter.java:73)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:92)
~[classes/:?]
at
org.apache.ignite.internal.processors.cache.CacheObjectImpl.value(CacheObjectImpl.java:58)
~[classes/:?]
at
org.apache.ignite.internal.pagemem.wal.record.UnwrapDataEntry.unwrappedValue(UnwrapDataEntry.java:104)
~[classes/:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.lambda$static$c56580e2$1(WalRecordsConsumer.java:99)
~[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.nextX(TransformFilteringIterator.java:119)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:35)
[classes/:?]
at
org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNextX(TransformFilteringIterator.java:85)
[classes/:?]
at
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
[classes/:?]
at
org.apache.ignite.cdc.AbstractCdcEventsApplier.apply(AbstractCdcEventsApplier.java:71)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.cdc.AbstractIgniteCdcStreamer.onEvents(AbstractIgniteCdcStreamer.java:118)
[ignite-cdc-ext-1.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.cdc.WalRecordsConsumer.onRecords(WalRecordsConsumer.java:142)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeSegmentActively(CdcMain.java:557)
[classes/:?]
at
org.apache.ignite.internal.cdc.CdcMain.consumeWalSegmentsUntilStopped(CdcMain.java:496)
[classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.runX(CdcMain.java:344) [classes/:?]
at org.apache.ignite.internal.cdc.CdcMain.run(CdcMain.java:283) [classes/:?]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-19729:
-
Description:
To test the new calcite sql query engine the sqlConfiguration field in ignite
configuration should be supported in ducktests.
Additional small ducktests fixes were also included in scope:
* Add ability to run arbitrary control.sh subcommand.
* It appears that {{pgrep}} on some linuxes (centos) cuts long command lines
(say with long list of jars in classpath) even if '-a' option is specified. So
ducktape fails to detect the PID of the service java process. Rewrite via the
{{ps}}.
* One of the source of long command lines was a bug that IgniteSpec adds
modules to service modules list each time the new node started. So say the 6th
node gets command line with the same jar modules mentioned 6 times and the
corresponing command line exceed limit for the {{pgrep}}.
was:
To test the new calcite sql query engine the sqlConfiguration field in ignite
configuration should be supported in ducktests.
Additional small ducktests fixes were also included in scope:
* Add ability to run arbitrary control.sh subcommand.
* It appears that `pgrep` on some linuxes (centos) cuts long command lines
(say with long list of jars in classpath) even if '-a' option is specified. So
ducktape fails to detect the PID of the service java process. Rewrite via the
`ps`.
* One of the source of long command lines was a bug that IgniteSpec adds
modules to service modules list each time the new node started. So say the 6th
node gets command line with the same jar modules mentioned 6 times and the
corresponing command line exceed limit for the `pgrep`.
> [ducktests] Support sqlConfiguration field in ignite configuration
> --
>
> Key: IGNITE-19729
> URL: https://issues.apache.org/jira/browse/IGNITE-19729
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Trivial
> Labels: ducktests
> Time Spent: 50m
> Remaining Estimate: 0h
>
> To test the new calcite sql query engine the sqlConfiguration field in ignite
> configuration should be supported in ducktests.
> Additional small ducktests fixes were also included in scope:
> * Add ability to run arbitrary control.sh subcommand.
> * It appears that {{pgrep}} on some linuxes (centos) cuts long command lines
> (say with long list of jars in classpath) even if '-a' option is specified.
> So ducktape fails to detect the PID of the service java process. Rewrite via
> the {{ps}}.
> * One of the source of long command lines was a bug that IgniteSpec adds
> modules to service modules list each time the new node started. So say the
> 6th node gets command line with the same jar modules mentioned 6 times and
> the corresponing command line exceed limit for the {{pgrep}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19729: - Description: To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. Additional small ducktests fixes were also included in scope: * Add ability to run arbitrary control.sh subcommand. * It appears that `pgrep` on some linuxes (centos) cuts long command lines (say with long list of jars in classpath) even if '-a' option is specified. So ducktape fails to detect the PID of the service java process. Rewrite via the `ps`. * One of the source of long command lines was a bug that IgniteSpec adds modules to service modules list each time the new node started. So say the 6th node gets command line with the same jar modules mentioned 6 times and the corresponing command line exceed limit for th. was: To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. Additional small ducktests fixes were also included in scope: * Add ability to run arbitrary control.sh subcommand. * It appears that `pgrep` on some linuxes (centos) cuts long command lines even if 'a' option is specified (say with long list of jars in classpath), so ducktape fails to detect the PID of the service java process. Rewrite via the `ps`. * One of the source of long command lines was a bug that IgniteSpec adds modules to service modules list each time the new node started. So say the 6th node gets command line with the same jar modules mentioned 6 times and the corresponing command line exceed limit for th. > [ducktests] Support sqlConfiguration field in ignite configuration > -- > > Key: IGNITE-19729 > URL: https://issues.apache.org/jira/browse/IGNITE-19729 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Trivial > Labels: ducktests > Time Spent: 50m > Remaining Estimate: 0h > > To test the new calcite sql query engine the sqlConfiguration field in ignite > configuration should be supported in ducktests. > Additional small ducktests fixes were also included in scope: > * Add ability to run arbitrary control.sh subcommand. > * It appears that `pgrep` on some linuxes (centos) cuts long command lines > (say with long list of jars in classpath) even if '-a' option is specified. > So ducktape fails to detect the PID of the service java process. Rewrite via > the `ps`. > * One of the source of long command lines was a bug that IgniteSpec adds > modules to service modules list each time the new node started. So say the > 6th node gets command line with the same jar modules mentioned 6 times and > the corresponing command line exceed limit for th. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19729: - Description: To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. Additional small ducktests fixes were also included in scope: * Add ability to run arbitrary control.sh subcommand. * It appears that `pgrep` on some linuxes (centos) cuts long command lines (say with long list of jars in classpath) even if '-a' option is specified. So ducktape fails to detect the PID of the service java process. Rewrite via the `ps`. * One of the source of long command lines was a bug that IgniteSpec adds modules to service modules list each time the new node started. So say the 6th node gets command line with the same jar modules mentioned 6 times and the corresponing command line exceed limit for the `pgrep`. was: To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. Additional small ducktests fixes were also included in scope: * Add ability to run arbitrary control.sh subcommand. * It appears that `pgrep` on some linuxes (centos) cuts long command lines (say with long list of jars in classpath) even if '-a' option is specified. So ducktape fails to detect the PID of the service java process. Rewrite via the `ps`. * One of the source of long command lines was a bug that IgniteSpec adds modules to service modules list each time the new node started. So say the 6th node gets command line with the same jar modules mentioned 6 times and the corresponing command line exceed limit for th. > [ducktests] Support sqlConfiguration field in ignite configuration > -- > > Key: IGNITE-19729 > URL: https://issues.apache.org/jira/browse/IGNITE-19729 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Trivial > Labels: ducktests > Time Spent: 50m > Remaining Estimate: 0h > > To test the new calcite sql query engine the sqlConfiguration field in ignite > configuration should be supported in ducktests. > Additional small ducktests fixes were also included in scope: > * Add ability to run arbitrary control.sh subcommand. > * It appears that `pgrep` on some linuxes (centos) cuts long command lines > (say with long list of jars in classpath) even if '-a' option is specified. > So ducktape fails to detect the PID of the service java process. Rewrite via > the `ps`. > * One of the source of long command lines was a bug that IgniteSpec adds > modules to service modules list each time the new node started. So say the > 6th node gets command line with the same jar modules mentioned 6 times and > the corresponing command line exceed limit for the `pgrep`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19729: - Description: To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. Additional small ducktests fixes were also included in scope: * Add ability to run arbitrary control.sh subcommand. * It appears that `pgrep` on some linuxes (centos) cuts long command lines even if 'a' option is specified (say with long list of jars in classpath), so ducktape fails to detect the PID of the service java process. Rewrite via the `ps`. * One of the source of long command lines was a bug that IgniteSpec adds modules to service modules list each time the new node started. So say the 6th node gets command line with the same jar modules mentioned 6 times and the corresponing command line exceed limit for th. was:To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. > [ducktests] Support sqlConfiguration field in ignite configuration > -- > > Key: IGNITE-19729 > URL: https://issues.apache.org/jira/browse/IGNITE-19729 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Trivial > Labels: ducktests > Time Spent: 50m > Remaining Estimate: 0h > > To test the new calcite sql query engine the sqlConfiguration field in ignite > configuration should be supported in ducktests. > Additional small ducktests fixes were also included in scope: > * Add ability to run arbitrary control.sh subcommand. > * It appears that `pgrep` on some linuxes (centos) cuts long command lines > even if 'a' option is specified (say with long list of jars in classpath), so > ducktape fails to detect the PID of the service java process. Rewrite via the > `ps`. > * One of the source of long command lines was a bug that IgniteSpec adds > modules to service modules list each time the new node started. So say the > 6th node gets command line with the same jar modules mentioned 6 times and > the corresponing command line exceed limit for th. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19746) control.sh --performance-statistics status doesn't not print actual status
[
https://issues.apache.org/jira/browse/IGNITE-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17744591#comment-17744591
]
Sergey Korotkov edited comment on IGNITE-19746 at 7/20/23 6:21 AM:
---
after the IGNITE-19676 start, stop and rotate sub-commands still do not print
operation result
was (Author: JIRAUSER279895):
start, stop and rotate sub-commands still not print operation result
> control.sh --performance-statistics status doesn't not print actual status
> --
>
> Key: IGNITE-19746
> URL: https://issues.apache.org/jira/browse/IGNITE-19746
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: IEP-81, ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The status sub-command of the control.sh --performance-statistics doesn't not
> print the actual status to console.
> Previously it was like (note the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230422-sha1:7f80003d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-04-23T22:17:12.489
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Disabled.
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-04-23T22:17:13.271
> Execution time: 782 ms
> {noformat}
>
> Now it's like (note the absence of the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230613-sha1:cacee58d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-06-15T15:46:41.586
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-06-15T15:46:42.523
> Execution time: 937 ms
> {noformat}
>
> Outputs of other sub-commands are also need to be checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (IGNITE-19746) control.sh --performance-statistics status doesn't not print actual status
[
https://issues.apache.org/jira/browse/IGNITE-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov reopened IGNITE-19746:
--
Assignee: Sergey Korotkov (was: Nikolay Izhikov)
start, stop and rotate sub-commands still not print operation result
> control.sh --performance-statistics status doesn't not print actual status
> --
>
> Key: IGNITE-19746
> URL: https://issues.apache.org/jira/browse/IGNITE-19746
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: IEP-81, ise
>
> The status sub-command of the control.sh --performance-statistics doesn't not
> print the actual status to console.
> Previously it was like (note the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230422-sha1:7f80003d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-04-23T22:17:12.489
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Disabled.
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-04-23T22:17:13.271
> Execution time: 782 ms
> {noformat}
>
> Now it's like (note the absence of the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230613-sha1:cacee58d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-06-15T15:46:41.586
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-06-15T15:46:42.523
> Execution time: 937 ms
> {noformat}
>
> Outputs of other sub-commands are also need to be checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19746) control.sh --performance-statistics status doesn't not print actual status
[
https://issues.apache.org/jira/browse/IGNITE-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-19746:
-
Labels: IEP-81 ise (was: IEP-81)
> control.sh --performance-statistics status doesn't not print actual status
> --
>
> Key: IGNITE-19746
> URL: https://issues.apache.org/jira/browse/IGNITE-19746
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-81, ise
>
> The status sub-command of the control.sh --performance-statistics doesn't not
> print the actual status to console.
> Previously it was like (note the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230422-sha1:7f80003d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-04-23T22:17:12.489
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Disabled.
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-04-23T22:17:13.271
> Execution time: 782 ms
> {noformat}
>
> Now it's like (note the absence of the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230613-sha1:cacee58d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-06-15T15:46:41.586
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-06-15T15:46:42.523
> Execution time: 937 ms
> {noformat}
>
> Outputs of other sub-commands are also need to be checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19814) Calcite engine uses 0 as an inlineSize for index created by INT column
[
https://issues.apache.org/jira/browse/IGNITE-19814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-19814:
-
Labels: calcite (was: )
> Calcite engine uses 0 as an inlineSize for index created by INT column
> --
>
> Key: IGNITE-19814
> URL: https://issues.apache.org/jira/browse/IGNITE-19814
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Minor
> Labels: calcite
> Attachments:
> 0001-IGNITE-19814-Add-calcite-test-for-integer-column-ind.patch
>
>
> Using the Calcite query engine the following SQL statement
> {code:sql}
> CREATE TABLE TEST (id INT, name VARCHAR, PRIMARY KEY(id))
> {code}
> creates index for INT id column with the inlineSize = 0.
> If the _key_type_ is specified in the WITH clause index is created correctly
> with the inlineSize = 5:
> {code:sql}
> CREATE TABLE TEST (id INT, name VARCHAR, PRIMARY KEY(id))
> WITH "key_type=Integer"
> {code}
> For H2 engine in both cases inlineSize is 5.
> Reproducer is attached as a unit test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19814) Calcite engine uses 0 as an inlineSize for index created by INT column
[
https://issues.apache.org/jira/browse/IGNITE-19814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-19814:
-
Attachment: 0001-IGNITE-19814-Add-calcite-test-for-integer-column-ind.patch
> Calcite engine uses 0 as an inlineSize for index created by INT column
> --
>
> Key: IGNITE-19814
> URL: https://issues.apache.org/jira/browse/IGNITE-19814
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Korotkov
>Priority: Minor
> Attachments:
> 0001-IGNITE-19814-Add-calcite-test-for-integer-column-ind.patch
>
>
> Using the Calcite query engine the following SQL statement
> {code:sql}
> CREATE TABLE TEST (id INT, name VARCHAR, PRIMARY KEY(id))
> {code}
> creates index for INT id column with the inlineSize = 0.
> If the _key_type_ is specified in the WITH clause index is created correctly
> with the inlineSize = 5:
> {code:sql}
> CREATE TABLE TEST (id INT, name VARCHAR, PRIMARY KEY(id))
> WITH "key_type=Integer"
> {code}
> For H2 engine in both cases inlineSize is 5.
> Reproducer is attached as a unit test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19814) Calcite engine uses 0 as an inlineSize for index created by INT column
Sergey Korotkov created IGNITE-19814:
Summary: Calcite engine uses 0 as an inlineSize for index created
by INT column
Key: IGNITE-19814
URL: https://issues.apache.org/jira/browse/IGNITE-19814
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
Using the Calcite query engine the following SQL statement
{code:sql}
CREATE TABLE TEST (id INT, name VARCHAR, PRIMARY KEY(id))
{code}
creates index for INT id column with the inlineSize = 0.
If the _key_type_ is specified in the WITH clause index is created correctly
with the inlineSize = 5:
{code:sql}
CREATE TABLE TEST (id INT, name VARCHAR, PRIMARY KEY(id))
WITH "key_type=Integer"
{code}
For H2 engine in both cases inlineSize is 5.
Reproducer is attached as a unit test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19729: - Description: To test the new calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. (was: To test the ne calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests.) > [ducktests] Support sqlConfiguration field in ignite configuration > -- > > Key: IGNITE-19729 > URL: https://issues.apache.org/jira/browse/IGNITE-19729 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Trivial > Labels: ducktests > Time Spent: 20m > Remaining Estimate: 0h > > To test the new calcite sql query engine the sqlConfiguration field in ignite > configuration should be supported in ducktests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19729: - Description: To test the ne calcite sql query engine the sqlConfiguration field in ignite configuration should be supported in ducktests. (was: To test the ne calcite sql query engine the ) > [ducktests] Support sqlConfiguration field in ignite configuration > -- > > Key: IGNITE-19729 > URL: https://issues.apache.org/jira/browse/IGNITE-19729 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Trivial > Labels: ducktests > Time Spent: 20m > Remaining Estimate: 0h > > To test the ne calcite sql query engine the sqlConfiguration field in ignite > configuration should be supported in ducktests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
[ https://issues.apache.org/jira/browse/IGNITE-19729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19729: - Description: To test the ne calcite sql query engine the > [ducktests] Support sqlConfiguration field in ignite configuration > -- > > Key: IGNITE-19729 > URL: https://issues.apache.org/jira/browse/IGNITE-19729 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Trivial > Labels: ducktests > Time Spent: 20m > Remaining Estimate: 0h > > To test the ne calcite sql query engine the -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19746) control.sh --performance-statistics status doesn't not print actual status
[
https://issues.apache.org/jira/browse/IGNITE-19746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-19746:
-
Summary: control.sh --performance-statistics status doesn't not print
actual status (was: control.sh --performance-statistics status do not print
actual status)
> control.sh --performance-statistics status doesn't not print actual status
> --
>
> Key: IGNITE-19746
> URL: https://issues.apache.org/jira/browse/IGNITE-19746
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Priority: Minor
>
> The status sub-command of the control.sh --performance-statistics doesn't not
> print the actual status to console.
> Previously it was like (note the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230422-sha1:7f80003d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-04-23T22:17:12.489
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Disabled.
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-04-23T22:17:13.271
> Execution time: 782 ms
> {noformat}
>
> Now it's like (note the absence of the *Disabled.* word):
> {noformat}
> Control utility [ver. 15.0.0-SNAPSHOT#20230613-sha1:cacee58d]
> 2023 Copyright(C) Apache Software Foundation
> User: ducker
> Time: 2023-06-15T15:46:41.586
> Command [PERFORMANCE-STATISTICS] started
> Arguments: --host x.x.x.x --performance-statistics status --user admin
> --password *
>
> Command [PERFORMANCE-STATISTICS] finished with code: 0
> Control utility has completed execution at: 2023-06-15T15:46:42.523
> Execution time: 937 ms
> {noformat}
>
> Outputs of other sub-commands are also need to be checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19746) control.sh --performance-statistics status do not print actual status
Sergey Korotkov created IGNITE-19746:
Summary: control.sh --performance-statistics status do not print
actual status
Key: IGNITE-19746
URL: https://issues.apache.org/jira/browse/IGNITE-19746
Project: Ignite
Issue Type: Task
Reporter: Sergey Korotkov
The status sub-command of the control.sh --performance-statistics doesn't not
print the actual status to console.
Previously it was like (note the *Disabled.* word):
{noformat}
Control utility [ver. 15.0.0-SNAPSHOT#20230422-sha1:7f80003d]
2023 Copyright(C) Apache Software Foundation
User: ducker
Time: 2023-04-23T22:17:12.489
Command [PERFORMANCE-STATISTICS] started
Arguments: --host x.x.x.x --performance-statistics status --user admin
--password *
Disabled.
Command [PERFORMANCE-STATISTICS] finished with code: 0
Control utility has completed execution at: 2023-04-23T22:17:13.271
Execution time: 782 ms
{noformat}
Now it's like (note the absence of the *Disabled.* word):
{noformat}
Control utility [ver. 15.0.0-SNAPSHOT#20230613-sha1:cacee58d]
2023 Copyright(C) Apache Software Foundation
User: ducker
Time: 2023-06-15T15:46:41.586
Command [PERFORMANCE-STATISTICS] started
Arguments: --host x.x.x.x --performance-statistics status --user admin
--password *
Command [PERFORMANCE-STATISTICS] finished with code: 0
Control utility has completed execution at: 2023-06-15T15:46:42.523
Execution time: 937 ms
{noformat}
Outputs of other sub-commands are also need to be checked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19729) [ducktests] Support sqlConfiguration field in ignite configuration
Sergey Korotkov created IGNITE-19729: Summary: [ducktests] Support sqlConfiguration field in ignite configuration Key: IGNITE-19729 URL: https://issues.apache.org/jira/browse/IGNITE-19729 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19645) Suppress an illegal reflective access runtime warning for JDK11
[
https://issues.apache.org/jira/browse/IGNITE-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-19645:
-
Description:
Currently the following runtime warnings are printed to console by command line
utilities like ignite.sh or control.sh if used with JDK11:
{noformat}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/opt/ignite/libs/ignite-core-2.15.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}
{noformat}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker
(file:/opt/ignite-dev/modules/core/target/classes/) to field
sun.nio.ch.SelectorImpl.selectedKeys
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}
Other such warnings are suppressed by the corresponding _--add-opens_ JVM
options in the {{bin/include/jvmdefaults.sh}} (and
{{{}bin/include/jvmdefaults.bat{}}}) files. But not these ones.
Warning needs to be suppressed by the JVM options like
_--add-opens=java.base/java.nio=ALL-UNNAMED_
_--add-opens=java.base/sun.nio.ch=ALL-UNNAMED_
was:
Currently the following runtime warnings are printed to console by command line
utilities like ignite.sh or control.sh if used with JDK11:
{noformat}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/opt/ignite/libs/ignite-core-2.15.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}
Other such warnings are suppressed by the corresponding _--add-opens_ JVM
options in the {{bin/include/jvmdefaults.sh}} (and
{{{}bin/include/jvmdefaults.bat{}}}) files. But not this one.
Warning needs to be suppressed by the
_--add-opens=java.base/java.nio=ALL-UNNAMED_ JVM option.
> Suppress an illegal reflective access runtime warning for JDK11
> ---
>
> Key: IGNITE-19645
> URL: https://issues.apache.org/jira/browse/IGNITE-19645
> Project: Ignite
> Issue Type: Task
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the following runtime warnings are printed to console by command
> line utilities like ignite.sh or control.sh if used with JDK11:
>
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/opt/ignite/libs/ignite-core-2.15.0.jar) to field
> java.nio.Buffer.address
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.GridUnsafe$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
>
> {noformat}
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker
> (file:/opt/ignite-dev/modules/core/target/classes/) to field
> sun.nio.ch.SelectorImpl.selectedKeys
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> Other such warnings are suppressed by the corresponding _--add-opens_ JVM
> options in the {{bin/include/jvmdefaults.sh}} (and
> {{{}bin/include/jvmdefaults.bat{}}}) files. But not these ones.
> Warning needs to be suppressed by the JVM options like
> _--add-opens=java.base/java.nio=ALL-UNNAMED_
> _--add-opens=java.base/sun.nio.ch=ALL-UNNAMED_
--
[jira] [Created] (IGNITE-19645) Suppress an illegal reflective access runtime warning for JDK11
Sergey Korotkov created IGNITE-19645:
Summary: Suppress an illegal reflective access runtime warning for
JDK11
Key: IGNITE-19645
URL: https://issues.apache.org/jira/browse/IGNITE-19645
Project: Ignite
Issue Type: Task
Reporter: Sergey Korotkov
Assignee: Sergey Korotkov
Currently the following runtime warnings are printed to console by command line
utilities like ignite.sh or control.sh if used with JDK11:
{noformat}
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/opt/ignite/libs/ignite-core-2.15.0.jar) to field java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
{noformat}
Other such warnings are suppressed by the corresponding _--add-opens_ JVM
options in the {{bin/include/jvmdefaults.sh}} (and
{{{}bin/include/jvmdefaults.bat{}}}) files. But not this one.
Warning needs to be suppressed by the
_--add-opens=java.base/java.nio=ALL-UNNAMED_ JVM option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-19554) [ducktests] Allow to configure more options in communication and data storage
Sergey Korotkov created IGNITE-19554: Summary: [ducktests] Allow to configure more options in communication and data storage Key: IGNITE-19554 URL: https://issues.apache.org/jira/browse/IGNITE-19554 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov Assignee: Sergey Korotkov Ducktests need more options to be configurable _Data storage_ / _Data region_ * lazy_memory_allocation * page_size * wal_page_compression * wal_page_compression_level * wal_path * wal_archive_path _TcpCommunicationSpi_ * unacknowledged_messages_buffer_size -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19347) Update log4j2 version because of the performance regression
[ https://issues.apache.org/jira/browse/IGNITE-19347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19347: - Fix Version/s: 2.15 > Update log4j2 version because of the performance regression > --- > > Key: IGNITE-19347 > URL: https://issues.apache.org/jira/browse/IGNITE-19347 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > log4j2 dependency needs to be updated to v2.20.0 version because of a major > performance regression found in the v2.18.0. This bug affects the ignite > behaviour and can be discovered on the PutBenchmark in particular. > Details of the regression: https://github.com/apache/logging-log4j2/pull/1214 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19347) Update log4j2 version because of the performance regression
[ https://issues.apache.org/jira/browse/IGNITE-19347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19347: - Labels: ise (was: ) > Update log4j2 version because of the performance regression > --- > > Key: IGNITE-19347 > URL: https://issues.apache.org/jira/browse/IGNITE-19347 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Labels: ise > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > log4j2 dependency needs to be updated to v2.20.0 version because of a major > performance regression found in the v2.18.0. This bug affects the ignite > behaviour and can be discovered on the PutBenchmark in particular. > Details of the regression: https://github.com/apache/logging-log4j2/pull/1214 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19347) Update log4j2 version because of the performance regression
[ https://issues.apache.org/jira/browse/IGNITE-19347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19347: - Summary: Update log4j2 version because of the performance regression (was: Update log4j2 version because of a major performance regression) > Update log4j2 version because of the performance regression > --- > > Key: IGNITE-19347 > URL: https://issues.apache.org/jira/browse/IGNITE-19347 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > log4j2 dependency needs to be updated to v2.20.0 version because of a major > performance regression found in the v2.18.0. This bug affects the ignite > behaviour and can be discovered on the PutBenchmark in particular. > Details of the regression: https://github.com/apache/logging-log4j2/pull/1214 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19347) Update log4j2 version because of a major performance regression
[ https://issues.apache.org/jira/browse/IGNITE-19347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-19347: Assignee: Sergey Korotkov > Update log4j2 version because of a major performance regression > --- > > Key: IGNITE-19347 > URL: https://issues.apache.org/jira/browse/IGNITE-19347 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > log4j2 dependency needs to be updated to v2.20.0 version because of a major > performance regression found in the v2.18.0. This bug affects the ignite > behaviour and can be discovered on the PutBenchmark in particular. > Details of the regression: https://github.com/apache/logging-log4j2/pull/1214 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19347) Update log4j2 version because of a major performance regression
Sergey Korotkov created IGNITE-19347: Summary: Update log4j2 version because of a major performance regression Key: IGNITE-19347 URL: https://issues.apache.org/jira/browse/IGNITE-19347 Project: Ignite Issue Type: Task Reporter: Sergey Korotkov log4j2 dependency needs to be updated to v2.20.0 version because of a major performance regression found in the v2.18.0. This bug affects the ignite behaviour and can be discovered on the PutBenchmark in particular. Details of the regression: https://github.com/apache/logging-log4j2/pull/1214 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19140) [ducktests] Fix classpaths for modules in IgniteSpec
[ https://issues.apache.org/jira/browse/IGNITE-19140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19140: - Fix Version/s: 2.15 > [ducktests] Fix classpaths for modules in IgniteSpec > > > Key: IGNITE-19140 > URL: https://issues.apache.org/jira/browse/IGNITE-19140 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Fix modules classpaths in dev-mode. > Add more extension abilities for 3rd party modules via 3rd party specs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19140) [ducktests] Fix classpaths for modules in IgniteSpec
[ https://issues.apache.org/jira/browse/IGNITE-19140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-19140: - Description: Fix modules classpaths in dev-mode. Add more extension abilities for 3rd party modules via 3rd party specs. was:tbd > [ducktests] Fix classpaths for modules in IgniteSpec > > > Key: IGNITE-19140 > URL: https://issues.apache.org/jira/browse/IGNITE-19140 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 20m > Remaining Estimate: 0h > > Fix modules classpaths in dev-mode. > Add more extension abilities for 3rd party modules via 3rd party specs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19140) [ducktests] Fix classpaths for modules in IgniteSpec
Sergey Korotkov created IGNITE-19140: Summary: [ducktests] Fix classpaths for modules in IgniteSpec Key: IGNITE-19140 URL: https://issues.apache.org/jira/browse/IGNITE-19140 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Assignee: Sergey Korotkov tbd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19117) [ducktests] Partition awareness mode can not be disabled in thin client config
Sergey Korotkov created IGNITE-19117: Summary: [ducktests] Partition awareness mode can not be disabled in thin client config Key: IGNITE-19117 URL: https://issues.apache.org/jira/browse/IGNITE-19117 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Assignee: Sergey Korotkov Currently the partition awareness mode (enabled by default) can not be disabled via the thin client config in ducktest. The couse of the problem is error in the client_configuration_macro.j2 template. It just would not include the _partitionAwarenessEnabled_ property to XML configuration file if config.partition_awareness_enabled == False -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19064) [ducktests] Allow several server node addresses in thin client configuration
Sergey Korotkov created IGNITE-19064: Summary: [ducktests] Allow several server node addresses in thin client configuration Key: IGNITE-19064 URL: https://issues.apache.org/jira/browse/IGNITE-19064 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Assignee: Sergey Korotkov Currently the only server node address can be specified in the thin client configuration. It should be possible to pass several ones. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18936) [ducktests] Fix parse of the control.sh --baseline output
[ https://issues.apache.org/jira/browse/IGNITE-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-18936: Assignee: Sergey Korotkov > [ducktests] Fix parse of the control.sh --baseline output > - > > Key: IGNITE-18936 > URL: https://issues.apache.org/jira/browse/IGNITE-18936 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > > Currently the output of the control.sh --baseline is parsed in a wrong way. > In particular the baseline node state can not be obtained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18936) [ducktests] Fix parse of the control.sh --baseline output
[ https://issues.apache.org/jira/browse/IGNITE-18936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-18936: - Labels: ducktests (was: ) > [ducktests] Fix parse of the control.sh --baseline output > - > > Key: IGNITE-18936 > URL: https://issues.apache.org/jira/browse/IGNITE-18936 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Priority: Minor > Labels: ducktests > > Currently the output of the control.sh --baseline is parsed in a wrong way. > In particular the baseline node state can not be obtained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18936) [ducktests] Fix parse of the control.sh --baseline output
Sergey Korotkov created IGNITE-18936: Summary: [ducktests] Fix parse of the control.sh --baseline output Key: IGNITE-18936 URL: https://issues.apache.org/jira/browse/IGNITE-18936 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Currently the output of the control.sh --baseline is parsed in a wrong way. In particular the baseline node state can not be obtained. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18921) [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric symbols
[
https://issues.apache.org/jira/browse/IGNITE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18921:
-
Description:
The IndexRebuildTest test fails with the error like
{noformat}
Error: 'rm: cannot remove
'/mnt/service/work/db/ducktape-12_ignite-dev_ru/cache-test-cache-1/index.bin':
No such file or directory'
{noformat}
All alphanumeric symbols should be replaced with the undescores following the
ignite-core procedure from the
{code:java}IgniteUtils.maskForFileName().{code}
was:
The IndexRebuildTest test fails with the error like
{noformat}
Error: 'rm: cannot remove
'/mnt/service/work/db/ducktape-12_ignite-dev_ru/cache-test-cache-1/index.bin':
No such file or directory'
{noformat}
All alphanumeric symbols should be replaced with the undescores in fact.
> [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric
> symbols
>
>
> Key: IGNITE-18921
> URL: https://issues.apache.org/jira/browse/IGNITE-18921
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The IndexRebuildTest test fails with the error like
>
> {noformat}
> Error: 'rm: cannot remove
> '/mnt/service/work/db/ducktape-12_ignite-dev_ru/cache-test-cache-1/index.bin':
> No such file or directory'
> {noformat}
> All alphanumeric symbols should be replaced with the undescores following the
> ignite-core procedure from the
> {code:java}IgniteUtils.maskForFileName().{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18921) [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric symbols
[
https://issues.apache.org/jira/browse/IGNITE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18921:
-
Description:
The IndexRebuildTest test fails with the error like
{noformat}
Error: 'rm: cannot remove
'/mnt/service/work/db/ducktape-12_ignite-dev_ru/cache-test-cache-1/index.bin':
No such file or directory'
{noformat}
All alphanumeric symbols should be replaced with the undescores in fact.
> [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric
> symbols
>
>
> Key: IGNITE-18921
> URL: https://issues.apache.org/jira/browse/IGNITE-18921
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The IndexRebuildTest test fails with the error like
>
> {noformat}
> Error: 'rm: cannot remove
> '/mnt/service/work/db/ducktape-12_ignite-dev_ru/cache-test-cache-1/index.bin':
> No such file or directory'
> {noformat}
> All alphanumeric symbols should be replaced with the undescores in fact.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18921) [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric symbols
[ https://issues.apache.org/jira/browse/IGNITE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-18921: - Summary: [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric symbols (was: [ducktests] IndexRebuildTest fails if fully qualified hostname used as consistentId) > [ducktests] IndexRebuildTest fails if consistentId contains non-alphanumeric > symbols > > > Key: IGNITE-18921 > URL: https://issues.apache.org/jira/browse/IGNITE-18921 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18921) [ducktests] IndexRebuildTest fails if fully qualified hostname used as consistentId
Sergey Korotkov created IGNITE-18921: Summary: [ducktests] IndexRebuildTest fails if fully qualified hostname used as consistentId Key: IGNITE-18921 URL: https://issues.apache.org/jira/browse/IGNITE-18921 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Assignee: Sergey Korotkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16319) Replace DataLoaderApplication with DataGenerationApplication
[
https://issues.apache.org/jira/browse/IGNITE-16319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-16319:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Replace DataLoaderApplication with DataGenerationApplication
>
>
> Key: IGNITE-16319
> URL: https://issues.apache.org/jira/browse/IGNITE-16319
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently, two application exists in ducktape for one purpose - generate some
> data and put it in the cluster.
> We should remove {{DataLoaderApplication}} and use
> {{DataGenerationApplication}} instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18765) [ducktests] Fix ducktests python module version format
[
https://issues.apache.org/jira/browse/IGNITE-18765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov reassigned IGNITE-18765:
Assignee: Sergey Korotkov
> [ducktests] Fix ducktests python module version format
> --
>
> Key: IGNITE-18765
> URL: https://issues.apache.org/jira/browse/IGNITE-18765
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Blocker
> Labels: ducktests
> Time Spent: 10m
> Remaining Estimate: 0h
>
> X.X.X-SNAPSHOT version format is not allowed any more by the setuptools
> starting from the 66.0.0
> So among other, it blocks the github actions used to check the pull-requests
> as
> {panel}
> {noformat}
> python setup.py egg_info did not run successfully.
> │ exit code: 1
> ╰─> [27 lines of output]
> running egg_info
>
> /home/runner/.virtualenvs/ignite-ducktests-codestyle/lib/python3.8/site-packages/setuptools/dist.py:548:
> UserWarning: The version specified ('2.15.0-SNAPSHOT') is an invalid
> version, this may not work as expected with newer versions of setuptools,
> pip, and PyPI. Please see PEP 440 for more details.
> {noformat}
> {panel}
> See the corresponding discussion in the setuptools' github:
> https://github.com/pypa/setuptools/issues/3772
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18765) [ducktests] Fix ducktests python module version format
[
https://issues.apache.org/jira/browse/IGNITE-18765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18765:
-
Labels: ducktests (was: )
> [ducktests] Fix ducktests python module version format
> --
>
> Key: IGNITE-18765
> URL: https://issues.apache.org/jira/browse/IGNITE-18765
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Priority: Blocker
> Labels: ducktests
>
> X.X.X-SNAPSHOT version format is not allowed any more by the setuptools
> starting from the 66.0.0
> So among other, it blocks the github actions used to check the pull-requests
> as
> {panel}
> {noformat}
> python setup.py egg_info did not run successfully.
> │ exit code: 1
> ╰─> [27 lines of output]
> running egg_info
>
> /home/runner/.virtualenvs/ignite-ducktests-codestyle/lib/python3.8/site-packages/setuptools/dist.py:548:
> UserWarning: The version specified ('2.15.0-SNAPSHOT') is an invalid
> version, this may not work as expected with newer versions of setuptools,
> pip, and PyPI. Please see PEP 440 for more details.
> {noformat}
> {panel}
> See the corresponding discussion in the setuptools' github:
> https://github.com/pypa/setuptools/issues/3772
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18765) [ducktests] Fix ducktests python module version format
Sergey Korotkov created IGNITE-18765:
Summary: [ducktests] Fix ducktests python module version format
Key: IGNITE-18765
URL: https://issues.apache.org/jira/browse/IGNITE-18765
Project: Ignite
Issue Type: Test
Reporter: Sergey Korotkov
X.X.X-SNAPSHOT version format is not allowed any more by the setuptools
starting from the 66.0.0
So among other, it blocks the github actions used to check the pull-requests as
{panel}
{noformat}
python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [27 lines of output]
running egg_info
/home/runner/.virtualenvs/ignite-ducktests-codestyle/lib/python3.8/site-packages/setuptools/dist.py:548:
UserWarning: The version specified ('2.15.0-SNAPSHOT') is an invalid version,
this may not work as expected with newer versions of setuptools, pip, and PyPI.
Please see PEP 440 for more details.
{noformat}
{panel}
See the corresponding discussion in the setuptools' github:
https://github.com/pypa/setuptools/issues/3772
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18676) [ducktests] Support --performance-statistics in the ControlUtility
[ https://issues.apache.org/jira/browse/IGNITE-18676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-18676: - Labels: ducktests (was: ) > [ducktests] Support --performance-statistics in the ControlUtility > -- > > Key: IGNITE-18676 > URL: https://issues.apache.org/jira/browse/IGNITE-18676 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > Add ability to run --performance-statistics [1] subcommands in ducktests via > the ControlUtility class. > [1] - the > https://ignite.apache.org/docs/latest/monitoring-metrics/performance-statistics > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18676) [ducktests] Support --performance-statistics in the ControlUtility
[ https://issues.apache.org/jira/browse/IGNITE-18676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-18676: Assignee: Sergey Korotkov > [ducktests] Support --performance-statistics in the ControlUtility > -- > > Key: IGNITE-18676 > URL: https://issues.apache.org/jira/browse/IGNITE-18676 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > > Add ability to run --performance-statistics [1] subcommands in ducktests via > the ControlUtility class. > [1] - the > https://ignite.apache.org/docs/latest/monitoring-metrics/performance-statistics > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18676) [ducktests] Support --performance-statistics in the ControlUtility
Sergey Korotkov created IGNITE-18676: Summary: [ducktests] Support --performance-statistics in the ControlUtility Key: IGNITE-18676 URL: https://issues.apache.org/jira/browse/IGNITE-18676 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov Add ability to run --performance-statistics [1] subcommands in ducktests via the ControlUtility class. [1] - the https://ignite.apache.org/docs/latest/monitoring-metrics/performance-statistics -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18592) [ducktests] Clean nodes before service start
[
https://issues.apache.org/jira/browse/IGNITE-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18592:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> [ducktests] Clean nodes before service start
>
>
> Key: IGNITE-18592
> URL: https://issues.apache.org/jira/browse/IGNITE-18592
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Current Ignite base class of ducktape service (DucktestsService class)
> prevents the node cleanup before the service start (which is the default
> ducktape service behaviour in fact).
> This causes say the following problem. The
> {{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
> test frees nodes used by one of its IgniteApplicationService (preloader)
> before the test completion. So some other test running concurrently may
> reuse this node (yet uncleaned and containing data at /mnt/service) which
> would cause unexpected test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18592) [ducktests] Clean nodes before service start
[
https://issues.apache.org/jira/browse/IGNITE-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680142#comment-17680142
]
Sergey Korotkov commented on IGNITE-18592:
--
[~ivandasch] would you please review?
> [ducktests] Clean nodes before service start
>
>
> Key: IGNITE-18592
> URL: https://issues.apache.org/jira/browse/IGNITE-18592
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current Ignite base class of ducktape service (DucktestsService class)
> prevents the node cleanup before the service start (which is the default
> ducktape service behaviour in fact).
> This causes say the following problem. The
> {{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
> test frees nodes used by one of its IgniteApplicationService (preloader)
> before the test completion. So some other test running concurrently may
> reuse this node (yet uncleaned and containing data at /mnt/service) which
> would cause unexpected test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18592) [ducktests] Clean nodes before service start
[
https://issues.apache.org/jira/browse/IGNITE-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18592:
-
Description:
Current Ignite base class of ducktape service (DucktestsService class) prevents
the node cleanup before the service start (which is the default ducktape
service behaviour in fact).
This causes say the following problem. The
{{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
test frees nodes used by one of its IgniteApplicationService (preloader)
before the test completion. So some other test running concurrently may reuse
this node (yet uncleaned and containing data at /mnt/service) which would cause
unexpected test failures.
was:
The
{{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
test frees nodes used by one of its IgniteApplicationService (preloader)
before the test completion.
It causes the following two problems:
1. Logs of the preloader are not copied to the test results package
2. Some other test running concurrently may try to reuse this node (yet
uncleaned and containing data at /mnt/service) which would cause unexpected
test failures.
> [ducktests] Clean nodes before service start
>
>
> Key: IGNITE-18592
> URL: https://issues.apache.org/jira/browse/IGNITE-18592
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
>
> Current Ignite base class of ducktape service (DucktestsService class)
> prevents the node cleanup before the service start (which is the default
> ducktape service behaviour in fact).
> This causes say the following problem. The
> {{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
> test frees nodes used by one of its IgniteApplicationService (preloader)
> before the test completion. So some other test running concurrently may
> reuse this node (yet uncleaned and containing data at /mnt/service) which
> would cause unexpected test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18592) [ducktests] Clean nodes before service start
[
https://issues.apache.org/jira/browse/IGNITE-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18592:
-
Summary: [ducktests] Clean nodes before service start (was: [ducktests] Do
not free service node before test completion)
> [ducktests] Clean nodes before service start
>
>
> Key: IGNITE-18592
> URL: https://issues.apache.org/jira/browse/IGNITE-18592
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
>
> The
> {{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
> test frees nodes used by one of its IgniteApplicationService (preloader)
> before the test completion.
> It causes the following two problems:
> 1. Logs of the preloader are not copied to the test results package
> 2. Some other test running concurrently may try to reuse this node (yet
> uncleaned and containing data at /mnt/service) which would cause unexpected
> test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18592) [ducktests] Do not free service node before test completion
[
https://issues.apache.org/jira/browse/IGNITE-18592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov reassigned IGNITE-18592:
Assignee: Sergey Korotkov
> [ducktests] Do not free service node before test completion
> ---
>
> Key: IGNITE-18592
> URL: https://issues.apache.org/jira/browse/IGNITE-18592
> Project: Ignite
> Issue Type: Test
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
>
> The
> {{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
> test frees nodes used by one of its IgniteApplicationService (preloader)
> before the test completion.
> It causes the following two problems:
> 1. Logs of the preloader are not copied to the test results package
> 2. Some other test running concurrently may try to reuse this node (yet
> uncleaned and containing data at /mnt/service) which would cause unexpected
> test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18592) [ducktests] Do not free service node before test completion
Sergey Korotkov created IGNITE-18592:
Summary: [ducktests] Do not free service node before test
completion
Key: IGNITE-18592
URL: https://issues.apache.org/jira/browse/IGNITE-18592
Project: Ignite
Issue Type: Test
Reporter: Sergey Korotkov
The
{{ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test}}
test frees nodes used by one of its IgniteApplicationService (preloader)
before the test completion.
It causes the following two problems:
1. Logs of the preloader are not copied to the test results package
2. Some other test running concurrently may try to reuse this node (yet
uncleaned and containing data at /mnt/service) which would cause unexpected
test failures.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18568) [ducktests] Fix dependency on filelock package
[ https://issues.apache.org/jira/browse/IGNITE-18568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-18568: - Summary: [ducktests] Fix dependency on filelock package (was: [ducktests] Fix dependency on filelock module) > [ducktests] Fix dependency on filelock package > -- > > Key: IGNITE-18568 > URL: https://issues.apache.org/jira/browse/IGNITE-18568 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > > IGNITE-18460 broke the dependency for docker run. > ducktape 0.11.x do not depend on 'filelock' any more, so 'filelock' should be > specified explicitely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18568) [ducktests] Fix dependency on filelock module
Sergey Korotkov created IGNITE-18568: Summary: [ducktests] Fix dependency on filelock module Key: IGNITE-18568 URL: https://issues.apache.org/jira/browse/IGNITE-18568 Project: Ignite Issue Type: Test Reporter: Sergey Korotkov IGNITE-18460 broke the dependency for docker run. ducktape 0.11.x do not depend on 'filelock' any more, so 'filelock' should be specified explicitely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18568) [ducktests] Fix dependency on filelock module
[ https://issues.apache.org/jira/browse/IGNITE-18568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov reassigned IGNITE-18568: Assignee: Sergey Korotkov > [ducktests] Fix dependency on filelock module > - > > Key: IGNITE-18568 > URL: https://issues.apache.org/jira/browse/IGNITE-18568 > Project: Ignite > Issue Type: Test >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Labels: ducktests > > IGNITE-18460 broke the dependency for docker run. > ducktape 0.11.x do not depend on 'filelock' any more, so 'filelock' should be > specified explicitely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18486) IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions number
[
https://issues.apache.org/jira/browse/IGNITE-18486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18486:
-
Labels: IEP-59 ise (was: )
> IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions
> number
> ---
>
> Key: IGNITE-18486
> URL: https://issues.apache.org/jira/browse/IGNITE-18486
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Sergey Korotkov
>Priority: Minor
> Labels: IEP-59, ise
>
> If Kafka topic specified in the {{IgniteToKafkaCdcStreamer}}'s property is
> absent it's created implicitely with the default number of partitions (which
> is 1).
> {quote}
> {{INFO [KafkaApi-1] Auto creation of topic ignite with 1 partitions and
> replication factor 1 is successful (kafka.server.KafkaApis)}}{quote}
> So {{IgniteToKafkaCdcStreamer}} ignores the {{kafkaPartitions}} property in
> this case.
> Looks like that {{IgniteToKafkaCdcStreamer}} should either refuse to work if
> topic is absent or create it respecting the {{kafkaPartitions}} property.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18486) IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions number
[
https://issues.apache.org/jira/browse/IGNITE-18486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18486:
-
Description:
If Kafka topic specified in the {{IgniteToKafkaCdcStreamer}}'s property is
absent it's created implicitely with the default number of partitions (which is
1).
{quote}
{{INFO [KafkaApi-1] Auto creation of topic ignite with 1 partitions and
replication factor 1 is successful (kafka.server.KafkaApis)}}{quote}
So {{IgniteToKafkaCdcStreamer}} ignores the {{kafkaPartitions}} property in
this case.
Looks like that {{IgniteToKafkaCdcStreamer}} should either refuse to work if
topic is absent or create it respecting the {{kafkaPartitions}} property.
was:
If Kafka topic specified in the {{IgniteToKafkaCdcStreamer}}'s property is
absent it's created implicitely with the default number of partitions (which is
1).
So {{IgniteToKafkaCdcStreamer}} ignores the {{kafkaPartitions}} property in
this case.
Looks like that {{IgniteToKafkaCdcStreamer}} should either refuse to work if
topic is absent or create it respecting the {{kafkaPartitions}} property.
> IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions
> number
> ---
>
> Key: IGNITE-18486
> URL: https://issues.apache.org/jira/browse/IGNITE-18486
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Sergey Korotkov
>Priority: Minor
>
> If Kafka topic specified in the {{IgniteToKafkaCdcStreamer}}'s property is
> absent it's created implicitely with the default number of partitions (which
> is 1).
> {quote}
> {{INFO [KafkaApi-1] Auto creation of topic ignite with 1 partitions and
> replication factor 1 is successful (kafka.server.KafkaApis)}}{quote}
> So {{IgniteToKafkaCdcStreamer}} ignores the {{kafkaPartitions}} property in
> this case.
> Looks like that {{IgniteToKafkaCdcStreamer}} should either refuse to work if
> topic is absent or create it respecting the {{kafkaPartitions}} property.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18486) IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions number
[
https://issues.apache.org/jira/browse/IGNITE-18486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Korotkov updated IGNITE-18486:
-
Component/s: extensions
> IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions
> number
> ---
>
> Key: IGNITE-18486
> URL: https://issues.apache.org/jira/browse/IGNITE-18486
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Sergey Korotkov
>Priority: Minor
>
> If Kafka topic specified in the {{IgniteToKafkaCdcStreamer}}'s property is
> absent it's created implicitely with the default number of partitions (which
> is 1).
> So {{IgniteToKafkaCdcStreamer}} ignores the {{kafkaPartitions}} property in
> this case.
> Looks like that {{IgniteToKafkaCdcStreamer}} should either refuse to work if
> topic is absent or create it respecting the {{kafkaPartitions}} property.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18486) IgniteToKafkaCdcStreamer implicitely creates topic with wrong partitions number
Sergey Korotkov created IGNITE-18486:
Summary: IgniteToKafkaCdcStreamer implicitely creates topic with
wrong partitions number
Key: IGNITE-18486
URL: https://issues.apache.org/jira/browse/IGNITE-18486
Project: Ignite
Issue Type: Bug
Reporter: Sergey Korotkov
If Kafka topic specified in the {{IgniteToKafkaCdcStreamer}}'s property is
absent it's created implicitely with the default number of partitions (which is
1).
So {{IgniteToKafkaCdcStreamer}} ignores the {{kafkaPartitions}} property in
this case.
Looks like that {{IgniteToKafkaCdcStreamer}} should either refuse to work if
topic is absent or create it respecting the {{kafkaPartitions}} property.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
