[jira] [Created] (IGNITE-15155) Utils IgniteWalConverter add ability to skip reading errors
Alexand Polyakov created IGNITE-15155: - Summary: Utils IgniteWalConverter add ability to skip reading errors Key: IGNITE-15155 URL: https://issues.apache.org/jira/browse/IGNITE-15155 Project: Ignite Issue Type: Improvement Components: extensions Affects Versions: 2.10 Reporter: Alexand Polyakov Assignee: Alexand Polyakov When reading WAL in IgniteWalConverter with error, it is useful not to stop at the first error, but to output all the data that can be read -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-315) Avast detects Ignite.Utils class as Agent-CWF trojan
[ https://issues.apache.org/jira/browse/IGNITE-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] กิตติภัทร์ ทองฤทธิ์ updated IGNITE-315: --- Attachment: AAR-37.doc > Avast detects Ignite.Utils class as Agent-CWF trojan > > > Key: IGNITE-315 > URL: https://issues.apache.org/jira/browse/IGNITE-315 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-2 >Reporter: Sergey Kozlov >Assignee: Irina Vasilinets >Priority: Minor > Fix For: sprint-2 > > Attachments: AAR-37.doc > > > Avast detects Ignite.Utils class as Agent-CWF trojan. > It's false positive and we need either send request to Avast or redesign this > class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15102:
-
Fix Version/s: python-0.5.1
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Fix For: python-0.5.1
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpEventListener, ConnectionEventListener,
> TopologyEventListener
> from pyignite import Client
> client = Client(event_listeners=[OpEventListener, ConnectionEventListener,
> TopologyEventListener])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15103) Add logging to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15103:
-
Fix Version/s: python-0.5.1
> Add logging to pyignite client
> --
>
> Key: IGNITE-15103
> URL: https://issues.apache.org/jira/browse/IGNITE-15103
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Fix For: python-0.5.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, there is no logging at all, should be added using {{logging}}
> module
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15118) Add handshake timeout to pyignite client
[
https://issues.apache.org/jira/browse/IGNITE-15118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15118:
-
Fix Version/s: python-0.5.1
> Add handshake timeout to pyignite client
>
>
> Key: IGNITE-15118
> URL: https://issues.apache.org/jira/browse/IGNITE-15118
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Fix For: python-0.5.1
>
>
> Additional handshake timeout should be added to both {{Client}} and
> {{AioClient}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14982) Persistent implementation for metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383630#comment-17383630 ] Semyon Danilov commented on IGNITE-14982: - [~agura] done. Here is a [green visa|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6093933] for the PR > Persistent implementation for metastorage > - > > Key: IGNITE-14982 > URL: https://issues.apache.org/jira/browse/IGNITE-14982 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-74, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 144h > Remaining Estimate: 144h > > KeyValueStorage aka metastorage now has only in-memory implementation. > RocksDB-based persistent implementation should be provided for > persistence-enabled scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14982) Persistent implementation for metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov reassigned IGNITE-14982: --- Assignee: Semyon Danilov > Persistent implementation for metastorage > - > > Key: IGNITE-14982 > URL: https://issues.apache.org/jira/browse/IGNITE-14982 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-74, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 144h > Remaining Estimate: 144h > > KeyValueStorage aka metastorage now has only in-memory implementation. > RocksDB-based persistent implementation should be provided for > persistence-enabled scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15154) Suddenly Integration Tests suite hangs on shutdown RAFT node
[
https://issues.apache.org/jira/browse/IGNITE-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15154:
---
Description:
This is an example of this freezing:
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6087991
{noformat}
[20:15:22]W: [org.apache.ignite:ignite-raft] 2021-07-15
20:15:07:183 +0300 [main] ERROR rejectedExecution - Failed to submit a listener
notification task. Event loop shut down?
[20:15:22]W: [org.apache.ignite:ignite-raft]
java.util.concurrent.RejectedExecutionException: event executor terminated
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.DefaultPromise.safeExecute(DefaultPromise.java:842)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:499)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.DefaultPromise.addListener(DefaultPromise.java:184)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:95)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:30)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyUtils.toCompletableFuture(NettyUtils.java:46)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyUtils.toCompletableFuture(NettyUtils.java:66)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyClient.lambda$stop$1(NettyClient.java:171)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyClient.stop(NettyClient.java:168)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3605)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:550)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
[20:15:22]W: [org.apache.ignite:ignite-raft]
[jira] [Updated] (IGNITE-15154) Suddenly Integration Tests suite hangs on shutdown RAFT node
[
https://issues.apache.org/jira/browse/IGNITE-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15154:
---
Summary: Suddenly Integration Tests suite hangs on shutdown RAFT node
(was: Sometime Integration Tests suite hangs on shutdown RAFT node)
> Suddenly Integration Tests suite hangs on shutdown RAFT node
>
>
> Key: IGNITE-15154
> URL: https://issues.apache.org/jira/browse/IGNITE-15154
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> {noformat}
> [20:15:22]W: [org.apache.ignite:ignite-raft] 2021-07-15
> 20:15:07:183 +0300 [main] ERROR rejectedExecution - Failed to submit a
> listener notification task. Event loop shut down?
> [20:15:22]W: [org.apache.ignite:ignite-raft]
> java.util.concurrent.RejectedExecutionException: event executor terminated
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.DefaultPromise.safeExecute(DefaultPromise.java:842)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:499)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.util.concurrent.DefaultPromise.addListener(DefaultPromise.java:184)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:95)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:30)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> org.apache.ignite.internal.network.netty.NettyUtils.toCompletableFuture(NettyUtils.java:46)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> org.apache.ignite.internal.network.netty.NettyUtils.toCompletableFuture(NettyUtils.java:66)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> org.apache.ignite.internal.network.netty.NettyClient.lambda$stop$1(NettyClient.java:171)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> org.apache.ignite.internal.network.netty.NettyClient.stop(NettyClient.java:168)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3605)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
> [20:15:22]W: [org.apache.ignite:ignite-raft]at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> [20:15:22]W:
[jira] [Created] (IGNITE-15154) Sometime Integration Tests suite hangs on shutdown RAFT node
Vladislav Pyatkov created IGNITE-15154:
--
Summary: Sometime Integration Tests suite hangs on shutdown RAFT
node
Key: IGNITE-15154
URL: https://issues.apache.org/jira/browse/IGNITE-15154
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
Assignee: Vladislav Pyatkov
{noformat}
[20:15:22]W: [org.apache.ignite:ignite-raft] 2021-07-15
20:15:07:183 +0300 [main] ERROR rejectedExecution - Failed to submit a listener
notification task. Event loop shut down?
[20:15:22]W: [org.apache.ignite:ignite-raft]
java.util.concurrent.RejectedExecutionException: event executor terminated
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.DefaultPromise.safeExecute(DefaultPromise.java:842)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:499)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.util.concurrent.DefaultPromise.addListener(DefaultPromise.java:184)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:95)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
io.netty.channel.DefaultChannelPromise.addListener(DefaultChannelPromise.java:30)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyUtils.toCompletableFuture(NettyUtils.java:46)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyUtils.toCompletableFuture(NettyUtils.java:66)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyClient.lambda$stop$1(NettyClient.java:171)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
org.apache.ignite.internal.network.netty.NettyClient.stop(NettyClient.java:168)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.concurrent.ConcurrentHashMap$ValueSpliterator.forEachRemaining(ConcurrentHashMap.java:3605)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(StreamSpliterators.java:312)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Streams.java:734)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:550)
[20:15:22]W: [org.apache.ignite:ignite-raft]at
java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
[20:15:22]W:
[jira] [Updated] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
[
https://issues.apache.org/jira/browse/IGNITE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-15146:
-
Fix Version/s: 2.12
> Checking the snapshot creates a large number of unused threads that do not
> terminate.
> -
>
> Key: IGNITE-15146
> URL: https://issues.apache.org/jira/browse/IGNITE-15146
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Pavel Pereslegin
>Priority: Critical
> Fix For: 2.12
>
>
> Each new run of snapshot verification creates dozens of new threads that do
> not terminate after the procedure is complete. Over time, this can lead to an
> OutOfMemoryError and node failure.
> {code:java}
> @Test
> public void testClusterSnapshotCheckMultipleTimes() throws Exception {
> IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
> CACHE_KEYS_RANGE);
> startClientGrid();
>
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
> .get();
> int activeThreadsCntBefore = Thread.activeCount();
> int iterations = 10;
> for (int i = 0; i < iterations; i++)
> snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
> int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
> assertTrue("Threads created: " + createdThreads, createdThreads <
> iterations);
> }
> {code}
> Reproducer shows that 10 snapshot checks add approx
> *{color:#de350b}~250{color}* new threads.
> The dump of "leaked" thread looks like this:
> {noformat}
> "binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
> nid=0x65b38 waiting on condition [0x7f986cf9c000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15152) Fix javadoc in Api module.
[
https://issues.apache.org/jira/browse/IGNITE-15152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-15152:
-
Assignee: Andrey Mashenkov
> Fix javadoc in Api module.
> --
>
> Key: IGNITE-15152
> URL: https://issues.apache.org/jira/browse/IGNITE-15152
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15102) Implement monitoring of various pyignite's events
[
https://issues.apache.org/jira/browse/IGNITE-15102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383437#comment-17383437
]
Igor Sapego commented on IGNITE-15102:
--
[~ivandasch] looks good, merge it.
> Implement monitoring of various pyignite's events
> -
>
> Key: IGNITE-15102
> URL: https://issues.apache.org/jira/browse/IGNITE-15102
> Project: Ignite
> Issue Type: Improvement
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: python, thin
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I suggest to add monitoring capabilities to {{pyignite}} similar to
> [pymongo's|https://pymongo.readthedocs.io/en/stable/api/pymongo/event_loggers.html#module-pymongo.event_loggers]
> Suggested api:
> {code:python}
> from pyignite.monitoring import OpEventListener, ConnectionEventListener,
> TopologyEventListener
> from pyignite import Client
> client = Client(event_listeners=[OpEventListener, ConnectionEventListener,
> TopologyEventListener])
> with client.connect(...):
> ..
> {code}
> I suggests to add listeners to:
> # *Connection events* connect or disconnect to specific ignite server,
> connection errors
> # *Topology events* when partition awareness is enabled, log new topology
> versions
> # *Operations events* start,success or failure with request_id, server
> (address, port and uuid), operation_id, error string if presents
> This approach can implement custom metrics, tracing and other useful
> client-side stuff in order to make client more observable
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15120) Condition isTombstone() is required
[
https://issues.apache.org/jira/browse/IGNITE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383416#comment-17383416
]
Andrey N. Gura commented on IGNITE-15120:
-
Added new method {{Conditions.tombstone(ByteArray key)}}. Please, review.
> Condition isTombstone() is required
> ---
>
> Key: IGNITE-15120
> URL: https://issues.apache.org/jira/browse/IGNITE-15120
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: iep-61, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently
> {code:java}
> Conditions.notExists(key){code}
> will both return true if there were no such key or if it was removed. New
> condition that will allow to detect whether a key was removed or not created
> is required. It might look like
> {code:java}
> Conditions.isTombstone(key){code}
> or similar.
>
> Seems that it'll be also helpful if
> org.apache.ignite.internal.metastorage.client.Conditions#notExists
> javadoc' will be more specific about tombstone case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15023) ClassNotFoundException when using security and trying to set a remote listener
[ https://issues.apache.org/jira/browse/IGNITE-15023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383410#comment-17383410 ] Sergei Ryzhov commented on IGNITE-15023: WA added to IgniteConfiguration > ClassNotFoundException when using security and trying to set a remote listener > -- > > Key: IGNITE-15023 > URL: https://issues.apache.org/jira/browse/IGNITE-15023 > Project: Ignite > Issue Type: Bug >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > ClassNotFoundException when using security and trying to set a remote listener > the issue in using SecurityAwarePredicate on a client node > it makes a wrapper over the remote listener so the class is not passed > through the Peer Class Loader > Caused by: java.lang.ClassNotFoundException: > examples.StartClientXml$$Lambda$703/253380088 > 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:9064) > at > org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:9002) > at > org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:376) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.descriptorFromCache(OptimizedMarshallerUtils.java:329) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:274) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readClass(OptimizedObjectInputStream.java:384) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:329) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:205) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367) > at > org.apache.ignite.internal.SecurityAwarePredicate.readExternal(SecurityAwarePredicate.java:86) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:560) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:980) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:353) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:205) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:367) > at > org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:251) > ... 22 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15153) Fix javadoc in Schema and Table modules.
Andrey Mashenkov created IGNITE-15153:
-
Summary: Fix javadoc in Schema and Table modules.
Key: IGNITE-15153
URL: https://issues.apache.org/jira/browse/IGNITE-15153
Project: Ignite
Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Ivan Bessonov
Fix For: 3.0.0-alpha3
Let's fix Javadoc styles regarding the policy.
Startpoint is to remove modules from excludes and run
{code:java}
mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15153) Fix javadoc in Schema and Table modules.
[
https://issues.apache.org/jira/browse/IGNITE-15153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-15153:
-
Assignee: Andrey Mashenkov (was: Ivan Bessonov)
> Fix javadoc in Schema and Table modules.
>
>
> Key: IGNITE-15153
> URL: https://issues.apache.org/jira/browse/IGNITE-15153
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15149) Fix javadoc in Configuration module.
[
https://issues.apache.org/jira/browse/IGNITE-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15149:
--
Summary: Fix javadoc in Configuration module. (was: Fix javadoc in Runner
module.)
> Fix javadoc in Configuration module.
>
>
> Key: IGNITE-15149
> URL: https://issues.apache.org/jira/browse/IGNITE-15149
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14563) Fix javadoc in Runner module.
[
https://issues.apache.org/jira/browse/IGNITE-14563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14563:
--
Description:
Let's fix Javadoc styles regarding the policy.
Startpoint is to remove modules from excludes and run
{code:java}
mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
{code}
was:
After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of
javadocs.
Let's fix "warnings" that is related to Runner modules.
Startpoint is to run javadoc goal for the apache-ignite project:
{code:java}
mvn javadoc:javadoc
{code}
> Fix javadoc in Runner module.
> -
>
> Key: IGNITE-14563
> URL: https://issues.apache.org/jira/browse/IGNITE-14563
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15151) Fix javadoc in Examples module.
Andrey Mashenkov created IGNITE-15151:
-
Summary: Fix javadoc in Examples module.
Key: IGNITE-15151
URL: https://issues.apache.org/jira/browse/IGNITE-15151
Project: Ignite
Issue Type: Bug
Reporter: Andrey Mashenkov
Fix For: 3.0.0-alpha3
Let's fix Javadoc styles regarding the policy.
Startpoint is to remove modules from excludes and run
{code:java}
mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15152) Fix javadoc in Api module.
Andrey Mashenkov created IGNITE-15152:
-
Summary: Fix javadoc in Api module.
Key: IGNITE-15152
URL: https://issues.apache.org/jira/browse/IGNITE-15152
Project: Ignite
Issue Type: Bug
Reporter: Andrey Mashenkov
Fix For: 3.0.0-alpha3
Let's fix Javadoc styles regarding the policy.
Startpoint is to remove modules from excludes and run
{code:java}
mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15150) Fix javadoc in Cli module.
[
https://issues.apache.org/jira/browse/IGNITE-15150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-15150:
-
Assignee: (was: Aleksandr Polovtcev)
> Fix javadoc in Cli module.
> --
>
> Key: IGNITE-15150
> URL: https://issues.apache.org/jira/browse/IGNITE-15150
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15149) Fix javadoc in Runner module.
[
https://issues.apache.org/jira/browse/IGNITE-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-15149:
-
Assignee: (was: Aleksandr Polovtcev)
> Fix javadoc in Runner module.
> -
>
> Key: IGNITE-15149
> URL: https://issues.apache.org/jira/browse/IGNITE-15149
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15150) Fix javadoc in Cli module.
Andrey Mashenkov created IGNITE-15150:
-
Summary: Fix javadoc in Cli module.
Key: IGNITE-15150
URL: https://issues.apache.org/jira/browse/IGNITE-15150
Project: Ignite
Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Aleksandr Polovtcev
Fix For: 3.0.0-alpha3
Let's fix Javadoc styles regarding the policy.
Startpoint is to remove modules from excludes and run
{code:java}
mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15149) Fix javadoc in Runner module.
[
https://issues.apache.org/jira/browse/IGNITE-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15149:
--
Summary: Fix javadoc in Runner module. (was: Fix javadoc in Network
module.)
> Fix javadoc in Runner module.
> -
>
> Key: IGNITE-15149
> URL: https://issues.apache.org/jira/browse/IGNITE-15149
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15149) Fix javadoc in Network module.
[
https://issues.apache.org/jira/browse/IGNITE-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-15149:
--
Description:
Let's fix Javadoc styles regarding the policy.
Startpoint is to remove modules from excludes and run
{code:java}
mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
{code}
was:
After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of
javadocs.
Let's fix "warnings" that is related to Network module.
Startpoint is to run javadoc goal for the apache-ignite project:
{code:java}
mvn javadoc:javadoc
{code}
> Fix javadoc in Network module.
> --
>
> Key: IGNITE-15149
> URL: https://issues.apache.org/jira/browse/IGNITE-15149
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15149) Fix javadoc in Network module.
Andrey Mashenkov created IGNITE-15149:
-
Summary: Fix javadoc in Network module.
Key: IGNITE-15149
URL: https://issues.apache.org/jira/browse/IGNITE-15149
Project: Ignite
Issue Type: Bug
Reporter: Andrey Mashenkov
Assignee: Aleksandr Polovtcev
Fix For: 3.0.0-alpha3
After IGNITE-13751 had been merged, Javadoc suite failed on TC due to lack of
javadocs.
Let's fix "warnings" that is related to Network module.
Startpoint is to run javadoc goal for the apache-ignite project:
{code:java}
mvn javadoc:javadoc
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15148) Implement top level node stop logic
Alexander Lapin created IGNITE-15148: Summary: Implement top level node stop logic Key: IGNITE-15148 URL: https://issues.apache.org/jira/browse/IGNITE-15148 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin Assignee: Alexander Lapin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14591:
--
Fix Version/s: 3.0.0-alpha3
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383379#comment-17383379
]
Andrey Mashenkov edited comment on IGNITE-14591 at 7/19/21, 2:33 PM:
-
Unfortunately, it is impossible to have different style policies for different
cod parts.
So, as decided on dev-list, new rules for public API added for now, see:
check-rules/checkstyle-public-api-javadoc.xml
Modules with broken styles are added to the exclude-list and will be fixed
within separate tasks:
check-rules/checkstyle-disabled-modules.xml
was (Author: amashenkov):
Unfortunately, it is impossible to have different style policies for different
cod parts.
So, as decided on dev-list new rules for public API added at first, see:
check-rules/checkstyle-public-api-javadoc.xml
Modules with broken styles are added to the exclude-list and will be fixed
within separate tasks:
check-rules/checkstyle-disabled-modules.xml
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383376#comment-17383376
]
Peter Ivanov commented on IGNITE-14591:
---
TC suite updated and checked.
Changes looks good, please, proceed with merge, thanks!
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15147) Possible leak in metrics in PageLockTracker
Sergey Chugunov created IGNITE-15147:
Summary: Possible leak in metrics in PageLockTracker
Key: IGNITE-15147
URL: https://issues.apache.org/jira/browse/IGNITE-15147
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.10
Reporter: Sergey Chugunov
Fix For: 2.12
In one of PageHandler#readPage methods there is the following code:
{code:java}
long pageAddr = readLock(pageMem, cacheId, pageId, page, lsnr);
if (pageAddr == 0L)
return lockFailed;
try {
PageIO io = pageIoRslvr.resolve(pageAddr);
return h.run(cacheId, pageId, page, pageAddr, io, null, arg, intArg,
statHolder);
}
finally {
readUnlock(pageMem, cacheId, pageId, page, pageAddr, lsnr);
}
{code}
Here we obtain a read lock on a page (this call has a side effect of
incrementing lock's metrics). But if returned pageAddr is zero (lock
acquisition has failed) we return from the method without entering try block.
As a result, readUnlock method is not called, the metrics are not decremented
back.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13136) Calcite integration. Improve join predicate testing.
[
https://issues.apache.org/jira/browse/IGNITE-13136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383363#comment-17383363
]
Aleksey Plekhanov commented on IGNITE-13136:
[~zstan], please see my comments on GitHub.
> Calcite integration. Improve join predicate testing.
>
>
> Key: IGNITE-13136
> URL: https://issues.apache.org/jira/browse/IGNITE-13136
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently we have to merge joining rows in order to test a join predicate:
> {code:java}
> Row row = handler.concat(left, rightMaterialized.get(rightIdx++));
> if (!cond.test(row))
> continue;
> {code}
> it results in unconditional building a joined row even if it will not be
> emitted to downstream further. To avoid extra GC pressure we need to test the
> join predicate before joining rows:
> {code:java}
> if (!cond.test(left, right))
> continue;
> Row row = handler.concat(left, right);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
[
https://issues.apache.org/jira/browse/IGNITE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15146:
--
Description:
Each new run of snapshot verification creates dozens of new threads that do not
terminate after the procedure is complete. Over time, this can lead to an
OutOfMemoryError and node failure.
{code:java}
@Test
public void testClusterSnapshotCheckMultipleTimes() throws Exception {
IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
CACHE_KEYS_RANGE);
startClientGrid();
ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
.get();
int activeThreadsCntBefore = Thread.activeCount();
int iterations = 10;
for (int i = 0; i < iterations; i++)
snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
assertTrue("Threads created: " + createdThreads, createdThreads <
iterations);
}
{code}
Reproducer shows that 10 snapshot checks add approx
*{color:#de350b}~250{color}* new threads.
The dump of "leaked" thread looks like this:
{noformat}
"binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
nid=0x65b38 waiting on condition [0x7f986cf9c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
Each new run of snapshot verification creates dozens of new threads that do not
terminate after the procedure is complete. Over time, this can lead to an
OutOfMemoryError and node failure.
{code:java}
@Test
public void testClusterSnapshotCheckMultipleTimes() throws Exception {
IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
CACHE_KEYS_RANGE);
startClientGrid();
ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
.get();
int activeThreadsCntBefore = Thread.activeCount();
int iterations = 10;
for (int i = 0; i < iterations; i++)
snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
assertTrue("Threads created: " + createdThreads, createdThreads <
iterations);
}
{code}
Reproducer shows that 10 snapshot checks add approx
*{color:#de350b}~250{color}* new threads that do not terminate.
The dump of "leaked" thread looks like this:
{noformat}
"binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
nid=0x65b38 waiting on condition [0x7f986cf9c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> Checking the snapshot creates a large number of unused threads that do not
> terminate.
> -
>
> Key: IGNITE-15146
> URL: https://issues.apache.org/jira/browse/IGNITE-15146
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Pavel Pereslegin
>Priority: Critical
>
> Each new run of snapshot verification creates dozens of new threads that do
> not terminate after the procedure is
[jira] [Updated] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
[
https://issues.apache.org/jira/browse/IGNITE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15146:
--
Description:
Each new run of snapshot verification creates dozens of new threads that do not
terminate after the procedure is complete. Over time, this can lead to an
OutOfMemoryError and node failure.
{code:java}
@Test
public void testClusterSnapshotCheckMultipleTimes() throws Exception {
IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
CACHE_KEYS_RANGE);
startClientGrid();
ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
.get();
int activeThreadsCntBefore = Thread.activeCount();
int iterations = 10;
for (int i = 0; i < iterations; i++)
snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
assertTrue("Threads created: " + createdThreads, createdThreads <
iterations);
}
{code}
Reproducer shows that 10 snapshot checks add approx
*{color:#de350b}~250{color}* new threads that do not terminate.
The dump of "leaked" thread looks like this:
{noformat}
"binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
nid=0x65b38 waiting on condition [0x7f986cf9c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
Each new run of snapshot verification creates dozens of new threads that do not
terminate after the procedure is complete.
{code:java}
@Test
public void testClusterSnapshotCheckMultipleTimes() throws Exception {
IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
CACHE_KEYS_RANGE);
startClientGrid();
ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
.get();
int activeThreadsCntBefore = Thread.activeCount();
int iterations = 10;
for (int i = 0; i < iterations; i++)
snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
assertTrue("Threads created: " + createdThreads, createdThreads <
iterations);
}
{code}
Reproducer shows that 10 snapshot checks add approx
*{color:#DE350B}~250{color}* new threads that do not terminate.
The dump of "leaked" thread looks like this:
{noformat}
"binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
nid=0x65b38 waiting on condition [0x7f986cf9c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> Checking the snapshot creates a large number of unused threads that do not
> terminate.
> -
>
> Key: IGNITE-15146
> URL: https://issues.apache.org/jira/browse/IGNITE-15146
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Pavel Pereslegin
>Priority: Critical
>
> Each new run of snapshot verification creates dozens of new threads that do
> not terminate after the procedure is complete. Over time, this can lead to an
[jira] [Updated] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
[
https://issues.apache.org/jira/browse/IGNITE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15146:
--
Priority: Critical (was: Major)
> Checking the snapshot creates a large number of unused threads that do not
> terminate.
> -
>
> Key: IGNITE-15146
> URL: https://issues.apache.org/jira/browse/IGNITE-15146
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Pavel Pereslegin
>Priority: Critical
>
> Each new run of snapshot verification creates dozens of new threads that do
> not terminate after the procedure is complete.
> {code:java}
> @Test
> public void testClusterSnapshotCheckMultipleTimes() throws Exception {
> IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
> CACHE_KEYS_RANGE);
> startClientGrid();
>
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
> .get();
> int activeThreadsCntBefore = Thread.activeCount();
> int iterations = 10;
> for (int i = 0; i < iterations; i++)
> snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
> int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
> assertTrue("Threads created: " + createdThreads, createdThreads <
> iterations);
> }
> {code}
> Reproducer shows that 10 snapshot checks add approx
> *{color:#DE350B}~250{color}* new threads that do not terminate.
> The dump of "leaked" thread looks like this:
> {noformat}
> "binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
> nid=0x65b38 waiting on condition [0x7f986cf9c000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
[
https://issues.apache.org/jira/browse/IGNITE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15146:
--
Affects Version/s: 2.11
> Checking the snapshot creates a large number of unused threads that do not
> terminate.
> -
>
> Key: IGNITE-15146
> URL: https://issues.apache.org/jira/browse/IGNITE-15146
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Pavel Pereslegin
>Priority: Major
>
> Each new run of snapshot verification creates dozens of new threads that do
> not terminate after the procedure is complete.
> {code:java}
> @Test
> public void testClusterSnapshotCheckMultipleTimes() throws Exception {
> IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
> CACHE_KEYS_RANGE);
> startClientGrid();
>
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
> .get();
> int activeThreadsCntBefore = Thread.activeCount();
> int iterations = 10;
> for (int i = 0; i < iterations; i++)
> snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
> int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
> assertTrue("Threads created: " + createdThreads, createdThreads <
> iterations);
> }
> {code}
> Reproducer shows that 10 snapshot checks add approx
> *{color:#DE350B}~250{color}* new threads that do not terminate.
> The dump of "leaked" thread looks like this:
> {noformat}
> "binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
> nid=0x65b38 waiting on condition [0x7f986cf9c000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
Pavel Pereslegin created IGNITE-15146:
-
Summary: Checking the snapshot creates a large number of unused
threads that do not terminate.
Key: IGNITE-15146
URL: https://issues.apache.org/jira/browse/IGNITE-15146
Project: Ignite
Issue Type: Bug
Reporter: Pavel Pereslegin
Each new run of snapshot verification creates dozens of new threads that do not
terminate after the procedure is complete.
{code:java}
@Test
public void testClusterSnapshotCheckMultipleTimes() throws Exception {
IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
CACHE_KEYS_RANGE);
startClientGrid();
ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
.get();
int activeThreadsCntBefore = Thread.activeCount();
int iterations = 10;
for (int i = 0; i < iterations; i++)
snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
assertTrue("Threads created: " + createdThreads, createdThreads <
iterations);
}
{code}
Reproducer shows that 10 snapshot checks add approx
*{color:#DE350B}~250{color}* new threads that do not terminate.
The dump of "leaked" thread looks like this:
{noformat}
"binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
nid=0x65b38 waiting on condition [0x7f986cf9c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15146) Checking the snapshot creates a large number of unused threads that do not terminate.
[
https://issues.apache.org/jira/browse/IGNITE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15146:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Checking the snapshot creates a large number of unused threads that do not
> terminate.
> -
>
> Key: IGNITE-15146
> URL: https://issues.apache.org/jira/browse/IGNITE-15146
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Priority: Major
>
> Each new run of snapshot verification creates dozens of new threads that do
> not terminate after the procedure is complete.
> {code:java}
> @Test
> public void testClusterSnapshotCheckMultipleTimes() throws Exception {
> IgniteEx ignite = startGridsWithCache(3, dfltCacheCfg,
> CACHE_KEYS_RANGE);
> startClientGrid();
>
> ignite.snapshot().createSnapshot(SNAPSHOT_NAME)
> .get();
> int activeThreadsCntBefore = Thread.activeCount();
> int iterations = 10;
> for (int i = 0; i < iterations; i++)
> snp(ignite).checkSnapshot(SNAPSHOT_NAME).get();
> int createdThreads = Thread.activeCount() - activeThreadsCntBefore;
> assertTrue("Threads created: " + createdThreads, createdThreads <
> iterations);
> }
> {code}
> Reproducer shows that 10 snapshot checks add approx
> *{color:#DE350B}~250{color}* new threads that do not terminate.
> The dump of "leaked" thread looks like this:
> {noformat}
> "binary-metadata-writer-#2208" #2249 prio=5 os_prio=0 tid=0x7f9974087000
> nid=0x65b38 waiting on condition [0x7f986cf9c000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:460)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:441)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15120) Condition isTombstone() is required
[
https://issues.apache.org/jira/browse/IGNITE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-15120:
Labels: iep-61 ignite-3 (was: ignite-3)
> Condition isTombstone() is required
> ---
>
> Key: IGNITE-15120
> URL: https://issues.apache.org/jira/browse/IGNITE-15120
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: iep-61, ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Currently
> {code:java}
> Conditions.notExists(key){code}
> will both return true if there were no such key or if it was removed. New
> condition that will allow to detect whether a key was removed or not created
> is required. It might look like
> {code:java}
> Conditions.isTombstone(key){code}
> or similar.
>
> Seems that it'll be also helpful if
> org.apache.ignite.internal.metastorage.client.Conditions#notExists
> javadoc' will be more specific about tombstone case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14763) Inconsistence between meta storage client interface and server implementation
[
https://issues.apache.org/jira/browse/IGNITE-14763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14763:
Summary: Inconsistence between meta storage client interface and server
implementation (was: Inconsistence btwee meta storage client interface and
server implementation)
> Inconsistence between meta storage client interface and server implementation
> -
>
> Key: IGNITE-14763
> URL: https://issues.apache.org/jira/browse/IGNITE-14763
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: iep-61, ignite-3
>
> {{MetaStorageService.watch(keyFrom, KeyTo, revision, lsnr)}} describes
> {{keyFrom}} as "Start key of range (inclusive). Could be null." while
> {{SimpleInMemoryKeyValueStorage}} doesn't allow {{null}} value for
> {{keyForm}}.
> Needs to allow meta storage take {{null}} value for {{keyFrom}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15120) Condition isTombstone() is required
[
https://issues.apache.org/jira/browse/IGNITE-15120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-15120:
Fix Version/s: 3.0.0-alpha3
> Condition isTombstone() is required
> ---
>
> Key: IGNITE-15120
> URL: https://issues.apache.org/jira/browse/IGNITE-15120
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Andrey N. Gura
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Currently
> {code:java}
> Conditions.notExists(key){code}
> will both return true if there were no such key or if it was removed. New
> condition that will allow to detect whether a key was removed or not created
> is required. It might look like
> {code:java}
> Conditions.isTombstone(key){code}
> or similar.
>
> Seems that it'll be also helpful if
> org.apache.ignite.internal.metastorage.client.Conditions#notExists
> javadoc' will be more specific about tombstone case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15137) Fix javadoc phase for ignite-cli module
[ https://issues.apache.org/jira/browse/IGNITE-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-15137: - Ignite Flags: (was: Docs Required,Release Notes Required) > Fix javadoc phase for ignite-cli module > --- > > Key: IGNITE-15137 > URL: https://issues.apache.org/jira/browse/IGNITE-15137 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 20m > Remaining Estimate: 0h > > Javadoc generation fails in module ignite-cli because maven-assembly-plugin > adds module-info.class of the jackson dependency. This can be fixed by > changing assembly plugin to shade plugin and excluding module-info from the > super jar. > > Also sourcepath parameter of the javadoc plugin should be overridden for the > root module, because otherwise aggregate goal won't look through the > submodules -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14857) Calcite integration. ALTER TABLE support
[ https://issues.apache.org/jira/browse/IGNITE-14857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383308#comment-17383308 ] Stanilovsky Evgeny commented on IGNITE-14857: - [~alex_pl] thanks, looks good. > Calcite integration. ALTER TABLE support > > > Key: IGNITE-14857 > URL: https://issues.apache.org/jira/browse/IGNITE-14857 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 2h 50m > Remaining Estimate: 0h > > We need to support DDL commands. The task about the support of ALTER TABLE > ADD/DROP/ALTER COLUMN. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15137) Fix javadoc phase for ignite-cli module
[ https://issues.apache.org/jira/browse/IGNITE-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-15137: Description: Javadoc generation fails in module ignite-cli because maven-assembly-plugin adds module-info.class of the jackson dependency. This can be fixed by changing assembly plugin to shade plugin and excluding module-info from the super jar. Also sourcepath parameter of the javadoc plugin should be overridden for the root module, because otherwise aggregate goal won't look through the submodules was: Javadoc aggregate fails because maven-assembly-plugin adds module-info.class of the jackson dependency. This can be fixed by changing assembly plugin to shade plugin and excluding module-info from the super jar. Also sourcepath parameter of the javadoc plugin should be overridden for the root module, because otherwise aggregate goal won't look through the submodules > Fix javadoc phase for ignite-cli module > --- > > Key: IGNITE-15137 > URL: https://issues.apache.org/jira/browse/IGNITE-15137 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Javadoc generation fails in module ignite-cli because maven-assembly-plugin > adds module-info.class of the jackson dependency. This can be fixed by > changing assembly plugin to shade plugin and excluding module-info from the > super jar. > > Also sourcepath parameter of the javadoc plugin should be overridden for the > root module, because otherwise aggregate goal won't look through the > submodules -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14896) Schema update. Changing default value.
[ https://issues.apache.org/jira/browse/IGNITE-14896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383306#comment-17383306 ] Konstantin Orlov commented on IGNITE-14896: --- [~amashenkov], LGTM > Schema update. Changing default value. > -- > > Key: IGNITE-14896 > URL: https://issues.apache.org/jira/browse/IGNITE-14896 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Implement evolution converters for changing column default value operation. > Configuration changes should trigger a new schema version adding to schema > history. > Assumes, all nodes will use a new schema after upgrade. > Old row can be upgraded on fly using evolution converters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15137) Fix javadoc phase for ignite-cli module
[ https://issues.apache.org/jira/browse/IGNITE-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-15137: Description: Javadoc aggregate fails because maven-assembly-plugin adds module-info.class of the jackson dependency. This can be fixed by changing assembly plugin to shade plugin and excluding module-info from the super jar. Also sourcepath parameter of the javadoc plugin should be overridden for the root module, because otherwise aggregate goal won't look through the submodules was:Javadoc aggregate fails > Fix javadoc phase for ignite-cli module > --- > > Key: IGNITE-15137 > URL: https://issues.apache.org/jira/browse/IGNITE-15137 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Javadoc aggregate fails because maven-assembly-plugin adds module-info.class > of the jackson dependency. This can be fixed by changing assembly plugin to > shade plugin and excluding module-info from the super jar. > > Also sourcepath parameter of the javadoc plugin should be overridden for the > root module, because otherwise aggregate goal won't look through the > submodules -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15137) Fix javadoc phase for ignite-cli module
[ https://issues.apache.org/jira/browse/IGNITE-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov updated IGNITE-15137: Description: Javadoc aggregate fails > Fix javadoc phase for ignite-cli module > --- > > Key: IGNITE-15137 > URL: https://issues.apache.org/jira/browse/IGNITE-15137 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Javadoc aggregate fails -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14982) Persistent implementation for metastorage
[ https://issues.apache.org/jira/browse/IGNITE-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383302#comment-17383302 ] Andrey N. Gura commented on IGNITE-14982: - [~sdanilov] I've reviewed PR (https://github.com/apache/ignite-3/pull/203) and have one important comment about keeping keys index in memory. Also I've added a few minor comments. Could you please fix it. > Persistent implementation for metastorage > - > > Key: IGNITE-14982 > URL: https://issues.apache.org/jira/browse/IGNITE-14982 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Priority: Major > Labels: iep-74, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 144h > Remaining Estimate: 144h > > KeyValueStorage aka metastorage now has only in-memory implementation. > RocksDB-based persistent implementation should be provided for > persistence-enabled scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14979) Snapshots support in Storage to enable Raft log compaction
[ https://issues.apache.org/jira/browse/IGNITE-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383298#comment-17383298 ] Andrey N. Gura commented on IGNITE-14979: - [~sdanilov] Please, move PR to the https://issues.apache.org/jira/browse/IGNITE-14982 and move original issue to Path available status. Reason: PR fixes IGNITE-14982 issue. Do not forget change PR comment. > Snapshots support in Storage to enable Raft log compaction > -- > > Key: IGNITE-14979 > URL: https://issues.apache.org/jira/browse/IGNITE-14979 > Project: Ignite > Issue Type: Task >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-74, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 6h 50m > Remaining Estimate: 0h > > To preserve disk space Raft instance has to compact its log from time to > time. Log compacting involves taking snapshot of all keys currently residing > in memory and syncing them with persistent store. > Storage should provide a generic API for that operation (which in fact is > analogue of performing a checkpoint in Ignite 2.x) and RocksDB-based > implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14867) Calcite. Check aggregate SQL function works
[ https://issues.apache.org/jira/browse/IGNITE-14867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-14867: -- Assignee: Yury Gerzhedovich > Calcite. Check aggregate SQL function works > --- > > Key: IGNITE-14867 > URL: https://issues.apache.org/jira/browse/IGNITE-14867 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > > We need to write tests on existing aggregation SQL function and have a list > of supported such functions + create tasks for support another one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14838) Fix up messaging in jraft.
[ https://issues.apache.org/jira/browse/IGNITE-14838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14838: - Reviewer: Ivan Bessonov > Fix up messaging in jraft. > -- > > Key: IGNITE-14838 > URL: https://issues.apache.org/jira/browse/IGNITE-14838 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently jraft uses hand coded messages. > This should be cleaned up and switched to generated factories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15137) Fix javadoc phase for ignite-cli module
[
https://issues.apache.org/jira/browse/IGNITE-15137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383278#comment-17383278
]
Peter Ivanov commented on IGNITE-15137:
---
{{javadoc:aggregate}} fix looks good to me. Please, proceed with merge.
> Fix javadoc phase for ignite-cli module
> ---
>
> Key: IGNITE-15137
> URL: https://issues.apache.org/jira/browse/IGNITE-15137
> Project: Ignite
> Issue Type: Bug
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14857) Calcite integration. ALTER TABLE support
[ https://issues.apache.org/jira/browse/IGNITE-14857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383255#comment-17383255 ] Aleksey Plekhanov commented on IGNITE-14857: [~zstan], I've fixed your comments, can you please have a look again? > Calcite integration. ALTER TABLE support > > > Key: IGNITE-14857 > URL: https://issues.apache.org/jira/browse/IGNITE-14857 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 2h 50m > Remaining Estimate: 0h > > We need to support DDL commands. The task about the support of ALTER TABLE > ADD/DROP/ALTER COLUMN. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15133) Close cursors and wathces on node left
[ https://issues.apache.org/jira/browse/IGNITE-15133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15133: - Reviewer: Vladislav Pyatkov > Close cursors and wathces on node left > -- > > Key: IGNITE-15133 > URL: https://issues.apache.org/jira/browse/IGNITE-15133 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 1h > Remaining Estimate: 0h > > On the node left it's necessary to close range and watch cursors on the > server side. In order to linearize clearing with new cursors, creation > clearing should be implemented within raft. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15144) Missing @return in Javadoc for LoggerMessageHelper#arrayFormat()
[
https://issues.apache.org/jira/browse/IGNITE-15144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383208#comment-17383208
]
Vyacheslav Koptilin commented on IGNITE-15144:
--
Hello [~v.pyatkov], [~apolovtcev],
Merged to the main branch. Thank you for your contribution!
> Missing @return in Javadoc for LoggerMessageHelper#arrayFormat()
>
>
> Key: IGNITE-15144
> URL: https://issues.apache.org/jira/browse/IGNITE-15144
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Peter Ivanov
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{mvn install -P javadoc -Dmaven.test.skip}}:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default) on project
> ignite-core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - Error fetching URL:
> https://ignite.apache.org/releases/latest/javadoc/
> [ERROR]
> /Users/vveider/Development/ignite-3/modules/core/src/main/java/org/apache/ignite/lang/LoggerMessageHelper.java:94:
> warning: no @return
> [ERROR] static String arrayFormat(final String messagePattern, final
> Object[] params) {
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/javadoc
> @options @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/vveider/Development/ignite-3/modules/core/target/apidocs' dir.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15144) Missing @return in Javadoc for LoggerMessageHelper#arrayFormat()
[
https://issues.apache.org/jira/browse/IGNITE-15144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383206#comment-17383206
]
Aleksandr Polovtcev commented on IGNITE-15144:
--
LGTM!
> Missing @return in Javadoc for LoggerMessageHelper#arrayFormat()
>
>
> Key: IGNITE-15144
> URL: https://issues.apache.org/jira/browse/IGNITE-15144
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Peter Ivanov
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{mvn install -P javadoc -Dmaven.test.skip}}:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default) on project
> ignite-core: MavenReportException: Error while generating Javadoc:
> [ERROR] Exit code: 1 - javadoc: error - Error fetching URL:
> https://ignite.apache.org/releases/latest/javadoc/
> [ERROR]
> /Users/vveider/Development/ignite-3/modules/core/src/main/java/org/apache/ignite/lang/LoggerMessageHelper.java:94:
> warning: no @return
> [ERROR] static String arrayFormat(final String messagePattern, final
> Object[] params) {
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/javadoc
> @options @argfile
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in
> '/Users/vveider/Development/ignite-3/modules/core/target/apidocs' dir.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14557) Improve row layout.
[ https://issues.apache.org/jira/browse/IGNITE-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14557: -- Summary: Improve row layout. (was: Improve row layout. Skip writing null-map and vartable when possible.) > Improve row layout. > > > Key: IGNITE-14557 > URL: https://issues.apache.org/jira/browse/IGNITE-14557 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > h3. Motivation. > When one try to read a column value from a row, the very first check will be > a null-check. > As Null-Table resides right after an Offset-Table, the we need 2 jumps to for > the null-check. > h3. Description. > Assuming, Null-Table reserves a bit for each columns even if the columns is > not Nullable, > Null-table has constant size (within same version of schema) and we no need > extra bytes to persist it's length into the tuple. > * Null-checks will not require extra read for Offset-Table size and extra > jump. > * Offset-Table will not need extra read/jump to reach as Null-Table size is > constant. > Let's just swap these tables in layout and fix docs README.md and IEP. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-15124) Merge master to sql-calcite feature branch
[ https://issues.apache.org/jira/browse/IGNITE-15124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov resolved IGNITE-15124. --- Resolution: Fixed [~Berkov], merged. Thanks for contribution. > Merge master to sql-calcite feature branch > -- > > Key: IGNITE-15124 > URL: https://issues.apache.org/jira/browse/IGNITE-15124 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15145) javax.cache.CacheException: Failed to run reduce query locally. The query was cancelled while executing.
Juris Pipurs created IGNITE-15145: - Summary: javax.cache.CacheException: Failed to run reduce query locally. The query was cancelled while executing. Key: IGNITE-15145 URL: https://issues.apache.org/jira/browse/IGNITE-15145 Project: Ignite Issue Type: Bug Environment: Windows 10 pro Processor: Intel i9 2.4Ghz RAM: 32GB 64bit Operating system Ignite startup log: >>> __ >>> / _/ ___/ |/ / _/_ __/ __/ >>> _/ // (7 7 // / / / / _/ >>> /___/\___/_/|_/___/ /_/ /___/ >>> >>> ver. 2.10.0#20210310-sha1:bc24f6ba >>> 2021 Copyright(C) Apache Software Foundation >>> >>> Ignite documentation: http://ignite.apache.org [15:57:49,865][INFO][main][IgniteKernal] Config URL: file:/C:/Tools/apache_ignite/config/ignite_config.xml [15:57:49,878][INFO][main][IgniteKernal] IgniteConfiguration [igniteInstanceName=null, pubPoolSize=16, svcPoolSize=16, callbackPoolSize=16, stripedPoolSize=16, sysPoolSize=16, mgmtPoolSize=4, dataStreamerPoolSize=16, utilityCachePoolSize=16, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=16, buildIdxPoolSize=4, igniteHome=c:/Tools/apache-ignite-2.10.0-bin, igniteWorkDir=C:\Tools\apache_ignite\work_directory, mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@2ea6137, nodeId=b9e8ddca-e09a-4c1d-9a3a-bdb7264bfd91, marsh=BinaryMarshaller [], marshLocJobs=false, daemon=false, p2pEnabled=false, netTimeout=5000, netCompressionLevel=1, sndRetryDelay=1000, sndRetryCnt=3, metricsHistSize=1, metricsUpdateFreq=2000, metricsExpTime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null, sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10, reconDelay=2000, maxAckTimeout=60, soLinger=0, forceSrvMode=false, clientReconnectDisabled=false, internalLsnr=null, skipAddrsRandomization=false], segPlc=STOP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true, segChkFreq=1, commSpi=TcpCommunicationSpi [connectGate=org.apache.ignite.spi.communication.tcp.internal.ConnectGateway@57250572, ctxInitLatch=java.util.concurrent.CountDownLatch@5609159b[Count = 1], stopping=false, clientPool=null, nioSrvWrapper=null, stateProvider=null], evtSpi=org.apache.ignite.spi.eventstorage.NoopEventStorageSpi@2118cddf, colSpi=NoopCollisionSpi [], deploySpi=LocalDeploymentSpi [], indexingSpi=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@3f56875e, addrRslvr=null, encryptionSpi=org.apache.ignite.spi.encryption.noop.NoopEncryptionSpi@2b4bac49, tracingSpi=org.apache.ignite.spi.tracing.NoopTracingSpi@fd07cbb, clientMode=false, rebalanceThreadPoolSize=4, rebalanceTimeout=1, rebalanceBatchesPrefetchCnt=3, rebalanceThrottle=0, rebalanceBatchSize=524288, txCfg=TransactionConfiguration [txSerEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC, dfltTxTimeout=0, txTimeoutOnPartitionMapExchange=0, deadlockTimeout=1, pessimisticTxLogSize=0, pessimisticTxLogLinger=1, tmLookupClsName=null, txManagerFactory=null, useJtaSync=false], cacheSanityCheckEnabled=true, discoStartupDelay=6, deployMode=SHARED, p2pMissedCacheSize=100, locHost=null, timeSrvPortBase=31100, timeSrvPortRange=100, failureDetectionTimeout=1, sysWorkerBlockedTimeout=null, clientFailureDetectionTimeout=3, metricsLogFreq=6, connectorCfg=ConnectorConfiguration [jettyPath=null, host=null, port=11211, noDelay=true, directBuf=false, sndBufSize=32768, rcvBufSize=32768, idleQryCurTimeout=60, idleQryCurCheckFreq=6, sndQueueLimit=0, selectorCnt=4, idleTimeout=7000, sslEnabled=false, sslClientAuth=false, sslCtxFactory=null, sslFactory=null, portRange=100, threadPoolSize=16, msgInterceptor=null], odbcCfg=null, warmupClos=null, atomicCfg=AtomicConfiguration [seqReserveSize=1000, cacheMode=PARTITIONED, backups=1, aff=null, grpName=null], classLdr=null, sslCtxFactory=null, platformCfg=null, binaryCfg=null, memCfg=null, pstCfg=null, dsCfg=DataStorageConfiguration [sysRegionInitSize=41943040, sysRegionMaxSize=104857600, pageSize=0, concLvl=0, dfltDataRegConf=DataRegionConfiguration [name=default, maxSize=6818405580, initSize=268435456, swapPath=null, pageEvictionMode=DISABLED, evictionThreshold=0.9, emptyPagesPoolSize=100, metricsEnabled=false, metricsSubIntervalCount=5, metricsRateTimeInterval=6, persistenceEnabled=true, checkpointPageBufSize=0, lazyMemoryAllocation=true, warmUpCfg=null], dataRegions=DataRegionConfiguration[] [DataRegionConfiguration [name=4GB_Region, maxSize=4294967296, initSize=524288000, swapPath=null, pageEvictionMode=RANDOM_2_LRU, evictionThreshold=0.9, emptyPagesPoolSize=100, metricsEnabled=false, metricsSubIntervalCount=5, metricsRateTimeInterval=6, persistenceEnabled=true, checkpointPageBufSize=0, lazyMemoryAllocation=true, warmUpCfg=null]], storagePath=C:\Tools\apache_ignite\storage, checkpointFreq=18, lockWaitTime=1, checkpointThreads=4,
[jira] [Commented] (IGNITE-14866) Calcite. Check SQL function works
[ https://issues.apache.org/jira/browse/IGNITE-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383139#comment-17383139 ] Yury Gerzhedovich commented on IGNITE-14866: [~tledkov-gridgain], Taras, could you please merge the patch. > Calcite. Check SQL function works > - > > Key: IGNITE-14866 > URL: https://issues.apache.org/jira/browse/IGNITE-14866 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: calcite2-required, calcite3-required > Time Spent: 1h 20m > Remaining Estimate: 0h > > We need to write tests on existing simple SQL functions (nor aggregation or > window functions) and have a list of supported functions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15144) Missing @return in Javadoc for LoggerMessageHelper#arrayFormat()
Peter Ivanov created IGNITE-15144:
-
Summary: Missing @return in Javadoc for
LoggerMessageHelper#arrayFormat()
Key: IGNITE-15144
URL: https://issues.apache.org/jira/browse/IGNITE-15144
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha3
Reporter: Peter Ivanov
Assignee: Vladislav Pyatkov
Fix For: 3.0.0-alpha3
{{mvn install -P javadoc -Dmaven.test.skip}}:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default) on project
ignite-core: MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - Error fetching URL:
https://ignite.apache.org/releases/latest/javadoc/
[ERROR]
/Users/vveider/Development/ignite-3/modules/core/src/main/java/org/apache/ignite/lang/LoggerMessageHelper.java:94:
warning: no @return
[ERROR] static String arrayFormat(final String messagePattern, final
Object[] params) {
[ERROR] ^
[ERROR]
[ERROR] Command line was:
/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin/javadoc
@options @argfile
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/Users/vveider/Development/ignite-3/modules/core/target/apidocs' dir.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15052) Move thread pools creation to PoolProcessor.
[ https://issues.apache.org/jira/browse/IGNITE-15052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-15052: Description: It is proposed to 1. move the creation of thread pools that are shared across multiple Ignite processors to the PoolProcessor - now they are created in IgniitonEx 2. get thread pools instances through the PoolProcessor - now they are obtained through GridKernalContext This helps to encapsulate the logic related to shared thread pools into a dedicated processor that is in charge of thread pool management. The implementation of this proposal will also allow to implement more reliable way to keep correct security context for tasks that are asynchronously executed in thread pools. The only questionable change associated with this proposal is that thread pools will be stopped earlier than before but tests shows no issues with it. was: It is proposed to 1. move the creation of thread pools that are shared across multiple Ignite processors to the PoolProcessor - now they are created in IgniitonEx 2. get thread pools instances through the PoolProcessor - now they are obtained through GridKernalKontext This helps to encapsulate the logic related to shared thread pools into a dedicated processor that is in charge of thread pool management. The implementation of this proposal will also allow to implement more reliable way to keep correct security context for tasks that are asynchronously executed in thread pools. The only questionable change associated with this proposal is that thread pools will be stopped earlier than before but tests shows no issues with it. > Move thread pools creation to PoolProcessor. > > > Key: IGNITE-15052 > URL: https://issues.apache.org/jira/browse/IGNITE-15052 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > It is proposed to > 1. move the creation of thread pools that are shared across multiple Ignite > processors to the PoolProcessor - now they are created in IgniitonEx > 2. get thread pools instances through the PoolProcessor - now they are > obtained through GridKernalContext > This helps to encapsulate the logic related to shared thread pools into a > dedicated processor that is in charge of thread pool management. The > implementation of this proposal will also allow to implement more reliable > way to keep correct security context for tasks that are asynchronously > executed in thread pools. > The only questionable change associated with this proposal is that thread > pools will be stopped earlier than before but tests shows no issues with it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15101) Ignite tasks run in a security context other than the initiator's security context
[
https://issues.apache.org/jira/browse/IGNITE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15101:
Description:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
1. Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
2.
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskSecurityContextTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
was:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
1. Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
2.
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskSecurityContextTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
[jira] [Updated] (IGNITE-15101) Ignite tasks run in a security context other than the initiator's security context
[
https://issues.apache.org/jira/browse/IGNITE-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-15101:
Description:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
1. Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
2.
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskSecurityContextTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
}
@Override public Object execute() throws IgniteException {
assertEquals(secSubjId,
ignite.context().security().securityContext().subject().id());
return null;
}
}, subgrid.get(0));
}
/** {@inheritDoc} */
@Override public @Nullable Void reduce(List results)
throws IgniteException {
return null;
}
}
{code}
was:
Ignite tasks run in a security context other than the initiator's security
context.
Reproducer:
Make TestSecurityProcessor#authenticatedSubjects to return
TestSecurityProcessor#SECURITY_CONTEXTS values to determine client subject id
after authentication like:
{code:java}
return
SECURITY_CONTEXTS.values().stream().map(SecurityContext::subject).collect(Collectors.toList());
{code}
{code:java}
public class TaskSecurityContextTest extends AbstractSecurityTest {
/** */
private static final String TASK_NAME =
"org.apache.ignite.internal.processors.security.events.TaskSecurityContextTest$TestComputeTask";
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setClientConnectorConfiguration(
new ClientConnectorConfiguration().setThinClientConfiguration(
new
ThinClientConfiguration().setMaxActiveComputeTasksPerConnection(1)));
}
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGridAllowAll("srv");
String login = "test";
IgniteClient cli = Ignition.startClient(new ClientConfiguration()
.setAddresses(Config.SERVER)
.setUserName(login)
.setUserPassword("")
);
UUID subjId =
ignite.context().security().authenticatedSubjects().stream()
.filter(subj -> subj.login().equals(login))
.findFirst()
.get()
.id();
cli.compute().execute(TASK_NAME, subjId);
}
/** Test compute task. */
public static class TestComputeTask extends ComputeTaskAdapter {
/** {@inheritDoc} */
@Override public @NotNull Map map(
List subgrid,
@Nullable UUID secSubjId
) throws IgniteException {
return F.asMap(new ComputeJob() {
/** */
@IgniteInstanceResource
private IgniteEx ignite;
@Override public void cancel() {
// No-op.
[jira] [Updated] (IGNITE-15076) Calcite. ignite.[sh|bat] node runner script failed to start instance.
[
https://issues.apache.org/jira/browse/IGNITE-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-15076:
--
Labels: calcite (was: calcite calcite3-required)
> Calcite. ignite.[sh|bat] node runner script failed to start instance.
> -
>
> Key: IGNITE-15076
> URL: https://issues.apache.org/jira/browse/IGNITE-15076
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Found that node runner script failed with trace:
> {noformat}
> java.lang.ExceptionInInitializerError
> at
> org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:241)
> at
> org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:217)
> at
> org.apache.calcite.tools.Frameworks.newConfigBuilder(Frameworks.java:201)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.(CalciteQueryProcessor.java:73)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.ignite.internal.util.IgniteUtils.inClassPath(IgniteUtils.java:1754)
> at
> org.apache.ignite.internal.IgniteComponentType.inClassPath(IgniteComponentType.java:181)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1267)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: java.lang.NullPointerException
> at
> sun.reflect.annotation.TypeAnnotationParser.mapTypeAnnotations(TypeAnnotationParser.java:356)
> at
> sun.reflect.annotation.AnnotatedTypeFactory$AnnotatedTypeBaseImpl.(AnnotatedTypeFactory.java:139)
> at
> sun.reflect.annotation.AnnotatedTypeFactory.buildAnnotatedType(AnnotatedTypeFactory.java:65)
> at
> sun.reflect.annotation.TypeAnnotationParser.buildAnnotatedType(TypeAnnotationParser.java:79)
> at
> java.lang.reflect.Executable.getAnnotatedReturnType0(Executable.java:640)
> at java.lang.reflect.Method.getAnnotatedReturnType(Method.java:648)
> at
> org.apache.calcite.util.ImmutableBeans.makeDef(ImmutableBeans.java:146)
> at
> org.apache.calcite.util.ImmutableBeans.access$000(ImmutableBeans.java:55)
> at
> org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:68)
> at
> org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:65)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2276)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154)
> at
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3951)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3973)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4957)
> at
> org.apache.calcite.util.ImmutableBeans.create_(ImmutableBeans.java:95)
> at
> org.apache.calcite.util.ImmutableBeans.create(ImmutableBeans.java:76)
> at
> org.apache.calcite.sql.validate.SqlValidator$Config.(SqlValidator.java:792)
> ... 19 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15076) Calcite. ignite.[sh|bat] node runner script failed to start instance.
[
https://issues.apache.org/jira/browse/IGNITE-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383052#comment-17383052
]
Taras Ledkov commented on IGNITE-15076:
---
Merged to
[ignite-3|https://github.com/apache/ignite-3/commit/eb0980ad50d93e878665fe9cc755208123eec413]
> Calcite. ignite.[sh|bat] node runner script failed to start instance.
> -
>
> Key: IGNITE-15076
> URL: https://issues.apache.org/jira/browse/IGNITE-15076
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Found that node runner script failed with trace:
> {noformat}
> java.lang.ExceptionInInitializerError
> at
> org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:241)
> at
> org.apache.calcite.tools.Frameworks$ConfigBuilder.(Frameworks.java:217)
> at
> org.apache.calcite.tools.Frameworks.newConfigBuilder(Frameworks.java:201)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.(CalciteQueryProcessor.java:73)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:264)
> at
> org.apache.ignite.internal.util.IgniteUtils.inClassPath(IgniteUtils.java:1754)
> at
> org.apache.ignite.internal.IgniteComponentType.inClassPath(IgniteComponentType.java:181)
> at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1267)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2141)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1787)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1172)
> at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1066)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:952)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:851)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:721)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690)
> at org.apache.ignite.Ignition.start(Ignition.java:353)
> at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)
> Caused by: java.lang.NullPointerException
> at
> sun.reflect.annotation.TypeAnnotationParser.mapTypeAnnotations(TypeAnnotationParser.java:356)
> at
> sun.reflect.annotation.AnnotatedTypeFactory$AnnotatedTypeBaseImpl.(AnnotatedTypeFactory.java:139)
> at
> sun.reflect.annotation.AnnotatedTypeFactory.buildAnnotatedType(AnnotatedTypeFactory.java:65)
> at
> sun.reflect.annotation.TypeAnnotationParser.buildAnnotatedType(TypeAnnotationParser.java:79)
> at
> java.lang.reflect.Executable.getAnnotatedReturnType0(Executable.java:640)
> at java.lang.reflect.Method.getAnnotatedReturnType(Method.java:648)
> at
> org.apache.calcite.util.ImmutableBeans.makeDef(ImmutableBeans.java:146)
> at
> org.apache.calcite.util.ImmutableBeans.access$000(ImmutableBeans.java:55)
> at
> org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:68)
> at
> org.apache.calcite.util.ImmutableBeans$1.load(ImmutableBeans.java:65)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2276)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2154)
> at
> com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2044)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3951)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3973)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4957)
> at
> org.apache.calcite.util.ImmutableBeans.create_(ImmutableBeans.java:95)
> at
> org.apache.calcite.util.ImmutableBeans.create(ImmutableBeans.java:76)
> at
> org.apache.calcite.sql.validate.SqlValidator$Config.(SqlValidator.java:792)
> ... 19 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14743) Support Row with large values.
[
https://issues.apache.org/jira/browse/IGNITE-14743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17383047#comment-17383047
]
Taras Ledkov commented on IGNITE-14743:
---
[~amashenkov], the patch is OK with me.
> Support Row with large values.
> --
>
> Key: IGNITE-14743
> URL: https://issues.apache.org/jira/browse/IGNITE-14743
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: Byte array columns only benchmark.txt, Fixlen cols only
> benchmark.txt, Latin1 string columns benchmark.txt, Non-latin string columns
> benchmark.txt, String marshalling comparison
>
> Original Estimate: 168h
> Time Spent: 2h 10m
> Remaining Estimate: 165h 50m
>
> h3. Motivation.
> For now, TupleAssembler writes offsets for varlen columns as 2-byte \{{short
> }}type.
> This implicitly restricts key/value sizes down to 64 kB in total.
> On another side, for small rows that columns can be addressed with \{{byte}}
> type, we will waste few bytes.
> h3. Description.
> Let's
> # allow 4 byte types (byte, short, int) for offsets.
> # implement and benchmark different approaches that allow us to write rows in
> the most compact way.
> # then choose and merge the best one.
> We can introduce several formats for writing Vartable (using byte/short/int
> offsets).
> Additional information about Vartable format can be coded into chunk flags.
> The first approach is to precalculate chunk total size, then choose the most
> compact format and write a chunk.
> The second approach is to write a chunk with the widest format then convert
> the chunk into the most compact format in place.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
