[jira] [Comment Edited] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542507#comment-17542507 ] Pavel Tupitsyn edited comment on IGNITE-17038 at 5/27/22 5:38 AM: -- [~amashenkov] done. Merged to main: c52a70fa867f1df18c6259e183be00f63460d914, 0fc608aa49fac8accf25e2deca547798d44875e1 was (Author: ptupitsyn): [~amashenkov] done. Merged to main: c52a70fa867f1df18c6259e183be00f63460d914 > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17043) Performance degradation in Marshaller
[
https://issues.apache.org/jira/browse/IGNITE-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-17043:
Description:
There is a problem in ignite-core code in GridHandleTable used inside
OptimizedMarshaller where the internal buffers grow in size and does not shrink
back.
What problematic is in GridHandleTable? This is its reset() method that fills
arrays in memory. Done once, it's not a big deal. Done a million times for a
long buffer, it becomes really long and CPU-consuming.
Here is simple reproducer (omitting imports for brevity):
Marshalling of the same object at first takes about 50ms, and then after
degradation more than 100 seconds.
{code:title=DegradationReproducer.java|borderStyle=solid}
public class DegradationReproducer extends BinaryMarshallerSelfTest {
@Test
public void reproduce() throws Exception {
List> obj = IntStream.range(0,
10).mapToObj(Collections::singletonList).collect(Collectors.toList());
for (int i = 0; i < 50; i++) {
Assert.assertThat(measureMarshal(obj), Matchers.lessThan(1000L));
}
binaryMarshaller().marshal(
Collections.singletonList(IntStream.range(0,
1000_000).mapToObj(String::valueOf).collect(Collectors.toList()))
);
Assert.assertThat(measureMarshal(obj), Matchers.lessThan(1000L));
}
private long measureMarshal(List> obj) throws
IgniteCheckedException {
info("marshalling started ");
long millis = System.currentTimeMillis();
binaryMarshaller().marshal(obj);
millis = System.currentTimeMillis() - millis;
info("marshalling finished in " + millis + " ms");
return millis;
}
}
{code}
on my machine reslust is:
{quote}
.
[2022-05-26 20:58:27,178][INFO
][test-runner-#1%binary.DegradationReproducer%][root] marshalling finished in
39 ms
[2022-05-26 20:58:27,769][INFO
][test-runner-#1%binary.DegradationReproducer%][root] marshalling started
[2022-05-26 21:02:03,588][INFO
][test-runner-#1%binary.DegradationReproducer%][root] marshalling finished in
215819 ms
[2022-05-26 21:02:03,593][ERROR][main][root] Test failed
[test=DegradationReproducer#reproduce[useBinaryArrays = true], duration=218641]
java.lang.AssertionError:
Expected: a value less than <1000L>
but: <*215819L*> was greater than <1000L>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.Assert.assertThat(Assert.java:923)
at
org.apache.ignite.internal.binary.DegradationReproducer.reproduce(DegradationReproducer.java:27)
{quote}
was:
There is a problem in ignite-core code in GridHandleTable used inside
OptimizedMarshaller where the internal buffers grow in size and does not shrink
back.
SingletonList is serialized with OptimizedMarshaller by default in Ignite. In
contrast, for ArrayList serialization, BinaryMarshallerExImpl is used.
The difference between OptimizedMarshaller and BinaryMarshallerExImpl is that
when OptimizedMarshaller starts to serialize an object node, all the descedant
nodes continue to be serialized in OptimizedMarshaller using the same
GridHandleTable associated with the current thread. GridHandleTable is static
for a thread and never shrinks in size, its buffer becomes only larger in time.
BinaryMarshallerExImpl though, can divert serizliation to OptimizedMarshaller
down the road.
What problematic is in GridHandleTable? This is its reset() method that fills
arrays in memory. Done once, it's not a big deal. Done a million times for a
long buffer, it becomes really long and CPU-consuming.
Here is simple reproducer (omitting imports for brevity):
{code:title=DegradationReproducer.java|borderStyle=solid}
public class DegradationReproducer extends BinaryMarshallerSelfTest {
@Test
public void reproduce() throws Exception {
List> obj = IntStream.range(0,
10).mapToObj(Collections::singletonList).collect(Collectors.toList());
for (int i = 0; i < 50; i++) {
Assert.assertThat(measureMarshal(obj), Matchers.lessThan(1000L));
}
binaryMarshaller().marshal(
Collections.singletonList(IntStream.range(0,
1000_000).mapToObj(String::valueOf).collect(Collectors.toList()))
);
Assert.assertThat(measureMarshal(obj), Matchers.lessThan(1000L));
}
private long measureMarshal(List> obj) throws
IgniteCheckedException {
info("marshalling started ");
long millis = System.currentTimeMillis();
binaryMarshaller().marshal(obj);
millis = System.currentTimeMillis() - millis;
info("marshalling finished in " + millis + " ms");
return millis;
}
}
{code}
on my machine reslust is:
{quote}
.
[2022-05-26 20:58:27,178][INFO
][test-runner-#1%binary.DegradationReproducer%][root]
[jira] [Updated] (IGNITE-17043) Performance degradation in Marshaller
[
https://issues.apache.org/jira/browse/IGNITE-17043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kosarev updated IGNITE-17043:
Description:
There is a problem in ignite-core code in GridHandleTable used inside
OptimizedMarshaller where the internal buffers grow in size and does not shrink
back.
SingletonList is serialized with OptimizedMarshaller by default in Ignite. In
contrast, for ArrayList serialization, BinaryMarshallerExImpl is used.
The difference between OptimizedMarshaller and BinaryMarshallerExImpl is that
when OptimizedMarshaller starts to serialize an object node, all the descedant
nodes continue to be serialized in OptimizedMarshaller using the same
GridHandleTable associated with the current thread. GridHandleTable is static
for a thread and never shrinks in size, its buffer becomes only larger in time.
BinaryMarshallerExImpl though, can divert serizliation to OptimizedMarshaller
down the road.
What problematic is in GridHandleTable? This is its reset() method that fills
arrays in memory. Done once, it's not a big deal. Done a million times for a
long buffer, it becomes really long and CPU-consuming.
Here is simple reproducer (omitting imports for brevity):
{code:title=DegradationReproducer.java|borderStyle=solid}
public class DegradationReproducer extends BinaryMarshallerSelfTest {
@Test
public void reproduce() throws Exception {
List> obj = IntStream.range(0,
10).mapToObj(Collections::singletonList).collect(Collectors.toList());
for (int i = 0; i < 50; i++) {
Assert.assertThat(measureMarshal(obj), Matchers.lessThan(1000L));
}
binaryMarshaller().marshal(
Collections.singletonList(IntStream.range(0,
1000_000).mapToObj(String::valueOf).collect(Collectors.toList()))
);
Assert.assertThat(measureMarshal(obj), Matchers.lessThan(1000L));
}
private long measureMarshal(List> obj) throws
IgniteCheckedException {
info("marshalling started ");
long millis = System.currentTimeMillis();
binaryMarshaller().marshal(obj);
millis = System.currentTimeMillis() - millis;
info("marshalling finished in " + millis + " ms");
return millis;
}
}
{code}
on my machine reslust is:
{quote}
.
[2022-05-26 20:58:27,178][INFO
][test-runner-#1%binary.DegradationReproducer%][root] marshalling finished in
39 ms
[2022-05-26 20:58:27,769][INFO
][test-runner-#1%binary.DegradationReproducer%][root] marshalling started
[2022-05-26 21:02:03,588][INFO
][test-runner-#1%binary.DegradationReproducer%][root] marshalling finished in
215819 ms
[2022-05-26 21:02:03,593][ERROR][main][root] Test failed
[test=DegradationReproducer#reproduce[useBinaryArrays = true], duration=218641]
java.lang.AssertionError:
Expected: a value less than <1000L>
but: <215819L> was greater than <1000L>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.Assert.assertThat(Assert.java:923)
at
org.apache.ignite.internal.binary.DegradationReproducer.reproduce(DegradationReproducer.java:27)
{quote}
was:
There is a problem in ignite-core code in GridHandleTable used inside
OptimizedMarshaller where the internal buffers grow in size and does not shrink
back.
SingletonList is serialized with OptimizedMarshaller by default in Ignite. In
contrast, for ArrayList serialization, BinaryMarshallerExImpl is used.
The difference between OptimizedMarshaller and BinaryMarshallerExImpl is that
when OptimizedMarshaller starts to serialize an object node, all the descedant
nodes continue to be serialized in OptimizedMarshaller using the same
GridHandleTable associated with the current thread. GridHandleTable is static
for a thread and never shrinks in size, its buffer becomes only larger in time.
BinaryMarshallerExImpl though, can divert serizliation to OptimizedMarshaller
down the road.
What problematic is in GridHandleTable? This is its reset() method that fills
arrays in memory. Done once, it's not a big deal. Done a million times for a
long buffer, it becomes really long and CPU-consuming.
> Performance degradation in Marshaller
> -
>
> Key: IGNITE-17043
> URL: https://issues.apache.org/jira/browse/IGNITE-17043
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.13, 2.14
>Reporter: Sergey Kosarev
>Priority: Major
>
> There is a problem in ignite-core code in GridHandleTable used inside
> OptimizedMarshaller where the internal buffers grow in size and does not
> shrink back.
> SingletonList is serialized with OptimizedMarshaller by default in Ignite. In
> contrast, for ArrayList serialization, BinaryMarshallerExImpl is used.
> The difference
[jira] [Created] (IGNITE-17043) Performance degradation in Marshaller
Sergey Kosarev created IGNITE-17043: --- Summary: Performance degradation in Marshaller Key: IGNITE-17043 URL: https://issues.apache.org/jira/browse/IGNITE-17043 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.13, 2.14 Reporter: Sergey Kosarev There is a problem in ignite-core code in GridHandleTable used inside OptimizedMarshaller where the internal buffers grow in size and does not shrink back. SingletonList is serialized with OptimizedMarshaller by default in Ignite. In contrast, for ArrayList serialization, BinaryMarshallerExImpl is used. The difference between OptimizedMarshaller and BinaryMarshallerExImpl is that when OptimizedMarshaller starts to serialize an object node, all the descedant nodes continue to be serialized in OptimizedMarshaller using the same GridHandleTable associated with the current thread. GridHandleTable is static for a thread and never shrinks in size, its buffer becomes only larger in time. BinaryMarshallerExImpl though, can divert serizliation to OptimizedMarshaller down the road. What problematic is in GridHandleTable? This is its reset() method that fills arrays in memory. Done once, it's not a big deal. Done a million times for a long buffer, it becomes really long and CPU-consuming. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17042) Fix flaky tests failed due to client cache is null
[
https://issues.apache.org/jira/browse/IGNITE-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-17042:
-
Fix Version/s: 2.14
> Fix flaky tests failed due to client cache is null
> --
>
> Key: IGNITE-17042
> URL: https://issues.apache.org/jira/browse/IGNITE-17042
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.14
>
>
> There are several tests that failed due to client cache is null:
> {noformat}
> grid(0).createCache(ccfg);
> clientCache = client.cache(ccfg.getName());
> clientCache.put(); // Cache can be null due to client registers cache
> asynchroniously.
> {noformat}
> Example of test:
> CacheEntryProcessorNonSerializableTest.testPessimisticFullSync
> {noformat}
> === Failed test run #1 ==
> --- Stdout: ---
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.doTestInvokeTest(CacheEntryProcessorNonSerializableTest.java:437)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.testPessimisticFullSync(CacheEntryProcessorNonSerializableTest.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454657#comment-17454657
]
Ilya Shishkov edited comment on IGNITE-14913 at 5/26/22 4:42 PM:
-
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are to turn on/off or show status of metrics:
# For all caches of a cluster.
# For a particular list of the caches.
IMHO, below syntax is more suitable:
{code:java}
--cache metrics enable|disable|status --caches cache1[,...,cacheN]|--all-caches
{code}
was (Author: shishkovilja):
It seems, that command with the proposed syntax (with regex) can result to the
unpredictable results for an user.
I think, that 2 main use cases are to turn on/off or show status of metrics:
# For all caches of a cluster.
# For a particular list of the caches.
IMHO, below syntax is more suitable:
{code}
--cache metric enable|disable|status --caches cache1[,...,cacheN]|--all-caches
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a command to manage cache metrics
> collection.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status --caches
> cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which sub-command should be applied.
> --all-caches - applies sub-command to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17042) Fix flaky tests failed due to client cache is null
Amelchev Nikita created IGNITE-17042:
Summary: Fix flaky tests failed due to client cache is null
Key: IGNITE-17042
URL: https://issues.apache.org/jira/browse/IGNITE-17042
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
There are several tests that failed due to client cache is null:
{noformat}
grid(0).createCache(ccfg);
clientCache = client.cache(ccfg.getName());
clientCache.put(); // Can be null due client registers cache asynchroniously.
{noformat}
Example of test: CacheEntryProcessorNonSerializableTest.testPessimisticFullSync
{noformat}
=== Failed test run #1 ==
--- Stdout: ---
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.doTestInvokeTest(CacheEntryProcessorNonSerializableTest.java:437)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.testPessimisticFullSync(CacheEntryProcessorNonSerializableTest.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14913:
---
Description:
Currently, enabling or disabling cache metrics collection is available only via
IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer being
developed, it would be helpful to add a command to manage cache metrics
collection.
Suggested syntax for a command:
{code:java}
--cache metrics enable|disable|status --caches cache1[,...,cacheN]|--all-caches
Manages user cache metrics collection: enables, disables it or shows status.
Parameters:
--caches cache1[,...,cacheN] - specifies a comma-separated list of cache
names to which sub-command should be applied.
--all-caches - applies sub-command to all user caches.
{code}
was:
Currently, enabling or disabling cache metrics collection is available only via
IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer being
developed, it would be helpful to add a cache statistics switch into the
control script.
Suggested syntax for a command:
{code:java}
--cache metrics enable|disable|status --caches cache1[,...,cacheN]|--all-caches
Manages user cache metrics collection: enables, disables it or shows status.
Parameters:
--caches cache1[,...,cacheN] - specifies a comma-separated list of cache
names to which sub-command should be applied.
--all-caches - applies sub-command to all user caches.
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a command to manage cache metrics
> collection.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status --caches
> cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which sub-command should be applied.
> --all-caches - applies sub-command to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17042) Fix flaky tests failed due to client cache is null
[
https://issues.apache.org/jira/browse/IGNITE-17042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-17042:
-
Description:
There are several tests that failed due to client cache is null:
{noformat}
grid(0).createCache(ccfg);
clientCache = client.cache(ccfg.getName());
clientCache.put(); // Cache can be null due to client registers cache
asynchroniously.
{noformat}
Example of test: CacheEntryProcessorNonSerializableTest.testPessimisticFullSync
{noformat}
=== Failed test run #1 ==
--- Stdout: ---
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.doTestInvokeTest(CacheEntryProcessorNonSerializableTest.java:437)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.testPessimisticFullSync(CacheEntryProcessorNonSerializableTest.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
There are several tests that failed due to client cache is null:
{noformat}
grid(0).createCache(ccfg);
clientCache = client.cache(ccfg.getName());
clientCache.put(); // Can be null due client registers cache asynchroniously.
{noformat}
Example of test: CacheEntryProcessorNonSerializableTest.testPessimisticFullSync
{noformat}
=== Failed test run #1 ==
--- Stdout: ---
java.lang.NullPointerException
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.doTestInvokeTest(CacheEntryProcessorNonSerializableTest.java:437)
at
org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.testPessimisticFullSync(CacheEntryProcessorNonSerializableTest.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> Fix flaky tests failed due to client cache is null
> --
>
> Key: IGNITE-17042
> URL: https://issues.apache.org/jira/browse/IGNITE-17042
> Project: Ignite
> Issue Type: Bug
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
>
> There are several tests that failed due to client cache is null:
> {noformat}
> grid(0).createCache(ccfg);
> clientCache = client.cache(ccfg.getName());
> clientCache.put(); // Cache can be null due to client registers cache
> asynchroniously.
> {noformat}
> Example of test:
> CacheEntryProcessorNonSerializableTest.testPessimisticFullSync
> {noformat}
> === Failed test run #1 ==
> --- Stdout: ---
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.doTestInvokeTest(CacheEntryProcessorNonSerializableTest.java:437)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheEntryProcessorNonSerializableTest.testPessimisticFullSync(CacheEntryProcessorNonSerializableTest.java:197)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
[jira] [Updated] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14913:
---
Description:
Currently, enabling or disabling cache metrics collection is available only via
IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer being
developed, it would be helpful to add a cache statistics switch into the
control script.
Suggested syntax for a command:
{code:java}
--cache metrics enable|disable|status --caches cache1[,...,cacheN]|--all-caches
Manages user cache metrics collection: enables, disables it or shows status.
Parameters:
--caches cache1[,...,cacheN] - specifies a comma-separated list of cache
names to which sub-command should be applied.
--all-caches - applies sub-command to all user caches.
{code}
was:
Currently, enabling or disabling cache metrics collection is available only via
IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer being
developed, it would be helpful to add a cache statistics switch into the
control script.
Suggested syntax for a command:
{code:java}
--cache metric enable|disable|status --caches cache1[,...,cacheN]|--all-caches
Manages user cache metrics collection: enables, disables it or shows status.
Parameters:
--caches cache1[,...,cacheN] - specifies a comma-separated list of cache
names to which sub-command should be applied.
--all-caches - applies sub-command to all user caches.
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> the control script.
> Suggested syntax for a command:
> {code:java}
> --cache metrics enable|disable|status --caches
> cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which sub-command should be applied.
> --all-caches - applies sub-command to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14913:
---
Description:
Currently, enabling or disabling cache metrics collection is available only via
IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer being
developed, it would be helpful to add a cache statistics switch into the
control script.
Suggested syntax for a command:
{code:java}
--cache metric enable|disable|status --caches cache1[,...,cacheN]|--all-caches
Manages user cache metrics collection: enables, disables it or shows status.
Parameters:
--caches cache1[,...,cacheN] - specifies a comma-separated list of cache
names to which sub-command should be applied.
--all-caches - applies sub-command to all user caches.
{code}
was:
Currently, enabling or disabling cache statistics is available only via
IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer being
developed, it would be helpful to add a cache statistics switch into the
control script.
Suggested syntax for a command:
{code}
--cache metric enable|disable|status --caches cache1[,...,cacheN]|--all-caches
Manages user cache metrics collection: enables, disables it or shows status.
Parameters:
--caches cache1[,...,cacheN] - specifies a comma-separated list of cache
names to which sub-command should be applied.
--all-caches - applies sub-command to all user caches.
{code}
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Currently, enabling or disabling cache metrics collection is available only
> via IgniteVisorCmd or JMX. Because it seems that IgniteVisorCmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> the control script.
> Suggested syntax for a command:
> {code:java}
> --cache metric enable|disable|status --caches cache1[,...,cacheN]|--all-caches
> Manages user cache metrics collection: enables, disables it or shows status.
> Parameters:
> --caches cache1[,...,cacheN] - specifies a comma-separated list of cache
> names to which sub-command should be applied.
> --all-caches - applies sub-command to all user caches.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542507#comment-17542507 ] Pavel Tupitsyn commented on IGNITE-17038: - [~amashenkov] done. Merged to main: c52a70fa867f1df18c6259e183be00f63460d914 > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 0.5h > Remaining Estimate: 0h > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-14744) Restore snapshot taken on different topologies
[
https://issues.apache.org/jira/browse/IGNITE-14744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542501#comment-17542501
]
Maxim Muzafarov commented on IGNITE-14744:
--
Folks, my notes during the issue implementation:
{code}
Snapshot recovery with transfer partitions.
TODO: Some notes left to do for the restore using rebalancing:
(done) 1. Disable WAL for starting caches.
(done) 2. Own partitions on exchange (like the rebalancing does).
(done) 3. Handle and fire affinity change message when waitInfo becomes empty.
(done) 4. Load partitions from remote nodes.
(no need) 5. Set partition to MOVING state during copy from snapshot and read
partition Metas.
(done) 6. Replace index if topology match partitions.
(done) 7. Rebuild index if need.
8. Check the partition reservation during the restore if a next exchange
occurs (see message:
Cache groups were not reserved [[[grpId=-903566235, grpName=shared],
reason=Checkpoint was marked
as inapplicable for historical rebalancing]])
(done) 9. Add cache destroy rollback procedure if loading was unsuccessful.
(done) 10. Crash-recovery when node crashes with started, but not loaded
caches.
(?) 11. Do not allow schema changes during the restore procedure.
12. Restore busy lock should throw exception if a lock acquire fails.
(?) 13. Should we clean the 'dirty' flag prior to markCheckpointBegin, so
pages won't be collected by the checkpoint?
(?) 14. cancelOrWaitPartitionDestroy should we wait for partition destroying.
(done) 15. prevent page store initialization on write if tag has been
incremented.
(?) 16. Register snapshot task by request id not by snapshot name.
(?) 17. Does waitRebInfo need to be cleaned on
DynamicCacheChangeFailureMessage occurs for restored caches?
(?) 18. Do we need to remove cache from the waitInfo rebalance groups prior
to cache actually rollback fired?
(?) 19. Exclude partitions for restoring caches from PME.
20. Make the CacheGroupActionData private inner class.
21. Partitions may not be even created in a snapshot.
22. Snapshot interrupted during caches loading from snapshot.
Other strategies to be memento to:
1. Load partitions from snapshot, then start cache groups
- registered cache groups calculated from discovery thread, no affinity cache
data can be calculated without it
- index rebuild may be started only after cache group start, will it require
cache availability using disabled proxies?
- Can affinity be calculated on each node? Node attributes may cause some
issues.
2. Start cache groups disabled, then load partitions from snapshot
- What would happen with partition counters on primaries and backups?
(probably not required)
- Should the partition map be updated on client nodes?
- When partition is loaded from snapshot, should we update partition counters
under checkpoint?
3. Start cache disabled and load data from each partition using partition
iterator (defragmentation out of the box + index rebuild)
3a. Transfer snapshot partition files from remove node and read them as local
data.
3b. Read partitions on remote node and transfer data via Supply cache message.
- cacheId is not stored in the partition file, so it's required to obtain it
from the cache data tree
- data streamer load job is not suitable for caches running with disabled
cache proxies
- too many dirty pages can lead to data eviction to ssd
4. Start cache and load partitions as it rebalancing do (transfer files)
- There is no lazy init for index partition
- node2part must be updated on forceRecreatePartition method call
- do not own partitions after cache start
- update node2part map after partitions loaded from source and start
refreshPartitions/affinityChange (each node sends
a single message with its own cntrMap to the coordinator node, than
coordinator resends aggregated message to the whole
cluster nodes on update incomeCntrMap).
- Two strategies for the restore on the same topology with indexes: start
cache group from preloaded files or start cache
and then re-init index for started cache group. The second case will require
data structures re-initialization on the fly.
IMPLEMENTATION NOTES
-
There are still some dirty pages related to processing partition available in
the PageMemory.
Loaded:
- need to set MOVING states to loading partitions.
- need to acquire partition counters from each part
The process of re-init options:
1. Clear heap entries from GridDhtLocalPartition, swap datastore, re-init
counters
2. Re-create the whole GridDhtLocalPartition from scratch in
GridDhtPartitionTopologyImpl
as it the eviction does
The re-init notes:
- clearAsync() should move the clearVer in clearAll() to the end.
- How to handle updates on partition prior to the storage switch? (the same as
waitPartitionRelease()?)
- destroyCacheDataStore()
[jira] [Updated] (IGNITE-17007) TxAbstractTest#testBalance is flaky
[
https://issues.apache.org/jira/browse/IGNITE-17007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17007:
--
Priority: Blocker (was: Major)
> TxAbstractTest#testBalance is flaky
> ---
>
> Key: IGNITE-17007
> URL: https://issues.apache.org/jira/browse/IGNITE-17007
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_2895.log
>
>
> Implementations of {{TxAbstractTest#testBalance}} sometimes fail when running
> on TeamCity:
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleTable?mode=builds#all-projects
> I wasn't able to reproduce these failures locally, so this might be a
> TC-specific issue.
> Example error log:
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleTable/6575460
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17037) Compatibility test-jar is missed in the ignite bom dependency
[ https://issues.apache.org/jira/browse/IGNITE-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542489#comment-17542489 ] Maxim Muzafarov commented on IGNITE-17037: -- Merged to the master branch. > Compatibility test-jar is missed in the ignite bom dependency > - > > Key: IGNITE-17037 > URL: https://issues.apache.org/jira/browse/IGNITE-17037 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Compatibility test-jar is missed in the ignite bom dependency. This > dependency is used in the Ignite Extensions project and required to be > installed in the local repository. During the development lifecycle in will > be simpler to publish it to the maven snapshot repository. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17041) Normalize query entity after it is modified during merge process.
Mikhail Petrov created IGNITE-17041:
---
Summary: Normalize query entity after it is modified during merge
process.
Key: IGNITE-17041
URL: https://issues.apache.org/jira/browse/IGNITE-17041
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
It is needed to to normalize query entity after it is modified during MERGE
process as it is done during the first cache configuration processing.
Currently new table columns that was created based on Query Entity fields which
was added during MERGE process has the naming that differs from columns that
were created based on initial Query Entity fields.
For example if CacheConfiguration#isSqlEscapeAll flag is disabled - all
QueryEntity fields are converted to upper case and used as such to name
columns. But it does not happen if Query Entity field was added during MERGE
process. It confuses users and leads to the situations when column conflicts
cannot be found because column names are different.
Reproducer:
{code:java}
public class TestClass extends GridCommonAbstractTest {
/**
* Start cluster nodes.
*/
public static final int NODES_CNT = 2;
/**
* Count of backup partitions.
*/
public static final int BACKUPS = 2;
@Override
protected IgniteConfiguration getConfiguration(String igniteInstanceName)
throws Exception {
QueryEntity queryEntity = new QueryEntity(String.class, Person.class)
.setTableName("PERSON")
.addQueryField("id", Boolean.class.getName(), null)
.addQueryField("name", String.class.getName(), null);
CacheConfiguration configuration = new
CacheConfiguration<>(GridAbstractTest.DEFAULT_CACHE_NAME)
.setBackups(BACKUPS)
.setQueryEntities(Collections.singletonList(queryEntity));
if (igniteInstanceName.endsWith("1"))
queryEntity.addQueryField("age", Boolean.class.getName(), null);
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName)
.setConsistentId(igniteInstanceName)
.setDataStorageConfiguration(new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(new
DataRegionConfiguration()))
.setCacheConfiguration(
configuration);
return cfg;
}
/**
* {@inheritDoc}
*/
@Override
protected void afterTest() throws Exception {
stopAllGrids();
}
/**
*
*/
@Test
public void testIssue() throws Exception {
startGrid(0);
grid(0);
grid(0).cache(GridAbstractTest.DEFAULT_CACHE_NAME).query(new
SqlFieldsQuery("ALTER TABLE PERSON ADD age INTEGER")).getAll();
GridTestUtils.assertThrows(log, () -> startGrid(1), Exception.class,
"");
grid(0).cluster().state(ClusterState.INACTIVE);
startGrid(1);
grid(0).cluster().state(ClusterState.ACTIVE);
System.out.println(grid(0).cache(DEFAULT_CACHE_NAME).query(new
SqlFieldsQuery("select * from \"SYS\".TABLE_COLUMNS"))
.getAll());
}
class Person {
private int id;
private String name;
private boolean age;
}
}
{code}
As a result we can see that "age" column is duplicated in UPPER and CAMEL case.
And no conflicts were found.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17040) Netty buffer leak detected in networking tests
Semyon Danilov created IGNITE-17040:
---
Summary: Netty buffer leak detected in networking tests
Key: IGNITE-17040
URL: https://issues.apache.org/jira/browse/IGNITE-17040
Project: Ignite
Issue Type: Bug
Components: networking
Reporter: Semyon Danilov
Assignee: Semyon Danilov
Fix For: 3.0.0-alpha5
{noformat}
[12:45:21]W: [org.apache.ignite:ignite-network] 2022-05-26
12:45:21:043 +0300 [ERROR][main][ResourceLeakDetector] LEAK: ByteBuf.release()
was not called before it's garbage-collected. See
https://netty.io/wiki/reference-counted-objects.html for more information.
[12:45:21]W: [org.apache.ignite:ignite-network] Recent access
records:
[12:45:21]W: [org.apache.ignite:ignite-network] Created at:
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:402)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:132)
[12:45:21]W: [org.apache.ignite:ignite-network]
org.apache.ignite.internal.network.netty.OutboundEncoder$NetworkMessageChunkedInput.readChunk(OutboundEncoder.java:142)
[12:45:21]W: [org.apache.ignite:ignite-network]
org.apache.ignite.internal.network.netty.OutboundEncoder$NetworkMessageChunkedInput.readChunk(OutboundEncoder.java:67)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.handler.stream.ChunkedWriteHandler.doFlush(ChunkedWriteHandler.java:229)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:131)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:742)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:728)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.DefaultChannelPipeline.flush(DefaultChannelPipeline.java:967)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannel.flush(AbstractChannel.java:254)
[12:45:21]W: [org.apache.ignite:ignite-network]
org.apache.ignite.internal.network.recovery.RecoveryServerHandshakeManager.handshake(RecoveryServerHandshakeManager.java:182)
[12:45:21]W: [org.apache.ignite:ignite-network]
org.apache.ignite.internal.network.recovery.RecoveryServerHandshakeManager.onMessage(RecoveryServerHandshakeManager.java:139)
[12:45:21]W: [org.apache.ignite:ignite-network]
org.apache.ignite.internal.network.netty.HandshakeHandler.channelRead(HandshakeHandler.java:85)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
[12:45:21]W: [org.apache.ignite:ignite-network]
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
[12:45:21]W:
[jira] [Commented] (IGNITE-17023) Python thin: Fix supported versions
[ https://issues.apache.org/jira/browse/IGNITE-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542469#comment-17542469 ] Igor Sapego commented on IGNITE-17023: -- Merged to master. > Python thin: Fix supported versions > --- > > Key: IGNITE-17023 > URL: https://issues.apache.org/jira/browse/IGNITE-17023 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: python-0.5.2 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Remove 3.6 from supported versions and add 3.10. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542463#comment-17542463 ] Andrey Mashenkov commented on IGNITE-17038: --- [~ptupitsyn], looks good. Let's add closeReactive method and proceed with merge. > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 20m > Remaining Estimate: 0h > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-15550) Calcite engine. Support collections constuction from the query
[
https://issues.apache.org/jira/browse/IGNITE-15550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky reassigned IGNITE-15550:
Assignee: Ivan Daschinsky
> Calcite engine. Support collections constuction from the query
> --
>
> Key: IGNITE-15550
> URL: https://issues.apache.org/jira/browse/IGNITE-15550
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Minor
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> Currently, queries like:
>
> {noformat}
> SELECT MAP(SELECT 'a', 1)
> SELECT ARRAY(SELECT 1){noformat}
> Can't be executed, since logical plan contains \{{Collect}} relational
> operator and there is no rule and no physical operator to convert this
> logical operator.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17023) Python thin: Fix supported versions
[ https://issues.apache.org/jira/browse/IGNITE-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542462#comment-17542462 ] Igor Sapego edited comment on IGNITE-17023 at 5/26/22 12:21 PM: Tests passed: https://ci.ignite.apache.org/buildConfiguration/IgniteThinClients_Tests_ThinClientPython/6589848 was (Author: isapego): Tests passed: https://ggtc.gridgain.com/buildConfiguration/Tests_GridGainCeEeUe_Latest_CE_ThinClientPython/7645336 > Python thin: Fix supported versions > --- > > Key: IGNITE-17023 > URL: https://issues.apache.org/jira/browse/IGNITE-17023 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: python-0.5.2 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Remove 3.6 from supported versions and add 3.10. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17023) Python thin: Fix supported versions
[ https://issues.apache.org/jira/browse/IGNITE-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542462#comment-17542462 ] Igor Sapego commented on IGNITE-17023: -- Tests passed: https://ggtc.gridgain.com/buildConfiguration/Tests_GridGainCeEeUe_Latest_CE_ThinClientPython/7645336?showRootCauses=false > Python thin: Fix supported versions > --- > > Key: IGNITE-17023 > URL: https://issues.apache.org/jira/browse/IGNITE-17023 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: python-0.5.2 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Remove 3.6 from supported versions and add 3.10. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17023) Python thin: Fix supported versions
[ https://issues.apache.org/jira/browse/IGNITE-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542462#comment-17542462 ] Igor Sapego edited comment on IGNITE-17023 at 5/26/22 12:20 PM: Tests passed: https://ggtc.gridgain.com/buildConfiguration/Tests_GridGainCeEeUe_Latest_CE_ThinClientPython/7645336 was (Author: isapego): Tests passed: https://ggtc.gridgain.com/buildConfiguration/Tests_GridGainCeEeUe_Latest_CE_ThinClientPython/7645336?showRootCauses=false > Python thin: Fix supported versions > --- > > Key: IGNITE-17023 > URL: https://issues.apache.org/jira/browse/IGNITE-17023 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: python-0.5.2 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Remove 3.6 from supported versions and add 3.10. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17035) The testChangeSnapshotTransferRateInRuntime test is flaky.
[
https://issues.apache.org/jira/browse/IGNITE-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542459#comment-17542459
]
Ignite TC Bot commented on IGNITE-17035:
{panel:title=Branch: [pull/10041/head] Base: [master] : Possible Blockers
(16)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Queries 2 (lazy=true){color} [[tests 12 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6453596]]
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout1 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout2 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout5 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout6 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout3 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout4 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testNoExplicitTimeout1 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testNoExplicitTimeout2 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout7 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testExplicitTimeout8 - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteBinaryCacheQueryLazyTestSuite2:
DefaultQueryTimeoutThinJavaTest.testNoExplicitTimeout3 - Test has low fail rate
in base branch 0,0% and is not flaky
... and 1 tests blockers
{color:#d04437}PDS 4{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6453580]]
* IgnitePdsTestSuite4:
IgnitePdsContinuousRestartTestWithSharedGroupAndIndexes.testRebalancingDuringLoad_1000_500_8_16
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 1{color} [[tests 1 TIMEOUT , Exit Code
|https://ci2.ignite.apache.org/viewLog.html?buildId=6453577]]
* IgnitePdsTestSuite: IgnitePdsDynamicCacheTest.testCreate - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10041/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6453625buildTypeId=IgniteTests24Java8_RunAll]
> The testChangeSnapshotTransferRateInRuntime test is flaky.
> --
>
> Key: IGNITE-17035
> URL: https://issues.apache.org/jira/browse/IGNITE-17035
> Project: Ignite
> Issue Type: Task
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Minor
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The test is flaky:
> https://ci2.ignite.apache.org/test/5720057658324237232?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true
> The reason - it does not take into account release time of
> BasicRateLimiter#acquire() after rate set to unlimited.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17039) [Extensions] Fix binary assembly of performance statistics module
[ https://issues.apache.org/jira/browse/IGNITE-17039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17039: - Component/s: extensions > [Extensions] Fix binary assembly of performance statistics module > - > > Key: IGNITE-17039 > URL: https://issues.apache.org/jira/browse/IGNITE-17039 > Project: Ignite > Issue Type: Bug > Components: extensions >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > > The release build was broken after IGNITE-16847. The release archive does not > include UI resources. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17039) [Extensions] Fix binary assembly of performance statistics module
[ https://issues.apache.org/jira/browse/IGNITE-17039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542457#comment-17542457 ] Amelchev Nikita commented on IGNITE-17039: -- TC run: https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_PerformanceStatistics/6453935?showRootCauses=false=true > [Extensions] Fix binary assembly of performance statistics module > - > > Key: IGNITE-17039 > URL: https://issues.apache.org/jira/browse/IGNITE-17039 > Project: Ignite > Issue Type: Bug > Components: extensions >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > > The release build was broken after IGNITE-16847. The release archive does not > include UI resources. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17039) [Extensions] Fix binary assembly of performance statistics module
Amelchev Nikita created IGNITE-17039: Summary: [Extensions] Fix binary assembly of performance statistics module Key: IGNITE-17039 URL: https://issues.apache.org/jira/browse/IGNITE-17039 Project: Ignite Issue Type: Bug Reporter: Amelchev Nikita Assignee: Amelchev Nikita The release build was broken after IGNITE-16847. The release archive does not include UI resources. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17038: Ignite Flags: (was: Docs Required,Release Notes Required) > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542444#comment-17542444 ] Anton Vinogradov commented on IGNITE-15329: --- Merged to the master. [~nizhikov] thanks for the review! > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-15329) Atomics should be repairable by Read Repair
[
https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542443#comment-17542443
]
Ignite TC Bot commented on IGNITE-15329:
{panel:title=Branch: [pull/9907/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9907/head] Base: [master] : New Tests
(1010)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
50|https://ci.ignite.apache.org/viewLog.html?buildId=6587785]]
* {color:#013220}IgniteControlUtilityTestSuite:
KillCommandsCommandShTest.testCancelConsistencyTaskSequential - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
KillCommandsCommandShTest.testCancelConsistencyTaskParallel - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=false, strategy=CHECK_ONLY, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=false, strategy=CHECK_ONLY, parallel=true] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=true, strategy=LWW, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=true, strategy=PRIMARY, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=false, strategy=LWW, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=false, strategy=PRIMARY, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=false, strategy=RELATIVE_MAJORITY, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessAtomicTest.test[misses=false,
nulls=false, strategy=REMOVE, parallel=false] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=true,
nulls=true, strategy=RELATIVE_MAJORITY, parallel=false] - PASSED{color}
... and 39 new tests
{color:#8b}Consistency{color} [[tests
960|https://ci.ignite.apache.org/viewLog.html?buildId=6587832]]
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=true, misses=false, nulls=false,
binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=true, misses=false, nulls=true,
binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=true, misses=false, nulls=true,
binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=true, misses=true, nulls=false,
binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false, misses=true, nulls=false,
binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false, misses=true, nulls=true,
binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false, misses=true, nulls=true,
binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=true, misses=false, nulls=false,
binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false, misses=false,
nulls=false, binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false, misses=false, nulls=true,
binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
AtomicReadRepairTest.test[getEntry=true, async=false, misses=false, nulls=true,
binary=true] - PASSED{color}
... and 949 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6587853buildTypeId=IgniteTests24Java8_RunAll]
> Atomics should be repairable by Read Repair
> ---
>
> Key: IGNITE-15329
> URL: https://issues.apache.org/jira/browse/IGNITE-15329
> Project: Ignite
> Issue Type: Sub-task
>Reporter:
[jira] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329 ]
Anton Vinogradov deleted comment on IGNITE-15329:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/9907/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9907/head] Base: [master] : New Tests
(1001)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
41|https://ci2.ignite.apache.org/viewLog.html?buildId=6424824]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=false, strategy=LWW] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=false, strategy=CHECK_ONLY] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=false, strategy=REMOVE] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=false, strategy=RELATIVE_MAJORITY] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=false, strategy=PRIMARY] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=true, strategy=REMOVE] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=true, strategy=RELATIVE_MAJORITY] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=true, strategy=PRIMARY] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=false,
nulls=true, strategy=LWW] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=true,
nulls=false, strategy=RELATIVE_MAJORITY] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyRepairCorrectnessTransactionalTest.test[misses=true,
nulls=false, strategy=PRIMARY] - PASSED{color}
... and 30 new tests
{color:#8b}Consistency{color} [[tests
960|https://ci2.ignite.apache.org/viewLog.html?buildId=6424819]]
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=false, nulls=false, binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=false, nulls=false, binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=false,
misses=true, nulls=true, binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=false,
misses=true, nulls=true, binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=true, nulls=false, binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=true, nulls=false, binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=false, nulls=true, binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=false, nulls=true, binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
PdsAtomicReadRepairTest.test[getEntry=false, async=false, misses=false,
nulls=false, binary=true] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
PdsAtomicReadRepairTest.test[getEntry=false, async=false, misses=false,
nulls=false, binary=false] - PASSED{color}
* {color:#013220}IgniteCacheConsistencySelfTestSuite:
ImplicitTransactionalReadRepairTest.test[getEntry=true, async=true,
misses=true, nulls=true, binary=true] - PASSED{color}
... and 949 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6424898buildTypeId=IgniteTests24Java8_RunAll]
> Atomics should be repairable by Read Repair
> ---
>
> Key: IGNITE-15329
> URL:
[jira] [Updated] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17038: Description: * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* was: * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* * Change *AsyncResultSet.currentPage()* from *Iterable* to *Collection* > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17038: Description: * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* * Change *AsyncResultSet.currentPage()* from *Iterable* to *Collection* was: * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* > * Change *AsyncResultSet.currentPage()* from *Iterable* to > *Collection* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17038) Improve SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17038: Description: * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* was: * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* > Improve SQL API > --- > > Key: IGNITE-17038 > URL: https://issues.apache.org/jira/browse/IGNITE-17038 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with > other APIs where sync and async methods reside in a single interface > * Add missing async/reactive methods (*executeScript*), make sure everything > is symmetric > * Add missing arguments to *executeAsync(@Nullable Transaction transaction, > Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17038) Improve SQL API
Pavel Tupitsyn created IGNITE-17038: --- Summary: Improve SQL API Key: IGNITE-17038 URL: https://issues.apache.org/jira/browse/IGNITE-17038 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 3.0.0-alpha4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha5 * Merge *AsyncSession* and *ReactiveSession* into *Session*: consistent with other APIs where sync and async methods reside in a single interface * Add missing async/reactive methods (*executeScript*), make sure everything is symmetric * Add missing arguments to *executeAsync(@Nullable Transaction transaction, Statement statement)* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17037) Compatibility test-jar is missed in the ignite bom dependency
[ https://issues.apache.org/jira/browse/IGNITE-17037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17037: - Ignite Flags: (was: Docs Required,Release Notes Required) > Compatibility test-jar is missed in the ignite bom dependency > - > > Key: IGNITE-17037 > URL: https://issues.apache.org/jira/browse/IGNITE-17037 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > Compatibility test-jar is missed in the ignite bom dependency. This > dependency is used in the Ignite Extensions project and required to be > installed in the local repository. During the development lifecycle in will > be simpler to publish it to the maven snapshot repository. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17037) Compatibility test-jar is missed in the ignite bom dependency
Maxim Muzafarov created IGNITE-17037: Summary: Compatibility test-jar is missed in the ignite bom dependency Key: IGNITE-17037 URL: https://issues.apache.org/jira/browse/IGNITE-17037 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.14 Compatibility test-jar is missed in the ignite bom dependency. This dependency is used in the Ignite Extensions project and required to be installed in the local repository. During the development lifecycle in will be simpler to publish it to the maven snapshot repository. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17033) Move ignite-aop to the Ignite Extensions
[ https://issues.apache.org/jira/browse/IGNITE-17033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542424#comment-17542424 ] Maxim Muzafarov commented on IGNITE-17033: -- Merged to the master branch. > Move ignite-aop to the Ignite Extensions > > > Key: IGNITE-17033 > URL: https://issues.apache.org/jira/browse/IGNITE-17033 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The ignite-aop module must be moved to the Ignite Extension since it has not > been updated for a few years and it is not configured on TC for running tests. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17036) RaftException: ESTATEMACHINE:null when change replicas from 3 to 2 for a table
[
https://issues.apache.org/jira/browse/IGNITE-17036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-17036:
-
Description:
Reproducer on a feature branch ignite-14209 :
{code:java}
void testOneRebalance(@WorkDirectory Path workDir, TestInfo testInfo) throws
Exception {
TableDefinition schTbl1 = SchemaBuilders.tableBuilder("PUBLIC",
"tbl1").columns(
SchemaBuilders.column("key", ColumnType.INT64).build(),
SchemaBuilders.column("val",
ColumnType.INT32).asNullable(true).build()
).withPrimaryKey("key").build();
nodes.get(0).tableManager.createTable(
"PUBLIC.tbl1",
tblChanger -> SchemaConfigurationConverter.convert(schTbl1,
tblChanger)
.changeReplicas(1)
.changePartitions(1));
assertEquals(1,
nodes.get(0).clusterCfgMgr.configurationRegistry().getConfiguration(TablesConfiguration.KEY)
.tables().get("PUBLIC.TBL1").replicas().value());
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(3));
waitPartitionAssignmentsSyncedToExpected(0, 3);
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(2));
waitPartitionAssignmentsSyncedToExpected(0, 2);
assertEquals(3, getAssignments(0, 0).size());
assertEquals(3, getAssignments(1, 0).size());
assertEquals(3, getAssignments(2, 0).size());
}
{code}
This code hangs with
{noformat}
2022-05-26 12:14:00:871 +0300 [ERROR][Thread-89][MetaStorageServiceImpl]
Unexpected exception
java.util.concurrent.CompletionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: ESTATEMACHINE:null
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:617)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:556)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: class org.apache.ignite.raft.jraft.rpc.impl.RaftException:
ESTATEMACHINE:null
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:618)
... 9 more
{noformat}
Root cause is the bug in {{{}SimpleInMemoryKeyValueStorage{}}}, method
{{SimpleInMemoryKeyValueStorage#doGetValue}} throws NPE when tries to get
revision on the line {{if (lastVal.tombstone())}} because {{Value lastVal =
lastRevVals.get(key)}} is null.
was:
Reproducer on a feature branch :
{code:java}
void testOneRebalance(@WorkDirectory Path workDir, TestInfo testInfo) throws
Exception {
TableDefinition schTbl1 = SchemaBuilders.tableBuilder("PUBLIC",
"tbl1").columns(
SchemaBuilders.column("key", ColumnType.INT64).build(),
SchemaBuilders.column("val",
ColumnType.INT32).asNullable(true).build()
).withPrimaryKey("key").build();
nodes.get(0).tableManager.createTable(
"PUBLIC.tbl1",
tblChanger -> SchemaConfigurationConverter.convert(schTbl1,
tblChanger)
.changeReplicas(1)
.changePartitions(1));
assertEquals(1,
nodes.get(0).clusterCfgMgr.configurationRegistry().getConfiguration(TablesConfiguration.KEY)
.tables().get("PUBLIC.TBL1").replicas().value());
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(3));
waitPartitionAssignmentsSyncedToExpected(0, 3);
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(2));
[jira] [Created] (IGNITE-17036) RaftException: ESTATEMACHINE:null when change replicas from 3 to 2 for a table
Mirza Aliev created IGNITE-17036:
Summary: RaftException: ESTATEMACHINE:null when change replicas
from 3 to 2 for a table
Key: IGNITE-17036
URL: https://issues.apache.org/jira/browse/IGNITE-17036
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Reproducer on a feature branch :
{code:java}
void testOneRebalance(@WorkDirectory Path workDir, TestInfo testInfo) throws
Exception {
TableDefinition schTbl1 = SchemaBuilders.tableBuilder("PUBLIC",
"tbl1").columns(
SchemaBuilders.column("key", ColumnType.INT64).build(),
SchemaBuilders.column("val",
ColumnType.INT32).asNullable(true).build()
).withPrimaryKey("key").build();
nodes.get(0).tableManager.createTable(
"PUBLIC.tbl1",
tblChanger -> SchemaConfigurationConverter.convert(schTbl1,
tblChanger)
.changeReplicas(1)
.changePartitions(1));
assertEquals(1,
nodes.get(0).clusterCfgMgr.configurationRegistry().getConfiguration(TablesConfiguration.KEY)
.tables().get("PUBLIC.TBL1").replicas().value());
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(3));
waitPartitionAssignmentsSyncedToExpected(0, 3);
nodes.get(0).tableManager.alterTable("PUBLIC.TBL1", ch ->
ch.changeReplicas(2));
waitPartitionAssignmentsSyncedToExpected(0, 2);
assertEquals(3, getAssignments(0, 0).size());
assertEquals(3, getAssignments(1, 0).size());
assertEquals(3, getAssignments(2, 0).size());
}
{code}
This code hangs with
{noformat}
2022-05-26 12:14:00:871 +0300 [ERROR][Thread-89][MetaStorageServiceImpl]
Unexpected exception
java.util.concurrent.CompletionException: class
org.apache.ignite.raft.jraft.rpc.impl.RaftException: ESTATEMACHINE:null
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:632)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:617)
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:556)
at
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: class org.apache.ignite.raft.jraft.rpc.impl.RaftException:
ESTATEMACHINE:null
at
org.apache.ignite.raft.jraft.rpc.impl.RaftGroupServiceImpl$1.accept(RaftGroupServiceImpl.java:618)
... 9 more
{noformat}
Root cause is the bug in {{{}SimpleInMemoryKeyValueStorage{}}}, method
{{SimpleInMemoryKeyValueStorage#doGetValue}} throws NPE when tries to get
revision on the line {{if (lastVal.tombstone())}} because {{Value lastVal =
lastRevVals.get(key)}} is null.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[
https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-17025:
-
Fix Version/s: 2.14
> Remove the ability to manually set INLINE_SIZE for types with a fixed length
>
>
> Key: IGNITE-17025
> URL: https://issues.apache.org/jira/browse/IGNITE-17025
> Project: Ignite
> Issue Type: Improvement
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Attachments: InlineIndexTest1.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing
> when INLINE_SIZE increases when creating indexes on fixed length fields.The
> negative point is that a place is reserved that does not carry any profit.
> As a solution. When trying to build an index on a field with a fixed length
> type, do not allow this. The value of INLINE_SIZE for such types is
> calculated automatically. And display a WARN level message about it.
> To see the size of index.bin, run the
> {code:java}
> du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
> {code}
> after running the reproducer.
> {code:java}
> 36K BIGINT_INLINE10/index.bin
> 320K BIGINT_INLINE100/index.bin
> 128K INT_INLINE10/index.bin
> 324K INT_INLINE100/index.bin
> 64K NUMBER_INLINE10/index.bin
> 64K NUMBER_INLINE100/index.bin
> 128K VARCHAR_INLINE10/index.bin
> 256K VARCHAR_INLINE100/index.bin
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[
https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542415#comment-17542415
]
Ignite TC Bot commented on IGNITE-17025:
{panel:title=Branch: [pull/10038/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10038/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 5{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6452660]]
* {color:#013220}IgniteCacheWithIndexingTestSuite:
ComputeInlineSizeTest.testTooBigInlineNotUsed - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6452759buildTypeId=IgniteTests24Java8_RunAll]
> Remove the ability to manually set INLINE_SIZE for types with a fixed length
>
>
> Key: IGNITE-17025
> URL: https://issues.apache.org/jira/browse/IGNITE-17025
> Project: Ignite
> Issue Type: Improvement
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ise
> Attachments: InlineIndexTest1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing
> when INLINE_SIZE increases when creating indexes on fixed length fields.The
> negative point is that a place is reserved that does not carry any profit.
> As a solution. When trying to build an index on a field with a fixed length
> type, do not allow this. The value of INLINE_SIZE for such types is
> calculated automatically. And display a WARN level message about it.
> To see the size of index.bin, run the
> {code:java}
> du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
> {code}
> after running the reproducer.
> {code:java}
> 36K BIGINT_INLINE10/index.bin
> 320K BIGINT_INLINE100/index.bin
> 128K INT_INLINE10/index.bin
> 324K INT_INLINE100/index.bin
> 64K NUMBER_INLINE10/index.bin
> 64K NUMBER_INLINE100/index.bin
> 128K VARCHAR_INLINE10/index.bin
> 256K VARCHAR_INLINE100/index.bin
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17035) The testChangeSnapshotTransferRateInRuntime test is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542412#comment-17542412 ] Pavel Pereslegin commented on IGNITE-17035: --- [~NSAmelchev], looks good, thanks for fixing it! > The testChangeSnapshotTransferRateInRuntime test is flaky. > -- > > Key: IGNITE-17035 > URL: https://issues.apache.org/jira/browse/IGNITE-17035 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The test is flaky: > https://ci2.ignite.apache.org/test/5720057658324237232?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true > The reason - it does not take into account release time of > BasicRateLimiter#acquire() after rate set to unlimited. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17033) Move ignite-aop to the Ignite Extensions
[
https://issues.apache.org/jira/browse/IGNITE-17033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542410#comment-17542410
]
Ignite TC Bot commented on IGNITE-17033:
{panel:title=Branch: [pull/10037/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}AOP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6589290]]
{panel}
{panel:title=Branch: [pull/10037/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=6588704buildTypeId=IgniteTests24Java8_RunAll]
> Move ignite-aop to the Ignite Extensions
>
>
> Key: IGNITE-17033
> URL: https://issues.apache.org/jira/browse/IGNITE-17033
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The ignite-aop module must be moved to the Ignite Extension since it has not
> been updated for a few years and it is not configured on TC for running tests.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17023) Python thin: Fix supported versions
[ https://issues.apache.org/jira/browse/IGNITE-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542405#comment-17542405 ] Igor Sapego commented on IGNITE-17023: -- [~ivandasch] Fixed. Please take another look. > Python thin: Fix supported versions > --- > > Key: IGNITE-17023 > URL: https://issues.apache.org/jira/browse/IGNITE-17023 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: python-0.5.2 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: python-0.6.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Remove 3.6 from supported versions and add 3.10. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17035) The testChangeSnapshotTransferRateInRuntime test is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17035: - Fix Version/s: 2.14 > The testChangeSnapshotTransferRateInRuntime test is flaky. > -- > > Key: IGNITE-17035 > URL: https://issues.apache.org/jira/browse/IGNITE-17035 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > The test is flaky: > https://ci2.ignite.apache.org/test/5720057658324237232?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true > The reason - it does not take into account release time of > BasicRateLimiter#acquire() after rate set to unlimited. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17035) The testChangeSnapshotTransferRateInRuntime test is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17035: - Ignite Flags: (was: Docs Required,Release Notes Required) > The testChangeSnapshotTransferRateInRuntime test is flaky. > -- > > Key: IGNITE-17035 > URL: https://issues.apache.org/jira/browse/IGNITE-17035 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The test is flaky: > https://ci2.ignite.apache.org/test/5720057658324237232?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true > The reason - it does not take into account release time of > BasicRateLimiter#acquire() after rate set to unlimited. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17035) The testChangeSnapshotTransferRateInRuntime test is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-17035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542383#comment-17542383 ] Amelchev Nikita commented on IGNITE-17035: -- Multiple tests run: https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6453509?showRootCauses=false > The testChangeSnapshotTransferRateInRuntime test is flaky. > -- > > Key: IGNITE-17035 > URL: https://issues.apache.org/jira/browse/IGNITE-17035 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The test is flaky: > https://ci2.ignite.apache.org/test/5720057658324237232?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true > The reason - it does not take into account release time of > BasicRateLimiter#acquire() after rate set to unlimited. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16856) Sql. Ability to create table without specifying PK
[
https://issues.apache.org/jira/browse/IGNITE-16856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542382#comment-17542382
]
Konstantin Orlov commented on IGNITE-16856:
---
Hi, [~tledkov-gridgain]! Thanks for your review.
Actually you a describing a two different problems. The first one about
functional default value generator support should be addressed in IGNITE-16870.
The second one about UUID type support should be addressed in IGNITE-16376.
> Sql. Ability to create table without specifying PK
> --
>
> Key: IGNITE-16856
> URL: https://issues.apache.org/jira/browse/IGNITE-16856
> Project: Ignite
> Issue Type: New Feature
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> Despite a keyless use case currently is not supported by Ignite-3, SQL
> standard allows to create such tables, and many external tests (TCP-H for
> instance) are taking advantage of this.
> To make it easier to adopt such a tests, let's provide a special mode for
> Ignite, where implicit PK will be created in case of lack explicit one.
> Key points to consider:
> * This mode considered for test purpose only, hence the implementation
> should be as less invasive as possible.
> * An implicit key column should not be returned by {{SELECT *}} queries. It
> may be accessed by its name though.
> * Type of this column doesn't matter, but the range of possible values
> should be big enough to support billiones of unique values.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17035) The testChangeSnapshotTransferRateInRuntime test is flaky.
Amelchev Nikita created IGNITE-17035: Summary: The testChangeSnapshotTransferRateInRuntime test is flaky. Key: IGNITE-17035 URL: https://issues.apache.org/jira/browse/IGNITE-17035 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita The test is flaky: https://ci2.ignite.apache.org/test/5720057658324237232?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true The reason - it does not take into account release time of BasicRateLimiter#acquire() after rate set to unlimited. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17034) Thin 3.0: Rename JDBC packages and classes to separate them from Ignite SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542375#comment-17542375 ] Pavel Tupitsyn commented on IGNITE-17034: - Merged to main: 32ec17b1a88a36a2becb2f1b83fea5324d2a6c96 > Thin 3.0: Rename JDBC packages and classes to separate them from Ignite SQL > API > --- > > Key: IGNITE-17034 > URL: https://issues.apache.org/jira/browse/IGNITE-17034 > Project: Ignite > Issue Type: Improvement > Components: jdbc, sql, thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 20m > Remaining Estimate: 0h > > Rename client operation names, request handlers, and their packages from Sql > to Jdbc. -- This message was sent by Atlassian Jira (v8.20.7#820007)
