[jira] [Updated] (IGNITE-16832) Expose the number of lost partitions as a metric
[ https://issues.apache.org/jira/browse/IGNITE-16832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-16832: Summary: Expose the number of lost partitions as a metric (was: Expose the number of lost partitions as a metricc) > Expose the number of lost partitions as a metric > > > Key: IGNITE-16832 > URL: https://issues.apache.org/jira/browse/IGNITE-16832 > Project: Ignite > Issue Type: Bug >Reporter: Stanislav Lukyanov >Priority: Major > > It would be useful to have a number of lost partitions of a cache as a > metric. That way monitoring tools can be set up to fire an alert when there > are lost partitions. > For the record, there is a metric MinimumNumberOfPartitionCopies which kinda > helps with that but 1) no one will ever look for it to monitor lost > partitions 2) number of lost partition would be useful (and this metric only > shows the fact that there are some lost partitions) 3) this metric doesn't > seem to work on inactive cluster, topology changes, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16832) Expose the number of lost partitions as a metricc
Stanislav Lukyanov created IGNITE-16832: --- Summary: Expose the number of lost partitions as a metricc Key: IGNITE-16832 URL: https://issues.apache.org/jira/browse/IGNITE-16832 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov It would be useful to have a number of lost partitions of a cache as a metric. That way monitoring tools can be set up to fire an alert when there are lost partitions. For the record, there is a metric MinimumNumberOfPartitionCopies which kinda helps with that but 1) no one will ever look for it to monitor lost partitions 2) number of lost partition would be useful (and this metric only shows the fact that there are some lost partitions) 3) this metric doesn't seem to work on inactive cluster, topology changes, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16755) C++ Thin: Add user threadpool size option to public configuration
[ https://issues.apache.org/jira/browse/IGNITE-16755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-16755: Assignee: Pavel Tupitsyn (was: Igor Sapego) Ready for review. [~ptupitsyn] please take a look. > C++ Thin: Add user threadpool size option to public configuration > - > > Key: IGNITE-16755 > URL: https://issues.apache.org/jira/browse/IGNITE-16755 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > There are some cases when application creates many instances of C++ thin > client. Therefore each client instance spawns many threads (equals number of > cores). I propose add configuration to > ignite::thin::IgniteClientConfiguration which will override default > threadpool size when provided. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16831) Update versions of maven plugins which are used for build (pom.xml)
Maxim Muzafarov created IGNITE-16831: Summary: Update versions of maven plugins which are used for build (pom.xml) Key: IGNITE-16831 URL: https://issues.apache.org/jira/browse/IGNITE-16831 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Currently, the most of the maven plugins which are used in pom.xml project files are outdated and required to be updated. Some of the plugins required to be declared in the pluginManagement sections to avoid versions duplication. Due to some of plugins are inherited from the org.apache:apache:23 parent pom artifact you should also consider updating it to the latest version. The list of maven plugins: - maven-surefire-plugin - build-helper-maven-plugin - maven-resources-plugin etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16804) Add ability to collect metrics from ducktests
[
https://issues.apache.org/jira/browse/IGNITE-16804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-16804:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add ability to collect metrics from ducktests
> -
>
> Key: IGNITE-16804
> URL: https://issues.apache.org/jira/browse/IGNITE-16804
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add ability to run ducktests with the metrics export enabled.
> It should be possible to export metrics both via the JMX remote and in the
> prometheus format via the HTTP.
> It should be possible both for local run in docker and for runs in real
> environments.
> It should be possible to separate metrics obtained for each individual test.
> Metrics export configuration should be defined via the _globals_ parameters
> like
> {code:json}
> {
> "jmx_remote": {
> "enabled":true,
> "port":1098
> },
> "metrics": {
> "opencensus": {
> "enabled":true,
> "port": 8082
> },
> "jmx": {
> "enabled":true
> }
> }
> }{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16804) Add ability to collect metrics from ducktests
[
https://issues.apache.org/jira/browse/IGNITE-16804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-16804:
-
Fix Version/s: 2.14
> Add ability to collect metrics from ducktests
> -
>
> Key: IGNITE-16804
> URL: https://issues.apache.org/jira/browse/IGNITE-16804
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Korotkov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add ability to run ducktests with the metrics export enabled.
> It should be possible to export metrics both via the JMX remote and in the
> prometheus format via the HTTP.
> It should be possible both for local run in docker and for runs in real
> environments.
> It should be possible to separate metrics obtained for each individual test.
> Metrics export configuration should be defined via the _globals_ parameters
> like
> {code:json}
> {
> "jmx_remote": {
> "enabled":true,
> "port":1098
> },
> "metrics": {
> "opencensus": {
> "enabled":true,
> "port": 8082
> },
> "jmx": {
> "enabled":true
> }
> }
> }{code}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16550) Redesign SchemaRegistry to use causality tokens
[
https://issues.apache.org/jira/browse/IGNITE-16550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-16550:
-
Assignee: Denis Chudov (was: Vladislav Pyatkov)
> Redesign SchemaRegistry to use causality tokens
> ---
>
> Key: IGNITE-16550
> URL: https://issues.apache.org/jira/browse/IGNITE-16550
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> SchemaRegistry designed before the causality logic aspired(IGNITE-16391), by
> the reason all method do not apply a token and work synchronously.
> After the redesign part of the methods should be removed
> (SchemaRegistry#lastSchemaVersion, SchemaRegistry#waitLatestSchema), others
> should entirely depend on causality.
> Possibly the new methods will return futures.
> UPD:
> It was decided that in the current ticket it's worth to decouple Schema logic
> from the {{TableManager}} and create a new manager called {{SchemaManager}},
> so we can integrate causality tokens logic to the {{SchemaManager}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16741) DoS attacks on ignite ports
[
https://issues.apache.org/jira/browse/IGNITE-16741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-16741:
Assignee: Aleksandr Polovtcev
> DoS attacks on ignite ports
> ---
>
> Key: IGNITE-16741
> URL: https://issues.apache.org/jira/browse/IGNITE-16741
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11.1
>Reporter: biandeqiang
>Assignee: Aleksandr Polovtcev
>Priority: Critical
> Labels: ise
>
> DoS attacks on ignite's TcpCommunicationSpi and TcpDiscoverySpi's ports
> The ignite I use is embedded,ignite uses two ports, When I was testing a dos
> attack on the port, ignite had java.lang.OutOfMemoryError: Direct buffer
> memory.
> TcpDiscoverySpi spi = new TcpDiscoverySpi();
> spi.setLocalPort("port")
> TcpCommunicationSpi ipCom = new TcpCommunicationSpi();
> ipCom.setLocalPort("port")
>
> {{[2021-12-01 14:12:59,056][WARN
> ][0][0][grid-nio-worker-tcp-comm-4-#43%TcpCommunicationSpi%][ROOT][IgniteLoggerImp][88]
> Caught unhandled exception in NIO worker thread (restart the node).
> java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:695)
> at java.nio.DirectByteBuffer.(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.register(GridNioServer.java:2672)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2089)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1910)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)}}
>
> I hope Ignite can also add MaxConnect as Tomcat and set a counter. If the
> counter exceeds the value, wait for several seconds.{{{}{}}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16775) Configure GitHub Actions for continuous deployment the Ignite master branch
[
https://issues.apache.org/jira/browse/IGNITE-16775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520614#comment-17520614
]
Maxim Muzafarov commented on IGNITE-16775:
--
Merged to the master branch.
Deploy job:
https://github.com/apache/ignite/runs/5973796621
> Configure GitHub Actions for continuous deployment the Ignite master branch
> ---
>
> Key: IGNITE-16775
> URL: https://issues.apache.org/jira/browse/IGNITE-16775
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Ignite maven snaphost artifacts must be available at the Maven Central
> Snapshot repository for plugins development and continuous integration.
> Examples:
> Calcite - https://github.com/apache/calcite/pull/2641/files
> Axis -
> https://github.com/apache/axis-axis2-java-core/blob/master/.github/workflows/ci.yml
> [1] {{Publishing packages to Maven Central Repository}} -
> https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16103) Failed to create index for table "table" with some options
[ https://issues.apache.org/jira/browse/IGNITE-16103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520604#comment-17520604 ] Luchnikov Alexander commented on IGNITE-16103: -- [~timonin.maksim] review these changes, please. > Failed to create index for table "table" with some options > -- > > Key: IGNITE-16103 > URL: https://issues.apache.org/jira/browse/IGNITE-16103 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Timonin >Assignee: Luchnikov Alexander >Priority: Minor > Labels: good-first-issue, newbie > Time Spent: 50m > Remaining Estimate: 0h > > 1. How to reproduce - all options CACHE_NAME, VALUE_TYPE, INLINE_SIZE should > be in the queries to reproduce failure: > ``` > create table table(id int PRIMARY KEY, fld1 int, fld2 int) with > "CACHE_NAME=TEST_CACHE_NAME,VALUE_TYPE=TEST_VALUE_TYPE"; > create index idx_0 on table(fld1, fld2) INLINE_SIZE 0; > ``` > Creation of index fails with exception: > Syntax error in SQL statement "CREATE INDEX IDX_0 ON TABLE(FLD1, FLD2) > INLINE_SIZE[*] 0 "; SQL statement: > create index IDX_0 on table(fld1, fld2) INLINE_SIZE 0 [42000-197] > at > > 2. How to fix: need to debug why parameters matters, looks like appearance of > this options triggers some checks that doesn't run while no options > specified. Then this checks should be triggers independently on specified > options or should be removed (depends on). > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16103) Failed to create index for table "table" with some options
[
https://issues.apache.org/jira/browse/IGNITE-16103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520602#comment-17520602
]
Ignite TC Bot commented on IGNITE-16103:
{panel:title=Branch: [pull/9952/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests 0 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6387757]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6387756]]
{color:#d04437}[Missing Tests]{color} [[tests 0 Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6387739]]
{panel}
{panel:title=Branch: [pull/9952/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6387791buildTypeId=IgniteTests24Java8_RunAll]
> Failed to create index for table "table" with some options
> --
>
> Key: IGNITE-16103
> URL: https://issues.apache.org/jira/browse/IGNITE-16103
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Timonin
>Assignee: Luchnikov Alexander
>Priority: Minor
> Labels: good-first-issue, newbie
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 1. How to reproduce - all options CACHE_NAME, VALUE_TYPE, INLINE_SIZE should
> be in the queries to reproduce failure:
> ```
> create table table(id int PRIMARY KEY, fld1 int, fld2 int) with
> "CACHE_NAME=TEST_CACHE_NAME,VALUE_TYPE=TEST_VALUE_TYPE";
> create index idx_0 on table(fld1, fld2) INLINE_SIZE 0;
> ```
> Creation of index fails with exception:
> Syntax error in SQL statement "CREATE INDEX IDX_0 ON TABLE(FLD1, FLD2)
> INLINE_SIZE[*] 0 "; SQL statement:
> create index IDX_0 on table(fld1, fld2) INLINE_SIZE 0 [42000-197]
> at
>
> 2. How to fix: need to debug why parameters matters, looks like appearance of
> this options triggers some checks that doesn't run while no options
> specified. Then this checks should be triggers independently on specified
> options or should be removed (depends on).
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-16362: -- Labels: ignite-3 (was: ignite-3 test) > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Epic >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16775) Configure GitHub Actions for continuous deployment the Ignite master branch
[
https://issues.apache.org/jira/browse/IGNITE-16775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-16775:
-
Description:
The Ignite maven snaphost artifacts must be available at the Maven Central
Snapshot repository for plugins development and continuous integration.
Examples:
Calcite - https://github.com/apache/calcite/pull/2641/files
Axis -
https://github.com/apache/axis-axis2-java-core/blob/master/.github/workflows/ci.yml
[1] {{Publishing packages to Maven Central Repository}} -
https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven
was:
The Ignite maven snaphost artifacts must be available at the Maven Central
Snapshot repository for plugins development and continuous integration.
[1] {{Publishing packages to Maven Central Repository}} -
https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven
> Configure GitHub Actions for continuous deployment the Ignite master branch
> ---
>
> Key: IGNITE-16775
> URL: https://issues.apache.org/jira/browse/IGNITE-16775
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Ignite maven snaphost artifacts must be available at the Maven Central
> Snapshot repository for plugins development and continuous integration.
> Examples:
> Calcite - https://github.com/apache/calcite/pull/2641/files
> Axis -
> https://github.com/apache/axis-axis2-java-core/blob/master/.github/workflows/ci.yml
> [1] {{Publishing packages to Maven Central Repository}} -
> https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16805:
--
Description:
Cache Restarts 1 suite hangs on TeamCity due to
GridCachePartitionedOptimisticTxNodeRestartTest test.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
{noformat}
Thread
[name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
id=383240, state=WAITING, blockCnt=20, waitCnt=42]
Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
at java.base@11.0.8/java.lang.Object.wait(Native Method)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
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
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
"test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
#383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
nid=0x6474 waiting on condition [0x7f68edcc2000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
- parking to wait for <0x87987d88> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
at
java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
at
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.8/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.8/NativeMethodAccessorImpl.java:62)
at
[jira] [Updated] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16805:
--
Description:
Cache Restarts 1 suite hangs on TeamCity due to
GridCachePartitionedOptimisticTxNodeRestartTest test.
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
{noformat}
Thread
[name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
id=383240, state=WAITING, blockCnt=20, waitCnt=42]
Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
at java.base@11.0.8/java.lang.Object.wait(Native Method)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
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
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
"test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
#383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
nid=0x6474 waiting on condition [0x7f68edcc2000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
- parking to wait for <0x87987d88> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
at
java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
at
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.8/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.8/NativeMethodAccessorImpl.java:62)
at
[jira] [Commented] (IGNITE-16542) Ignite h2 security vulnerabilities
[ https://issues.apache.org/jira/browse/IGNITE-16542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520563#comment-17520563 ] Lokesh Bandaru commented on IGNITE-16542: - Hi, is this still being looked at? Looks like the version 2.1.212 of h2 no longer supports Apache Ignite. Is there a direction/advise to share on how these can be addressed? > Ignite h2 security vulnerabilities > -- > > Key: IGNITE-16542 > URL: https://issues.apache.org/jira/browse/IGNITE-16542 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Pratiksha P >Priority: Major > > I face below vulnaribilities while using ignite 2.12.0 or 2.11.0 version > # CVE-2018-10054 > # CVE-2018-14335 > # CVE-2022-23221 > # CVE-2021-42392 > # CVE-2021-23463 > Is there is any solution available for above issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16732) Add configurable Ignite logo and Ignite metrics log messages
[
https://issues.apache.org/jira/browse/IGNITE-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520556#comment-17520556
]
Maxim Muzafarov commented on IGNITE-16732:
--
Cherry-picked to 2.13
> Add configurable Ignite logo and Ignite metrics log messages
>
>
> Key: IGNITE-16732
> URL: https://issues.apache.org/jira/browse/IGNITE-16732
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For some of the deployments it may be necessary do customize the output
> Ignite messages. For instance,
> {code}
> >>> ++
> >>> Ignite ver.
> >>> 2.13.0-SNAPSHOT#20220321-sha1:86e91596680009b498991421d161229b178896c6
> >>> ++
> >>> OS name: Mac OS X 10.16 x86_64
> >>> CPU(s): 12
> >>> Heap: 6.0GB
> >>> VM name: 94661@CAB-WSM-0004852
> >>> Ignite instance name: snapshot.IgniteClusterSnapshotSelfTest0
> >>> Local node [ID=FCCB81D4-1A83-4771-926A-B5A01AF0, order=1,
> >>> clientMode=false]
> >>> Local node addresses: [127.0.0.1]
> >>> Local ports: TCP:10800 TCP:47100 TCP:47500
> {code}
> This message may be extended with plugins of some custom environment specific
> variables.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16732) Add configurable Ignite logo and Ignite metrics log messages
[
https://issues.apache.org/jira/browse/IGNITE-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-16732:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add configurable Ignite logo and Ignite metrics log messages
>
>
> Key: IGNITE-16732
> URL: https://issues.apache.org/jira/browse/IGNITE-16732
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For some of the deployments it may be necessary do customize the output
> Ignite messages. For instance,
> {code}
> >>> ++
> >>> Ignite ver.
> >>> 2.13.0-SNAPSHOT#20220321-sha1:86e91596680009b498991421d161229b178896c6
> >>> ++
> >>> OS name: Mac OS X 10.16 x86_64
> >>> CPU(s): 12
> >>> Heap: 6.0GB
> >>> VM name: 94661@CAB-WSM-0004852
> >>> Ignite instance name: snapshot.IgniteClusterSnapshotSelfTest0
> >>> Local node [ID=FCCB81D4-1A83-4771-926A-B5A01AF0, order=1,
> >>> clientMode=false]
> >>> Local node addresses: [127.0.0.1]
> >>> Local ports: TCP:10800 TCP:47100 TCP:47500
> {code}
> This message may be extended with plugins of some custom environment specific
> variables.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-16805:
-
Assignee: (was: Pavel Pereslegin)
> Cache Restarts 1 suite hangs
>
>
> Key: IGNITE-16805
> URL: https://issues.apache.org/jira/browse/IGNITE-16805
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Minor
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Cache Restarts 1 suite hangs on TeamCity due to
> GridCachePartitionedOptimisticTxNodeRestartTest test.
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
> {noformat}
> Thread
> [name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
> id=383240, state=WAITING, blockCnt=20, waitCnt=42]
> Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
> at java.base@11.0.8/java.lang.Object.wait(Native Method)
> at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
> at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
> at
> o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
> at
> o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
> at
> o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
> at
> java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
> 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
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
> at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
>
> "test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
> #383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
> nid=0x6474 waiting on condition [0x7f68edcc2000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
> - parking to wait for <0x87987d88> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
> at
> java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
> at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
> at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
> at
>
[jira] [Commented] (IGNITE-16792) Configuration for Default Storage Engine
[ https://issues.apache.org/jira/browse/IGNITE-16792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520506#comment-17520506 ] Ivan Bessonov commented on IGNITE-16792: [~ktkale...@gridgain.com] looks good to me, I'll merge it to main. Thank you! > Configuration for Default Storage Engine > > > Key: IGNITE-16792 > URL: https://issues.apache.org/jira/browse/IGNITE-16792 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 3.5h > Remaining Estimate: 0h > > Pluggable storage concept enables user to set up different storage engines > (SE) on the same node e.g. for performance reasons, each table can be hosted > only by one storage. > From DDL point of view SE is specified as part of CREATE TABLE command. But > in case of only one SE and some other cases specifying it for each table > creates a lot of unnecessary boilerplate code. > To address this and free user from writing exactly the same code a > cluster-wide setting *defaultStorageEngine* should be introduced. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15000) putAllConflict removeAllConfict support in thin client
[
https://issues.apache.org/jira/browse/IGNITE-15000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15000:
-
Fix Version/s: 2.14
(was: 2.13)
> putAllConflict removeAllConfict support in thin client
> --
>
> Key: IGNITE-15000
> URL: https://issues.apache.org/jira/browse/IGNITE-15000
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: IEP-59
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{IgniteInternalCache}} contains methods {{putAllConfict}},
> {{removeAllConfict}} that can be used to perform put, remove operations with
> entry {{GridCacheVersion}}.
> To implement multi-cluster replication using thin clients we need to add
> these methods to the thin client protocol.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-12652) Add example of failure handling
[ https://issues.apache.org/jira/browse/IGNITE-12652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luchnikov Alexander reassigned IGNITE-12652: Assignee: Luchnikov Alexander > Add example of failure handling > --- > > Key: IGNITE-12652 > URL: https://issues.apache.org/jira/browse/IGNITE-12652 > Project: Ignite > Issue Type: Task > Components: examples >Reporter: Anton Kalashnikov >Assignee: Luchnikov Alexander >Priority: Major > Labels: newbie > > Ignite has the following feature - > https://apacheignite.readme.io/docs/critical-failures-handling, but there is > not an example of how to use it correctly. So it is good to add some examples. > Also, Ignite has DiagnosticProcessor which invokes when the failure handler > is triggered. Maybe it is a good idea to add to this example some samples of > diagnostic work. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16797) DDL support for Storage specific parameters
[ https://issues.apache.org/jira/browse/IGNITE-16797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16797: - Fix Version/s: 3.0.0-alpha5 > DDL support for Storage specific parameters > --- > > Key: IGNITE-16797 > URL: https://issues.apache.org/jira/browse/IGNITE-16797 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Different Storage Engines (SE) may have different sets of configuration > parameters. These parameters are supported on configuration level but should > be integrated with DDL as well. > DDL scripts should be able to transfer SE parameters from CREATE TABLE > command to configuration and properly handle any validation or other > exceptions generated by configuration module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16763) TableManager doesn't throw exception on table create, if something goes wrong in configuration listener for updateAssignments
[ https://issues.apache.org/jira/browse/IGNITE-16763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520350#comment-17520350 ] Sergey Uttsel commented on IGNITE-16763: The test ItIgniteNodeRestartTest#nodeWithDataTest in https://github.com/gridgain/apache-ignite-3/tree/ignite-16763 reproduces the issue. On create table if TableManager#onUpdateAssignments throws an exception, then tblFut.completeExceptionally(ex) is invoked in TableManager#createTableAsyncInternal. But at this time tblFut is completed so a completeExceptionally does not affect anything. > TableManager doesn't throw exception on table create, if something goes wrong > in configuration listener for updateAssignments > - > > Key: IGNITE-16763 > URL: https://issues.apache.org/jira/browse/IGNITE-16763 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Scenario: > Start a node, try to create a table. Inside of TableManager the listener > onTableCreate is successfully executed. Then, an exception happens inside of > TableManager#onUpdateAssignments > configuration listener, which is triggered after the completion of > onTableCreate listener. To reproduce the issue need to add an exception > throwing in TableManager#onUpdateAssignments and create a table. > Expected behavior: > There is no operational instance of the newly created table on the node that > initiated creation of the table, because onUpdateAssignments had failed. > "Create table" operation should fail with exception. > Actual: > "Create table" operation succeeds, as onTableCreate listener in TableManager > had succeeded. > Suggested fix: > onUpdateAssignments should save exception to versioned values in > TableManager, as it updates these versioned values. Thus, the following > VersionedValue#get will throw an exception, and table creation future will be > completed exceptionally (see TableManager#completeApiCreateFuture ). However, > we should think about how further updates of these versioned values will > happen. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16776) Thin 3.0: Potential resource leak on disconnect
[ https://issues.apache.org/jira/browse/IGNITE-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520330#comment-17520330 ] Pavel Tupitsyn commented on IGNITE-16776: - Merged to main: 3c7fa582df2311e95c7e297a0582af9e71030dae > Thin 3.0: Potential resource leak on disconnect > --- > > Key: IGNITE-16776 > URL: https://issues.apache.org/jira/browse/IGNITE-16776 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-alpha5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 20m > Remaining Estimate: 0h > > *ClientResourceRegistry#clean* is called on connection loss. However, some > request handlers may be still active and call *put* after or during *clean*, > causing a resource leak. We should use an rw lock to handle this. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16776) Thin 3.0: Potential resource leak on disconnect
[ https://issues.apache.org/jira/browse/IGNITE-16776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520318#comment-17520318 ] Igor Sapego commented on IGNITE-16776: -- [~ptupitsyn] looks good to me. Ship it > Thin 3.0: Potential resource leak on disconnect > --- > > Key: IGNITE-16776 > URL: https://issues.apache.org/jira/browse/IGNITE-16776 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-alpha5 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > *ClientResourceRegistry#clean* is called on connection loss. However, some > request handlers may be still active and call *put* after or during *clean*, > causing a resource leak. We should use an rw lock to handle this. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-14972) Thin 3.0: Implement SQL API for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-14972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-14972: --- Assignee: Pavel Tupitsyn > Thin 3.0: Implement SQL API for java thin client > > > Key: IGNITE-14972 > URL: https://issues.apache.org/jira/browse/IGNITE-14972 > Project: Ignite > Issue Type: New Feature > Components: sql, thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > > We need to implement basic SQL API for java thin client in 3.0. Maybe this > task should involve creating an IEP and discussion on the dev list. > Also, keep in mind that protocol messages themselves should re-use as much as > possible JDBC protocol. -- This message was sent by Atlassian Jira (v8.20.1#820001)
