[jira] [Created] (IGNITE-15700) Rename 'Table#tableName' method to 'name'
Valentin Kulichenko created IGNITE-15700:
Summary: Rename 'Table#tableName' method to 'name'
Key: IGNITE-15700
URL: https://issues.apache.org/jira/browse/IGNITE-15700
Project: Ignite
Issue Type: Bug
Reporter: Valentin Kulichenko
The {{table}} prefix seems redundant here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15699) Incorrect class name: TableSchemaBuilder
Valentin Kulichenko created IGNITE-15699:
Summary: Incorrect class name: TableSchemaBuilder
Key: IGNITE-15699
URL: https://issues.apache.org/jira/browse/IGNITE-15699
Project: Ignite
Issue Type: Bug
Reporter: Valentin Kulichenko
Looks like {{TableSchemaBuilder}} was left untouched during renamings in the
{{org.apache.ignite.schema}} package.
The correct name should be {{TableDefinitionBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15698) SQL query may hangs where table is dropped concurrently
Alexander Belyak created IGNITE-15698: - Summary: SQL query may hangs where table is dropped concurrently Key: IGNITE-15698 URL: https://issues.apache.org/jira/browse/IGNITE-15698 Project: Ignite Issue Type: Bug Components: sql Reporter: Alexander Belyak Assignee: Alexander Belyak SQL query may hangs where table is dropped concurrently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15696) NullPointerException in StripeEntryHandler
[
https://issues.apache.org/jira/browse/IGNITE-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425169#comment-17425169
]
Vladislav Pyatkov commented on IGNITE-15696:
LGTM, but need to wait a green visa.
> NullPointerException in StripeEntryHandler
> --
>
> Key: IGNITE-15696
> URL: https://issues.apache.org/jira/browse/IGNITE-15696
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Temporary fix https://issues.apache.org/jira/browse/IGNITE-15663 introduced
> NPE in {{org.apache.ignite.raft.jraft.core.FSMCallerImpl#runApplyTask}}, also
> bug with logging has been found
> {{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeExceptionHandler}},
> exception doesn't been propagated to logger
> Solution with NPE is to set true to {{endOfBatch}} field in
> {{com.lmax.disruptor.EventHandler#onEvent}} in
> {{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeEntryHandler#onEvent}},
> so we don't need to rely on
> {{node.getOptions().getRaftOptions().getApplyBatch()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15696) NullPointerException in StripeEntryHandler
[
https://issues.apache.org/jira/browse/IGNITE-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425161#comment-17425161
]
Vladislav Pyatkov commented on IGNITE-15696:
Hi [~maliev] I looked to your PR and have another opinion.
1) Got rid of the limitation on RaftOptions#applyBatch. It does not matter
anymore.
2) Remove references of RaftOptions for the StripedDisruptorTest. It will be a
test for StripedDisruptar as is.
3) All todoes of the test might be also reduced.
> NullPointerException in StripeEntryHandler
> --
>
> Key: IGNITE-15696
> URL: https://issues.apache.org/jira/browse/IGNITE-15696
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Temporary fix https://issues.apache.org/jira/browse/IGNITE-15663 introduced
> NPE in {{org.apache.ignite.raft.jraft.core.FSMCallerImpl#runApplyTask}}, also
> bug with logging has been found
> {{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeExceptionHandler}},
> exception doesn't been propagated to logger
> Solution with NPE is to set true to {{endOfBatch}} field in
> {{com.lmax.disruptor.EventHandler#onEvent}} in
> {{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeEntryHandler#onEvent}},
> so we don't need to rely on
> {{node.getOptions().getRaftOptions().getApplyBatch()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15651) CacheGroupReencryptionTest.testReencryptionMetrics is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15651:
--
Description:
Test CacheGroupReencryptionTest.testReencryptionMetrics is flaky on TeamCity:
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-1489145953860433024=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.encryption.CacheGroupReencryptionTest.validateMetrics(CacheGroupReencryptionTest.java:821)
at
org.apache.ignite.internal.encryption.CacheGroupReencryptionTest.testReencryptionMetrics(CacheGroupReencryptionTest.java:786)
{noformat}
It seems we should update metrics synchronously before finish the "key-change"
future or wait for metrics update in the test.
was:
Test CacheGroupReencryptionTest.testReencryptionMetrics is flaky on TeamCity:
[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-1489145953860433024=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.encryption.CacheGroupReencryptionTest.validateMetrics(CacheGroupReencryptionTest.java:821)
at
org.apache.ignite.internal.encryption.CacheGroupReencryptionTest.testReencryptionMetrics(CacheGroupReencryptionTest.java:786)
{noformat}
It seems we should update metrics synchronously before finish the "key-change"
future.
> CacheGroupReencryptionTest.testReencryptionMetrics is flaky
> ---
>
> Key: IGNITE-15651
> URL: https://issues.apache.org/jira/browse/IGNITE-15651
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test CacheGroupReencryptionTest.testReencryptionMetrics is flaky on TeamCity:
>
> [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8==testDetails=-1489145953860433024=TEST_STATUS_DESC=50_IgniteTests24Java8=%3Cdefault%3E]
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.encryption.CacheGroupReencryptionTest.validateMetrics(CacheGroupReencryptionTest.java:821)
> at
> org.apache.ignite.internal.encryption.CacheGroupReencryptionTest.testReencryptionMetrics(CacheGroupReencryptionTest.java:786)
> {noformat}
> It seems we should update metrics synchronously before finish the
> "key-change" future or wait for metrics update in the test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15675) Ignite CLI commands must fit general logging formatting
[
https://issues.apache.org/jira/browse/IGNITE-15675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-15675:
-
Priority: Blocker (was: Major)
> Ignite CLI commands must fit general logging formatting
>
>
> Key: IGNITE-15675
> URL: https://issues.apache.org/jira/browse/IGNITE-15675
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> When you run, for example,
> {code:bash}
> ./ignite init
> ./ignite node start
> {code}
> output log differs from formatting for ignite, that is described in
> {{config/java.util.logging.properties}}. CLI commands must reuse the common
> config file.
> A possible solution is to pass
> {code:java}
> -Djava.util.logging.config.file=../../config/java.util.logging.properties
> {code}
> in {{modules/cli/ignite.sh}} and in
> {{org.apache.ignite.cli.builtins.node.NodeManager#start}}
>
> Also, this dependency must be added to cli module pom:
> {code:xml}
>
> org.slf4j
> slf4j-jdk14
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-15682) Verbose output produced by 'ignite init' and 'ignite module add' commands
[
https://issues.apache.org/jira/browse/IGNITE-15682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev resolved IGNITE-15682.
--
Resolution: Duplicate
> Verbose output produced by 'ignite init' and 'ignite module add' commands
> -
>
> Key: IGNITE-15682
> URL: https://issues.apache.org/jira/browse/IGNITE-15682
> Project: Ignite
> Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha3
>
>
> {{ignite init}} and {{ignite module add}} commands started to output a lot of
> unnecessary logging information (see a sample below). This output should be
> removed from the console output.
> {noformat}
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha3...
> Oct 05, 2021 3:38:20 PM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: :: resolving dependencies ::
> org.apache.ignite#installer-envelope;working
> Oct 05, 2021 3:38:20 PM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: confs: [default]
> |>
> | 1%Oct 05, 2021 3:38:22 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.apache.ignite#ignite-runner;3.0.0-alpha3 in
> /content/repositories/orgapacheignite-1527
> |=>
> | 2%Oct 05, 2021 3:38:24 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.apache.ignite#ignite-configuration;3.0.0-alpha3 in
> /content/repositories/orgapacheignite-1527
> |==>
> | 3%Oct 05, 2021 3:38:25 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.apache.ignite#ignite-bytecode;3.0.0-alpha3 in
> /content/repositories/orgapacheignite-1527
> |===>
> | 4%Oct 05, 2021 3:38:26 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.jetbrains#annotations;20.1.0 in central
> |>
> | 5%Oct 05, 2021 3:38:27 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.ow2.asm#asm;9.0 in central
> |=>
> | 6%Oct 05, 2021 3:38:28 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.ow2.asm#asm-tree;9.0 in central
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15682) Verbose output produced by 'ignite init' and 'ignite module add' commands
[
https://issues.apache.org/jira/browse/IGNITE-15682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-15682:
Assignee: Mirza Aliev
> Verbose output produced by 'ignite init' and 'ignite module add' commands
> -
>
> Key: IGNITE-15682
> URL: https://issues.apache.org/jira/browse/IGNITE-15682
> Project: Ignite
> Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha3
>
>
> {{ignite init}} and {{ignite module add}} commands started to output a lot of
> unnecessary logging information (see a sample below). This output should be
> removed from the console output.
> {noformat}
> Installing org.apache.ignite:ignite-runner:3.0.0-alpha3...
> Oct 05, 2021 3:38:20 PM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: :: resolving dependencies ::
> org.apache.ignite#installer-envelope;working
> Oct 05, 2021 3:38:20 PM org.apache.ignite.lang.IgniteLogger logInternal
> INFO: confs: [default]
> |>
> | 1%Oct 05, 2021 3:38:22 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.apache.ignite#ignite-runner;3.0.0-alpha3 in
> /content/repositories/orgapacheignite-1527
> |=>
> | 2%Oct 05, 2021 3:38:24 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.apache.ignite#ignite-configuration;3.0.0-alpha3 in
> /content/repositories/orgapacheignite-1527
> |==>
> | 3%Oct 05, 2021 3:38:25 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.apache.ignite#ignite-bytecode;3.0.0-alpha3 in
> /content/repositories/orgapacheignite-1527
> |===>
> | 4%Oct 05, 2021 3:38:26 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.jetbrains#annotations;20.1.0 in central
> |>
> | 5%Oct 05, 2021 3:38:27 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.ow2.asm#asm;9.0 in central
> |=>
> | 6%Oct 05, 2021 3:38:28 PM
> org.apache.ignite.lang.IgniteLogger logInternal
> INFO: found org.ow2.asm#asm-tree;9.0 in central
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15675) Ignite CLI commands must fit general logging formatting
[
https://issues.apache.org/jira/browse/IGNITE-15675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-15675:
Assignee: Mirza Aliev
> Ignite CLI commands must fit general logging formatting
>
>
> Key: IGNITE-15675
> URL: https://issues.apache.org/jira/browse/IGNITE-15675
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> When you run, for example,
> {code:bash}
> ./ignite init
> ./ignite node start
> {code}
> output log differs from formatting for ignite, that is described in
> {{config/java.util.logging.properties}}. CLI commands must reuse the common
> config file.
> A possible solution is to pass
> {code:java}
> -Djava.util.logging.config.file=../../config/java.util.logging.properties
> {code}
> in {{modules/cli/ignite.sh}} and in
> {{org.apache.ignite.cli.builtins.node.NodeManager#start}}
>
> Also, this dependency must be added to cli module pom:
> {code:xml}
>
> org.slf4j
> slf4j-jdk14
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15675) Ignite CLI commands must fit general logging formatting
[
https://issues.apache.org/jira/browse/IGNITE-15675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-15675:
-
Fix Version/s: 3.0.0-alpha3
> Ignite CLI commands must fit general logging formatting
>
>
> Key: IGNITE-15675
> URL: https://issues.apache.org/jira/browse/IGNITE-15675
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> When you run, for example,
> {code:bash}
> ./ignite init
> ./ignite node start
> {code}
> output log differs from formatting for ignite, that is described in
> {{config/java.util.logging.properties}}. CLI commands must reuse the common
> config file.
> A possible solution is to pass
> {code:java}
> -Djava.util.logging.config.file=../../config/java.util.logging.properties
> {code}
> in {{modules/cli/ignite.sh}} and in
> {{org.apache.ignite.cli.builtins.node.NodeManager#start}}
>
> Also, this dependency must be added to cli module pom:
> {code:xml}
>
> org.slf4j
> slf4j-jdk14
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15125) Implement naive partitions reassignment
[ https://issues.apache.org/jira/browse/IGNITE-15125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-15125: - Fix Version/s: 3.0.0-alpha3 > Implement naive partitions reassignment > --- > > Key: IGNITE-15125 > URL: https://issues.apache.org/jira/browse/IGNITE-15125 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexander Lapin >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 96h > Time Spent: 0.5h > Remaining Estimate: 95.5h > > TBD -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15060) ignitecli must provide work directory path during node start
[ https://issues.apache.org/jira/browse/IGNITE-15060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-15060: - Fix Version/s: 3.0.0-alpha3 > ignitecli must provide work directory path during node start > > > Key: IGNITE-15060 > URL: https://issues.apache.org/jira/browse/IGNITE-15060 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15351) Research possibility of having caching layer on top of RocksDB partitions
[ https://issues.apache.org/jira/browse/IGNITE-15351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425119#comment-17425119 ] Andrey N. Gura commented on IGNITE-15351: - [~ibessonov] I've took a look at the PR and have some comments. Could you please take a look? Thanks. > Research possibility of having caching layer on top of RocksDB partitions > - > > Key: IGNITE-15351 > URL: https://issues.apache.org/jira/browse/IGNITE-15351 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha2 >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-74, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 8.5h > Remaining Estimate: 0h > > In Ignite 2.x there's a concept of "Data Regions", which is basically a set > of fixed-sized in-memory caches that store data for a number of cache groups > (let's ignore system region and similar stuff for now). It is very convenient > and represents a core design feature in Apache Ignite - In-Memory Database. > Currently, Page Memory subsystem is not yet ported to Ignite 3.x codebase. > Instead, there's an implementation based on RocksDB database to store data > persistently. > But, this implementation is very simple and naive. There's no notion of > in-memory cache across multiple tables, meaning that it can't be called an > In-Memory Database. We should investigate ways to add this concept back on > top of RocksDB implementation. > There are several things to investigate here: > * how do you set up rocksdb properly and control its memory consumption - we > should allow some configuration and a meaningful set of defaults; > * how do you put a cache on top of several rocksdb instances. This is > actually pretty easy, just use > "org.rocksdb.Options#setRowCache(org.rocksdb.Cache)", it has LRU and Clock > implementations. A way to configure it is still required; > * how do we introduce data regions into our system? I see something like > this: > ** list of regions is either a node or cluster configuration; > ** name of the region is a property of every individual table or table group > (or whatever else we'll be having). > Last proposition is a bit tricky, cause it won't look like "create table with > rocks engine with Clock cache...", it would look like "create table in region > Foo". We have to conceptualize all these things and come up with proper > naming at least. > h3. Update 1 > * the only way to control rocksdb memory usage is to have a single DB > instance. For every table there will be several column families: > ** one for table meta; > ** one for every partition; > ** one for every index; > * data regions are a configuration of every individual node. They will have > name, type and some other settings. The way tables chose the region remains > to be defined; > * there have to be common rocksdb settings outside of region settings, like > mem table size, wal settings, etc. > h3. Update 2 > * actually, there is a way to have a shared memory manager for several > instances -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15697) Attempt to run testNodesStartWithBootstrapConfiguration on Windows results in InvalidPathException
Vyacheslav Koptilin created IGNITE-15697:
Summary: Attempt to run testNodesStartWithBootstrapConfiguration
on Windows results in InvalidPathException
Key: IGNITE-15697
URL: https://issues.apache.org/jira/browse/IGNITE-15697
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Koptilin
Attempt to run testNodesStartWithBootstrapConfiguration on Windows results in
the following exception:
{noformat}
java.nio.file.InvalidPathException: Illegal char <:> at index 93:
org.apache.ignite.internal.runner.app.ITIgnitionTest#testNodesStartWithBootstrapConfiguration:3344
at
java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
at
java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at
java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
at
java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
at java.base/java.nio.file.Path.resolve(Path.java:515)
at
org.apache.ignite.internal.runner.app.ITIgnitionTest.lambda$testNodesStartWithBootstrapConfiguration$0(ITIgnitionTest.java:115)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
at
org.apache.ignite.internal.runner.app.ITIgnitionTest.testNodesStartWithBootstrapConfiguration(ITIgnitionTest.java:114)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
at
org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
[jira] [Updated] (IGNITE-15696) NullPointerException in StripeEntryHandler
[
https://issues.apache.org/jira/browse/IGNITE-15696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-15696:
-
Issue Type: Bug (was: Improvement)
> NullPointerException in StripeEntryHandler
> --
>
> Key: IGNITE-15696
> URL: https://issues.apache.org/jira/browse/IGNITE-15696
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Temporary fix https://issues.apache.org/jira/browse/IGNITE-15663 introduced
> NPE in {{org.apache.ignite.raft.jraft.core.FSMCallerImpl#runApplyTask}}, also
> bug with logging has been found
> {{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeExceptionHandler}},
> exception doesn't been propagated to logger
> Solution with NPE is to set true to {{endOfBatch}} field in
> {{com.lmax.disruptor.EventHandler#onEvent}} in
> {{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeEntryHandler#onEvent}},
> so we don't need to rely on
> {{node.getOptions().getRaftOptions().getApplyBatch()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15692) Implement TableManager component stop
[ https://issues.apache.org/jira/browse/IGNITE-15692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15692: - Description: *Problem* TableManager stop isn't implemented, therefore, stopping an Ignite node does not stop rafts groups of table partitions, which in turn leads to leaking resources, particularly threads and thread pools. Things to be done: * Proper stop of everything that was started during TableManager start and withing it's life cycle. Definitely it's raft groups and maybe something else. * Proper stop assumes that it's thread safe, so that busy lock is involved to protect local part of operations. > Implement TableManager component stop > -- > > Key: IGNITE-15692 > URL: https://issues.apache.org/jira/browse/IGNITE-15692 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > *Problem* > TableManager stop isn't implemented, therefore, stopping an Ignite node does > not stop rafts groups of table partitions, which in turn leads to leaking > resources, particularly threads and thread pools. > Things to be done: > * Proper stop of everything that was started during TableManager start and > withing it's life cycle. Definitely it's raft groups and maybe something else. > * Proper stop assumes that it's thread safe, so that busy lock is involved > to protect local part of operations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15696) NullPointerException in StripeEntryHandler
Mirza Aliev created IGNITE-15696:
Summary: NullPointerException in StripeEntryHandler
Key: IGNITE-15696
URL: https://issues.apache.org/jira/browse/IGNITE-15696
Project: Ignite
Issue Type: Improvement
Reporter: Mirza Aliev
Fix For: 3.0.0-alpha3
Temporary fix https://issues.apache.org/jira/browse/IGNITE-15663 introduced NPE
in {{org.apache.ignite.raft.jraft.core.FSMCallerImpl#runApplyTask}}, also bug
with logging has been found
{{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeExceptionHandler}},
exception doesn't been propagated to logger
Solution with NPE is to set true to {{endOfBatch}} field in
{{com.lmax.disruptor.EventHandler#onEvent}} in
{{org.apache.ignite.raft.jraft.disruptor.StripedDisruptor.StripeEntryHandler#onEvent}},
so we don't need to rely on
{{node.getOptions().getRaftOptions().getApplyBatch()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14292) Change permissions required to create/destroy caches in GridRestProcessor
[
https://issues.apache.org/jira/browse/IGNITE-14292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425050#comment-17425050
]
Dmitry Pavlov commented on IGNITE-14292:
Folks, what is the fix version for the ticket? Is it 2.12?
> Change permissions required to create/destroy caches in GridRestProcessor
> -
>
> Key: IGNITE-14292
> URL: https://issues.apache.org/jira/browse/IGNITE-14292
> Project: Ignite
> Issue Type: Improvement
> Components: security
>Affects Versions: 2.9.1
>Reporter: Andrey Kuznetsov
>Assignee: Sergei Ryzhov
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {{GridRestProcessor}} authorizes {{ADMIN_CACHE}} permission before cache
> creation/destruction. This is inconsistent with thin client connector
> behavior and looks counterintuitive. {{ADMIN_CACHE}} should be replaced with
> {{CACHE_CREATE}} and {{CACHE_DESTROY}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12991) Calcite integration. Introduce running query registry & cancellation refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-12991:
--
Component/s: sql
> Calcite integration. Introduce running query registry & cancellation
> refactoring
>
>
> Key: IGNITE-12991
> URL: https://issues.apache.org/jira/browse/IGNITE-12991
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Igor Seliverstov
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, sql
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Users should have the ability to cancel a query on planning or execution
> stages.
> Firstly we should have API to retrieve the identifier of the query and API to
> cancel a query by the identifier.
> For cancel planning see {{AbstractRelOptPlanner.java:91}}, here
> {{CancelFlag}} is used to cancel planning loop. We need to pass it into a
> newly created context and bind its state with {{PlanningContext#queryCancel}}
> to break possible infinite planning loop. See also {{PlanningContext#unwrap}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14681) Calcite engine. Extend return type of sum() aggregate function
[
https://issues.apache.org/jira/browse/IGNITE-14681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14681:
--
Component/s: sql
> Calcite engine. Extend return type of sum() aggregate function
> --
>
> Key: IGNITE-14681
> URL: https://issues.apache.org/jira/browse/IGNITE-14681
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, {{sum()}} aggregate function returns the same type as an argument
> and there can be an overflow.
> For example, query:
> {noformat}
> SELECT SUM(i::SMALLINT) FROM (SELECT 32000 as i UNION ALL SELECT
> 32000){noformat}
> Returns {{-1536}}.
> or
> {noformat}
> CREATE TABLE integers(i INTEGER);
> INSERT INTO integers SELECT * FROM table(system_range(0, 999, 1));
> SELECT SUM(b) FROM bigints
> {noformat}
> Returns {{499500}} instead of {{4611686018427388403500}}.
> Perhaps it would be better to return an extended type as some other vendors
> do.
> For example, PostgreSQL returns {{bigint}} for {{smallint}} or {{int}}
> arguments, {{numeric}} for {{bigint}} arguments, {{double precision}} for
> floating-point arguments. MySQL returns a {{DECIMAL}} value for exact-value
> arguments ({{INTEGER}} or {{DECIMAL}}), and a {{DOUBLE}} value for
> approximate-value arguments ({{FLOAT}} or {{DOUBLE}})
> Affected tests:
> {{modules/calcite/src/test/sql/aggregate/aggregates/test_sum.test_ignore}}
> Result type of SUM:
> || Argument type || SUM type ||
> | TINYINT
> SMALLINT
> INTEGER | BIGINT |
> | REAL
> FLOAT
> DOUBLE | DOUBLE |
> | BIGINT
> DECIMAL | DECIMAL |
> | other *type* | the same *type* |
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-15323) Calcite engine. Query lifecycle refactoting
[
https://issues.apache.org/jira/browse/IGNITE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-15323.
---
Resolution: Duplicate
> Calcite engine. Query lifecycle refactoting
> ---
>
> Key: IGNITE-15323
> URL: https://issues.apache.org/jira/browse/IGNITE-15323
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Motivation and goals:
> - introduce a {{Query}} abstraction to track a query on all phases: planning,
> mapping, execution;
> - use one place to query management
> - try to make query phases more isolated, e.g.. now {{PlanningContext}}
> contains AffinityTopologyVersion and node IDs. It looks like this information
> has nothing to do with the query planning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12991) Calcite integration. Introduce running query registry & cancellation refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-12991:
--
Summary: Calcite integration. Introduce running query registry &
cancellation refactoring (was: Calcite integration. Query registry &
cancellation refactoring)
> Calcite integration. Introduce running query registry & cancellation
> refactoring
>
>
> Key: IGNITE-12991
> URL: https://issues.apache.org/jira/browse/IGNITE-12991
> Project: Ignite
> Issue Type: Improvement
>Reporter: Igor Seliverstov
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, sql
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Users should have the ability to cancel a query on planning or execution
> stages.
> Firstly we should have API to retrieve the identifier of the query and API to
> cancel a query by the identifier.
> For cancel planning see {{AbstractRelOptPlanner.java:91}}, here
> {{CancelFlag}} is used to cancel planning loop. We need to pass it into a
> newly created context and bind its state with {{PlanningContext#queryCancel}}
> to break possible infinite planning loop. See also {{PlanningContext#unwrap}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15695) The GridCommandHandlerIndexForceRebuildTest fails if the count of available processors is less or equal to 4
[
https://issues.apache.org/jira/browse/IGNITE-15695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15695:
-
Summary: The GridCommandHandlerIndexForceRebuildTest fails if the count of
available processors is less or equal to 4 (was:
GridCommandHandlerIndexForceRebuildTest fails if availableProcessors<=4)
> The GridCommandHandlerIndexForceRebuildTest fails if the count of available
> processors is less or equal to 4
>
>
> Key: IGNITE-15695
> URL: https://issues.apache.org/jira/browse/IGNITE-15695
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
>
> The {{BuildIndexThreadPoolSize}} value will be 1 if the count of available
> processors is less or equal to 4.
> Test expect at least 2 thread: one thread is blocked by {{blockRebuildIdx}}
> logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15695) GridCommandHandlerIndexForceRebuildTest fails if availableProcessors<=4
Amelchev Nikita created IGNITE-15695:
Summary: GridCommandHandlerIndexForceRebuildTest fails if
availableProcessors<=4
Key: IGNITE-15695
URL: https://issues.apache.org/jira/browse/IGNITE-15695
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The {{BuildIndexThreadPoolSize}} value will be 1 if the count of available
processors is less or equal to 4.
Test expect at least 2 thread: one thread is blocked by {{blockRebuildIdx}}
logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15379) Thin 3.0: Add example for Table API and KeyValueBinaryView
[ https://issues.apache.org/jira/browse/IGNITE-15379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425024#comment-17425024 ] Pavel Tupitsyn commented on IGNITE-15379: - [~isapego] please see a couple comments on GitHub. > Thin 3.0: Add example for Table API and KeyValueBinaryView > -- > > Key: IGNITE-15379 > URL: https://issues.apache.org/jira/browse/IGNITE-15379 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha2 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to create example for Table and KeyValueBinaryView API for thin > client. The example scenarios can be copied from > org.apache.ignite.example.table.TableExample and > org.apache.ignite.example.table.KeyValueBinaryViewExample -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15694) Document building ODBC driver using cmake, remove Visual Studio building sections
[ https://issues.apache.org/jira/browse/IGNITE-15694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-15694: - Ignite Flags: (was: Docs Required,Release Notes Required) > Document building ODBC driver using cmake, remove Visual Studio building > sections > - > > Key: IGNITE-15694 > URL: https://issues.apache.org/jira/browse/IGNITE-15694 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Ivan Daschinsky >Priority: Major > Fix For: 2.12 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15694) Document building ODBC driver using cmake, remove Visual Studio building sections
[ https://issues.apache.org/jira/browse/IGNITE-15694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-15694: - Fix Version/s: 2.12 > Document building ODBC driver using cmake, remove Visual Studio building > sections > - > > Key: IGNITE-15694 > URL: https://issues.apache.org/jira/browse/IGNITE-15694 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Ivan Daschinsky >Priority: Major > Fix For: 2.12 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12991) Calcite integration. Query registry & cancellation refactoring
[
https://issues.apache.org/jira/browse/IGNITE-12991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-12991:
--
Summary: Calcite integration. Query registry & cancellation refactoring
(was: Calcite integration. Query Cancellation)
> Calcite integration. Query registry & cancellation refactoring
> --
>
> Key: IGNITE-12991
> URL: https://issues.apache.org/jira/browse/IGNITE-12991
> Project: Ignite
> Issue Type: Improvement
>Reporter: Igor Seliverstov
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, sql
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Users should have the ability to cancel a query on planning or execution
> stages.
> Firstly we should have API to retrieve the identifier of the query and API to
> cancel a query by the identifier.
> For cancel planning see {{AbstractRelOptPlanner.java:91}}, here
> {{CancelFlag}} is used to cancel planning loop. We need to pass it into a
> newly created context and bind its state with {{PlanningContext#queryCancel}}
> to break possible infinite planning loop. See also {{PlanningContext#unwrap}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425013#comment-17425013 ] Stanislav Lukyanov commented on IGNITE-15688: - None of the blockers could've been caused by this patch. > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
// Getting proxy context.
ServiceProxyContext ctx = ServiceProxyContext.current();
// Reading attributes.
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
// Getting proxy context.
ServiceProxyContext ctx = ServiceProxyContext.current();
// Reading attributes.
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
// Getting proxy context.
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
// Getting proxy context.
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
// Getting proxy context.
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
// Getting proxy context.
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
[jira] [Created] (IGNITE-15694) Document building ODBC driver using cmake, remove Visual Studio building sections
Ivan Daschinsky created IGNITE-15694: Summary: Document building ODBC driver using cmake, remove Visual Studio building sections Key: IGNITE-15694 URL: https://issues.apache.org/jira/browse/IGNITE-15694 Project: Ignite Issue Type: Task Components: documentation Reporter: Ivan Daschinsky -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[
https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky reassigned IGNITE-15693:
Assignee: Petr Ivanov
> TC: Change build ODBC installer step to utilize cmake
> -
>
> Key: IGNITE-15693
> URL: https://issues.apache.org/jira/browse/IGNITE-15693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Petr Ivanov
>Priority: Major
>
> In order to drop VC projects files, it is required to build ODBC installer in
> release step using cmake. Since IGNITE-15678 have been implemented, it is now
> possible to build installer using cmake only.
> Building installer using cmake (WIX toolset's {{candle.exe}} and
> {{light.exe}} should be in {{%Path%}}):
> * 32-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
> $ mkdir cmake-build-release-32
> $ cd cmake-build-release-32
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\x86\bin}}
> * 64-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
> $ mkdir cmake-build-release-64
> $ cd cmake-build-release-64
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\amd64\bin}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[
https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15693:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> TC: Change build ODBC installer step to utilize cmake
> -
>
> Key: IGNITE-15693
> URL: https://issues.apache.org/jira/browse/IGNITE-15693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Assignee: Petr Ivanov
>Priority: Major
>
> In order to drop VC projects files, it is required to build ODBC installer in
> release step using cmake. Since IGNITE-15678 have been implemented, it is now
> possible to build installer using cmake only.
> Building installer using cmake (WIX toolset's {{candle.exe}} and
> {{light.exe}} should be in {{%Path%}}):
> * 32-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
> $ mkdir cmake-build-release-32
> $ cd cmake-build-release-32
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\x86\bin}}
> * 64-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
> $ mkdir cmake-build-release-64
> $ cd cmake-build-release-64
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\amd64\bin}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[
https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15693:
-
Description:
In order to drop VC projects files, it is required to build ODBC installer in
release step using cmake. Since IGNITE-15678 have been implemented, it is now
possible to build installer using cmake only.
Building installer using cmake (WIX toolset's {{candle.exe}} and {{light.exe}}
should be in {{%Path%}}):
* 32-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
$ mkdir cmake-build-release-32
$ cd cmake-build-release-32
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\x86\bin}}
* 64-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
$ mkdir cmake-build-release-64
$ cd cmake-build-release-64
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\amd64\bin}}
was:
In order to drop VC projects files, it is required to build ODBC installer in
release step using cmake. Since IGNITE-15678 have been implemented, it is now
possible to build installer using cmake only.
Building installer using cmake (WIX tollset's {{candle.exe}} and {{light.exe}}
should be in {{%Path%}}):
* 32-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
$ mkdir cmake-build-release-32
$ cd cmake-build-release-32
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\x86\bin}}
* 64-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
$ mkdir cmake-build-release-64
$ cd cmake-build-release-64
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\amd64\bin}}
> TC: Change build ODBC installer step to utilize cmake
> -
>
> Key: IGNITE-15693
> URL: https://issues.apache.org/jira/browse/IGNITE-15693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Priority: Major
>
> In order to drop VC projects files, it is required to build ODBC installer in
> release step using cmake. Since IGNITE-15678 have been implemented, it is now
> possible to build installer using cmake only.
> Building installer using cmake (WIX toolset's {{candle.exe}} and
> {{light.exe}} should be in {{%Path%}}):
> * 32-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
> $ mkdir cmake-build-release-32
> $ cd cmake-build-release-32
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\x86\bin}}
> * 64-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
> $ mkdir cmake-build-release-64
> $ cd cmake-build-release-64
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\amd64\bin}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[
https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15693:
-
Description:
In order to drop VC projects files, it is required to build ODBC installer in
release step using cmake. Since IGNITE-15678 have been implemented, it is now
possible to build installer using cmake only.
Building installer using cmake (WIX tollset's {{candle.exe}} and {{light.exe}}
should be in {{%Path%}}):
* 32-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
$ mkdir cmake-build-release-32
$ cd cmake-build-release-32
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\x86\bin}}
* 64-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
$ mkdir cmake-build-release-64
$ cd cmake-build-release-64
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\amd64\bin}}
was:
In order to drop VC projects files, it is required to build ODBC installer in
release step using cmake. Since IGNITE-15678 have been implemented, it is now
possible to build installer using cmake only.
Building installer using cmake:
* 32-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
$ mkdir cmake-build-release-32
$ cd cmake-build-release-32
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\x86\bin}}
* 64-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
$ mkdir cmake-build-release-64
$ cd cmake-build-release-64
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\amd64\bin}}
> TC: Change build ODBC installer step to utilize cmake
> -
>
> Key: IGNITE-15693
> URL: https://issues.apache.org/jira/browse/IGNITE-15693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Priority: Major
>
> In order to drop VC projects files, it is required to build ODBC installer in
> release step using cmake. Since IGNITE-15678 have been implemented, it is now
> possible to build installer using cmake only.
> Building installer using cmake (WIX tollset's {{candle.exe}} and
> {{light.exe}} should be in {{%Path%}}):
> * 32-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
> $ mkdir cmake-build-release-32
> $ cd cmake-build-release-32
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\x86\bin}}
> * 64-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
> $ mkdir cmake-build-release-64
> $ cd cmake-build-release-64
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\amd64\bin}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[
https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-15693:
-
Description:
In order to drop VC projects files, it is required to build ODBC installer in
release step using cmake. Since IGNITE-15678 have been implemented, it is now
possible to build installer using cmake only.
Building installer using cmake:
* 32-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
$ mkdir cmake-build-release-32
$ cd cmake-build-release-32
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\x86\bin}}
* 64-bit version
{code}
$ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
$ mkdir cmake-build-release-64
$ cd cmake-build-release-64
$ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
-DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
$ cmake --build . --target install --config Release
{code}
Installer will be located in {{C:\cpp-staging\amd64\bin}}
was:In order to drop VC projects files, it is required to build ODBC
installer in release step using cmake. Since IGNITE-15678 have been
implemented, it is now possible to build installer using cmake only.
> TC: Change build ODBC installer step to utilize cmake
> -
>
> Key: IGNITE-15693
> URL: https://issues.apache.org/jira/browse/IGNITE-15693
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Daschinsky
>Priority: Major
>
> In order to drop VC projects files, it is required to build ODBC installer in
> release step using cmake. Since IGNITE-15678 have been implemented, it is now
> possible to build installer using cmake only.
> Building installer using cmake:
> * 32-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86
> $ mkdir cmake-build-release-32
> $ cd cmake-build-release-32
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=Win32
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\x86 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\x86\bin}}
> * 64-bit version
> {code}
> $ set OPENSSL_ROOT_DIR=C:\openssl\1.1.0l\x86_64
> $ mkdir cmake-build-release-64
> $ cd cmake-build-release-64
> $ cmake -DWITH_CORE=OFF -DWITH_ODBC=ON -DWITH_ODBC_MSI=ON
> -DCMAKE_BUILD_TYPE=Release -DCMAKE_GENERATOR_PLATFORM=x64
> -DCMAKE_INSTALL_PREFIX=C:\cpp-staging\amd64 ..
> $ cmake --build . --target install --config Release
> {code}
> Installer will be located in {{C:\cpp-staging\amd64\bin}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[ https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-15693: - Description: In order to drop VC projects files, it is required to build ODBC installer in release step using cmake. Since IGNITE-15678 have been implemented, it is now possible to build installer using cmake only. (was: In order to drop VC projects files, it is required to build ODBC installer in release step using cmake. Since IGNITE-15637 have been implemented, it) > TC: Change build ODBC installer step to utilize cmake > - > > Key: IGNITE-15693 > URL: https://issues.apache.org/jira/browse/IGNITE-15693 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Priority: Major > > In order to drop VC projects files, it is required to build ODBC installer in > release step using cmake. Since IGNITE-15678 have been implemented, it is now > possible to build installer using cmake only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
[ https://issues.apache.org/jira/browse/IGNITE-15693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-15693: - Description: In order to drop VC projects files, it is required to build ODBC installer in release step using cmake. Since IGNITE-15637 have been implemented, it > TC: Change build ODBC installer step to utilize cmake > - > > Key: IGNITE-15693 > URL: https://issues.apache.org/jira/browse/IGNITE-15693 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Priority: Major > > In order to drop VC projects files, it is required to build ODBC installer in > release step using cmake. Since IGNITE-15637 have been implemented, it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15693) TC: Change build ODBC installer step to utilize cmake
Ivan Daschinsky created IGNITE-15693: Summary: TC: Change build ODBC installer step to utilize cmake Key: IGNITE-15693 URL: https://issues.apache.org/jira/browse/IGNITE-15693 Project: Ignite Issue Type: Improvement Reporter: Ivan Daschinsky -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15692) Implement TableManager component stop
Alexander Lapin created IGNITE-15692: Summary: Implement TableManager component stop Key: IGNITE-15692 URL: https://issues.apache.org/jira/browse/IGNITE-15692 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15673) Update Ignite dependency zookeeper
[ https://issues.apache.org/jira/browse/IGNITE-15673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-15673: --- Description: Update Ignite dependency: Zookeeper 3.5.5 to 3.5.9 (was: Update Ignite dependency: Zookeeper 3.5.5 to 3.7.0) > Update Ignite dependency zookeeper > -- > > Key: IGNITE-15673 > URL: https://issues.apache.org/jira/browse/IGNITE-15673 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: newbie > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Ignite dependency: Zookeeper 3.5.5 to 3.5.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15691) Excessive creation of threads within RocksDB
Alexander Lapin created IGNITE-15691: Summary: Excessive creation of threads within RocksDB Key: IGNITE-15691 URL: https://issues.apache.org/jira/browse/IGNITE-15691 Project: Ignite Issue Type: Improvement Reporter: Alexander Lapin Currently we have thread per partition in RocksDB that, along with other similar problems of the excessive start of threads, leads to the impossibility of creating a table with a default number of partitions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d,
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc", MyService.class,
false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc",
MyService.class, false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc",
MyService.class, false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context with two attributes.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("usr", "X").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("usr", "X").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("svc",
MyService.class, false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("svc",
MyService.class, false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("usr");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating "execution context".
Map execCtx1 = new HashMap() {{
put("user.id", 1);
put("arg1", 10);
}};
Map execCtx2 = new HashMap() {{
putAll(execCtx1);
put("arg1", 6);
}};
// Binding "execution context" to proxy invocation handler.
MyService svcProxy1 = ignite.services().serviceProxy("svc",
MyService.class, false, execCtx1, 0);
MyService svcProxy2 = ignite.services().serviceProxy("svc",
MyService.class, false, execCtx2, 0);
assert svcProxy1.multiply(2) == 20;
assert svcProxy2.multiply(2) == 12;
assert svcProxy1.divide(2) == 5;
assert svcProxy2.divide(2) == 3;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 /
[jira] [Commented] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[
https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424955#comment-17424955
]
Ignite TC Bot commented on IGNITE-15688:
{panel:title=Branch: [pull/9475/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6212651]]
* IgniteSpiTestSuite:
TcpDiscoveryPendingMessageDeliveryTest.testDeliveryAllFailedMessagesInCorrectOrder
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Control Utility (Zookeeper){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6212715]]
{color:#d04437}Cache 8{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6212684]]
* IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencySortedLocalFewKeys
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0 TIMEOUT
, Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=6212716]]
{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 0 TIMEOUT , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=6212660]]
{panel}
{panel:title=Branch: [pull/9475/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6212723buildTypeId=IgniteTests24Java8_RunAll]
> IgniteClient.close shouldn't throw Exception
>
>
> Key: IGNITE-15688
> URL: https://issues.apache.org/jira/browse/IGNITE-15688
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteClient interface currently doesn't override close() from AutoClosable.
> Because of that, it inherits `close() throws Exception` forcing all users to
> catch Exception when using IgniteClient.
>
> In fact, this shouldn't be required. `TcpIgniteClient implements
> IgniteClient` currently throws Exception but it doesn't need to - its code
> doesn't throw any checked exceptions.
>
> Proposal:
> # Add `@Overrides public void close()` with no `throws` to IgniteClient.
> # Remove `throws Exception` from `TcpIgniteClient::close`
> Note: this change is fully backwards-compatible. It is legal to narrow the
> scope of `throws` in a new version of a method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating "execution context".
Map execCtx1 = new HashMap() {{
put("user.id", 1);
put("arg1", 10);
}};
Map execCtx2 = new HashMap() {{
putAll(execCtx1);
put("arg1", 6);
}};
// Binding "execution context" to proxy invocation handler.
MyService svcProxy1 = ignite.services().serviceProxy("service",
MyService.class, false, execCtx1, 0);
MyService svcProxy2 = ignite.services().serviceProxy("service",
MyService.class, false, execCtx2, 0);
assert svcProxy1.multiply(2) == 20;
assert svcProxy2.multiply(2) == 12;
assert svcProxy1.divide(2) == 5;
assert svcProxy2.divide(2) == 3;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context.
ServiceProxyContext ctx1 =
new ServiceProxyContextBuilder("arg1", 10).put("userId",
"admin").build();
ServiceProxyContext ctx2 =
new ServiceProxyContextBuilder("arg1", 6).put("userId",
"admin").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
> Ability to set custom execution context for Ignite service.
>
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating "execution context".
Map execCtx1 = new HashMap() {{
put("user.id", 1);
put("arg1", 10);
}};
Map execCtx2 = new HashMap() {{
putAll(execCtx1);
put("arg1", 6);
}};
// Binding "execution context" to proxy invocation handler.
MyService svcProxy1 = ignite.services().serviceProxy("svc",
MyService.class, false, execCtx1, 0);
MyService svcProxy2 = ignite.services().serviceProxy("svc",
MyService.class, false, execCtx2, 0);
assert svcProxy1.multiply(2) == 20;
assert svcProxy2.multiply(2) == 12;
assert svcProxy1.divide(2) == 5;
assert svcProxy2.divide(2) == 3;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating "execution context".
Map execCtx1 = new HashMap() {{
put("user.id", 1);
put("arg1", 10);
}};
Map execCtx2 = new HashMap() {{
putAll(execCtx1);
put("arg1", 6);
}};
// Binding "execution context" to proxy invocation handler.
MyService svcProxy1 = ignite.services().serviceProxy("service",
MyService.class, false, execCtx1, 0);
MyService svcProxy2 = ignite.services().serviceProxy("service",
MyService.class, false, execCtx2, 0);
assert svcProxy1.multiply(2) == 20;
assert svcProxy2.multiply(2) == 12;
assert svcProxy1.divide(2) == 5;
assert svcProxy2.divide(2) == 3;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
> Ability to set custom execution context for Ignite service.
> ---
>
> Key: IGNITE-15572
> URL: https://issues.apache.org/jira/browse/IGNITE-15572
> Project: Ignite
>
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context.
ServiceProxyContext ctx1 =
new ServiceProxyContextBuilder("arg1", 10).put("userId",
"admin").build();
ServiceProxyContext ctx2 =
new ServiceProxyContextBuilder("arg1", 6).put("userId",
"admin").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("userId", "admin").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("userId", "admin").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
[jira] [Updated] (IGNITE-15572) Ability to set custom execution context for Ignite service.
[
https://issues.apache.org/jira/browse/IGNITE-15572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-15572:
--
Description:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating service proxy invocation context.
ServiceProxyContext ctx1 = new ServiceProxyContextBuilder("arg1",
10).put("userId", "admin").build();
ServiceProxyContext ctx2 = new ServiceProxyContextBuilder("arg1",
6).put("userId", "admin").build();
// Binding "execution context" to proxy invocation handler.
MyService proxy1 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx1, 0);
MyService proxy2 = ignite.services().serviceProxy("myservice",
MyService.class, false, ctx2, 0);
// Invoke service methods with argument "10".
assert proxy1.multiply(2) == 10 * 2;
assert proxy1.divide(2) == 10 / 2;
// Invoke service methods with argument "6".
assert proxy2.multiply(2) == 6 * 2;
assert proxy2.divide(2) == 6 / 2;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
@Override public int multiply(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
ServiceProxyContext ctx = ServiceProxyContext.current();
int arg1 = ctx.attribute("arg1");
String userId = ctx.attribute("userId");
log.info(String.format("user=%s, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
was:
In traditional microservices, we have the ability to set a custom execution
context.
For example, a REST service may obtain the session ID from the request. We can
say that each client request, in this case, has a set of explicit and implicit
parameters. One of the implicit parameters is a session identifier that can be
passed to the service using request headers.
It would be nice to have a similar feature in Ignite services.
The basic idea behind the implementation:
1. Allow the user to bind the "execution context" to the service proxy object.
2. Pass this context as an additional implicit parameter each time the user
service method is called.
Sample code for using "execution context".
{code:java}
// Creating "execution context".
Map execCtx1 = new HashMap() {{
put("user.id", 1);
put("arg1", 10);
}};
Map execCtx2 = new HashMap() {{
putAll(execCtx1);
put("arg1", 6);
}};
// Binding "execution context" to proxy invocation handler.
MyService svcProxy1 = ignite.services().serviceProxy("myservice",
MyService.class, false, execCtx1, 0);
MyService svcProxy2 = ignite.services().serviceProxy("myservice",
MyService.class, false, execCtx2, 0);
assert svcProxy1.multiply(2) == 20;
assert svcProxy2.multiply(2) == 12;
assert svcProxy1.divide(2) == 5;
assert svcProxy2.divide(2) == 3;
...
{code}
Sample code for reading "execution context".
{code:java}
class MyServiceImpl implements MyService {
@LoggerResource
private IgniteLogger log;
private ServiceContext ctx;
@Override public void init(ServiceContext ctx) throws Exception {
this.ctx = (ServiceContextImpl)ctx;
}
@Override public int multiply(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"multiply", arg1, arg2));
return arg1 * arg2;
}
@Override public int divide(int arg2) {
int arg1 = ctx.attribute("arg1");
int userId = ctx.attribute("user.id");
log.info(String.format("user=%d, oper=%s, a=%d, b=%d", userId,
"divide", arg1, arg2));
return arg1 / arg2;
}
...
}
{code}
> Ability to set custom execution context for Ignite service.
>
[jira] [Commented] (IGNITE-15594) Calcite. ArrayIndexOutOfBoundsException with left outer join on subquery.
[
https://issues.apache.org/jira/browse/IGNITE-15594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424936#comment-17424936
]
Evgeny Stanilovsky commented on IGNITE-15594:
-
seems that calcite has the same problem, fill the ticket
https://issues.apache.org/jira/browse/CALCITE-4833
> Calcite. ArrayIndexOutOfBoundsException with left outer join on subquery.
> -
>
> Key: IGNITE-15594
> URL: https://issues.apache.org/jira/browse/IGNITE-15594
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> {noformat}
> # left outer join on subquery only involving RHS works
> query TT
> SELECT * FROM integers s1 LEFT OUTER JOIN integers s2 ON s1.i=s2.i AND
> (SELECT CASE WHEN s2.i>2 THEN TRUE ELSE FALSE END) ORDER BY s1.i NULLS FIRST;
>
> NULL NULL
> 1 NULL
> 2 NULL
> 3 3
> statement ok
> CREATE TABLE tbl(a TINYINT, b SMALLINT, c INTEGER, d BIGINT, e VARCHAR, f
> DATE, g TIMESTAMP)
> statement ok
> INSERT INTO tbl VALUES (1, 2, 3, 4, '5', DATE '1992-01-01', TIMESTAMP
> '1992-01-01 00:00:00')
> query TT
> SELECT * FROM tbl t1 LEFT JOIN tbl t2 ON (SELECT t2.a)<100
>
> 1 2 3 4 5 1992-01-01 1992-01-01 00:00:00
> 1 2 3 4 5 1992-01-01 1992-01-01 00:00:0
> {noformat}
> {noformat}
> /subquery/scalar/test_complex_correlated_subquery.test[_ignore]
> /subquery/scalar/test_complex_nested_correlated_subquery.test[_ignore]
> {noformat}
> {noformat}
> [2021-09-24 14:35:07,214][WARN
> ][calciteQry-#147%srv1%][org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImplc{1}]
> Uncaught exception
> class org.apache.ignite.IgniteException: Unexpected exception
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:309)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 5
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ArrayRowHandler.get(ArrayRowHandler.java:36)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ArrayRowHandler.get(ArrayRowHandler.java:27)
> at SC.execute(Unknown Source)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15408) CLI: 'ignite node start' command produces NPE when optional config path is not passed
[
https://issues.apache.org/jira/browse/IGNITE-15408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15408:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> CLI: 'ignite node start' command produces NPE when optional config path is
> not passed
> -
>
> Key: IGNITE-15408
> URL: https://issues.apache.org/jira/browse/IGNITE-15408
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: ignite-3
>
> CLI command {{ignite node start}} produces {{NullPointerException}} in case
> when optional {{--config=}} parameter is not passed.
> *Steps to reproduce:*
> 1. {{ignite init}}
> 2. {{ignite node start prb-node}}
> *Result:*
> {noformat}
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
> -Djava.net.preferIPv4Stack=true
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
> details.
> Starting a new Ignite node...
> Can't start the node. Read logs for details:
> /ignite-log/prb-node.log
> {noformat}
> *Log:*
> {noformat}
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
> -Djava.net.preferIPv4Stack=true
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> {noformat}
> *Expected behavior:*
> Node should be started with some defaults or {{--config}} parameter must be
> mandatory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-15408) CLI: 'ignite node start' command produces NPE when optional config path is not passed
[
https://issues.apache.org/jira/browse/IGNITE-15408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-15408.
--
Resolution: Duplicate
> CLI: 'ignite node start' command produces NPE when optional config path is
> not passed
> -
>
> Key: IGNITE-15408
> URL: https://issues.apache.org/jira/browse/IGNITE-15408
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: ignite-3
>
> CLI command {{ignite node start}} produces {{NullPointerException}} in case
> when optional {{--config=}} parameter is not passed.
> *Steps to reproduce:*
> 1. {{ignite init}}
> 2. {{ignite node start prb-node}}
> *Result:*
> {noformat}
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
> -Djava.net.preferIPv4Stack=true
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
> details.
> Starting a new Ignite node...
> Can't start the node. Read logs for details:
> /ignite-log/prb-node.log
> {noformat}
> *Log:*
> {noformat}
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
> -Djava.net.preferIPv4Stack=true
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> {noformat}
> *Expected behavior:*
> Node should be started with some defaults or {{--config}} parameter must be
> mandatory.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-15683) CLI tool says 'Can't start the node' even though the node is successfully started
[
https://issues.apache.org/jira/browse/IGNITE-15683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424921#comment-17424921
]
Vyacheslav Koptilin edited comment on IGNITE-15683 at 10/6/21, 10:47 AM:
-
Duplicates IGNITE-15538 (The proposed fix was already applied under
IGNITE-15538)
was (Author: slava.koptilin):
Duplicates IGNITE-15538
> CLI tool says 'Can't start the node' even though the node is successfully
> started
> -
>
> Key: IGNITE-15683
> URL: https://issues.apache.org/jira/browse/IGNITE-15683
> Project: Ignite
> Issue Type: Bug
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha3
>
>
> {{ignite node start}} command fails with the following message even though
> the node actually starts:
> {code}
> Starting a new Ignite node...
> Can't start the node. Read logs for details:
> /Users/vkulichenko/GridGain/ignite-3/target/apache-ignite-3.0.0-alpha3/ignite-log/node-1.log
> {code}
> Looks like this happens because there is the following line in the log:
> {noformat}
> Oct 05, 2021 3:41:45 PM org.apache.ignite.lang.IgniteLogger
> logInternalExceptional
> {noformat}
> The tool treats it as a failure because of this condition (see
> {{NodeManager}} class):
> {code}
> else if (content.contains("Exception"))
> throw new IgniteCLIException("Can't start the node. Read logs for
> details: " + file);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15690) Add a collective metric to log by caches for entries which are removed by expiry policy for time interval.
Konstantin Sirotkin created IGNITE-15690: Summary: Add a collective metric to log by caches for entries which are removed by expiry policy for time interval. Key: IGNITE-15690 URL: https://issues.apache.org/jira/browse/IGNITE-15690 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.11 Reporter: Konstantin Sirotkin Assignee: Konstantin Sirotkin Within the task [IGNITE-13810 |https://issues.apache.org/jira/browse/IGNITE-13810 ] was appended additional info to log about which expiry policy is applied for cache. Need to add a collective metric to log by caches for entries which are removed by expiry policy for time interval. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13810) Append additional log and metrics info regarding cache expiration.
[ https://issues.apache.org/jira/browse/IGNITE-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424918#comment-17424918 ] Evgeny Stanilovsky commented on IGNITE-13810: - [~ksirotkin] Thanks for your effort, merged under sha: 312c5c69f3045855b708fb99f901458 > Append additional log and metrics info regarding cache expiration. > --- > > Key: IGNITE-13810 > URL: https://issues.apache.org/jira/browse/IGNITE-13810 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.9 >Reporter: Evgeny Stanilovsky >Assignee: Konstantin Sirotkin >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Currently we have no any additional information regarding > _cache.withExpiryPolicy_ execution. Additionally it would be very useful to > have a corresponding metric. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15538) Starting node via CLI can lead to NullPointerException
[
https://issues.apache.org/jira/browse/IGNITE-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424915#comment-17424915
]
Vyacheslav Koptilin commented on IGNITE-15538:
--
Hi [~maliev],
Your comment makes sense to me. I updated the PR in accordance with it.
> Starting node via CLI can lead to NullPointerException
> --
>
> Key: IGNITE-15538
> URL: https://issues.apache.org/jira/browse/IGNITE-15538
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Gusakov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Trying to start a new node via CLI without specifying metastorage raft group
> may lead to the following exception:
> {code:java}
> Exception in thread "main" class org.apache.ignite.lang.IgniteException:
> Unable to start node=[new1].
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
> at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
> at
> org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
> at
> org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
> {code}
> The root cause is the fact we a trying to start RaftGroupServiceImpl with an
> empty list of peers, which leads to this NullPointerException when
> refsreshLeader request is issued. This behavior is fixed by IGNITE-15027
> (well, it is a work-around until IGNITE-14414 is implemented).
>
> Also, trying to start a new node without a configuration file (which is
> optional) results in NullPointerException:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> {code}
> The reason for this exception is the following code:
> {code:java|title=IgniteCliRunner}
> public static void main(String[] args) throws IOException {
> ...
> ignition.start(parsedArgs.nodeName,
> parsedArgs.config.toAbsolutePath(), Path.of("work"));
> }
> {code}
> where _parsedArgs.config_ can be _null_ just because the configuration file
> is optional. so, the fix is trivial.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15547) Accept Classes/Enums extending an Interface which is used as cache indexed field
[
https://issues.apache.org/jira/browse/IGNITE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424914#comment-17424914
]
Taras Ledkov commented on IGNITE-15547:
---
[~andrian.boscanean], the patch is OK with me.
> Accept Classes/Enums extending an Interface which is used as cache indexed
> field
>
>
> Key: IGNITE-15547
> URL: https://issues.apache.org/jira/browse/IGNITE-15547
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Andrian Boscanean
>Assignee: Andrian Boscanean
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently Classes/Enums that extend an interface which is used as Indexed
> field are not allowed.
> Example
> @QuerySqlField(index = true)
> private TestInterface testInterface;
> --
> enum TestEnum1 implements TestInterface
> { VALUE_1, VALUE_2, VALUE_3 }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424909#comment-17424909 ] Stanislav Lukyanov commented on IGNITE-15688: - [~isapego] could you please review? > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15654) Calcite engine. Fix the test HashAggregateExecutionTest#countOfEmptyWithRewind
[
https://issues.apache.org/jira/browse/IGNITE-15654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-15654:
---
Labels: calcite3-required ignite-3 (was: calcite2-required
calcite3-required ignite-3)
> Calcite engine. Fix the test HashAggregateExecutionTest#countOfEmptyWithRewind
> --
>
> Key: IGNITE-15654
> URL: https://issues.apache.org/jira/browse/IGNITE-15654
> Project: Ignite
> Issue Type: Improvement
>Reporter: Taras Ledkov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: calcite3-required, ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test {{HashAggregateExecutionTest#countOfEmptyWithRewind}} uses
> aggregates without specified groups.
> The test fails with:
> {code}
> class org.apache.ignite.IgniteException: Unexpected exception
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:309)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:68)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.ClassCastException: class [Ljava.lang.Object; cannot be
> cast to class java.lang.Comparable ([Ljava.lang.Object; and
> java.lang.Comparable are in module java.base of loader 'bootstrap')
> at
> java.base/java.util.PriorityQueue.siftUpComparable(PriorityQueue.java:659)
> at java.base/java.util.PriorityQueue.siftUp(PriorityQueue.java:655)
> at java.base/java.util.PriorityQueue.offer(PriorityQueue.java:346)
> at java.base/java.util.PriorityQueue.add(PriorityQueue.java:327)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.SortNode.push(SortNode.java:92)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.flush(HashAggregateNode.java:188)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.end(HashAggregateNode.java:142)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:127)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:304)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15671) Atomic and PrimarySync doesn't make guarantees for index writes.
[ https://issues.apache.org/jira/browse/IGNITE-15671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-15671: --- Labels: IEP-71 (was: ) > Atomic and PrimarySync doesn't make guarantees for index writes. > > > Key: IGNITE-15671 > URL: https://issues.apache.org/jira/browse/IGNITE-15671 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > > Investigate this. Maybe there is a workaround, or bug. Or maybe it's possible > to provide a flag for including indexes to PrimarySync. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15647) -e parameter of sqlline command does not work properly
[
https://issues.apache.org/jira/browse/IGNITE-15647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424904#comment-17424904
]
Yury Gerzhedovich commented on IGNITE-15647:
[~ilyak], I see you are an assignee here. Are you working on the ticket?
> -e parameter of sqlline command does not work properly
> --
>
> Key: IGNITE-15647
> URL: https://issues.apache.org/jira/browse/IGNITE-15647
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
> Environment: CentOS7.8.2003
>Reporter: Anton Kondratev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.12
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> SQL query specified in -e parameter of sqlline command does not get parsed
> properly and therefore not executed.
> I'm trying to use it like this:
> {code:java}
> ./sqlline.sh -u jdbc:ignite:thin://1.2.3.4 -n login -p password -e 'select *
> from \"sys\".\"tables\";'{code}
> and output is:
> {code:java}
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> include (Is a directory)
> Property "url" is required
> Property "url" is required
> from (No such file or directory)
> \"sys\".\"tables\"; (No such file or directory)
> Error: Failed to parse query. Syntax error in SQL statement "SELECT [*]";
> expected "TOP, LIMIT, DISTINCT, ALL, *, NOT, EXISTS, INTERSECTS"; SQL
> statement:
> select [42001-197] (state=42000,code=1001)
> java.sql.SQLException: Failed to parse query. Syntax error in SQL statement
> "SELECT [*]"; expected "TOP, LIMIT, DISTINCT, ALL, *, NOT, EXISTS,
> INTERSECTS"; SQL statement:
> select [42001-197]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
> at sqlline.Commands.executeSingleQuery(Commands.java:1054)
> at sqlline.Commands.execute(Commands.java:1003)
> at sqlline.Commands.sql(Commands.java:967)
> at sqlline.SqlLine.dispatch(SqlLine.java:734)
> at sqlline.SqlLine.initArgs(SqlLine.java:449)
> at sqlline.SqlLine.begin(SqlLine.java:515)
> at sqlline.SqlLine.start(SqlLine.java:267)
> at sqlline.SqlLine.main(SqlLine.java:206)
> sqlline version 1.9.0{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15689) Create a method that allow to pass not only file as a startup configuration
[
https://issues.apache.org/jira/browse/IGNITE-15689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15689:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Create a method that allow to pass not only file as a startup configuration
> ---
>
> Key: IGNITE-15689
> URL: https://issues.apache.org/jira/browse/IGNITE-15689
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> We have methods which get a configuration as a string or a path, but it does
> not allow to pass a resource or any stream.
> {code}
> IgnitionManager#start(String, Path, Path, ClassLoader)
> IgnitionManager#start(String, String, Path)
> {code}
> I think, methods which get URI or InputStream are required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15638) BinaryObjectBuilder build() causes java.lang.StackOverflowError
[
https://issues.apache.org/jira/browse/IGNITE-15638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424903#comment-17424903
]
Yury Gerzhedovich commented on IGNITE-15638:
[~assens], could you please provide a full reproducer.
> BinaryObjectBuilder build() causes java.lang.StackOverflowError
> ---
>
> Key: IGNITE-15638
> URL: https://issues.apache.org/jira/browse/IGNITE-15638
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.11
>Reporter: Assen Sharlandjiev
>Priority: Major
>
> The following code causes java.lang.StackOverflowError.
> {code:java}
> final var value = (BinaryObjectImpl) entry.getValue();
> final var builder = value.toBuilder();
> final var binaryObject = builder.build();
> {code}
> below is the stack trace:
> {noformat}
> java.lang.StackOverflowError: null
> at java.base/java.lang.Class.isArray(Native Method) ~[na:na]
> at java.base/java.lang.Class.getComponentType(Class.java:1227) ~[na:na]
> at
> java.base/jdk.internal.misc.Unsafe.checkPrimitiveArray(Unsafe.java:558)
> ~[na:na]
> at
> java.base/jdk.internal.misc.Unsafe.checkPrimitivePointer(Unsafe.java:579)
> ~[na:na]
> at java.base/jdk.internal.misc.Unsafe.copyMemoryChecks(Unsafe.java:832)
> ~[na:na]
> at java.base/jdk.internal.misc.Unsafe.copyMemory(Unsafe.java:800)
> ~[na:na]
> at jdk.unsupported/sun.misc.Unsafe.copyMemory(Unsafe.java:573) ~[na:na]
> at
> org.apache.ignite.internal.util.GridUnsafe.copyMemory(GridUnsafe.java:1312)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.copyAndShift(BinaryHeapOutputStream.java:96)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.write(BinaryAbstractOutputStream.java:233)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.BinaryWriterExImpl.write(BinaryWriterExImpl.java:401)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryPlainLazyValue.writeTo(BinaryPlainLazyValue.java:47)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryLazyMap.writeTo(BinaryLazyMap.java:99)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryLazyMap.writeTo(BinaryLazyMap.java:100)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:73)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryBuilderSerializer.writeValue(BinaryBuilderSerializer.java:54)
> ~[ignite-core-2.11.0.jar:2.11.0]
> at
> org.apache.ignite.internal.binary.builder.BinaryLazyMap.writeTo(BinaryLazyMap.java:100)
> ~[ignite-core-2.11.0.jar:2.11.0]
> .
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15688: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov reassigned IGNITE-15688: --- Assignee: Stanislav Lukyanov > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15538) Starting node via CLI can lead to NullPointerException
[
https://issues.apache.org/jira/browse/IGNITE-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15538:
-
Description:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
The reason for this exception is the following code:
{code:java|title=IgniteCliRunner}
public static void main(String[] args) throws IOException {
...
ignition.start(parsedArgs.nodeName, parsedArgs.config.toAbsolutePath(),
Path.of("work"));
}
{code}
where parsedArgs.config can be null just because the configuration file is
optional. so, the fix is trivial.
was:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
> Starting node via CLI can lead to NullPointerException
> --
>
> Key: IGNITE-15538
> URL: https://issues.apache.org/jira/browse/IGNITE-15538
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Gusakov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to start a new node via CLI without specifying metastorage raft group
> may lead to the following exception:
>
[jira] [Updated] (IGNITE-15538) Starting node via CLI can lead to NullPointerException
[
https://issues.apache.org/jira/browse/IGNITE-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15538:
-
Description:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
The reason for this exception is the following code:
{code:java|title=IgniteCliRunner}
public static void main(String[] args) throws IOException {
...
ignition.start(parsedArgs.nodeName, parsedArgs.config.toAbsolutePath(),
Path.of("work"));
}
{code}
where _parsedArgs.config_ can be _null _just because the configuration file is
optional. so, the fix is trivial.
was:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
The reason for this exception is the following code:
{code:java|title=IgniteCliRunner}
public static void main(String[] args) throws IOException {
...
ignition.start(parsedArgs.nodeName, parsedArgs.config.toAbsolutePath(),
Path.of("work"));
}
{code}
where parsedArgs.config can be null just because the configuration file is
optional. so, the fix is trivial.
> Starting node via CLI can lead to NullPointerException
> --
>
> Key: IGNITE-15538
> URL: https://issues.apache.org/jira/browse/IGNITE-15538
> Project:
[jira] [Updated] (IGNITE-15538) Starting node via CLI can lead to NullPointerException
[
https://issues.apache.org/jira/browse/IGNITE-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15538:
-
Description:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
The reason for this exception is the following code:
{code:java|title=IgniteCliRunner}
public static void main(String[] args) throws IOException {
...
ignition.start(parsedArgs.nodeName, parsedArgs.config.toAbsolutePath(),
Path.of("work"));
}
{code}
where _parsedArgs.config_ can be _null_ just because the configuration file is
optional. so, the fix is trivial.
was:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
The reason for this exception is the following code:
{code:java|title=IgniteCliRunner}
public static void main(String[] args) throws IOException {
...
ignition.start(parsedArgs.nodeName, parsedArgs.config.toAbsolutePath(),
Path.of("work"));
}
{code}
where _parsedArgs.config_ can be _null _just because the configuration file is
optional. so, the fix is trivial.
> Starting node via CLI can lead to NullPointerException
> --
>
> Key: IGNITE-15538
> URL: https://issues.apache.org/jira/browse/IGNITE-15538
>
[jira] [Updated] (IGNITE-15538) Starting node via CLI can lead to NullPointerException
[
https://issues.apache.org/jira/browse/IGNITE-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15538:
-
Description:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
The root cause is the fact we a trying to start RaftGroupServiceImpl with an
empty list of peers, which leads to this NullPointerException when
refsreshLeader request is issued. This behavior is fixed by IGNITE-15027 (well,
it is a work-around until IGNITE-14414 is implemented).
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
was:
Trying to start a new node via CLI without specifying metastorage raft group
may lead to the following exception:
{code:java}
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable
to start node=[new1].
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
at
org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
at
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
Caused by: java.lang.NullPointerException
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
at
org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
at
org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
{code}
Also, trying to start a new node without a configuration file (which is
optional) results in NullPointerException:
{code:java}
Exception in thread "main" java.lang.NullPointerException
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
{code}
> Starting node via CLI can lead to NullPointerException
> --
>
> Key: IGNITE-15538
> URL: https://issues.apache.org/jira/browse/IGNITE-15538
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Gusakov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to start a new node via CLI without specifying metastorage raft group
> may lead to the following exception:
> {code:java}
> Exception in thread "main" class org.apache.ignite.lang.IgniteException:
> Unable to start node=[new1].
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
> at
>
[jira] [Created] (IGNITE-15689) Create a method that allow to pass not only file as a startup configuration
Vladislav Pyatkov created IGNITE-15689:
--
Summary: Create a method that allow to pass not only file as a
startup configuration
Key: IGNITE-15689
URL: https://issues.apache.org/jira/browse/IGNITE-15689
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
We have methods which get a configuration as a string or a path, but it does
not allow to pass a resource or any stream.
{code}
IgnitionManager#start(String, Path, Path, ClassLoader)
IgnitionManager#start(String, String, Path)
{code}
I think, methods which get URI or InputStream are required.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-15547) Accept Classes/Enums extending an Interface which is used as cache indexed field
[
https://issues.apache.org/jira/browse/IGNITE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424881#comment-17424881
]
Andrian Boscanean edited comment on IGNITE-15547 at 10/6/21, 9:45 AM:
--
[~zstan] Thank you for fast review. I am sorry for formatting misses. I fixed
what you pointed and removed boxing. Do I need to run all tests on CI?
was (Author: andrian.boscanean):
[~zstan] Thank you for fast review. I am sorry for formatting misses. I fixed
what you pointed and removed boxing.
> Accept Classes/Enums extending an Interface which is used as cache indexed
> field
>
>
> Key: IGNITE-15547
> URL: https://issues.apache.org/jira/browse/IGNITE-15547
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Andrian Boscanean
>Assignee: Andrian Boscanean
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently Classes/Enums that extend an interface which is used as Indexed
> field are not allowed.
> Example
> @QuerySqlField(index = true)
> private TestInterface testInterface;
> --
> enum TestEnum1 implements TestInterface
> { VALUE_1, VALUE_2, VALUE_3 }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15547) Accept Classes/Enums extending an Interface which is used as cache indexed field
[
https://issues.apache.org/jira/browse/IGNITE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424881#comment-17424881
]
Andrian Boscanean commented on IGNITE-15547:
[~zstan] Thank you for fast review. I am sorry for formatting misses. I fixed
what you pointed and removed boxing.
> Accept Classes/Enums extending an Interface which is used as cache indexed
> field
>
>
> Key: IGNITE-15547
> URL: https://issues.apache.org/jira/browse/IGNITE-15547
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Andrian Boscanean
>Assignee: Andrian Boscanean
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently Classes/Enums that extend an interface which is used as Indexed
> field are not allowed.
> Example
> @QuerySqlField(index = true)
> private TestInterface testInterface;
> --
> enum TestEnum1 implements TestInterface
> { VALUE_1, VALUE_2, VALUE_3 }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
[ https://issues.apache.org/jira/browse/IGNITE-15688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-15688: Description: IgniteClient interface currently doesn't override close() from AutoClosable. Because of that, it inherits `close() throws Exception` forcing all users to catch Exception when using IgniteClient. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: # Add `@Overrides public void close()` with no `throws` to IgniteClient. # Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. was: IgniteClient interfaecs currently doesn't override close() from AutoClosable. Because of that it inherits `close() throws Exception` forcing all users to catch Exception when using IgniteClient. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: # Add `@Overrides public void close()` with no `throws` to IgniteClient. # Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. > IgniteClient.close shouldn't throw Exception > > > Key: IGNITE-15688 > URL: https://issues.apache.org/jira/browse/IGNITE-15688 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Stanislav Lukyanov >Priority: Major > > IgniteClient interface currently doesn't override close() from AutoClosable. > Because of that, it inherits `close() throws Exception` forcing all users to > catch Exception when using IgniteClient. > > In fact, this shouldn't be required. `TcpIgniteClient implements > IgniteClient` currently throws Exception but it doesn't need to - its code > doesn't throw any checked exceptions. > > Proposal: > # Add `@Overrides public void close()` with no `throws` to IgniteClient. > # Remove `throws Exception` from `TcpIgniteClient::close` > Note: this change is fully backwards-compatible. It is legal to narrow the > scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15688) IgniteClient.close shouldn't throw Exception
Stanislav Lukyanov created IGNITE-15688: --- Summary: IgniteClient.close shouldn't throw Exception Key: IGNITE-15688 URL: https://issues.apache.org/jira/browse/IGNITE-15688 Project: Ignite Issue Type: Bug Components: thin client Reporter: Stanislav Lukyanov IgniteClient interfaecs currently doesn't override close() from AutoClosable. Because of that it inherits `close() throws Exception` forcing all users to catch Exception when using IgniteClient. In fact, this shouldn't be required. `TcpIgniteClient implements IgniteClient` currently throws Exception but it doesn't need to - its code doesn't throw any checked exceptions. Proposal: # Add `@Overrides public void close()` with no `throws` to IgniteClient. # Remove `throws Exception` from `TcpIgniteClient::close` Note: this change is fully backwards-compatible. It is legal to narrow the scope of `throws` in a new version of a method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15547) Accept Classes/Enums extending an Interface which is used as cache indexed field
[
https://issues.apache.org/jira/browse/IGNITE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrian Boscanean updated IGNITE-15547:
---
Summary: Accept Classes/Enums extending an Interface which is used as cache
indexed field (was: QueryTypeDescriptorImpl: Accept Classes/Enums extending an
Interface which is used as cache indexed field)
> Accept Classes/Enums extending an Interface which is used as cache indexed
> field
>
>
> Key: IGNITE-15547
> URL: https://issues.apache.org/jira/browse/IGNITE-15547
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Andrian Boscanean
>Assignee: Andrian Boscanean
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently Classes/Enums that extend an interface which is used as Indexed
> field are not allowed.
> Example
> @QuerySqlField(index = true)
> private TestInterface testInterface;
> --
> enum TestEnum1 implements TestInterface
> { VALUE_1, VALUE_2, VALUE_3 }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15538) Starting node via CLI can lead to NullPointerException
[
https://issues.apache.org/jira/browse/IGNITE-15538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424864#comment-17424864
]
Mirza Aliev commented on IGNITE-15538:
--
Hello [~slava.koptilin]! I've left a minor comment, in general, I'm ok with
changes, thank you!
> Starting node via CLI can lead to NullPointerException
> --
>
> Key: IGNITE-15538
> URL: https://issues.apache.org/jira/browse/IGNITE-15538
> Project: Ignite
> Issue Type: Bug
>Reporter: Kirill Gusakov
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Trying to start a new node via CLI without specifying metastorage raft group
> may lead to the following exception:
> {code:java}
> Exception in thread "main" class org.apache.ignite.lang.IgniteException:
> Unable to start node=[new1].
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:293)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:141)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:72)
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.sendWithRetry(RaftGroupServiceImpl.java:456)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.refreshLeader(RaftGroupServiceImpl.java:202)
> at
> org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl.start(RaftGroupServiceImpl.java:158)
> at org.apache.ignite.internal.raft.Loza.prepareRaftGroup(Loza.java:99)
> at
> org.apache.ignite.internal.metastorage.MetaStorageManager.start(MetaStorageManager.java:167)
> at
> org.apache.ignite.internal.app.IgniteImpl.doStartComponent(IgniteImpl.java:384)
> at org.apache.ignite.internal.app.IgniteImpl.start(IgniteImpl.java:278)
> {code}
> Also, trying to start a new node without a configuration file (which is
> optional) results in NullPointerException:
> {code:java}
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:59)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15547) QueryTypeDescriptorImpl: Accept Classes/Enums extending an Interface which is used as cache indexed field
[
https://issues.apache.org/jira/browse/IGNITE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424852#comment-17424852
]
Evgeny Stanilovsky commented on IGNITE-15547:
-
[~andrian.boscanean] i check your fix,
1. fill issue comment correctly, i.e. : "IGNITE-15547 Accept Classes/Enums
extending an Interface which is used as cache indexed field"
2. replace redundant :
https://github.com/apache/ignite/pull/9427/files#diff-53acab6205b01405f8cb887ffa59ff4dd8c831b38ff61e4aa3e9418cdb19cf7cR44
https://github.com/apache/ignite/pull/9427/files#diff-53acab6205b01405f8cb887ffa59ff4dd8c831b38ff61e4aa3e9418cdb19cf7cR85
new line no need
https://github.com/apache/ignite/pull/9427/files#diff-53acab6205b01405f8cb887ffa59ff4dd8c831b38ff61e4aa3e9418cdb19cf7cR111
and so on
3. If i rewrite your fix without boxing tests still be ok, thus - or append
additional tests, or remove boxing.
> QueryTypeDescriptorImpl: Accept Classes/Enums extending an Interface which is
> used as cache indexed field
> -
>
> Key: IGNITE-15547
> URL: https://issues.apache.org/jira/browse/IGNITE-15547
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Andrian Boscanean
>Assignee: Andrian Boscanean
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently Classes/Enums that extend an interface which is used as Indexed
> field are not allowed.
> Example
> @QuerySqlField(index = true)
> private TestInterface testInterface;
> --
> enum TestEnum1 implements TestInterface
> { VALUE_1, VALUE_2, VALUE_3 }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15547) QueryTypeDescriptorImpl: Accept Classes/Enums extending an Interface which is used as cache indexed field
[
https://issues.apache.org/jira/browse/IGNITE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424843#comment-17424843
]
Andrian Boscanean commented on IGNITE-15547:
Hi [~timonin.maksim]. I fixed comments on PR. Could you take a look.
Regarding performance, in our case there is no big amount of data that will use
the enums.
> QueryTypeDescriptorImpl: Accept Classes/Enums extending an Interface which is
> used as cache indexed field
> -
>
> Key: IGNITE-15547
> URL: https://issues.apache.org/jira/browse/IGNITE-15547
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Andrian Boscanean
>Assignee: Andrian Boscanean
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently Classes/Enums that extend an interface which is used as Indexed
> field are not allowed.
> Example
> @QuerySqlField(index = true)
> private TestInterface testInterface;
> --
> enum TestEnum1 implements TestInterface
> { VALUE_1, VALUE_2, VALUE_3 }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15686) TableExample and KeyValueBinaryViewExample fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424834#comment-17424834
]
Igor Sapego commented on IGNITE-15686:
--
[~v.pyatkov], looks good overall. See my comment in PR.
> TableExample and KeyValueBinaryViewExample fail with NPE
>
>
> Key: IGNITE-15686
> URL: https://issues.apache.org/jira/browse/IGNITE-15686
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> Exception in thread "main" java.util.concurrent.CompletionException: class
> org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
> at
> java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTable(TableManager.java:382)
> at
> org.apache.ignite.example.table.TableExample.main(TableExample.java:65)
> Caused by: class org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.manager.Producer.removeListener(Producer.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$10(TableManager.java:489)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1769)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1756)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.lang.IgniteInternalCheckedException:
> java.lang.NullPointerException
> ... 11 more
> Caused by: java.util.concurrent.CompletionException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1766)
> ... 6 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.configuration.schemas.table.TableNode.partitions(Unknown
> Source)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$8(TableManager.java:464)
> at
> org.apache.ignite.internal.configuration.tree.NamedListNode.create(NamedListNode.java:131)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$9(TableManager.java:452)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:88)
> at
> org.apache.ignite.configuration.schemas.table.TablesNode.construct(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.SuperRoot.construct(SuperRoot.java:137)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$1(ConfigurationChanger.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1764)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15686) TableExample and KeyValueBinaryViewExample fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15686:
---
Reviewer: Igor Sapego
> TableExample and KeyValueBinaryViewExample fail with NPE
>
>
> Key: IGNITE-15686
> URL: https://issues.apache.org/jira/browse/IGNITE-15686
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {noformat}
> Exception in thread "main" java.util.concurrent.CompletionException: class
> org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
> at
> java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTable(TableManager.java:382)
> at
> org.apache.ignite.example.table.TableExample.main(TableExample.java:65)
> Caused by: class org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.manager.Producer.removeListener(Producer.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$10(TableManager.java:489)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1769)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1756)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.lang.IgniteInternalCheckedException:
> java.lang.NullPointerException
> ... 11 more
> Caused by: java.util.concurrent.CompletionException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1766)
> ... 6 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.configuration.schemas.table.TableNode.partitions(Unknown
> Source)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$8(TableManager.java:464)
> at
> org.apache.ignite.internal.configuration.tree.NamedListNode.create(NamedListNode.java:131)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$9(TableManager.java:452)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:88)
> at
> org.apache.ignite.configuration.schemas.table.TablesNode.construct(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.SuperRoot.construct(SuperRoot.java:137)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$1(ConfigurationChanger.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1764)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15686) TableExample and KeyValueBinaryViewExample fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424832#comment-17424832
]
Vladislav Pyatkov commented on IGNITE-15686:
[~isapego] Could you please, review my patch?
> TableExample and KeyValueBinaryViewExample fail with NPE
>
>
> Key: IGNITE-15686
> URL: https://issues.apache.org/jira/browse/IGNITE-15686
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {noformat}
> Exception in thread "main" java.util.concurrent.CompletionException: class
> org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
> at
> java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTable(TableManager.java:382)
> at
> org.apache.ignite.example.table.TableExample.main(TableExample.java:65)
> Caused by: class org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.manager.Producer.removeListener(Producer.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$10(TableManager.java:489)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1769)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1756)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.lang.IgniteInternalCheckedException:
> java.lang.NullPointerException
> ... 11 more
> Caused by: java.util.concurrent.CompletionException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1766)
> ... 6 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.configuration.schemas.table.TableNode.partitions(Unknown
> Source)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$8(TableManager.java:464)
> at
> org.apache.ignite.internal.configuration.tree.NamedListNode.create(NamedListNode.java:131)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$9(TableManager.java:452)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:88)
> at
> org.apache.ignite.configuration.schemas.table.TablesNode.construct(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.SuperRoot.construct(SuperRoot.java:137)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$1(ConfigurationChanger.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1764)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15686) TableExample and KeyValueBinaryViewExample fail with NPE
[
https://issues.apache.org/jira/browse/IGNITE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-15686:
--
Assignee: Vladislav Pyatkov (was: Igor Sapego)
> TableExample and KeyValueBinaryViewExample fail with NPE
>
>
> Key: IGNITE-15686
> URL: https://issues.apache.org/jira/browse/IGNITE-15686
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {noformat}
> Exception in thread "main" java.util.concurrent.CompletionException: class
> org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:412)
> at
> java.base/java.util.concurrent.CompletableFuture.join(CompletableFuture.java:2108)
> at
> org.apache.ignite.internal.table.distributed.TableManager.createTable(TableManager.java:382)
> at
> org.apache.ignite.example.table.TableExample.main(TableExample.java:65)
> Caused by: class org.apache.ignite.internal.manager.ListenerRemovedException:
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.manager.Producer.removeListener(Producer.java:65)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$10(TableManager.java:489)
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> at
> java.base/java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1769)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1756)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> Caused by: class org.apache.ignite.lang.IgniteInternalCheckedException:
> java.lang.NullPointerException
> ... 11 more
> Caused by: java.util.concurrent.CompletionException:
> java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1766)
> ... 6 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.configuration.schemas.table.TableNode.partitions(Unknown
> Source)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$8(TableManager.java:464)
> at
> org.apache.ignite.internal.configuration.tree.NamedListNode.create(NamedListNode.java:131)
> at
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableAsync$9(TableManager.java:452)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:88)
> at
> org.apache.ignite.configuration.schemas.table.TablesNode.construct(Unknown
> Source)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.SuperRoot.construct(SuperRoot.java:137)
> at
> org.apache.ignite.internal.configuration.DynamicConfiguration$1.descend(DynamicConfiguration.java:90)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.lambda$changeInternally$1(ConfigurationChanger.java:376)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1764)
> ... 6 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-15678) CPP: Build ODBC installers using cmake
[ https://issues.apache.org/jira/browse/IGNITE-15678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky resolved IGNITE-15678. -- Resolution: Fixed [~isapego] Thanks for review, merged > CPP: Build ODBC installers using cmake > -- > > Key: IGNITE-15678 > URL: https://issues.apache.org/jira/browse/IGNITE-15678 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Fix For: 2.12 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
