[jira] [Assigned] (IGNITE-21478) OOM crash with unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov reassigned IGNITE-21478:
Assignee: Mikhail Petrov
> OOM crash with unstable topology
>
>
> Key: IGNITE-21478
> URL: https://issues.apache.org/jira/browse/IGNITE-21478
> Project: Ignite
> Issue Type: Bug
>Reporter: Luchnikov Alexander
>Assignee: Mikhail Petrov
>Priority: Minor
> Labels: ise
> Attachments: HistoMinorTop.png, histo.png
>
>
> User cases:
> 1) Frequent entry/exit of a thick client into the topology leads to a crash
> of the server node due to OMM.
> 2) Frequent creation and destroy of caches leads to a server node crash due
> to OOM.
> topVer=20098
> *Real case*
> Part of the log before the OOM crash, pay attention to *topVer=20098*
> {code:java}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f080abcd, uptime=3 days, 09:00:55.274]
> ^-- Cluster [hosts=4, CPUs=6, servers=2, clients=2, topVer=20098,
> minorTopVer=6]
> ^-- Network [addrs=[192.168.1.2, 127.0.0.1], discoPort=47500,
> commPort=47100]
> ^-- CPU [CPUs=2, curLoad=86.83%, avgLoad=21.9%, GC=23.9%]
> ^-- Heap [used=867MB, free=15.29%, comm=1024MB]
> ^-- Outbound messages queue [size=0]
> ^-- Public thread pool [active=0, idle=7, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> ^-- Striped thread pool [active=0, idle=8, qSize=0]
> {code}
> Histogram from heap-dump after node failed
> !histo.png!
> *MinorTop example*
> {code:java}
> @Test
> public void testMinorVer() throws Exception {
> Ignite server = startGrids(1);
> IgniteEx client = startClientGrid();
> String cacheName = "cacheName";
> for (int i = 0; i < 500; i++) {
> client.getOrCreateCache(cacheName);
> client.destroyCache(cacheName);
> }
> System.err.println("Heap dump time");
> Thread.sleep(100);
> }
> {code}
> {code:java}
> [INFO
> ][exchange-worker-#149%internal.IgniteOomTest%][GridCachePartitionExchangeManager]
> AffinityTopologyVersion [topVer=2, minorTopVer=1000],
> evt=DISCOVERY_CUSTOM_EVT, evtNode=52b4c130-1a01-4858-813a-ebc8a5dabf1e,
> client=true]
> {code}
> !HistoMinorTop.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21261) Fix exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater
[ https://issues.apache.org/jira/browse/IGNITE-21261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806816#comment-17806816 ] Alexey Gidaspov edited comment on IGNITE-21261 at 1/16/24 1:50 PM: --- https://tc2.sbt-ignite-dev.ru/viewLog.html?buildId=7706734=IgniteExtensions_Tests_RunAllTests=dependencies#_expand=block_bt1193-7706734=0=1580 was (Author: agidaspov): https://tc2.sbt-ignite-dev.ru/viewLog.html?tab=dependencies=snapshot=7705635=IgniteExtensions_Tests_RunAllTests=true#_expand=block_bt1193-7705635== > Fix exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater > - > > Key: IGNITE-21261 > URL: https://issues.apache.org/jira/browse/IGNITE-21261 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Major > Labels: ise > > exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater > since kafka lib was upgraded to 3.4.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21261) Fix exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater
[ https://issues.apache.org/jira/browse/IGNITE-21261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806816#comment-17806816 ] Alexey Gidaspov commented on IGNITE-21261: -- https://tc2.sbt-ignite-dev.ru/viewLog.html?tab=dependencies=snapshot=7705635=IgniteExtensions_Tests_RunAllTests=true#_expand=block_bt1193-7705635== > Fix exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater > - > > Key: IGNITE-21261 > URL: https://issues.apache.org/jira/browse/IGNITE-21261 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Major > Labels: ise > > exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater > since kafka lib was upgraded to 3.4.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21261) Fix exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater
Alexey Gidaspov created IGNITE-21261: Summary: Fix exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater Key: IGNITE-21261 URL: https://issues.apache.org/jira/browse/IGNITE-21261 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov exception 'Unknown topic' is never thrown in KafkaToIgniteMetadataUpdater since kafka lib was upgraded to 3.4.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20626) Update ignite dependency: http-jetty
[ https://issues.apache.org/jira/browse/IGNITE-20626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-20626: - Labels: ise (was: ) > Update ignite dependency: http-jetty > > > Key: IGNITE-20626 > URL: https://issues.apache.org/jira/browse/IGNITE-20626 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Major > Labels: ise > Fix For: 2.16 > > > Update http-jetty to 9.4.53.v20231009 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20626) Update ignite dependency: http-jetty
Alexey Gidaspov created IGNITE-20626: Summary: Update ignite dependency: http-jetty Key: IGNITE-20626 URL: https://issues.apache.org/jira/browse/IGNITE-20626 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov Fix For: 2.16 Update http-jetty to 9.4.53.v20231009 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-19514) Expiry Rate metric to be implemented
Alexey Gidaspov created IGNITE-19514: Summary: Expiry Rate metric to be implemented Key: IGNITE-19514 URL: https://issues.apache.org/jira/browse/IGNITE-19514 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Metric that shows rate of expiring keys per caches needs to be implemented. It would be useful in administration and troubleshooting scenarios. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15071) Fix "update version" script to change version in documentation code snippets
[ https://issues.apache.org/jira/browse/IGNITE-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656540#comment-17656540 ] Alexey Gidaspov commented on IGNITE-15071: -- [~alex_pl] , I've checked version changing in code snipets POM. That works fine, version changed as expected. > Fix "update version" script to change version in documentation code snippets > > > Key: IGNITE-15071 > URL: https://issues.apache.org/jira/browse/IGNITE-15071 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > The script should be modified to automatically update Ignite version in > "docs/_docs/code-snippets/java/pom.xml" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-14726) [Log4j2] Omitted start character [ in default log pattern
[
https://issues.apache.org/jira/browse/IGNITE-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov reassigned IGNITE-14726:
Assignee: Alexey Gidaspov
> [Log4j2] Omitted start character [ in default log pattern
> -
>
> Key: IGNITE-14726
> URL: https://issues.apache.org/jira/browse/IGNITE-14726
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Fedor Malchikov
>Assignee: Alexey Gidaspov
>Priority: Major
> Labels: newbie
>
> {code:java}.withPattern("%d{ISO8601}][%-5p][%t][%c{1}] %m%n"){code}
> should be:
> {code:java}.withPattern("[%d{ISO8601}][%-5p][%t][%c{1}] %m%n"){code}
> code:
> https://github.com/apache/ignite/blob/master/modules/log4j2/src/main/java/org/apache/ignite/logger/log4j2/Log4J2Logger.java#L363
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17509) [Extensions] Spring Data pageable request result contains incorrect total value.
[
https://issues.apache.org/jira/browse/IGNITE-17509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-17509:
-
Labels: ise (was: )
> [Extensions] Spring Data pageable request result contains incorrect total
> value.
>
>
> Key: IGNITE-17509
> URL: https://issues.apache.org/jira/browse/IGNITE-17509
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Labels: ise
> Attachments: Reproduces_incorrect_pageable_request_total_value_.patch
>
>
> Assume that Spring Data repository contains the following method
> {code:java}
> public Page findByFirstNameContaining(String val, Pageable
> pageable);
> {code}
> In this case the following checks will fail
> {code:java}
> Page res = repo.findByFirstNameContaining("person",
> PageRequest.of(2, 100));
> assertEquals(CACHE_SIZE, res.getTotalElements());
> {code}
> where 'repo' is the instance of the previously mention repository.
> The full reproduccer is attached.
> The main reason of the such behaviour is that IgniteRepositoryQuery.java:614
> does not make a separate request of the total rows count and just sets Page
> 'total' value to 0.
> See also org.springframework.data.domain.PageImpl#PageImpl(java.util.List,
> org.springframework.data.domain.Pageable, long) logic to understand the how
> the final result of 'getTotalElements()' is calculated.
> It seems that as a workaround, you can explicitly request the total number of
> rows with a separate query.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17499) Service method invocation excepition is not propagated to thin client side.
[ https://issues.apache.org/jira/browse/IGNITE-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-17499: - Labels: ise (was: ) > Service method invocation excepition is not propagated to thin client side. > --- > > Key: IGNITE-17499 > URL: https://issues.apache.org/jira/browse/IGNITE-17499 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > > https://issues.apache.org/jira/browse/IGNITE-13389 introduced dedicated flag > that make it possible to propagate server side stacktrace to a thin client > side. The mentoined above propagation does not work for exceptions that > arises during Ignite Service invocation. > Steps to reproduce: > 1. Start .Net Ignite node > 2. Deploy service which invocation throws an arbitrary uncaught exception > 3. Invoke previously deployed services via Java thin client > As a result, information about the custom code exception is not present in > the exception stacktrace that is thrown after the service call. > The main reason of such behaviour is that > ClientServiceInvokeRequest.java:198 does not propagate initial exception. So > ClientRequestHandler#handleException could not handle exception properly even > if ThinClientConfiguration#sendServerExceptionStackTraceToClient() is enabled. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17427) Update netty version up to 4.1.79.Final
[ https://issues.apache.org/jira/browse/IGNITE-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-17427: - Summary: Update netty version up to 4.1.79.Final (was: Update netty version up to 4.1.75.Final) > Update netty version up to 4.1.79.Final > --- > > Key: IGNITE-17427 > URL: https://issues.apache.org/jira/browse/IGNITE-17427 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Minor > > Need to update netty version up to 4.1.75.Final because of > [CVE-2022-24823|https://nvd.nist.gov/vuln/detail/CVE-2022-24823] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17427) Update netty version up to 4.1.79.Final
[ https://issues.apache.org/jira/browse/IGNITE-17427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-17427: - Description: Need to update netty version up to 4.1.79.Final because of [CVE-2022-24823|https://nvd.nist.gov/vuln/detail/CVE-2022-24823] (was: Need to update netty version up to 4.1.75.Final because of [CVE-2022-24823|https://nvd.nist.gov/vuln/detail/CVE-2022-24823]) > Update netty version up to 4.1.79.Final > --- > > Key: IGNITE-17427 > URL: https://issues.apache.org/jira/browse/IGNITE-17427 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Minor > > Need to update netty version up to 4.1.79.Final because of > [CVE-2022-24823|https://nvd.nist.gov/vuln/detail/CVE-2022-24823] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17427) Update netty version up to 4.1.75.Final
Alexey Gidaspov created IGNITE-17427: Summary: Update netty version up to 4.1.75.Final Key: IGNITE-17427 URL: https://issues.apache.org/jira/browse/IGNITE-17427 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov Need to update netty version up to 4.1.75.Final because of [CVE-2022-24823|https://nvd.nist.gov/vuln/detail/CVE-2022-24823] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-16795) control.sh fails to change state of the cluster without autoconfirmation
Alexey Gidaspov created IGNITE-16795:
Summary: control.sh fails to change state of the cluster without
autoconfirmation
Key: IGNITE-16795
URL: https://issues.apache.org/jira/browse/IGNITE-16795
Project: Ignite
Issue Type: Bug
Affects Versions: 2.12
Reporter: Alexey Gidaspov
Assignee: Alexey Gidaspov
*How to reproduce:*
# Start ignite cluster with PDS
# Activate cluster (--set-state ACTIVE)
# Deactivate cluster (--set-state INACTIVE)
# Activate cluster (--set-state ACTIVE)
*On step 4 following will happen:*
{code:java}
Command [SET-STATE] finished with code: 4
Error stack trace:
class org.apache.ignite.internal.client.GridClientException: null
suppressed:
at
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleClientResponse(GridClientNioTcpConnection.java:631)
at
org.apache.ignite.internal.client.impl.connection.GridClientNioTcpConnection.handleResponse(GridClientNioTcpConnection.java:562)
at
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter$NioListener.onMessage(GridClientConnectionManagerAdapter.java:651)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:116)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter.onMessageReceived(GridNioSslFilter.java:349)
at
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at
org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3693)
at
org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
at
org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1192)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2472)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2239)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1880)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Control utility has completed execution at: 2021-09-16T19:17:30.632
Execution time: 492 ms {code}
and cluster won't be activated.
*WA:*
When using commands with autoconfirmation (–yes), we can see normal behavior.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14725) Cluster crashes when the client has a higher byte code version than server
[
https://issues.apache.org/jira/browse/IGNITE-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14725:
-
Fix Version/s: 2.11
> Cluster crashes when the client has a higher byte code version than server
> --
>
> Key: IGNITE-14725
> URL: https://issues.apache.org/jira/browse/IGNITE-14725
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Surkov Aleksandr
>Assignee: Sergei Ryzhov
>Priority: Blocker
> Fix For: 2.11
>
> Attachments: different-java.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the Java version on the server does not support the byte code that the
> client node sends to server, then some operations(Scan Queries) can lead to
> the fall of the cluster.
> Steps to reproduce the situation:
> 1. Start the server using Java 8(org.apache.ignite.SimpleServer#main)
> 2. Start the client using Java 11(target byte code version 11), which will
> run ScanQuery(org.apache.ignite.ThickClient#main)
> Reproducer is attached. Logs from the server and client are located in the
> errors folder.
> {code:java}
> SEVERE: Failed to process message
> [senderId=53c4266d-8b74-480b-bbf5-670bd94c4192, msg=GridCacheQueryRequest
> [id=13, cacheName=cache_scan, type=SCAN, fields=false, clause=null, limit=0,
> clsName=null, keyValFilter=null, rdc=null, trans=null, pageSize=1024,
> incBackups=false, cancel=false, incMeta=false, all=false, keepBinary=false,
> subjId=53c4266d-8b74-480b-bbf5-670bd94c4192, taskHash=0, part=-1,
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], mvccSnapshot=null,
> flags=0, super=GridCacheIdMessage [cacheId=29045018, super=GridCacheMessage
> [msgId=14, depInfo=GridDeploymentInfoBean
> [clsLdrId=74845d87971-53c4266d-8b74-480b-bbf5-670bd94c4192, depMode=SHARED,
> userVer=0, locDepOwner=false, participants=null],
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=1],
> err=null, skipPrepare=false
> java.lang.UnsupportedClassVersionError: org/apache/ignite/ThickClient has
> been compiled by a more recent version of the Java Runtime (class file
> version 55.0), this version of the Java Runtime only recognizes class file
> versions up to 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:635)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.findClass(GridDeploymentClassLoader.java:543)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.loadClass(GridDeploymentClassLoader.java:461)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9014)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8945)
> at
> org.apache.ignite.internal.managers.deployment.GridDeployment.deployedClass(GridDeployment.java:460)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:441)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:517)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.tryToloadClassFromCacheDep(GridCacheDeploymentManager.java:816)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.findClass(GridCacheDeploymentManager.java:783)
> at
> org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CacheClassLoader.loadClass(GridCacheDeploymentManager.java:760)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9012)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8957)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:376)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:693)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1641)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1578)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1555)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readClass(BinaryReaderExImpl.java:383)
> at
>
[jira] [Commented] (IGNITE-15274) Unexpected initialization of MaintainanceFileStore on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17398573#comment-17398573
]
Alexey Gidaspov commented on IGNITE-15274:
--
[~nizhikov] Can you cherry-pick this fix to 2.11 branch?
> Unexpected initialization of MaintainanceFileStore on client nodes
> --
>
> Key: IGNITE-15274
> URL: https://issues.apache.org/jira/browse/IGNITE-15274
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Node has a client flag but fails on persistence check.
> {noformat}
> [2021-08-09 06:54:24,056][WARN ][main][MaintenanceProcessor] Caught exception
> when starting MaintenanceProcessor, maintenance mode won't be entered
> class org.apache.ignite.IgniteCheckedException: Directory does not exist and
> cannot be created: /mnt/ssd/persistence
> at
> org.apache.ignite.internal.util.IgniteUtils.resolveWorkDirectory(IgniteUtils.java:9670)
> at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolvePersistentStoreBasePath(PdsConsistentIdProcessor.java:453)
> at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:160)
> at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)
> at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)
> at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
> at org.apache.ignite.IgniteSpring.start(IgniteSpring.java:66)
> at org.apache.ignite.yardstick.IgniteNode.start(IgniteNode.java:215)
> at
> org.apache.ignite.yardstick.IgniteAbstractBenchmark.setUp(IgniteAbstractBenchmark.java:65)
> at
> org.apache.ignite.yardstick.cache.IgniteCacheAbstractBenchmark.setUp(IgniteCacheAbstractBenchmark.java:108)
> at
> org.yardstickframework.BenchmarkDriverStartUp.main(BenchmarkDriverStartUp.java:130)
> {noformat}
> Such check should not happen.
> Config which leads to the failure (this config was used at Yardstick, so
> clientMode was set by Yardstick):
> {noformat}
>
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
>
>class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
>
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>name="addresses">
>
>
> 10.0.0.2:47500..47509
>
> 10.0.0.3:47500..47509
>
> 10.0.0.4:47500..47509
>
>
>
>
>
>
>
>class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
>
>
>
> class="org.apache.ignite.configuration.BinaryConfiguration">
>
>
> class="org.apache.ignite.configuration.DataRegionConfiguration">
>
>
[jira] [Updated] (IGNITE-15274) Unexpected initialization of MaintainanceFileStore on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-15274:
-
Fix Version/s: (was: 2.12)
2.11
> Unexpected initialization of MaintainanceFileStore on client nodes
> --
>
> Key: IGNITE-15274
> URL: https://issues.apache.org/jira/browse/IGNITE-15274
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Blocker
> Labels: newbie
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Node has a client flag but fails on persistence check.
> {noformat}
> [2021-08-09 06:54:24,056][WARN ][main][MaintenanceProcessor] Caught exception
> when starting MaintenanceProcessor, maintenance mode won't be entered
> class org.apache.ignite.IgniteCheckedException: Directory does not exist and
> cannot be created: /mnt/ssd/persistence
> at
> org.apache.ignite.internal.util.IgniteUtils.resolveWorkDirectory(IgniteUtils.java:9670)
> at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolvePersistentStoreBasePath(PdsConsistentIdProcessor.java:453)
> at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:160)
> at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)
> at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)
> at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:641)
> at org.apache.ignite.IgniteSpring.start(IgniteSpring.java:66)
> at org.apache.ignite.yardstick.IgniteNode.start(IgniteNode.java:215)
> at
> org.apache.ignite.yardstick.IgniteAbstractBenchmark.setUp(IgniteAbstractBenchmark.java:65)
> at
> org.apache.ignite.yardstick.cache.IgniteCacheAbstractBenchmark.setUp(IgniteCacheAbstractBenchmark.java:108)
> at
> org.yardstickframework.BenchmarkDriverStartUp.main(BenchmarkDriverStartUp.java:130)
> {noformat}
> Such check should not happen.
> Config which leads to the failure (this config was used at Yardstick, so
> clientMode was set by Yardstick):
> {noformat}
>
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd;>
>
> class="org.apache.ignite.configuration.IgniteConfiguration"
> parent="base-ignite.cfg">
>
>
>
>
>class="org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi">
>
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder">
>name="addresses">
>
>
> 10.0.0.2:47500..47509
>
> 10.0.0.3:47500..47509
>
> 10.0.0.4:47500..47509
>
>
>
>
>
>
>
>class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
>
>
>
>
>
> class="org.apache.ignite.configuration.BinaryConfiguration">
>
>
> class="org.apache.ignite.configuration.DataRegionConfiguration">
>
>
>
>
>
>
[jira] [Created] (IGNITE-15206) Update versions in master branch
Alexey Gidaspov created IGNITE-15206: Summary: Update versions in master branch Key: IGNITE-15206 URL: https://issues.apache.org/jira/browse/IGNITE-15206 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15095) Update DEB & RPM package version in ignite-2.11 branch
Alexey Gidaspov created IGNITE-15095: Summary: Update DEB & RPM package version in ignite-2.11 branch Key: IGNITE-15095 URL: https://issues.apache.org/jira/browse/IGNITE-15095 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov Update DEB & RPM package version in ignite-2.11 branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15061) Update version in ignite-2.11 release branch
[ https://issues.apache.org/jira/browse/IGNITE-15061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov reassigned IGNITE-15061: Assignee: Alexey Gidaspov > Update version in ignite-2.11 release branch > > > Key: IGNITE-15061 > URL: https://issues.apache.org/jira/browse/IGNITE-15061 > Project: Ignite > Issue Type: Task >Reporter: Alexey Gidaspov >Assignee: Alexey Gidaspov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Update version in ignite-2.11 release branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15041) Travis failed on ignite-spark compilation
[ https://issues.apache.org/jira/browse/IGNITE-15041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-15041: - Fix Version/s: 2.11 > Travis failed on ignite-spark compilation > - > > Key: IGNITE-15041 > URL: https://issues.apache.org/jira/browse/IGNITE-15041 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15061) Update version in ignite-2.11 release branch
Alexey Gidaspov created IGNITE-15061: Summary: Update version in ignite-2.11 release branch Key: IGNITE-15061 URL: https://issues.apache.org/jira/browse/IGNITE-15061 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Update version in ignite-2.11 release branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15059) Update Apache Ignite 2.11 release notes
Alexey Gidaspov created IGNITE-15059: Summary: Update Apache Ignite 2.11 release notes Key: IGNITE-15059 URL: https://issues.apache.org/jira/browse/IGNITE-15059 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov Fix For: 2.11 Need to update Apache Ignite 2.11 release notes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14377) Enchance log of node ping failure.
[ https://issues.apache.org/jira/browse/IGNITE-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14377: - Release Note: Enchanced log of node ping failure. Now failure reason is logged. Environment: (was: Enchanced log of node ping failure. Now failure reason is logged.) > Enchance log of node ping failure. > -- > > Key: IGNITE-14377 > URL: https://issues.apache.org/jira/browse/IGNITE-14377 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Log of unsuccessful ping during the joining is insufficient. No failure > reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13029) Support Spring Data repositories initialization with Spring Boot auto-starter
[
https://issues.apache.org/jira/browse/IGNITE-13029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-13029:
-
Release Note: Spring Data repositories initialization with Spring Boot
auto-starter is now supported
> Support Spring Data repositories initialization with Spring Boot auto-starter
> -
>
> Key: IGNITE-13029
> URL: https://issues.apache.org/jira/browse/IGNITE-13029
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Sergey Dorozhkin
>Priority: Major
> Labels: newbie
> Fix For: 2.11
>
>
> It's required to use {{@EnableIgniteRepositories}} annotation and follow this
> procedure to enable Ignite Spring Data repositories:
> https://apacheignite-mix.readme.io/docs/spring-data#spring-data-and-apache-ignite-configuration
> Support the Spring Data repositories enablement via the Spring Boot
> auto-starter if Spring Boot is used by a project:
> https://apacheignite-mix.readme.io/docs/spring-boot
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-13169: - Release Note: Removed Ignite bean name requirement for Spring Data Repository > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13767) Remove Python PHP and Node.js thin clients from main repository
[ https://issues.apache.org/jira/browse/IGNITE-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-13767: - Release Note: Python PHP and Node.js thin clients are removed from main repository > Remove Python PHP and Node.js thin clients from main repository > --- > > Key: IGNITE-13767 > URL: https://issues.apache.org/jira/browse/IGNITE-13767 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to remove the following directories, as we now have separate repos for > Python, Node.js and PHP thin clients: > modules/platforms/python > modules/platforms/nodejs > modules/platforms/php > > Also, need to check all the places in code where those directories are > referenced. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13818) Add extended logging topology for node left/join a grid
[ https://issues.apache.org/jira/browse/IGNITE-13818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-13818: - Release Note: Added extended logging topology for node left/join a grid > Add extended logging topology for node left/join a grid > --- > > Key: IGNITE-13818 > URL: https://issues.apache.org/jira/browse/IGNITE-13818 > Project: Ignite > Issue Type: Improvement >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > At start of the node write topology - the number of server and client nodes, > I would like to expand the list of nodes (information about each node: order, > id, host, ip), this will help in the case when the logs are only from one > node, and when there are logs from all nodes it will speed up the search for > coordinator or find the problem node id which was in the transaction -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14377) Enchance log of node ping failure.
[ https://issues.apache.org/jira/browse/IGNITE-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14377: - Environment: Enchanced log of node ping failure. Now failure reason is logged. > Enchance log of node ping failure. > -- > > Key: IGNITE-14377 > URL: https://issues.apache.org/jira/browse/IGNITE-14377 > Project: Ignite > Issue Type: Sub-task > Environment: Enchanced log of node ping failure. Now failure reason > is logged. >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Log of unsuccessful ping during the joining is insufficient. No failure > reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14397: - Release Note: Documented spring-transactions integration > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14378) Remove delay from node ping.
[ https://issues.apache.org/jira/browse/IGNITE-14378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14378: - Release Note: Removed delay from node ping > Remove delay from node ping. > > > Key: IGNITE-14378 > URL: https://issues.apache.org/jira/browse/IGNITE-14378 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove U.sleep(200) from the node ping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14398: - Ignite Flags: Release Notes Required Release Note: Documented thin client support for spring-data integration. > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14398) Document thin client support for spring-data integration.
[ https://issues.apache.org/jira/browse/IGNITE-14398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14398: - Ignite Flags: (was: Release Notes Required) > Document thin client support for spring-data integration. > - > > Key: IGNITE-14398 > URL: https://issues.apache.org/jira/browse/IGNITE-14398 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > It's needed to document thin client support for spring-data integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14448) Failure to connect to node leads to hanging connection future if paired connections are used
[
https://issues.apache.org/jira/browse/IGNITE-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14448:
-
Release Note: Fixed failure to connect to node leading to hanging
connection future if paired connections are used
> Failure to connect to node leads to hanging connection future if paired
> connections are used
>
>
> Key: IGNITE-14448
> URL: https://issues.apache.org/jira/browse/IGNITE-14448
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.10
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
> getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
>if (connRequestor != null) {
> ...
>if (isPairedConnection(node, tcpCommSpi))
>throw new IgniteSpiException("Inverse connection protocol
> doesn't support paired connections");{code}
> Turns out this exception is not handled property and connection future is
> never done. Then, striped pool threads wait forever on reserveClient() and
> cluster grinds to halt.This happens in versions which have
> communication-via-discovery and when usePairedConnections=true.
> {code:java}
> [12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
> 1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
> sockAddrs=HashSet [/127.0.0.1:0,
> ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
> intOrder=47, lastExchangeTime=1603983940522, loc=false,
> ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
> topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
> alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
> val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
> [idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
> sparkJobStatus=COMPLETED], prevVal=null,
> super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
> nearFutId=0, flags=near]], connIdx=-1]]
> class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
> doesn't support paired connections
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.handleUnreachableNodeException(ConnectionClientPool.java:365)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.reserveClient(ConnectionClientPool.java:256)
>
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1132)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1083)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1814)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1930)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.sendDhtRequests(GridDhtAtomicAbstractUpdateFuture
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14575: - Release Note: Write to Distributed Metastorage now throws exception on client if client is not connected to topology > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14397) Document spring-transactions integration.
[ https://issues.apache.org/jira/browse/IGNITE-14397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373292#comment-17373292 ] Alexey Gidaspov commented on IGNITE-14397: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Document spring-transactions integration. > - > > Key: IGNITE-14397 > URL: https://issues.apache.org/jira/browse/IGNITE-14397 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.11 > > Time Spent: 6h 20m > Remaining Estimate: 0h > > It's needed to document Ignite Spring-Transactions integration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14504) ClusterGroupEmptyException: Cluster group is empty error after client reconnect
[ https://issues.apache.org/jira/browse/IGNITE-14504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14504: - Ignite Flags: (was: Docs Required,Release Notes Required) > ClusterGroupEmptyException: Cluster group is empty error after client > reconnect > --- > > Key: IGNITE-14504 > URL: https://issues.apache.org/jira/browse/IGNITE-14504 > Project: Ignite > Issue Type: Bug > Components: messaging >Affects Versions: 2.10 >Reporter: Andrey Aleksandrov >Assignee: Andrey Aleksandrov >Priority: Major > Fix For: 2.11 > > Attachments: SendMessageAfterClientReconnect.java > > > Please run the attached test. > It will produce the following exception: > Exception in thread "main" class > org.apache.ignite.cluster.ClusterGroupEmptyException: Cluster group is empty. > at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:927) > at org.apache.ignite.internal.util.IgniteUtils$6.apply(IgniteUtils.java:925) > at > org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1083) > at > org.apache.ignite.internal.IgniteMessagingImpl.send0(IgniteMessagingImpl.java:105) > at > org.apache.ignite.internal.IgniteMessagingImpl.send(IgniteMessagingImpl.java:81) > at npe.IgnitePartitioningTest.main(IgnitePartitioningTest.java:110) > Caused by: class > org.apache.ignite.internal.cluster.ClusterGroupEmptyCheckedException: Cluster > group is empty. > at > org.apache.ignite.internal.util.IgniteUtils.emptyTopologyException(IgniteUtils.java:5106) > at > org.apache.ignite.internal.IgniteMessagingImpl.send0(IgniteMessagingImpl.java:100) > ... 2 more > Fix: > change > return new ClusterGroupAdapter(ctx, null, > Collections.singleton(cfg.getNodeId())); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14468) Adding a list of caches that will not be forced to rebuild indexes to the control.sh --cache indexes_force_rebuild
[ https://issues.apache.org/jira/browse/IGNITE-14468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14468: - Ignite Flags: (was: Release Notes Required) > Adding a list of caches that will not be forced to rebuild indexes to the > control.sh --cache indexes_force_rebuild > -- > > Key: IGNITE-14468 > URL: https://issues.apache.org/jira/browse/IGNITE-14468 > Project: Ignite > Issue Type: Improvement > Components: control.sh, sql >Reporter: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > > After the IGNITE-14321 is implemented, it will be necessary to add to the > command the ability to display to the user that the forced rebuilding of the > indexes is impossible, since they are already being rebuilt. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-13949:
-
Ignite Flags: (was: Release Notes Required)
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-13949:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14027) Switching Auto-adjust on does not trigger including existent nodes(which are not in BLT) to the BLT
[ https://issues.apache.org/jira/browse/IGNITE-14027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14027: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Switching Auto-adjust on does not trigger including existent nodes(which are > not in BLT) to the BLT > --- > > Key: IGNITE-14027 > URL: https://issues.apache.org/jira/browse/IGNITE-14027 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.9.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 40m > Remaining Estimate: 0h > > Steps to reproduce: > * Start cluster with AA on > * Disable AA > * Start new node - it joins topology, not the BL > * Enable AA > Expected: > * As _softTimeout_ passes, the node joins the BLT > Actual: > * The node remains out of BLT > With that new note won't join BLT until either another new node started or AA > disabled and the node is included in the BLT manually -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14055) Deadlock in timeoutObjectProcessor between 'send message' & 'handshake timeout'
[
https://issues.apache.org/jira/browse/IGNITE-14055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14055:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Deadlock in timeoutObjectProcessor between 'send message' & 'handshake
> timeout'
> ---
>
> Key: IGNITE-14055
> URL: https://issues.apache.org/jira/browse/IGNITE-14055
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.11
>
> Attachments: StartServerWithTxPuts (1).java, freeze (1).sh
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cluster hangs after jvm pauses on one of server nodes.
> Scenario:
> 1. Start three server nodes with put operations using StartServerWithTxPuts.
> 2. Emulate jvm freezes on one server node by running the attached script:
> {{*sh freeze.sh *}}
> 3. Wait until the script has finished.
> Result:
> The cluster hangs on tx put operations.
> The first server node continuously prints:
> {noformat}
> [2020-11-03 09:36:01,719][INFO
> ][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
> rmtAddr=/127.0.0.1:57714][2020-11-03 09:36:01,720][INFO
> ][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
> Received incoming connection from remote node while connecting to this node,
> rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
> rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
> 09:36:01,922][INFO
> ][grid-nio-worker-tcp-comm-0-#23%TcpCommunicationSpi%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
> rmtAddr=/127.0.0.1:57716][2020-11-03 09:36:01,922][INFO
> ][grid-nio-worker-tcp-comm-0-#23%TcpCommunicationSpi%][TcpCommunicationSpi]
> Received incoming connection from remote node while connecting to this node,
> rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
> rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
> 09:36:02,124][INFO
> ][grid-nio-worker-tcp-comm-1-#24%TcpCommunicationSpi%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
> rmtAddr=/127.0.0.1:57718][2020-11-03 09:36:02,125][INFO
> ][grid-nio-worker-tcp-comm-1-#24%TcpCommunicationSpi%][TcpCommunicationSpi]
> Received incoming connection from remote node while connecting to this node,
> rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
> rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
> 09:36:02,326][INFO
> ][grid-nio-worker-tcp-comm-2-#25%TcpCommunicationSpi%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
> rmtAddr=/127.0.0.1:57720][2020-11-03 09:36:02,327][INFO
> ][grid-nio-worker-tcp-comm-2-#25%TcpCommunicationSpi%][TcpCommunicationSpi]
> Received incoming connection from remote node while connecting to this node,
> rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
> rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3][2020-11-03
> 09:36:02,528][INFO
> ][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
> Accepted incoming communication connection [locAddr=/127.0.0.1:47100,
> rmtAddr=/127.0.0.1:57722][2020-11-03 09:36:02,529][INFO
> ][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][TcpCommunicationSpi]
> Received incoming connection from remote node while connecting to this node,
> rejecting [locNode=5defd32f-5bdb-4b9e-8a6e-5ee268edac42, locNodeOrder=1,
> rmtNode=07583a9d-36c8-4100-a69c-8cbd26ca82c9, rmtNodeOrder=3]}}
> {noformat}
> The second node prints long running transactions in prepared state ignoring
> the default tx timeout:
>
> {noformat}
> [2020-11-03 09:36:46,199][WARN
> ][sys-#83%56b4f715-82d6-4d63-ba99-441ffcd673b4%][diagnostic] >>> Future
> [startTime=09:33:08.496, curTime=09:36:46.181, fut=GridNearTxFinishFuture
> [futId=425decc8571-4ce98554-8c56-4daf-a7a9-5b9bff52fa08, tx=GridNearTxLocal
> [mappings=IgniteTxMappingsSingleImpl [mapping=GridDistributedTxMapping
> [entries=LinkedHashSet [IgniteTxEntry [txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [part=833, val=833, hasValBytes=true],
> cacheId=-923393186], val=TxEntryValueHolder [val=CacheObjectByteArrayImpl
> [arrLen=1048576], op=CREATE], prevVal=TxEntryValueHolder [val=null, op=NOOP],
> oldVal=TxEntryValueHolder [val=null, op=NOOP], entryProcessorsCol=null,
> ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null,
> dhtVer=null, filters=CacheEntryPredicate[] [], filtersPassed=false,
[jira] [Updated] (IGNITE-14139) Incorrect initialize checkpoint-runner-cpu thread pool
[
https://issues.apache.org/jira/browse/IGNITE-14139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14139:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Incorrect initialize checkpoint-runner-cpu thread pool
> --
>
> Key: IGNITE-14139
> URL: https://issues.apache.org/jira/browse/IGNITE-14139
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> First initialization of checkpoint thread pool for CPU is incorrect.
> Look at the constructor of {{CheckpointWorkflow}}:
> At start, we initialize the pool:
> {code:java}
> this.checkpointCollectPagesInfoPool = initializeCheckpointPool();
> {code}
> and only after, we set a size of the pool:
> {code:java}
> this.checkpointCollectInfoThreads = checkpointCollectInfoThreads;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14140) Checkpointer thread holds write lock too long
[
https://issues.apache.org/jira/browse/IGNITE-14140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14140:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Checkpointer thread holds write lock too long
> -
>
> Key: IGNITE-14140
> URL: https://issues.apache.org/jira/browse/IGNITE-14140
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Free lists flushing optimization can block db-checkpoint-thread when it got
> Write lock. It might block all transactions for several hundreds milliseconds.
> {noformat}
> "db-checkpoint-thread-#334%DPL_GRID%DplGridNodeName%" #667 daemon prio=5
> os_prio=0 tid=0x7e765c123800 nid=0xee0b8 runnable [0x7e767f535000]
>java.lang.Thread.State: RUNNABLE
> at sun.misc.Unsafe.getObjectVolatile(Native Method)
> at
> java.util.concurrent.atomic.AtomicReferenceArray.getRaw(AtomicReferenceArray.java:130)
> at
> java.util.concurrent.atomic.AtomicReferenceArray.get(AtomicReferenceArray.java:125)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.getBucketCache(AbstractFreeList.java:690)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.flushBucketsCache(PagesList.java:374)
> at
> org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.saveMetadata(PagesList.java:343)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.saveStoreMetadata(GridCacheOffheapManager.java:373)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.syncMetadata(GridCacheOffheapManager.java:336)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.syncMetadata(GridCacheOffheapManager.java:322)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager.onMarkCheckpointBegin(GridCacheOffheapManager.java:247)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointWorkflow.markCheckpointBegin(CheckpointWorkflow.java:281)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:388)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:264)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> We can to reduce time into Write lock if switch off optimization before the
> lock will be gotten and enable it after the lock will be left off.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14141) Remove unnecessary storage configuration from PageStore
[
https://issues.apache.org/jira/browse/IGNITE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14141:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Remove unnecessary storage configuration from PageStore
> ---
>
> Key: IGNITE-14141
> URL: https://issues.apache.org/jira/browse/IGNITE-14141
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DataStorageConfiguration}} is used only for getting the {{pageSize}} in
> the {{FilePageStore}} implementation and can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14153) TcpCommunicationSpi#closeStaleConnections() doesn't work for outgoing connections
[ https://issues.apache.org/jira/browse/IGNITE-14153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14153: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > TcpCommunicationSpi#closeStaleConnections() doesn't work for outgoing > connections > - > > Key: IGNITE-14153 > URL: https://issues.apache.org/jira/browse/IGNITE-14153 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.9.1 >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Major > Fix For: 2.11 > > Attachments: TcpCommunicationSpiHalfOpenedConnectionTest.java > > Time Spent: 20m > Remaining Estimate: 0h > > Scenario: > 1. Node1 established communication connection to Node2. > 2. Due to network issue the connection was closed on Node2 side, but was > still alive on Node1 side. (half-open connection) > 3. At some point of time Node2 tries to send a message to Node1, and since > there are no existing connections it creates a new one. > 4. Node1 detects that it already has connection to Node2 and prints next > message: > [TcpCommunicationSpi] Received incoming connection when already connected to > this node, rejecting [locNode=2cc905e6--48c1-b316-7652d661, > rmtNode=44c537a7-6070-4272-a545-cff054b0] > 5. Node1 tries to close existing connection by using closeStaleConnection() > method, but since the connection was outcoming it skipped due to "if > (ses0.accepted())" check. > 6. Node2 makes an infinite amount of tries to connect without success. > Reproducer is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14331:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14385) Add checkpoint information to the performance statistics.
[ https://issues.apache.org/jira/browse/IGNITE-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14385: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Add checkpoint information to the performance statistics. > - > > Key: IGNITE-14385 > URL: https://issues.apache.org/jira/browse/IGNITE-14385 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add start/end time and other parameters of checkpoint to performance > statistics. > Add information about throttling if necessary -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14378) Remove delay from node ping.
[ https://issues.apache.org/jira/browse/IGNITE-14378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14378: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Remove delay from node ping. > > > Key: IGNITE-14378 > URL: https://issues.apache.org/jira/browse/IGNITE-14378 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove U.sleep(200) from the node ping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14394:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14451) PK becomes corrupted after node restart
[ https://issues.apache.org/jira/browse/IGNITE-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14451: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > PK becomes corrupted after node restart > --- > > Key: IGNITE-14451 > URL: https://issues.apache.org/jira/browse/IGNITE-14451 > Project: Ignite > Issue Type: Bug >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 0.5h > Remaining Estimate: 0h > > PK index tree becomes corrupted after node restart in case it was created > through SQL API and it's fields order differs from the one in field list. For > example: > CREATE TABLE t (id1 INTEGER, id2 INTEGER, val VARCHAR, CONSTRAINT PK PRIMARY > KEY (id2, id1)) - this won't survive restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14448) Failure to connect to node leads to hanging connection future if paired connections are used
[
https://issues.apache.org/jira/browse/IGNITE-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14448:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Failure to connect to node leads to hanging connection future if paired
> connections are used
>
>
> Key: IGNITE-14448
> URL: https://issues.apache.org/jira/browse/IGNITE-14448
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.10
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
> getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
>if (connRequestor != null) {
> ...
>if (isPairedConnection(node, tcpCommSpi))
>throw new IgniteSpiException("Inverse connection protocol
> doesn't support paired connections");{code}
> Turns out this exception is not handled property and connection future is
> never done. Then, striped pool threads wait forever on reserveClient() and
> cluster grinds to halt.This happens in versions which have
> communication-via-discovery and when usePairedConnections=true.
> {code:java}
> [12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
> 1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
> sockAddrs=HashSet [/127.0.0.1:0,
> ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
> intOrder=47, lastExchangeTime=1603983940522, loc=false,
> ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
> topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
> alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
> val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
> [idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
> sparkJobStatus=COMPLETED], prevVal=null,
> super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
> nearFutId=0, flags=near]], connIdx=-1]]
> class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
> doesn't support paired connections
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.handleUnreachableNodeException(ConnectionClientPool.java:365)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.reserveClient(ConnectionClientPool.java:256)
>
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1132)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1083)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1814)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1930)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.sendDhtRequests(GridDhtAtomicAbstractUpdateFuture
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14582) Continuous Query deploys remote filter even on client nodes
[ https://issues.apache.org/jira/browse/IGNITE-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14582: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Continuous Query deploys remote filter even on client nodes > --- > > Key: IGNITE-14582 > URL: https://issues.apache.org/jira/browse/IGNITE-14582 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Major > Fix For: 2.11 > > Attachments: CacheContinuousQueryDeploymentToClientTest.java > > Time Spent: 20m > Remaining Estimate: 0h > > When the client node joins cluster CQ routine is deployed on it, but there's > no sense to have CQ on the client node which doesn't store any data at all. > Test attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14584) Server node fails on remote filter with static initializer deployment if client disconnects
[
https://issues.apache.org/jira/browse/IGNITE-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14584:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Server node fails on remote filter with static initializer deployment if
> client disconnects
> ---
>
> Key: IGNITE-14584
> URL: https://issues.apache.org/jira/browse/IGNITE-14584
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Igor Belyakov
>Assignee: Igor Belyakov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cluster contains 1 server and 1 client node. PeerClassLoading is turned on.
> 1. Client node deploys CQ with remote filter, server node doesn't have
> classes required for remote filter in classpath. Remote filter should has a
> class with static initializer, which has a type that should be deployed:
>
> {code:java}
> public class TestClass {
> static {
> TestSubClass testSubClass = new TestSubClass();
> }
> }
> public class TestSubClass {
> }
> {code}
>
> 2. When TestSubClass deployment is in progress on the server node, the client
> node is stopped
> 3. The server node is unable to deploy TestSubClass and static initializer
> can't be finished, as result java.lang.ExceptionInInitializerError happens in
> discovery thread and server node fails:
> {code:java}
> [16:56:23,829][WARNING][disco-notifier-worker-#49%srv1%][GridDeploymentPerVersionStore]
> Failed to send class-loading request to node (is node alive?)
> [node=72513f9a-8053-410c-bc4f-aa4935e06661, clsName=TestSubClass,
> clsPath=TestSubClass.class,
> clsLdrId=1ca6c09f471-72513f9a-8053-410c-bc4f-aa4935e06661,
> parentClsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2][16:56:23,829][WARNING][disco-notifier-worker-#49%srv1%][GridDeploymentPerVersionStore]
> Failed to send class-loading request to node (is node alive?)
> [node=72513f9a-8053-410c-bc4f-aa4935e06661, clsName=TestSubClass,
> clsPath=TestSubClass.class,
> clsLdrId=1ca6c09f471-72513f9a-8053-410c-bc4f-aa4935e06661,
> parentClsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2]
> [16:56:23,829][SEVERE][disco-notifier-worker-#49%srv1%][GridDiscoveryManager]
> Exception in discovery notifier worker
> thread.java.lang.ExceptionInInitializerError at
> java.lang.Class.forName0(Native Method) at
> java.lang.Class.forName(Class.java:348) at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9066) at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:325)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:640)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1976)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:315)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:300)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10573)
> at
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10602)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryDeployableObject.unmarshal(CacheContinuousQueryDeployableObject.java:96)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1308)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.p2pUnmarshal(CacheContinuousQueryHandler.java:1283)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processStartRequest(GridContinuousProcessor.java:1408)
[jira] [Updated] (IGNITE-14610) BinaryBuilderReader doesn't supports reference (HANDLE) to collection
[
https://issues.apache.org/jira/browse/IGNITE-14610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14610:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> BinaryBuilderReader doesn't supports reference (HANDLE) to collection
> -
>
> Key: IGNITE-14610
> URL: https://issues.apache.org/jira/browse/IGNITE-14610
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Critical
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Steps to reproduce:*
> 1. Create object with two objects collection fields, e.g. List
> 2. Assign the reference of the one field to the second.
> 3. Serialize object to BinaryObject
> 4. Create BinaryObjectBuiler from the object.
> 5. Add/change any field except collections.
> 6. Try to build new BinaryObject form the builer
> *Exception is thrown:*
> {code:java}
> class org.apache.ignite.binary.BinaryObjectException: Unsupported protocol
> version: 2
> at
> org.apache.ignite.internal.binary.BinaryUtils.checkProtocolVersion(BinaryUtils.java:795)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.(BinaryObjectBuilderImpl.java:139)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderReader.parseValue(BinaryBuilderReader.java:522)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:286)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:100)
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:53)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:293)
> at
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:188)
> {code}
> *Root cause:*
> BinaryBuilderReader#parseValue doesn’t support handle to collection. Only
> handles to object are expected.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14687) BinaryHeapOutputStream BinaryOffheapOutputStream corrupt memory in case of overflow and cause JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-14687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14687: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > BinaryHeapOutputStream BinaryOffheapOutputStream corrupt memory in case of > overflow and cause JVM crash > --- > > Key: IGNITE-14687 > URL: https://issues.apache.org/jira/browse/IGNITE-14687 > Project: Ignite > Issue Type: Bug > Components: binary >Affects Versions: 2.10 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Reproducer is easy: > while (true) out.writeByteArray(bytes); > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x02742b26, > pid=17128, tid=0x24e4 > # > > > Actually It happened to me occassionally when by mistake a compute job tried > to return too many results. JVM crashed on the job result serialization. > See link to full reproducers below. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14661) Broken validation of parts of compound PK
[
https://issues.apache.org/jira/browse/IGNITE-14661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14661:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Broken validation of parts of compound PK
> -
>
> Key: IGNITE-14661
> URL: https://issues.apache.org/jira/browse/IGNITE-14661
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently it's possible to set {{null}} to column that is part of compound PK
> even if this field was declared as {{NOT NULL}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14821) AssertionError: Historical iterator tries to iterate WAL out of reservation
[
https://issues.apache.org/jira/browse/IGNITE-14821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14821:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> AssertionError: Historical iterator tries to iterate WAL out of reservation
> ---
>
> Key: IGNITE-14821
> URL: https://issues.apache.org/jira/browse/IGNITE-14821
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A reason of the issue is incorrect comparison WAL pointer, that leads to
> choose not quite the last pointer for reservation before rebalance. The code
> selected the earliest WAL segment, but not the last pointer in it.
> Assuming assertion error in description:
> {code}Historical iterator tries to iterate WAL out of reservation
> [cache=SYSTEM_CACHEGROUP_LONGKEYS, reservedPointer=FileWALPointer [idx=10,
> fileOff=448674503, len=104925], historicalPointer=FileWALPointer [idx=10,
> fileOff=442844723, len=104925]]{code}
> reservedPointer is chosen incorrect, but corresponds to the valid segment
> {{idx=10}} (the same as in historicalPointer).
> A valid comparison of WAL pointers solves this issue. Segment number and
> segment offset participate in it together (look at the
> FileWalPointer#comapreTo method).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14828) No fallback to full rebalance after exception on historical
[
https://issues.apache.org/jira/browse/IGNITE-14828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov updated IGNITE-14828:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> No fallback to full rebalance after exception on historical
> ---
>
> Key: IGNITE-14828
> URL: https://issues.apache.org/jira/browse/IGNITE-14828
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have noticed that in some cases when we handle demand message in
> {{GridDhtPartitionSupplier.java}} it is possible for some reasons that
> {code:java}
> iter = grp.offheap().rebalanceIterator(demandMsg.partitions(),
> demandMsg.topologyVersion());
> {code}
> throw an exception. In that case, rebalance should switch to full, but the
> code has a bug and {{remainingParts}} has been filed after rebalance iterator
> has been created
> {code:java}
> for (int i = 0; i < histMap.size(); i++) {
> int p = histMap.partitionAt(i);
> remainingParts.add(p);
> }
> {code}
> That means that we lost partitions that meant to be rebalanced by historical
> rebalance.
> The solution is to create an iterator after {{remainingParts}} filling.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14990) Incorrect values of cache, cache group, data region metrics after cluster re-activation
[ https://issues.apache.org/jira/browse/IGNITE-14990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14990: - Fix Version/s: (was: 2.12) 2.11 > Incorrect values of cache, cache group, data region metrics after cluster > re-activation > --- > > Key: IGNITE-14990 > URL: https://issues.apache.org/jira/browse/IGNITE-14990 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.11 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Cache, cache group, data region metrics values are incorrect after the > cluster re-activation. > It happens because they are not registered with the new cache* context and > still point to the previous one. Data region metrics are not reset/remove > after deactivation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371686#comment-17371686
]
Alexey Gidaspov commented on IGNITE-12508:
--
Hello [~atri],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Rakov
>Assignee: Atri Sharma
>Priority: Major
> Labels: newbie
> Fix For: 2.11
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-12852: - Fix Version/s: (was: 2.11) 2.12 > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.12 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13169) Remove Ignite bean name requirement for Spring Data Repository
[ https://issues.apache.org/jira/browse/IGNITE-13169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371681#comment-17371681 ] Alexey Gidaspov commented on IGNITE-13169: -- Hello [~sdanilov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Remove Ignite bean name requirement for Spring Data Repository > -- > > Key: IGNITE-13169 > URL: https://issues.apache.org/jira/browse/IGNITE-13169 > Project: Ignite > Issue Type: Improvement > Components: springdata >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > At the moment IgniteRepositoryFactoryBean requires Ignite instance bean (or > IgniteConfiguration instance bean) with specific name. > There are couple of problems with that behavior: > 1) We have a SpringBoot autoconfiguration module which creates bean with > different name, so Ignite Spring Data won't work out of the box > 2) That is, actually, not a Spring-way to do things: Spring prefers > injecting by class, qualifiers like name and order should be used only when > necessay > I propose changing behavior to "getting bean by class and not by name" > > This won't require any user code changes, because we only remove restrictions > on Ignite instance bean name -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13029) Support Spring Data repositories initialization with Spring Boot auto-starter
[
https://issues.apache.org/jira/browse/IGNITE-13029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371683#comment-17371683
]
Alexey Gidaspov commented on IGNITE-13029:
--
Hello [~stalkxt],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Support Spring Data repositories initialization with Spring Boot auto-starter
> -
>
> Key: IGNITE-13029
> URL: https://issues.apache.org/jira/browse/IGNITE-13029
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Assignee: Sergey Dorozhkin
>Priority: Major
> Labels: newbie
> Fix For: 2.11
>
>
> It's required to use {{@EnableIgniteRepositories}} annotation and follow this
> procedure to enable Ignite Spring Data repositories:
> https://apacheignite-mix.readme.io/docs/spring-data#spring-data-and-apache-ignite-configuration
> Support the Spring Data repositories enablement via the Spring Boot
> auto-starter if Spring Boot is used by a project:
> https://apacheignite-mix.readme.io/docs/spring-boot
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371680#comment-17371680 ] Alexey Gidaspov commented on IGNITE-13689: -- Hello [~a-polyakov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Extend test coverage [IGNITE-11512] Add counter left partition for index > rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-13689 > URL: https://issues.apache.org/jira/browse/IGNITE-13689 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Labels: test > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > New test: > Partial rebuild > # Start cluster, load data with indexes > # Kill single node, create new index, start node. > # Make sure that index rebuild count is in range of total new index size and > 0 and decreasing > # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13725) Add snapshot check command
[
https://issues.apache.org/jira/browse/IGNITE-13725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371679#comment-17371679
]
Alexey Gidaspov commented on IGNITE-13725:
--
Hello [~mmuzaf],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Add snapshot check command
> --
>
> Key: IGNITE-13725
> URL: https://issues.apache.org/jira/browse/IGNITE-13725
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.11
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> The user must be able to validate a created snapshot should be validated on
> its consistency the same way as the {{idle_verify}} procedure does.
> It is necessary to introduce a new {{SnapshotMetadata}} structure to save the
> additional snapshot meta information. The verify procedure must collect all
> snapshot metadata parts and check for its completeness and consistency.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13767) Remove Python PHP and Node.js thin clients from main repository
[ https://issues.apache.org/jira/browse/IGNITE-13767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371678#comment-17371678 ] Alexey Gidaspov commented on IGNITE-13767: -- Hello [~isapego], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Remove Python PHP and Node.js thin clients from main repository > --- > > Key: IGNITE-13767 > URL: https://issues.apache.org/jira/browse/IGNITE-13767 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Need to remove the following directories, as we now have separate repos for > Python, Node.js and PHP thin clients: > modules/platforms/python > modules/platforms/nodejs > modules/platforms/php > > Also, need to check all the places in code where those directories are > referenced. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13792) Reconnecting clients trigger failure handler
[
https://issues.apache.org/jira/browse/IGNITE-13792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371677#comment-17371677
]
Alexey Gidaspov commented on IGNITE-13792:
--
Hello [~v.pyatkov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Reconnecting clients trigger failure handler
>
>
> Key: IGNITE-13792
> URL: https://issues.apache.org/jira/browse/IGNITE-13792
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.9
>Reporter: Pavel Vinokurov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Attachments: UnstableClients.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code:java}
> Dec 01, 2020 9:38:29 PM java.util.logging.LogManager$RootLogger log
> SEVERE: JVM will be halted immediately due to the failure:
> [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
> o.a.i.IgniteCheckedException: Affinity for topology version is not
> initialized [locNode=b50635ff-0324-431b-bc34-00a6cd36c9e3,
> grp=ignite-sys-cache, topVer=AffinityTopologyVersion [topVer=570,
> minorTopVer=0], head=AffinityTopologyVersion [topVer=569, minorTopVer=0],
> history=[AffinityTopologyVersion [topVer=551, minorTopVer=0],
> AffinityTopologyVersion [topVer=552, minorTopVer=0], AffinityTopologyVersion
> [topVer=553, minorTopVer=0], AffinityTopologyVersion [topVer=554,
> minorTopVer=0], AffinityTopologyVersion [topVer=555, minorTopVer=0],
> AffinityTopologyVersion [topVer=556, minorTopVer=0], AffinityTopologyVersion
> [topVer=557, minorTopVer=0], AffinityTopologyVersion [topVer=558,
> minorTopVer=0], AffinityTopologyVersion [topVer=559, minorTopVer=0],
> AffinityTopologyVersion [topVer=560, minorTopVer=0], AffinityTopologyVersion
> [topVer=561, minorTopVer=0], AffinityTopologyVersion [topVer=562,
> minorTopVer=0], AffinityTopologyVersion [topVer=563, minorTopVer=0],
> AffinityTopologyVersion [topVer=564, minorTopVer=0], AffinityTopologyVersion
> [topVer=565, minorTopVer=0], AffinityTopologyVersion [topVer=566,
> minorTopVer=0], AffinityTopologyVersion [topVer=567, minorTopVer=0],
> AffinityTopologyVersion [topVer=568, minorTopVer=0], AffinityTopologyVersion
> [topVer=569, minorTopVer=0]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13805) Add support for cache group restore from a snapshot on the same topology
[ https://issues.apache.org/jira/browse/IGNITE-13805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371676#comment-17371676 ] Alexey Gidaspov commented on IGNITE-13805: -- Hello [~xtern], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add support for cache group restore from a snapshot on the same topology > > > Key: IGNITE-13805 > URL: https://issues.apache.org/jira/browse/IGNITE-13805 > Project: Ignite > Issue Type: New Feature >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Labels: iep-43, important > Fix For: 2.11 > > Time Spent: 12h 50m > Remaining Estimate: 0h > > Ignite 2.9 introduces a new feature to take [consistent cluster > snapshot|https://ignite.apache.org/docs/latest/persistence/snapshots]. > However, there is currently no way for the user to restore a separate cache > group from such a snapshot. > As a first step, we must provide the ability (CLI command and public API) to > restore the separate cache group(s) without considering the current partition > distribution and rely on rebalancing to achieve the ideal distribution. > This process consists of the following steps: > # Make sure that all partitions of the cache group are available in the > cluster and that there are no conflicts in the saved cache configurations. > # Make sure the target cache group does not exist (user must manually > destroy the cache before restoring).. > # Move the cache data files locally on each node with the cache data > snapshots. > # Merge the binary metadata from the snapshot on each node. > # Dynamically start the restored cache group. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13818) Add extended logging topology for node left/join a grid
[ https://issues.apache.org/jira/browse/IGNITE-13818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371675#comment-17371675 ] Alexey Gidaspov commented on IGNITE-13818: -- Hello [~makedonskaya], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add extended logging topology for node left/join a grid > --- > > Key: IGNITE-13818 > URL: https://issues.apache.org/jira/browse/IGNITE-13818 > Project: Ignite > Issue Type: Improvement >Reporter: Maria Makedonskaya >Assignee: Maria Makedonskaya >Priority: Major > Fix For: 2.11 > > Time Spent: 50m > Remaining Estimate: 0h > > At start of the node write topology - the number of server and client nodes, > I would like to expand the list of nodes (information about each node: order, > id, host, ip), this will help in the case when the logs are only from one > node, and when there are logs from all nodes it will speed up the search for > coordinator or find the problem node id which was in the transaction -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13873) Milti-cell transaction changes may be not visible (during some time) after the Cellular switch [Sync-free switch]
[
https://issues.apache.org/jira/browse/IGNITE-13873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371672#comment-17371672
]
Alexey Gidaspov commented on IGNITE-13873:
--
Hello [~av],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Milti-cell transaction changes may be not visible (during some time) after
> the Cellular switch [Sync-free switch]
> -
>
> Key: IGNITE-13873
> URL: https://issues.apache.org/jira/browse/IGNITE-13873
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: iep-45
> Fix For: 2.11
>
> Attachments: master (as 2.9) vs improved (as dev) .png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Transactions over some cells may be recovered after the stale data read.
> For example:
> We have 2 cells, the first contains partitions for k1, second for k2.
> Tx with put(k1,v1) and put(k2,v2) started and prepared.
> Then node from the first cell, which is the primary for k1, failed.
> Currently, the second cell (with key2) may finish the cellular switch before
> tx recovered and stale data read is possible.
> Primaries from the {{tx.transactionNodes()}} should be taken into account
> instead of the current logic that awaits for all transactions located on
> nodes who are backups to the failed primary.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13949) Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
[
https://issues.apache.org/jira/browse/IGNITE-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371670#comment-17371670
]
Alexey Gidaspov commented on IGNITE-13949:
--
Hello [~YAMolochkov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Insufficient synchronisation in PartitionUpdateCounterTrackingImpl
> --
>
> Key: IGNITE-13949
> URL: https://issues.apache.org/jira/browse/IGNITE-13949
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Right now
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl
> has 2 AtomicLong variables, cntr and reserveCntr, but there are some
> methods, that are unsynchronised, e.g. next:
> {code:java}
> @Override public long next() {
> long next = cntr.incrementAndGet();
> reserveCntr.set(next);
> return next;
> } {code}
> Even though both are AtomicLong, operation like "get then set" is a composite
> one and should be atomic in the context of an object that holds these
> variables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14134) Snapshot check command must cacluate primary and backup partition hashes
[ https://issues.apache.org/jira/browse/IGNITE-14134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371668#comment-17371668 ] Alexey Gidaspov commented on IGNITE-14134: -- Hello [~mmuzaf], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Snapshot check command must cacluate primary and backup partition hashes > > > Key: IGNITE-14134 > URL: https://issues.apache.org/jira/browse/IGNITE-14134 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 5.5h > Remaining Estimate: 0h > > The snapshot verify procedure must calculate primary and backup partition > hashes. > The procedure should read each K-V pairs from each partition and calculate a > resulted checksum. This collection of checksums must be compared between > primary and backup partition to ensue the same data stored in each partition > copy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14141) Remove unnecessary storage configuration from PageStore
[
https://issues.apache.org/jira/browse/IGNITE-14141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371667#comment-17371667
]
Alexey Gidaspov commented on IGNITE-14141:
--
Hello [~mmuzaf],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Remove unnecessary storage configuration from PageStore
> ---
>
> Key: IGNITE-14141
> URL: https://issues.apache.org/jira/browse/IGNITE-14141
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DataStorageConfiguration}} is used only for getting the {{pageSize}} in
> the {{FilePageStore}} implementation and can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14214) Incorrect merge query when using oracle dialect
[
https://issues.apache.org/jira/browse/IGNITE-14214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371664#comment-17371664
]
Alexey Gidaspov commented on IGNITE-14214:
--
Hello [~NSAmelchev],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Incorrect merge query when using oracle dialect
> ---
>
> Key: IGNITE-14214
> URL: https://issues.apache.org/jira/browse/IGNITE-14214
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.9.1
>Reporter: Yaroslav Molochkov
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> If table contains only keys (e.g. relationship table) then returned query
> contains empty update fields and resulting syntax is incorrect.
> Consider the following example:
> org.apache.ignite.cache.store.jdbc.dialect.OracleDialect#mergeQuery accepts
> key and val collections. The problem is relevant if val collection is empty.
> {code:java}
> return String.format("MERGE INTO %s t" +
> " USING (SELECT %s FROM dual) v" +
> " ON %s" +
> " WHEN MATCHED THEN" +
> " UPDATE SET %s" +
> " WHEN NOT MATCHED THEN" +
> " INSERT (%s) VALUES (%s)", fullTblName, selCols, match, setCols,
> colsLst, valuesCols);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14191) Add command to control.(sh|bin) to manage performance statistics
[
https://issues.apache.org/jira/browse/IGNITE-14191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371665#comment-17371665
]
Alexey Gidaspov commented on IGNITE-14191:
--
Hello [~NSAmelchev],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Add command to control.(sh|bin) to manage performance statistics
>
>
> Key: IGNITE-14191
> URL: https://issues.apache.org/jira/browse/IGNITE-14191
> Project: Ignite
> Issue Type: New Feature
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add command to control.(sh|bin) to manage performance statistics:
> {noformat}
> --performance-statistics [start|stop|status]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14241) IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive broken
[
https://issues.apache.org/jira/browse/IGNITE-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371662#comment-17371662
]
Alexey Gidaspov commented on IGNITE-14241:
--
Hello [~nizhikov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive
> broken
> -
>
> Key: IGNITE-14241
> URL: https://issues.apache.org/jira/browse/IGNITE-14241
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
> {{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
> is broken.
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-67455213630528885=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14221) SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
[
https://issues.apache.org/jira/browse/IGNITE-14221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371663#comment-17371663
]
Alexey Gidaspov commented on IGNITE-14221:
--
Hello [~nizhikov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
>
>
> Key: IGNITE-14221
> URL: https://issues.apache.org/jira/browse/IGNITE-14221
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> Currently, SQL constants not hidden if
> {{IGNITE_TO_STRING_INCLUDE_SENSITIVE=false}}.
> This can lead to security incidents when some applications don't use SQL
> parameters and send constant in query body.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14248) Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock properly
[
https://issues.apache.org/jira/browse/IGNITE-14248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371661#comment-17371661
]
Alexey Gidaspov commented on IGNITE-14248:
--
Hello [~Vladimir Pligin],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock
> properly
> ---
>
> Key: IGNITE-14248
> URL: https://issues.apache.org/jira/browse/IGNITE-14248
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Vladimir Pligin
>Assignee: Vladimir Pligin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> If an exception (or even Error) is thrown inside of the method then the node
> turns into some unrecoverable state. Here's an example.
> # an exchange is about to finish, it's time to invalidate partition
> reservations.
> # exchange thread delegates it to a thread in the management pool
> # management pool tries to allocate a new thread (maybe it's idle and
> therefore empty)
> # for example ulimit is reached, the error is
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> # It's being logged, no further action is taken
> # partitions are reserved forever
> Message:
>
> {code:java}
> 2021-02-25 05:52:03.242 [exchange-worker-#182] ERROR
> o.a.i.i.p.q.h.t.PartitionReservationManager - Unexpected exception on start
> reservations cleanup
> java.lang.OutOfMemoryError: unable to create native thread: possibly out of
> memory or process/resource limits reached
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:803)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.runLocal(GridClosureProcessor.java:847)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.PartitionReservationManager.onDoneAfterTopologyUnlock(PartitionReservationManager.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2617)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:159)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1064)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3375)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3194)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> Code of PartitionReservationManager.onDoneAfterTopologyUnlock:
> {code:java}
> @Override public void onDoneAfterTopologyUnlock(final
> GridDhtPartitionsExchangeFuture fut) {
> try {
> // Must not do anything at the exchange thread. Dispatch to the
> management thread pool.
> ctx.closure().runLocal(() -> {
> AffinityTopologyVersion topVer =
> ctx.cache().context().exchange()
>
> .lastAffinityChangedTopologyVersion(fut.topologyVersion());
> reservations.forEach((key, r) -> {
> if (r != REPLICATED_RESERVABLE &&
> !F.eq(key.topologyVersion(), topVer)) {
> assert r instanceof GridDhtPartitionsReservation;
>((GridDhtPartitionsReservation)r).invalidate();
> }
> });
> },
> GridIoPolicy.MANAGEMENT_POOL);
> }
> catch (Throwable e) {
> log.error("Unexpected exception on start reservations cleanup",
> e);
> }
> }
> {code}
>
>
> My vision is that there are two basic approaches:
> * to kill the node (it's already non-functional at this point), seems to be
> a FH job.
> * try to recover somehow (to be honest it's not clear how
[jira] [Commented] (IGNITE-14255) Added the ability to rotate collecting performance statistics
[ https://issues.apache.org/jira/browse/IGNITE-14255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371659#comment-17371659 ] Alexey Gidaspov commented on IGNITE-14255: -- Hello [~RyzhovSV], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Added the ability to rotate collecting performance statistics > - > > Key: IGNITE-14255 > URL: https://issues.apache.org/jira/browse/IGNITE-14255 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 5h 10m > Remaining Estimate: 0h > > Add the ability to rotate the performance statistics file using the > control.sh and JMX. > collection of performance statistics will continue to be written to the next > file -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14257) Add copy constructor to ClientCacheConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-14257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371658#comment-17371658 ] Alexey Gidaspov commented on IGNITE-14257: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add copy constructor to ClientCacheConfiguration > - > > Key: IGNITE-14257 > URL: https://issues.apache.org/jira/browse/IGNITE-14257 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > It's proposed to add copy constructor to ClientCacheConfiguration class. > This will make it possible to conveniently create a configuration based on > the provided template. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14267) Cluster snapshot must support encrypted caches
[ https://issues.apache.org/jira/browse/IGNITE-14267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Gidaspov updated IGNITE-14267: - Fix Version/s: (was: 2.11) 2.12 > Cluster snapshot must support encrypted caches > -- > > Key: IGNITE-14267 > URL: https://issues.apache.org/jira/browse/IGNITE-14267 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.12 > > > Currently, the snapshot procedure doesn't support taking a cluster snapshot > for caches with enabled encryption. We should support such a feature, so the > user will be able to create and restore for such snapshots. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371656#comment-17371656
]
Alexey Gidaspov commented on IGNITE-14331:
--
Hello [~slava.koptilin],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14335) Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
[
https://issues.apache.org/jira/browse/IGNITE-14335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371655#comment-17371655
]
Alexey Gidaspov commented on IGNITE-14335:
--
Hello [~PetrovMikhail],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Merge APIs of IgniteAuthenticationProcessor and IgniteSecurity
>
>
> Key: IGNITE-14335
> URL: https://issues.apache.org/jira/browse/IGNITE-14335
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> It is proposed:
> # Remove an IgniteAuthenticationProcessor that is now treated as an
> independent processor.
> # Move the logic of IgniteAuthenticationProcessor into the implementation
> of the security plugin that will be used if authentication is enabled via
> configuration.
> # Remove duplication of security checks and leave IgniteSecurity as a single
> security API. As of now, authentication operations are not delegated to
> IgniteAuthenticationProcessor if a security plugin is specified. So the
> overall security behavior from the user side will remain intact.
> # Remove the AuthorizationContext completely as IgniteSecurity provides an
> API for storing and managing the security contexts.
> # Extend GridSecurityPlugin interface with methods that provide the ability
> to manage security users to support existing commands available for
> authentication processor - alter/drop/create through SQL and REST.
> As a result, we will make the security-related code more consistent and
> simpler.
> Proposed signatures of GridSecurityPlugin methods that provide the ability to
> manage security users:
> {code:java}
> public void createUser(String login, UserOptions opts) throws
> IgniteCheckedException {code}
> {code:java}
> public void alterUser(String login, UserOptions opts) throws
> IgniteCheckedException{code}
> {code:java}
> public void dropUser(String login) throws IgniteCheckedException{code}
> The UserOptions class is a wrapper over EnumMap that maps option values to
> their aliases. This allows the class to be used for both create and alter
> user operations and doesn't break backward compatibility in case new options
> are declared.
> The proposed changes lead to the following compatibility issues:
> 1. When a user provides a security plugin and enables native authentication -
> in this case, the user will face exceptions during the node start while now
> node starts smoothly. This case makes a little sense because now
> authentication operations are not delegated to IgniteAuthenticationProcessor
> at all if a security plugin is specified.
> 2. The current implementation of IgniteAuthenticationProcessor can enable
> authentication itself if the current node connects to the cluster with
> authentication enabled - this functionality will not be supported. The user
> can easily overcome this by explicitly enabling authentication in the
> configuration on all nodes.3. The error message of some mutually exclusive
> events can be changed.
> The remaining implementation of the IgniteAuthenticationProcessor and its
> general behavior will remain intact. I also propose to keep the current
> callbacks for the IgniteAuthenticationProcessor (e.g.
> IgniteAuthenticationProcessor#cacheProcessorStarted) that are called from
> other managers intact, just skip these calls if the
> IgniteAuthenticationProcessor is not being used for security.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14368) System view for DataStructures
[ https://issues.apache.org/jira/browse/IGNITE-14368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371653#comment-17371653 ] Alexey Gidaspov commented on IGNITE-14368: -- Hello [~nizhikov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > System view for DataStructures > -- > > Key: IGNITE-14368 > URL: https://issues.apache.org/jira/browse/IGNITE-14368 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Currently, there is no way for the user to know what DataStructures exist in > Ignite. > We should provide a system view for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14377) Enchance log of node ping failure.
[ https://issues.apache.org/jira/browse/IGNITE-14377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371650#comment-17371650 ] Alexey Gidaspov commented on IGNITE-14377: -- Hello [~vladsz83], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Enchance log of node ping failure. > -- > > Key: IGNITE-14377 > URL: https://issues.apache.org/jira/browse/IGNITE-14377 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Log of unsuccessful ping during the joining is insufficient. No failure > reason is logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14378) Remove delay from node ping.
[ https://issues.apache.org/jira/browse/IGNITE-14378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371649#comment-17371649 ] Alexey Gidaspov commented on IGNITE-14378: -- Hello [~vladsz83], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Remove delay from node ping. > > > Key: IGNITE-14378 > URL: https://issues.apache.org/jira/browse/IGNITE-14378 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove U.sleep(200) from the node ping. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14376) JmxMetricExporter fails to export discovery metrics
[
https://issues.apache.org/jira/browse/IGNITE-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371651#comment-17371651
]
Alexey Gidaspov commented on IGNITE-14376:
--
Hello [~PetrovMikhail],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> JmxMetricExporter fails to export discovery metrics
> ---
>
> Key: IGNITE-14376
> URL: https://issues.apache.org/jira/browse/IGNITE-14376
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Error:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at java.lang.String.substring(String.java:1931)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.lambda$getMBeanInfo$0(MetricRegistryMBean.java:105)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getMBeanInfo(MetricRegistryMBean.java:85)
> at
> org.apache.ignite.spi.metric.jmx.MetricRegistryMBean.getAttribute(MetricRegistryMBean.java:58)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
> at
> javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:273)
> at com.sun.proxy.$Proxy32.getMBeanInfo(Unknown Source)
> at
> org.apache.ignite.internal.metric.JmxExporterSpiTest.test(JmxExporterSpiTest.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2391)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> cfg.setMetricExporterSpi(jmxSpi);
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx srv = startGrid();
> DynamicMBean mBean = metricRegistry(srv.name(), "io", "discovery");
> mBean.getMBeanInfo();
> }
> {code}
> The main reason: JMX exporter assumes that each metric must starts with the
> name of the registry it belongs to (see MetricRegistryMBean#getMBeanInfo),
> but discovery metrics do not obey this naming convection (see
> TcpDiscoveryStatistics/ZookeeperDiscoveryStatistics).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14385) Add checkpoint information to the performance statistics.
[ https://issues.apache.org/jira/browse/IGNITE-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371648#comment-17371648 ] Alexey Gidaspov commented on IGNITE-14385: -- Hello [~RyzhovSV], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Add checkpoint information to the performance statistics. > - > > Key: IGNITE-14385 > URL: https://issues.apache.org/jira/browse/IGNITE-14385 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add start/end time and other parameters of checkpoint to performance > statistics. > Add information about throttling if necessary -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14394) Baseline auto-adjustment does not happen when 2+ nodes join the cluster
[
https://issues.apache.org/jira/browse/IGNITE-14394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371647#comment-17371647
]
Alexey Gidaspov commented on IGNITE-14394:
--
Hello [~slava.koptilin],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Baseline auto-adjustment does not happen when 2+ nodes join the cluster
> ---
>
> Key: IGNITE-14394
> URL: https://issues.apache.org/jira/browse/IGNITE-14394
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the case of baseline topology autoadjustment is enabled and a few server
> nodes join the cluster the autoadjustment may not be triggered.
> Steps to reproduce:
> 1. start ignite cluster and enable baseline autoadjustment
> 2. start 2+ server nodes (in order to reproduce the issue, the corresponding
> exchange should be merged)
> 3. wait for baseline autoadjustment
> *RESOLUTION*
> The root cause of the issue relates to merging exchanges. Let's consider the
> following scenario:
> 1. 2 new nodes join the cluster
> 2. the first step triggers a call
> BaselineTopologyUpdater#triggerBaselineUpdate twice and creates the following
> baseline data objects:
> data1 - target topology version - X
> data2 - target topology version - X+1. This data object invalidates the
> previous one (data1)
> 3. in the case the exchanges are merged and the first data (data1)
> binds/listens to real {{GridDhtPartitionsExchangeFuture}} instead of
> affinityReadyFuture, see
> {{GridCachePartitionExchangeManager#affinityReadyFuture}} (data2 listens to
> affinityReadyFuture(X+1)), the implementation schedules data2 in the first
> place, and after that, it replaces data2 with data1 which is already
> invalidated at this point.
> The fix is quite obvious - we should not schedule baseline data instances
> that are related to "invalidated" target topology.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14424) Cache group re-encryption does not start after cluster secondary activation.
[
https://issues.apache.org/jira/browse/IGNITE-14424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371646#comment-17371646
]
Alexey Gidaspov commented on IGNITE-14424:
--
Hello [~xtern],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Cache group re-encryption does not start after cluster secondary activation.
>
>
> Key: IGNITE-14424
> URL: https://issues.apache.org/jira/browse/IGNITE-14424
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Cache group re-encryption does not start after cluster secondary activation.
> Reproducer
> {code:java}
> @Test
> public void testDeactivation() throws Exception {
> pageScanRate = 2;
> checkpointFreq = 10;
> T2 nodes = startTestGrids(true);
> IgniteEx node0 = nodes.get1();
> IgniteEx node1 = nodes.get2();
> createEncryptedCache(node0, node1, cacheName(), null);
> loadData(100_000);
>
> node0.encryption().changeCacheGroupKey(Collections.singleton(cacheName())).get();
>
> assertTrue(isReencryptionInProgress(Collections.singleton(cacheName(;
> node0.cluster().state(ClusterState.INACTIVE);
>
> assertFalse(isReencryptionInProgress(Collections.singleton(cacheName(;
>
> node0.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
>
> node1.context().encryption().setReencryptionRate(DFLT_REENCRYPTION_RATE_MBPS);
> node0.cluster().state(ClusterState.ACTIVE);
> checkGroupKey(CU.cacheId(cacheName()), INITIAL_KEY_ID + 1,
> MAX_AWAIT_MILLIS); // failing here
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14428) Formalize the names of the metrics included in the metric registry.
[ https://issues.apache.org/jira/browse/IGNITE-14428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371644#comment-17371644 ] Alexey Gidaspov commented on IGNITE-14428: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Formalize the names of the metrics included in the metric registry. > > > Key: IGNITE-14428 > URL: https://issues.apache.org/jira/browse/IGNITE-14428 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 3.5h > Remaining Estimate: 0h > > It's needed to refactor metric names to obey the global rule - all of them > must start with name of the registry they belongs to. And add corresponding > assertion. > The purpose of this change is to make all metrics that belongs to one > MetricRegistry have the name that obeys mentioned above rule regardless how > they were registered. It helps to use a consistent approach to work with all > metrics. > The following metric names will be changed to obey this rule: > JoinedNodes -> io.discovery.JoinedNodes > LeftNodes -> io.discovery.LeftNodes > FailedNodes -> io.discovery.FailedNodes > PendingMessagesRegistered -> io.discovery.PendingMessagesRegistered > CommunicationErrors -> io.discovery.CommunicationErrors > CurrentTopologyVersion -> io.discovery.CurrentTopologyVersion -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14461) Track down those who initiated a query
[
https://issues.apache.org/jira/browse/IGNITE-14461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371642#comment-17371642
]
Alexey Gidaspov commented on IGNITE-14461:
--
Hello [~tledkov-gridgain],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Track down those who initiated a query
> --
>
> Key: IGNITE-14461
> URL: https://issues.apache.org/jira/browse/IGNITE-14461
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We need to know and track who initiated a query. It could be useful for an IT
> guy to be able to find an application and ask the developers to change the
> code. It could be as part of {{LOCAL_SQL_RUNNING_QUERIES}} system view or may
> be better to have separate view which could be joined with running queries
> view.
> For first glance it should be :
> # ip, port, host name, user for thin clients.
> # for thick client - nodeId, clientId, ip, host name,
> # task name for compute
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14448) Failure to connect to node leads to hanging connection future if paired connections are used
[
https://issues.apache.org/jira/browse/IGNITE-14448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371643#comment-17371643
]
Alexey Gidaspov commented on IGNITE-14448:
--
Hello [~sdanilov],
I see 'Release Notes Required' flag is set and no release note attached. Please
add release note or remove the flag. Thank you.
> Failure to connect to node leads to hanging connection future if paired
> connections are used
>
>
> Key: IGNITE-14448
> URL: https://issues.apache.org/jira/browse/IGNITE-14448
> Project: Ignite
> Issue Type: Bug
> Components: networking
>Affects Versions: 2.10
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> if ((CommunicationSpi)spi instanceof TcpCommunicationSpi)
> getTcpCommunicationSpi().setConnectionRequestor(invConnHandler);
>if (connRequestor != null) {
> ...
>if (isPairedConnection(node, tcpCommSpi))
>throw new IgniteSpiException("Inverse connection protocol
> doesn't support paired connections");{code}
> Turns out this exception is not handled property and connection future is
> never done. Then, striped pool threads wait forever on reserveClient() and
> cluster grinds to halt.This happens in versions which have
> communication-via-discovery and when usePairedConnections=true.
> {code:java}
> [12:06:18,110][SEVERE][sys-stripe-0-#1][TcpCommunicationSpi] Failed to send
> message to remote node [node=TcpDiscoveryNode
> [id=54ddcf8b-3e41-4efe-bb9d-8a0369e7b893, consistentId=54ddcf8b-3e4
> 1-4efe-bb9d-8a0369e7b893, addrs=ArrayList [127.0.0.1, 172.22.229.21],
> sockAddrs=HashSet [/127.0.0.1:0,
> ip-172-22-229-21.ec2.internal/172.22.229.21:0], discPort=0, order=47,
> intOrder=47, lastExchangeTime=1603983940522, loc=false,
> ver=8.7.25#20200910-sha1:b580d9fd, isClient=true], msg=GridIoMessage [plc=2,
> topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0, skipOnTimeout=f
> alse, msg=GridDhtAtomicSingleUpdateRequest [key=KeyCacheObjectImpl [part=24,
> val=23576, hasValBytes=true], val=com.dream11.ignite.model.GetRoundSummaryRes
> [idHash=69226443, hash=580815760,roundId=23576, dataSource=MYSQL,
> sparkJobStatus=COMPLETED], prevVal=null,
> super=GridDhtAtomicAbstractUpdateRequest [onRes=false, nearNodeId=null,
> nearFutId=0, flags=near]], connIdx=-1]]
> class org.apache.ignite.spi.IgniteSpiException: Inverse connection protocol
> doesn't support paired connections
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$TcpCommunicationInverseConnectionHandler.request(GridIoManager.java:3564)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.handleUnreachableNodeException(ConnectionClientPool.java:365)
> at
> org.apache.ignite.spi.communication.tcp.internal.ConnectionClientPool.reserveClient(ConnectionClientPool.java:256)
>
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1132)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1083)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1814)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1930)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1257)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:1296)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.sendDhtRequests(GridDhtAtomicAbstractUpdateFuture
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14471) JDBCv2: query cursors leak when node to execute queries is specified
[ https://issues.apache.org/jira/browse/IGNITE-14471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371641#comment-17371641 ] Alexey Gidaspov commented on IGNITE-14471: -- Hello [~tledkov-gridgain], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > JDBCv2: query cursors leak when node to execute queries is specified > > > Key: IGNITE-14471 > URL: https://issues.apache.org/jira/browse/IGNITE-14471 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 40m > Remaining Estimate: 0h > > Query cursors leak when node to execute queries is specified. > In this case the query tasks are executed on the remote node instead of > client node launched by the JDBC v2 client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14569) Create data structures system view
[ https://issues.apache.org/jira/browse/IGNITE-14569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371640#comment-17371640 ] Alexey Gidaspov commented on IGNITE-14569: -- Hello [~Korol], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Create data structures system view > -- > > Key: IGNITE-14569 > URL: https://issues.apache.org/jira/browse/IGNITE-14569 > Project: Ignite > Issue Type: Improvement > Components: data structures >Affects Versions: 2.10 >Reporter: Ilya Kazakov >Assignee: Ilya Korol >Priority: Minor > Labels: newbie > Fix For: 2.11 > > > It will be good to have an api to list all created data structures: latches, > atomics and so on. So it could be a system view. > There is system views for caches, for nodes, for continuous queries: > [https://ignite.apache.org/docs/latest/monitoring-metrics/system-views]. > It needs a system views for data structures. In general, each data structure > system view must have the same fields as the method arguments that creates > the data structure. > For example system view for *latches* should have such fields: > name - name of the latch > initialCnt - count when latch was created (if this data is available) > cnt - current latch count > autoDel - does the latch automatically delete when its count reaches zero. > *Queue system view:* > name - name of the queue > capacity - capacity of the queue > size - current size of the queue > > *Set system view:* > name - name of the set > size - current size of the set > > *Atomics system view:* > name - name of the atomic > initVal - initial value of the atomic > currentVal - current value of the atomic > type - SEQUENCE | LONG | REFERENCE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14572) Include metastorage into snapshot
[ https://issues.apache.org/jira/browse/IGNITE-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371639#comment-17371639 ] Alexey Gidaspov commented on IGNITE-14572: -- Hello [~mmuzaf], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Include metastorage into snapshot > - > > Key: IGNITE-14572 > URL: https://issues.apache.org/jira/browse/IGNITE-14572 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.11 > > Time Spent: 10h 40m > Remaining Estimate: 0h > > Currently, only cache and cache groups with CacheType.USER included into a > snapshot. We must also include into snapshot the metastorage data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14658) [IEP-35] SSL metrics
[ https://issues.apache.org/jira/browse/IGNITE-14658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371637#comment-17371637 ] Alexey Gidaspov commented on IGNITE-14658: -- Hello [~PetrovMikhail], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > [IEP-35] SSL metrics > > > Key: IGNITE-14658 > URL: https://issues.apache.org/jira/browse/IGNITE-14658 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Mikhail Petrov >Priority: Major > Labels: IEP-35 > Fix For: 2.11 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > The following SSL metrics required: > * Count of SSL sessions. > * Count of rejected SSL sessions. > * Handshake time metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14575) Write to Distributed Metastorage should throw exception on client if client is not connected to topology
[ https://issues.apache.org/jira/browse/IGNITE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371638#comment-17371638 ] Alexey Gidaspov commented on IGNITE-14575: -- Hello [~sdanilov], I see 'Release Notes Required' flag is set and no release note attached. Please add release note or remove the flag. Thank you. > Write to Distributed Metastorage should throw exception on client if client > is not connected to topology > > > Key: IGNITE-14575 > URL: https://issues.apache.org/jira/browse/IGNITE-14575 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.11 > > Time Spent: 1h > Remaining Estimate: 0h > > Reference to Distributed Metastorage can be obtained on client that hasn't > connected to any server node yet. > The reference allows to send write request that will be completed after > client connect when Tcp Discovery is used and dropped on ZK Discovery. > To make API more reliable we need to change this behavior: when client is not > connected to any server (because there are no servers in topology yet or > because it has disconnected from topology) all incoming write or cas requests > should be dropped, appropriate exception should be thrown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
