[jira] [Commented] (IGNITE-815) Reactive Streams Compatibility
[ https://issues.apache.org/jira/browse/IGNITE-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352274#comment-17352274 ] Koala Lam commented on IGNITE-815: -- Is this feature available already? > Reactive Streams Compatibility > -- > > Key: IGNITE-815 > URL: https://issues.apache.org/jira/browse/IGNITE-815 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Priority: Major > > http://www.reactive-streams.org/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14746) Improve row layout. Omit offset for the first varlen.
[ https://issues.apache.org/jira/browse/IGNITE-14746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-14746: - Assignee: Andrey Mashenkov > Improve row layout. Omit offset for the first varlen. > - > > Key: IGNITE-14746 > URL: https://issues.apache.org/jira/browse/IGNITE-14746 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > Actually, there is no need to write varlen offset for the very first varlen > column. > Therefore, vartable can be skipped if a single varlen column is defined for > key and/or value. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14767) Ignite extensions: Copy spring-data-2.0 examples to spring-data-2.2 module.
[ https://issues.apache.org/jira/browse/IGNITE-14767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351919#comment-17351919 ] Mikhail Petrov commented on IGNITE-14767: - [~NSAmelchev], [~RyzhovSV] Thanks for the review. > Ignite extensions: Copy spring-data-2.0 examples to spring-data-2.2 module. > --- > > Key: IGNITE-14767 > URL: https://issues.apache.org/jira/browse/IGNITE-14767 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > It's needed to copy spring-data-2.0 examples to spring-data-2.2 module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest
[ https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-14783: --- Summary: Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest (was: Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest) > Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest > -- > > Key: IGNITE-14783 > URL: https://issues.apache.org/jira/browse/IGNITE-14783 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Fix test fail: > IgniteCacheTestSuite9:SystemViewComputeJobTest.testCancelComputeTask -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-14783: --- Description: Fix test fail: IgniteCacheTestSuite9:SystemViewComputeJobTest.testCancelComputeTask was: Fix tests fail: IgniteCacheTestSuite9: - SystemViewComputeJobTest.testCancelComputeTask - IoStatisticsSelfTest.testPersistentIOGlobalStat > Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, > IoStatisticsSelfTest > > > Key: IGNITE-14783 > URL: https://issues.apache.org/jira/browse/IGNITE-14783 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Fix test fail: > IgniteCacheTestSuite9:SystemViewComputeJobTest.testCancelComputeTask -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov edited comment on IGNITE-14783 at 5/26/21, 4:19 PM:
--
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
race between
{code:java}
ComputeJobView.finishTime(ComputeJobView.java:165)
SystemViewComputeJobTest.checkJobView(SystemViewComputeJobTest.java:472)
SystemViewComputeJobTest.testCancelComputeTask(SystemViewComputeJobTest.java:424)
{code}
and
{code:java}
GridJobWorker.finishJob(GridJobWorker.java:833)
GridJobWorker.finishJob(GridJobWorker.java:818)
GridJobWorker.execute0(GridJobWorker.java:665)
GridJobWorker.body(GridJobWorker.java:522)
{code}
was (Author: ryzhovsv):
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage(int grpId, long pageId, IoStatisticsHolder
statHolder, boolean restore, @nullable AtomicBoolean pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
the call to IoStatisticsHolderCache.trackPhysicalAndLogicalRead happens when
reading from disk, it does not happen because the data is in memory
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14767) Ignite extensions: Copy spring-data-2.0 examples to spring-data-2.2 module.
[ https://issues.apache.org/jira/browse/IGNITE-14767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351897#comment-17351897 ] Amelchev Nikita commented on IGNITE-14767: -- Merged to the master. [~PetrovMikhail], thanks for the contribution. [~RyzhovSV], thanks for the review. > Ignite extensions: Copy spring-data-2.0 examples to spring-data-2.2 module. > --- > > Key: IGNITE-14767 > URL: https://issues.apache.org/jira/browse/IGNITE-14767 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > > It's needed to copy spring-data-2.0 examples to spring-data-2.2 module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14789) Thin client startup hangs if SSL protocol version does not match the server's one
[
https://issues.apache.org/jira/browse/IGNITE-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-14789:
Environment: (was:
)
Issue Type: Bug (was: Improvement)
> Thin client startup hangs if SSL protocol version does not match the server's
> one
> -
>
> Key: IGNITE-14789
> URL: https://issues.apache.org/jira/browse/IGNITE-14789
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>
> Thin client startup hangs if SSL protocol version does not match the server's
> one.
> The main reason -
> Exception that throws during thin client connection process (see
> IgniteException in
> org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter#sslHandler) remains
> unhandled
> That leads to AbstractNioClientWorker terminates abruptly and user thread
> hangs with the following thread dump
> {code:java}
> "test-runner-#1%ignite.InvalidSslProtocolTest%" #12 prio=5 os_prio=0
> tid=0x7f4be0a0c800 nid=0xc5b3 waiting on condition [0x7f4b779eb000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.client.thin.io.gridnioserver.GridNioClientConnectionMultiplexer.open(GridNioClientConnectionMultiplexer.java:136)
> at
> org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:166)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient$$Lambda$582/1885200808.apply(Unknown
> Source)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableChannel.java:877)
> - locked <0x00076e493918> (a
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableChannel.java:858)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.access$400(ReliableChannel.java:807)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.applyOnDefaultChannel(ReliableChannel.java:739)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.applyOnDefaultChannel(ReliableChannel.java:712)
> at
> org.apache.ignite.internal.client.thin.ReliableChannel.channelsInit(ReliableChannel.java:683)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:124)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:101)
> at
> org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:327)
> at org.apache.ignite.Ignition.startClient(Ignition.java:612)
> at
> org.apache.ignite.InvalidSslProtocolTest.test(InvalidSslProtocolTest.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Reproducer:
> {code:java}
> public class InvalidSslProtocolTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setClientConnectorConfiguration(new ClientConnectorConfiguration()
> .setSslEnabled(true)
> .setSslClientAuth(true)
> .setUseIgniteSslContextFactory(false)
> .setSslContextFactory(sslContextFactory("thinServer", "trusttwo",
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLSv1.2")));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid();
> Ignition.star
[jira] [Created] (IGNITE-14789) Thin client startup hangs if SSL protocol version does not match the server's one
Mikhail Petrov created IGNITE-14789:
---
Summary: Thin client startup hangs if SSL protocol version does
not match the server's one
Key: IGNITE-14789
URL: https://issues.apache.org/jira/browse/IGNITE-14789
Project: Ignite
Issue Type: Improvement
Environment:
Reporter: Mikhail Petrov
Thin client startup hangs if SSL protocol version does not match the server's
one.
The main reason -
Exception that throws during thin client connection process (see
IgniteException in
org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter#sslHandler) remains
unhandled
That leads to AbstractNioClientWorker terminates abruptly and user thread hangs
with the following thread dump
{code:java}
"test-runner-#1%ignite.InvalidSslProtocolTest%" #12 prio=5 os_prio=0
tid=0x7f4be0a0c800 nid=0xc5b3 waiting on condition [0x7f4b779eb000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at
org.apache.ignite.internal.client.thin.io.gridnioserver.GridNioClientConnectionMultiplexer.open(GridNioClientConnectionMultiplexer.java:136)
at
org.apache.ignite.internal.client.thin.TcpClientChannel.(TcpClientChannel.java:166)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient$$Lambda$582/1885200808.apply(Unknown
Source)
at
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableChannel.java:877)
- locked <0x00076e493918> (a
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder)
at
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.getOrCreateChannel(ReliableChannel.java:858)
at
org.apache.ignite.internal.client.thin.ReliableChannel$ClientChannelHolder.access$400(ReliableChannel.java:807)
at
org.apache.ignite.internal.client.thin.ReliableChannel.applyOnDefaultChannel(ReliableChannel.java:739)
at
org.apache.ignite.internal.client.thin.ReliableChannel.applyOnDefaultChannel(ReliableChannel.java:712)
at
org.apache.ignite.internal.client.thin.ReliableChannel.channelsInit(ReliableChannel.java:683)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:124)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.(TcpIgniteClient.java:101)
at
org.apache.ignite.internal.client.thin.TcpIgniteClient.start(TcpIgniteClient.java:327)
at org.apache.ignite.Ignition.startClient(Ignition.java:612)
at
org.apache.ignite.InvalidSslProtocolTest.test(InvalidSslProtocolTest.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
at java.lang.Thread.run(Thread.java:748)
{code}
Reproducer:
{code:java}
public class InvalidSslProtocolTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
cfg.setClientConnectorConfiguration(new ClientConnectorConfiguration()
.setSslEnabled(true)
.setSslClientAuth(true)
.setUseIgniteSslContextFactory(false)
.setSslContextFactory(sslContextFactory("thinServer", "trusttwo",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLSv1.2")));
return cfg;
}
/** */
@Test
public void test() throws Exception {
startGrid();
Ignition.startClient(new ClientConfiguration()
.setAddresses("127.0.0.1:10800")
.setSslMode(SslMode.REQUIRED)
.setSslContextFactory(sslContextFactory("thinClient", "trusttwo",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", "TLSv1.1")));
}
/** */
private SslContextFactory sslContextFactory(String keyStore, String
trustStore, String cipherSuite,
[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.
[
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13348:
-
Description:
It looks like, the data structure processor does not properly initialize when a
client node connects to a cluster that changes its own state (state transition
from the inactive state to active).
reproducer attached.
*UPDATE*
It seems to me, the root cause of the issue is that {{joinFut}} is always
completed with {{false}}.
{code:java|title=GridClusterStateProcessor.java}
/** {@inheritDoc} */
@Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
msg) {
DiscoveryDataClusterState discoClusterState = globalState;
if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
...
TransitionOnJoinWaitFuture joinFut = this.joinFut;
if (joinFut != null)
joinFut.onDone(false);
...
}
else
U.warn(log, "Received state finish message with unexpected ID: " +
msg);
}
{code}
On the other hand, this value is used to determine the state of the cluster
when a new node joins the cluster
{code:java|title=IgniteKernal.java}
public void start(
DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
IgniteInternalFuture transitionWaitFut =
joinData.transitionWaitFuture();
...
boolean active;
if (transitionWaitFut != null) {
if (log.isInfoEnabled()) {
log.info("Join cluster while cluster state transition is in
progress, waiting when transition finish.");
}
active = transitionWaitFut.get();
}
else
active = joinData.active();
startTimer.finishGlobalStage("Await transition");
...
}
{code}
User list discussion:
http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-node-hangs-while-IgniteAtomicLong-is-created-tp33537.html
was:
It looks like, the data structure processor does not properly initialize when a
client node connects to a cluster that changes its own state (state transition
from the inactive state to active).
reproducer attached.
*UPDATE*
It seems to me, the root cause of the issue is that {{joinFut}} is always
completed with {{false}}.
{code:java|title=GridClusterStateProcessor.java}
/** {@inheritDoc} */
@Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
msg) {
DiscoveryDataClusterState discoClusterState = globalState;
if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
...
TransitionOnJoinWaitFuture joinFut = this.joinFut;
if (joinFut != null)
joinFut.onDone(false);
...
}
else
U.warn(log, "Received state finish message with unexpected ID: " +
msg);
}
{code}
On the other hand, this value is used to determine the state of the cluster
when a new node joins the cluster
{code:java|title=IgniteKernal.java}
public void start(
DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
IgniteInternalFuture transitionWaitFut =
joinData.transitionWaitFuture();
...
boolean active;
if (transitionWaitFut != null) {
if (log.isInfoEnabled()) {
log.info("Join cluster while cluster state transition is in
progress, waiting when transition finish.");
}
active = transitionWaitFut.get();
}
else
active = joinData.active();
startTimer.finishGlobalStage("Await transition");
...
}
{code}
> Creating IgniteAtomicLong from the client node may hang.
>
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.11
>
> Attachments: DataStructuresInitializationTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when
> a client node connects to a cluster that changes its own state (state
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
> msg) {
> DiscoveryDataClusterStat
[jira] [Commented] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351825#comment-17351825 ] Sergei Ryzhov commented on IGNITE-14783: [~nizhikov] Could you please review > Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, > IoStatisticsSelfTest > > > Key: IGNITE-14783 > URL: https://issues.apache.org/jira/browse/IGNITE-14783 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Fix tests fail: > IgniteCacheTestSuite9: > - SystemViewComputeJobTest.testCancelComputeTask > - IoStatisticsSelfTest.testPersistentIOGlobalStat -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14788) Make all configuration schema fields public
[ https://issues.apache.org/jira/browse/IGNITE-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14788: --- Fix Version/s: 3.0.0-alpha2 > Make all configuration schema fields public > --- > > Key: IGNITE-14788 > URL: https://issues.apache.org/jira/browse/IGNITE-14788 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > As a preparation for https://issues.apache.org/jira/browse/IGNITE-14704 we > should do it. > Schema fields with default values must be visible from other packages. > Everything else is for uniformity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14788) Make all configuration schema fields public
[ https://issues.apache.org/jira/browse/IGNITE-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351819#comment-17351819 ] Sergey Chugunov commented on IGNITE-14788: -- [~ibessonov], Change looks reasonable to me, it looks natural for schema classes to have public fields. Feel free to merge the change to necessary branches. > Make all configuration schema fields public > --- > > Key: IGNITE-14788 > URL: https://issues.apache.org/jira/browse/IGNITE-14788 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > As a preparation for https://issues.apache.org/jira/browse/IGNITE-14704 we > should do it. > Schema fields with default values must be visible from other packages. > Everything else is for uniformity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14788) Make all configuration schema fields public
[ https://issues.apache.org/jira/browse/IGNITE-14788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14788: --- Description: As a preparation for https://issues.apache.org/jira/browse/IGNITE-14704 we should do it. Schema fields with default values must be visible from other packages. Everything else is for uniformity. was:As a preparation for https://issues.apache.org/jira/browse/IGNITE-14704 we should do it > Make all configuration schema fields public > --- > > Key: IGNITE-14788 > URL: https://issues.apache.org/jira/browse/IGNITE-14788 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > As a preparation for https://issues.apache.org/jira/browse/IGNITE-14704 we > should do it. > Schema fields with default values must be visible from other packages. > Everything else is for uniformity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov edited comment on IGNITE-14783 at 5/26/21, 2:09 PM:
--
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage(int grpId, long pageId, IoStatisticsHolder
statHolder, boolean restore, @nullable AtomicBoolean pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
the call to IoStatisticsHolderCache.trackPhysicalAndLogicalRead happens when
reading from disk, it does not happen because the data is in memory
one of the solutions, to increase the amount of loaded data
was (Author: ryzhovsv):
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage(int grpId, long pageId, IoStatisticsHolder
statHolder, boolean restore, @nullable AtomicBoolean pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
the call to IoStatisticsHolderCache.trackPhysicalAndLogicalRead occurs when
reading from the disk, it does not come as long as the data is in memory
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov edited comment on IGNITE-14783 at 5/26/21, 2:05 PM:
--
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage(int grpId, long pageId, IoStatisticsHolder
statHolder, boolean restore, @nullable AtomicBoolean pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
the call to IoStatisticsHolderCache.trackPhysicalAndLogicalRead occurs when
reading from the disk, it does not come as long as the data is in memory
one of the solutions, to increase the amount of loaded data
was (Author: ryzhovsv):
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage(int grpId, long pageId, IoStatisticsHolder
statHolder, boolean restore, @nullable AtomicBoolean pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14785) Switch table related tests from configuration API to SchemaBuilders
[ https://issues.apache.org/jira/browse/IGNITE-14785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351805#comment-17351805 ] Vladislav Pyatkov commented on IGNITE-14785: LGTM > Switch table related tests from configuration API to SchemaBuilders > --- > > Key: IGNITE-14785 > URL: https://issues.apache.org/jira/browse/IGNITE-14785 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov edited comment on IGNITE-14783 at 5/26/21, 1:51 PM:
--
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage(int grpId, long pageId, IoStatisticsHolder
statHolder, boolean restore, @nullable AtomicBoolean pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
was (Author: ryzhovsv):
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage method (int grpId, long pageId,
IoStatisticsHolder statHolder, boolean restore, @nullable AtomicBoolean
pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov edited comment on IGNITE-14783 at 5/26/21, 1:48 PM:
--
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage method (int grpId, long pageId,
IoStatisticsHolder statHolder, boolean restore, @nullable AtomicBoolean
pageAllocated)
{code:java}
long relPtr = seg.loadedPages.get(
grpId,
PageIdUtils.effectivePageId(pageId),
seg.partGeneration(grpId, partId),
INVALID_REL_PTR,
INVALID_REL_PTR
);
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
was (Author: ryzhovsv):
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage method (int grpId, long pageId,
IoStatisticsHolder statHolder, boolean restore, @nullable AtomicBoolean
pageAllocated)
{code:java}
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov edited comment on IGNITE-14783 at 5/26/21, 1:47 PM:
--
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage method (int grpId, long pageId,
IoStatisticsHolder statHolder, boolean restore, @nullable AtomicBoolean
pageAllocated)
{code:java}
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
{code}
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
was (Author: ryzhovsv):
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage method (int grpId, long pageId,
IoStatisticsHolder statHolder, boolean restore, @nullable AtomicBoolean
pageAllocated)
`
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
`
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351795#comment-17351795
]
Sergei Ryzhov commented on IGNITE-14783:
*SystemViewComputeJobTest.testCancelComputeTask*
when job cancel, job.finishTime more than 0
the test flaky because job.finishTime does not always have time to update
*IoStatisticsSelfTest.testPersistentIOGlobalStat*
in the PageMemoryImpl.acquirePage method (int grpId, long pageId,
IoStatisticsHolder statHolder, boolean restore, @nullable AtomicBoolean
pageAllocated)
`
// The page is loaded to the memory.
if (relPtr != INVALID_REL_PTR) {
long absPtr = seg.absolute(relPtr);
seg.acquirePage(absPtr);
seg.pageReplacementPolicy.onHit(relPtr);
statHolder.trackLogicalRead(absPtr + PAGE_OVERHEAD);
return absPtr;
}
`
so we don't call IoStatisticsHolderCache.trackPhysicalAndLogicalRead
one of the solutions, to increase the amount of loaded data
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351766#comment-17351766 ] Peter Ivanov edited comment on IGNITE-14017 at 5/26/21, 1:14 PM: - You can just attach new Dockerfile, or patch file with changes to current. Concerning Docker release — you have to raise discussion on Apache Ignite dev-list about necessity of including s390x Docker to release. I guess this time (nearest release 2.11) you can ping me directly about releasing s390x — I will check how it can be done in terms of tags and repositories. was (Author: vveider): You can just attach new Dockerfile, or patch file with changes to current. > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351766#comment-17351766 ] Peter Ivanov commented on IGNITE-14017: --- You can just attach new Dockerfile, or patch file with changes to current. > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351759#comment-17351759 ] Vibhuti Sawant commented on IGNITE-14017: - Thanks [~vveider]! Checked the review comments given on PR, wanted to confirm how could we deliver the required changes? Also, we would like to know the process followed to release Apache Ignite images to Dockerhub. > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14788) Make all configuration schema fields public
Ivan Bessonov created IGNITE-14788: -- Summary: Make all configuration schema fields public Key: IGNITE-14788 URL: https://issues.apache.org/jira/browse/IGNITE-14788 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov As a preparation for https://issues.apache.org/jira/browse/IGNITE-14704 we should do it -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14120) select count * returns multiple rows
[
https://issues.apache.org/jira/browse/IGNITE-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351686#comment-17351686
]
Alexey Plotnik edited comment on IGNITE-14120 at 5/26/21, 11:35 AM:
Steps to reproduce:
1. Add cache template configuration (queryParallelism = 4):
{code}
{code}
2. Create TABLE:
{code}
DROP TABLE SC_NULL_TEST;
CREATE TABLE SC_NULL_TEST (
ID INT(11),
VAL INT(11),
PRIMARY KEY (ID)
) WITH "template=cache-partitioned-query-parallelism, CACHE_NAME=SC_NULL_TEST";
{code}
3. Insert some sample data:
{code}
insert into SC_NULL_TEST VALUES(1, 1);
insert into SC_NULL_TEST VALUES(2, 1);
insert into SC_NULL_TEST VALUES(3, 1);
insert into SC_NULL_TEST VALUES(4, 1);
insert into SC_NULL_TEST VALUES(5, 1);
insert into SC_NULL_TEST VALUES(6, 1);
insert into SC_NULL_TEST VALUES(7, 1);
{code}
4. Do a full scan count query:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST;
++
|COUNT(*)|
++
| 1 |
++
1 row selected (0.003 seconds)
{code}
The result is correct.
5. Do a count query with where clause:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST where
id = 1;
++
|COUNT(*)|
++
| 0 |
| 1 |
| 0 |
| 0 |
++
4 rows selected (0.004 seconds)
{code}
Resultset size is equal to queryParallelism value
UPD 1: Reproduced on both single-node cluser and cluster of two nodes
was (Author: alexey.plotnik):
Steps to reproduce:
1. Add cache template configuration (queryParallelism = 4):
{code}
{code}
2. Create TABLE:
{code}
DROP TABLE SC_NULL_TEST;
CREATE TABLE SC_NULL_TEST (
ID INT(11),
VAL INT(11),
PRIMARY KEY (ID)
) WITH "template=cache-partitioned-query-parallelism, CACHE_NAME=SC_NULL_TEST";
{code}
3. Insert some sample data:
{code}
insert into SC_NULL_TEST VALUES(1, 1);
insert into SC_NULL_TEST VALUES(2, 1);
insert into SC_NULL_TEST VALUES(3, 1);
insert into SC_NULL_TEST VALUES(4, 1);
insert into SC_NULL_TEST VALUES(5, 1);
insert into SC_NULL_TEST VALUES(6, 1);
insert into SC_NULL_TEST VALUES(7, 1);
{code}
4. Do a full scan count query:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST;
++
|COUNT(*)|
++
| 1 |
++
1 row selected (0.003 seconds)
{code}
The result is correct.
5. Do a count query with where clause:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST where
id = 1;
++
|COUNT(*)|
++
| 0 |
| 1 |
| 0 |
| 0 |
++
4 rows selected (0.004 seconds)
{code}
Resultset size is equal to queryParallelism value
> select count * returns multiple rows
>
>
> Key: IGNITE-14120
> URL: https://issues.apache.org/jira/browse/IGNITE-14120
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Isaac Zhu
>Priority: Major
>
> I have a partitioned table which has 1 backup, the *queryParallelism* is set
> to 4.
> The table primary key is column "ID",
> If I do this query:
> select count( * ) from my_table where ID = 1000;
> It will return 4 rows:
> 1
> 0
> 0
> 0
>
> If I query by other not primary-key columns of this table, the result is
> good, like:
> select count( *) from my_table where name = 'abcd'
> result is:
> 0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14120) select count * returns multiple rows
[
https://issues.apache.org/jira/browse/IGNITE-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351686#comment-17351686
]
Alexey Plotnik edited comment on IGNITE-14120 at 5/26/21, 11:14 AM:
Steps to reproduce:
1. Add cache template configuration (queryParallelism = 4):
{code}
{code}
2. Create TABLE:
{code}
DROP TABLE SC_NULL_TEST;
CREATE TABLE SC_NULL_TEST (
ID INT(11),
VAL INT(11),
PRIMARY KEY (ID)
) WITH "template=cache-partitioned-query-parallelism, CACHE_NAME=SC_NULL_TEST";
{code}
3. Insert some sample data:
{code}
insert into SC_NULL_TEST VALUES(1, 1);
insert into SC_NULL_TEST VALUES(2, 1);
insert into SC_NULL_TEST VALUES(3, 1);
insert into SC_NULL_TEST VALUES(4, 1);
insert into SC_NULL_TEST VALUES(5, 1);
insert into SC_NULL_TEST VALUES(6, 1);
insert into SC_NULL_TEST VALUES(7, 1);
{code}
4. Do a full scan count query:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST;
++
|COUNT(*)|
++
| 1 |
++
1 row selected (0.003 seconds)
{code}
The result is correct.
5. Do a count query with where clause:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST where
id = 1;
++
|COUNT(*)|
++
| 0 |
| 1 |
| 0 |
| 0 |
++
4 rows selected (0.004 seconds)
{code}
Resultset size is equal to queryParallelism value
was (Author: alexey.plotnik):
Steps to reproduce:
1. Add cache template configuration (queryParallelism = 4):
{code}
{code}
2. Create TABLE:
{code}
DROP TABLE SC_NULL_TEST;
CREATE TABLE SC_NULL_TEST (
ID INT(11),
VAL INT(11),
PRIMARY KEY (ID)
) WITH "template=cache-partitioned-query-parallelism, CACHE_NAME=SC_NULL_TEST";
{code}
3. Insert some sample data:
{code}
insert into SC_NULL_TEST VALUES(1, 1);
{code}
4. Do a full scan count query:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST;
++
|COUNT(*)|
++
| 1 |
++
1 row selected (0.003 seconds)
{code}
The result is correct.
5. Do a count query with where clause:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST where
id = 1;
++
|COUNT(*)|
++
| 0 |
| 1 |
| 0 |
| 0 |
++
4 rows selected (0.004 seconds)
{code}
Resultset size is equal to queryParallelism value
> select count * returns multiple rows
>
>
> Key: IGNITE-14120
> URL: https://issues.apache.org/jira/browse/IGNITE-14120
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Isaac Zhu
>Priority: Major
>
> I have a partitioned table which has 1 backup, the *queryParallelism* is set
> to 4.
> The table primary key is column "ID",
> If I do this query:
> select count( * ) from my_table where ID = 1000;
> It will return 4 rows:
> 1
> 0
> 0
> 0
>
> If I query by other not primary-key columns of this table, the result is
> good, like:
> select count( *) from my_table where name = 'abcd'
> result is:
> 0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14785) Switch table related tests from configuration API to SchemaBuilders
[ https://issues.apache.org/jira/browse/IGNITE-14785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351696#comment-17351696 ] Alexander Belyak commented on IGNITE-14785: --- https://github.com/apache/ignite-3/pull/150 > Switch table related tests from configuration API to SchemaBuilders > --- > > Key: IGNITE-14785 > URL: https://issues.apache.org/jira/browse/IGNITE-14785 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Alexander Belyak >Assignee: Alexander Belyak >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14120) select count * returns multiple rows
[
https://issues.apache.org/jira/browse/IGNITE-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351686#comment-17351686
]
Alexey Plotnik commented on IGNITE-14120:
-
Steps to reproduce:
1. Add cache template configuration (queryParallelism = 4):
{code}
{code}
2. Create TABLE:
{code}
DROP TABLE SC_NULL_TEST;
CREATE TABLE SC_NULL_TEST (
ID INT(11),
VAL INT(11),
PRIMARY KEY (ID)
) WITH "template=cache-partitioned-query-parallelism, CACHE_NAME=SC_NULL_TEST";
{code}
3. Insert some sample data:
{code}
insert into SC_NULL_TEST VALUES(1, 1);
{code}
4. Do a full scan count query:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST;
++
|COUNT(*)|
++
| 1 |
++
1 row selected (0.003 seconds)
{code}
The result is correct.
5. Do a count query with where clause:
{code}
0: jdbc:ignite:thin://127.0.0.1/PUBLIC> select count(*) from SC_NULL_TEST where
id = 1;
++
|COUNT(*)|
++
| 0 |
| 1 |
| 0 |
| 0 |
++
4 rows selected (0.004 seconds)
{code}
Resultset size is equal to queryParallelism value
> select count * returns multiple rows
>
>
> Key: IGNITE-14120
> URL: https://issues.apache.org/jira/browse/IGNITE-14120
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Isaac Zhu
>Priority: Major
>
> I have a partitioned table which has 1 backup, the *queryParallelism* is set
> to 4.
> The table primary key is column "ID",
> If I do this query:
> select count( * ) from my_table where ID = 1000;
> It will return 4 rows:
> 1
> 0
> 0
> 0
>
> If I query by other not primary-key columns of this table, the result is
> good, like:
> select count( *) from my_table where name = 'abcd'
> result is:
> 0
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13693) Add flags field with tombstone support, update schema size to 2 bytes
[ https://issues.apache.org/jira/browse/IGNITE-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-13693. --- Resolution: Duplicate > Add flags field with tombstone support, update schema size to 2 bytes > - > > Key: IGNITE-13693 > URL: https://issues.apache.org/jira/browse/IGNITE-13693 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > > After the IEP discussion, we agreed to extend the schema identifier size to 2 > bytes and introduce flags byte to support tombstones. Need to implement these > enhancements in the Tuple and TupleAssembler. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14787) ConnectionManager and H2Connection hard-coded sizes
João Fonseca created IGNITE-14787: - Summary: ConnectionManager and H2Connection hard-coded sizes Key: IGNITE-14787 URL: https://issues.apache.org/jira/browse/IGNITE-14787 Project: Ignite Issue Type: Improvement Reporter: João Fonseca There are hard-coded sizes used for internal structures in org.apache.ignite.internal.processors.query.h2.H2Connection (STATEMENT_CACHE_SIZE=256) and org.apache.ignite.internal.processors.query.h2.ConnectionManager (DFLT_CONNECTION_POOL_SIZE=32). Also, the ConnectionManager creates a ConcurrentStripedPool with stripes based on the number of CPUs (configurable using queryThreadPoolSize, which by default = CPUs). All the above can lead to excessive memory usage in servers with many CPUs. In my case, I'm running it on a 56 CPU machine, giving: 56 * 32 * 256 -> roughly half a million prepared statements 56 * 32 = 1792 connections I was only able to limit these numbers through the queryThreadPoolSize, but there should be a way of also controlling the size of each stripe and prepared statement caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13693) Add flags field with tombstone support, update schema size to 2 bytes
[ https://issues.apache.org/jira/browse/IGNITE-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-13693: -- Fix Version/s: 3.0.0-alpha2 > Add flags field with tombstone support, update schema size to 2 bytes > - > > Key: IGNITE-13693 > URL: https://issues.apache.org/jira/browse/IGNITE-13693 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha2 > > > After the IEP discussion, we agreed to extend the schema identifier size to 2 > bytes and introduce flags byte to support tombstones. Need to implement these > enhancements in the Tuple and TupleAssembler. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14733) NativeType and ColumnType names should matches.
[ https://issues.apache.org/jira/browse/IGNITE-14733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14733: -- Fix Version/s: 3.0.0-alpha3 > NativeType and ColumnType names should matches. > --- > > Key: IGNITE-14733 > URL: https://issues.apache.org/jira/browse/IGNITE-14733 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Trivial > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > For now, column types names contains their sizes like ColumnType.INT8, > ColumnType.INT16 and so on, to abstract from the platform Ignite can be used > on (via thin-clients). > But we use Java-specific notation for internal types: NativeType.BYTE, > NativeType.LONG. > Let's rename NativeTypes to easily match them to/from column type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14743) Support Row with large values.
[
https://issues.apache.org/jira/browse/IGNITE-14743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14743:
--
Fix Version/s: (was: 3.0)
> Support Row with large values.
> --
>
> Key: IGNITE-14743
> URL: https://issues.apache.org/jira/browse/IGNITE-14743
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: iep-54, ignite-3
>
> For now, TupleAssembler writes offsets for varlen columns as 2-byte \{{short
> }}type.
> This implicitly restricts key/value sizes down to 64 kB in total.
> Let's use 4-bytes {{int}} type for offsets for large tuples.
> Possible ways are:
> # Just use ints for offsets, this increases the memory overhead for Rows.
> # Pre-calculate potential row size during SchemaDescriptor initialization
> and keep 'offset_size' in schema.
> Unlimited varlen type (which is default) usage will end-up user will have
> 4-byte offset size in most cases.
> # Pre-calculate exact tuple size for each row and use row flags.
> This requires Tuple data analysis which we already do to detect non-null
> varlen values and nulls. Strings may be a headache as we have to analyze each
> char for accurate tuple size calculation.
> # Pre-calculate tuple size skipping chars analysis.
> Using adaptive offset_size approaches allows us to use 1-2-4 byte numbers
> (byte, short, int) for offsets.
> Collations for String columns may be introduced and used as a hint, but we
> will need to check a collation for every char on write.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14743) Support Row with large values.
[
https://issues.apache.org/jira/browse/IGNITE-14743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14743:
--
Fix Version/s: 3.0.0-alpha3
> Support Row with large values.
> --
>
> Key: IGNITE-14743
> URL: https://issues.apache.org/jira/browse/IGNITE-14743
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0.0-alpha3
>
>
> For now, TupleAssembler writes offsets for varlen columns as 2-byte \{{short
> }}type.
> This implicitly restricts key/value sizes down to 64 kB in total.
> Let's use 4-bytes {{int}} type for offsets for large tuples.
> Possible ways are:
> # Just use ints for offsets, this increases the memory overhead for Rows.
> # Pre-calculate potential row size during SchemaDescriptor initialization
> and keep 'offset_size' in schema.
> Unlimited varlen type (which is default) usage will end-up user will have
> 4-byte offset size in most cases.
> # Pre-calculate exact tuple size for each row and use row flags.
> This requires Tuple data analysis which we already do to detect non-null
> varlen values and nulls. Strings may be a headache as we have to analyze each
> char for accurate tuple size calculation.
> # Pre-calculate tuple size skipping chars analysis.
> Using adaptive offset_size approaches allows us to use 1-2-4 byte numbers
> (byte, short, int) for offsets.
> Collations for String columns may be introduced and used as a hint, but we
> will need to check a collation for every char on write.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14746) Improve row layout. Omit offset for the first varlen.
[ https://issues.apache.org/jira/browse/IGNITE-14746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14746: -- Fix Version/s: (was: 3.0) 3.0.0-alpha3 > Improve row layout. Omit offset for the first varlen. > - > > Key: IGNITE-14746 > URL: https://issues.apache.org/jira/browse/IGNITE-14746 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > Actually, there is no need to write varlen offset for the very first varlen > column. > Therefore, vartable can be skipped if a single varlen column is defined for > key and/or value. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14783) Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest, IoStatisticsSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-14783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351682#comment-17351682
]
Ignite TC Bot commented on IGNITE-14783:
{panel:title=Branch: [pull/9129/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9129/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=6022774&buildTypeId=IgniteTests24Java8_RunAll]
> Fix tests fail: IgniteCacheTestSuite9:SystemViewComputeJobTest,
> IoStatisticsSelfTest
>
>
> Key: IGNITE-14783
> URL: https://issues.apache.org/jira/browse/IGNITE-14783
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Fix tests fail:
> IgniteCacheTestSuite9:
> - SystemViewComputeJobTest.testCancelComputeTask
> - IoStatisticsSelfTest.testPersistentIOGlobalStat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14743) Support Row with large values.
[
https://issues.apache.org/jira/browse/IGNITE-14743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14743:
--
Description:
For now, TupleAssembler writes offsets for varlen columns as 2-byte \{{short
}}type.
This implicitly restricts key/value sizes down to 64 kB in total.
Let's use 4-bytes {{int}} type for offsets for large tuples.
Possible ways are:
# Just use ints for offsets, this increases the memory overhead for Rows.
# Pre-calculate potential row size during SchemaDescriptor initialization and
keep 'offset_size' in schema.
Unlimited varlen type (which is default) usage will end-up user will have
4-byte offset size in most cases.
# Pre-calculate exact tuple size for each row and use row flags.
This requires Tuple data analysis which we already do to detect non-null
varlen values and nulls. Strings may be a headache as we have to analyze each
char for accurate tuple size calculation.
# Pre-calculate tuple size skipping chars analysis.
Using adaptive offset_size approaches allows us to use 1-2-4 byte numbers
(byte, short, int) for offsets.
Collations for String columns may be introduced and used as a hint, but we will
need to check a collation for every char on write.
was:
For now, TupleAssembler writes offsets for varlen columns as 2-byte {{short
}}type.
This implicitly restricts key/value sizes down to 64 kB in total.
Let's use 4-bytes {{int}} type for offsets for large tuples.
Possible ways are:
# Just use ints for offsets, this increases the memory overhead for Rows.
# Pre-calculate potential row size during SchemaDescriptor initialization and
keep 'offset_size' in schema.
Unlimited varlen type (which is default) usage will end-up user will have
4-byte offset size in most cases.
# Pre-calculate exact tuple size for each row and use row flags.
This requires Tuple data analysis which we already do to detect non-null varlen
values and nulls. Strings may be a headache as we have to analyze each char for
accurate tuple size calculation.
# Pre-calculate tuple size skipping chars analysis.
Using adaptive offset_size approaches allows us to use 1-2-4 byte numbers
(byte, short, int) for offsets.
Collations for String columns may be introduced and used as a hint, but we will
need to check a collation for every char on write.
'Large keys' is an unwanted case, may a solution for values only will be
enough...
> Support Row with large values.
> --
>
> Key: IGNITE-14743
> URL: https://issues.apache.org/jira/browse/IGNITE-14743
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Priority: Major
> Labels: iep-54, ignite-3
> Fix For: 3.0
>
>
> For now, TupleAssembler writes offsets for varlen columns as 2-byte \{{short
> }}type.
> This implicitly restricts key/value sizes down to 64 kB in total.
> Let's use 4-bytes {{int}} type for offsets for large tuples.
> Possible ways are:
> # Just use ints for offsets, this increases the memory overhead for Rows.
> # Pre-calculate potential row size during SchemaDescriptor initialization
> and keep 'offset_size' in schema.
> Unlimited varlen type (which is default) usage will end-up user will have
> 4-byte offset size in most cases.
> # Pre-calculate exact tuple size for each row and use row flags.
> This requires Tuple data analysis which we already do to detect non-null
> varlen values and nulls. Strings may be a headache as we have to analyze each
> char for accurate tuple size calculation.
> # Pre-calculate tuple size skipping chars analysis.
> Using adaptive offset_size approaches allows us to use 1-2-4 byte numbers
> (byte, short, int) for offsets.
> Collations for String columns may be introduced and used as a hint, but we
> will need to check a collation for every char on write.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14709) Make ConfigurationStorage#readAll async
[
https://issues.apache.org/jira/browse/IGNITE-14709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-14709:
Assignee: Mirza Aliev
> Make ConfigurationStorage#readAll async
> ---
>
> Key: IGNITE-14709
> URL: https://issues.apache.org/jira/browse/IGNITE-14709
> Project: Ignite
> Issue Type: Improvement
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Currently, we faced with a problem when a node starts it is hanged on phase
> when we register {{DistributedConfigurationStorage}}. It happens because when
> {{ConfigurationChanger#register}} is run it requires
> {{ConfigurationStorage#readAll}}, this, in turn, calls
> {{MetaStorageServiceImpl#range}}, but the range is waiting on future until
> cluster init happens, so all process of starting node is hanged.
> Could be reproduced in
> {{IgnitionTest#testNodeStartWithoutBootstrapConfiguration}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14732) Use enum sort order in index columns configuration.
[
https://issues.apache.org/jira/browse/IGNITE-14732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351676#comment-17351676
]
Konstantin Orlov commented on IGNITE-14732:
---
[~amashenkov], LGTM!
> Use enum sort order in index columns configuration.
> ---
>
> Key: IGNITE-14732
> URL: https://issues.apache.org/jira/browse/IGNITE-14732
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Trivial
> Labels: iep-54, ignite-3
> Fix For: 3.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Now SortedIndexColumn interface has method that returns boolean for sort
> order.
> {code:java}
> boolean asc();{code}
> Let's introduce a enum Sort with ASC/DESC values for this.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14739) Enable a permanent wal recording of transactions states records.
[ https://issues.apache.org/jira/browse/IGNITE-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351657#comment-17351657 ] Stanilovsky Evgeny commented on IGNITE-14739: - [~ascherbakov] this drop is a payment for the correctness ) May be after your mention with incorrect logic it will reduce a bit. However i still suppose that this drop is negligible in comparison with fix that it contains. No one rejection on dev list found. > Enable a permanent wal recording of transactions states records. > > > Key: IGNITE-14739 > URL: https://issues.apache.org/jira/browse/IGNITE-14739 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > After [1] was merged, i suggest to enable transactions states wal logging on > a permanent basis. This will allow to correctly restore transactional states > after partial or whole nodes crash. > [1] https://issues.apache.org/jira/browse/IGNITE-6324 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14786) Authentication ducktest should not use internal api
Mikhail Filatov created IGNITE-14786: Summary: Authentication ducktest should not use internal api Key: IGNITE-14786 URL: https://issues.apache.org/jira/browse/IGNITE-14786 Project: Ignite Issue Type: Task Reporter: Mikhail Filatov Assignee: Mikhail Filatov Internal API used in test are different now. It's better to replace internal api usage to thin client (official documentation way) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14739) Enable a permanent wal recording of transactions states records.
[ https://issues.apache.org/jira/browse/IGNITE-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351647#comment-17351647 ] Alexey Scherbakov commented on IGNITE-14739: Additionally, the change if (ptr != null && !cctx.tm().logTxRecords()) -> if (ptr != null seems incorrect, because if tx logging is enabled, we will flush the WAL in [1] [1] org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter#state(org.apache.ignite.transactions.TransactionState, boolean) > Enable a permanent wal recording of transactions states records. > > > Key: IGNITE-14739 > URL: https://issues.apache.org/jira/browse/IGNITE-14739 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > After [1] was merged, i suggest to enable transactions states wal logging on > a permanent basis. This will allow to correctly restore transactional states > after partial or whole nodes crash. > [1] https://issues.apache.org/jira/browse/IGNITE-6324 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14774) Add metrics for index pages loaded into memory
[ https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14774: - Release Note: Added new metrics for monitoring the number of memory pages related to SQL indexes. These metrics can be made available through JMX and viewed as part of data region and cache group properties under the `InMemoryIndexPages` name. > Add metrics for index pages loaded into memory > -- > > Key: IGNITE-14774 > URL: https://issues.apache.org/jira/browse/IGNITE-14774 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Expose the number of index pages currently loaded into memory on per-cache > group and per-data region basis. > h3. Implementation details > # PageMetrics - an aggregation of all page-related metrics. At the moment of > writing, contains the total number of pages and the number of index pages. > # DataRegionMetricsImpl now contains page metrics related to every created > cache group in a form of an immutable copy-on-write IntMap. It also contains > an aggregation over these metrics that can be used as metrics for the whole > data region. > # Index pages allocation is tracked through the PageIO#initNewPage method, > which can later be used to track other kinds of pages. > # Index pages de-allocation is tracked in various places like replacing a > page or adding it to a free list as I couldn’t find a single suitable place > for this logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14739) Enable a permanent wal recording of transactions states records.
[ https://issues.apache.org/jira/browse/IGNITE-14739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351643#comment-17351643 ] Alexey Scherbakov commented on IGNITE-14739: [~zstan] It seems we have performance drop comparing to master revision #626168e1 I'm not sure it's ok to enable tx logging by default, considering the fact the fix in IGNITE-6324 is only partial. > Enable a permanent wal recording of transactions states records. > > > Key: IGNITE-14739 > URL: https://issues.apache.org/jira/browse/IGNITE-14739 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: screenshot-1.png > > Time Spent: 10m > Remaining Estimate: 0h > > After [1] was merged, i suggest to enable transactions states wal logging on > a permanent basis. This will allow to correctly restore transactional states > after partial or whole nodes crash. > [1] https://issues.apache.org/jira/browse/IGNITE-6324 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14774) Add metrics for index pages loaded into memory
[ https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14774: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Add metrics for index pages loaded into memory > -- > > Key: IGNITE-14774 > URL: https://issues.apache.org/jira/browse/IGNITE-14774 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Expose the number of index pages currently loaded into memory on per-cache > group and per-data region basis. > h3. Implementation details > # PageMetrics - an aggregation of all page-related metrics. At the moment of > writing, contains the total number of pages and the number of index pages. > # DataRegionMetricsImpl now contains page metrics related to every created > cache group in a form of an immutable copy-on-write IntMap. It also contains > an aggregation over these metrics that can be used as metrics for the whole > data region. > # Index pages allocation is tracked through the PageIO#initNewPage method, > which can later be used to track other kinds of pages. > # Index pages de-allocation is tracked in various places like replacing a > page or adding it to a free list as I couldn’t find a single suitable place > for this logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14774) Add metrics for index pages loaded into memory
[ https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-14774: - Affects Version/s: (was: 2.10) > Add metrics for index pages loaded into memory > -- > > Key: IGNITE-14774 > URL: https://issues.apache.org/jira/browse/IGNITE-14774 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Expose the number of index pages currently loaded into memory on per-cache > group and per-data region basis. > h3. Implementation details > # PageMetrics - an aggregation of all page-related metrics. At the moment of > writing, contains the total number of pages and the number of index pages. > # DataRegionMetricsImpl now contains page metrics related to every created > cache group in a form of an immutable copy-on-write IntMap. It also contains > an aggregation over these metrics that can be used as metrics for the whole > data region. > # Index pages allocation is tracked through the PageIO#initNewPage method, > which can later be used to track other kinds of pages. > # Index pages de-allocation is tracked in various places like replacing a > page or adding it to a free list as I couldn’t find a single suitable place > for this logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14774) Add metrics for index pages loaded into memory
[ https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351640#comment-17351640 ] Ivan Bessonov commented on IGNITE-14774: [~apolovtcev] thank you for the contribution! PR looks good, I'm looking forward for other additions to data regions metrics. > Add metrics for index pages loaded into memory > -- > > Key: IGNITE-14774 > URL: https://issues.apache.org/jira/browse/IGNITE-14774 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.11 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Expose the number of index pages currently loaded into memory on per-cache > group and per-data region basis. > h3. Implementation details > # PageMetrics - an aggregation of all page-related metrics. At the moment of > writing, contains the total number of pages and the number of index pages. > # DataRegionMetricsImpl now contains page metrics related to every created > cache group in a form of an immutable copy-on-write IntMap. It also contains > an aggregation over these metrics that can be used as metrics for the whole > data region. > # Index pages allocation is tracked through the PageIO#initNewPage method, > which can later be used to track other kinds of pages. > # Index pages de-allocation is tracked in various places like replacing a > page or adding it to a free list as I couldn’t find a single suitable place > for this logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14774) Add metrics for index pages loaded into memory
[ https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14774: --- Affects Version/s: (was: 2.11) 2.10 > Add metrics for index pages loaded into memory > -- > > Key: IGNITE-14774 > URL: https://issues.apache.org/jira/browse/IGNITE-14774 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.10 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Expose the number of index pages currently loaded into memory on per-cache > group and per-data region basis. > h3. Implementation details > # PageMetrics - an aggregation of all page-related metrics. At the moment of > writing, contains the total number of pages and the number of index pages. > # DataRegionMetricsImpl now contains page metrics related to every created > cache group in a form of an immutable copy-on-write IntMap. It also contains > an aggregation over these metrics that can be used as metrics for the whole > data region. > # Index pages allocation is tracked through the PageIO#initNewPage method, > which can later be used to track other kinds of pages. > # Index pages de-allocation is tracked in various places like replacing a > page or adding it to a free list as I couldn’t find a single suitable place > for this logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14774) Add metrics for index pages loaded into memory
[ https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351635#comment-17351635 ] Aleksandr Polovtcev commented on IGNITE-14774: -- [~ibessonov] please have a look at the PR. > Add metrics for index pages loaded into memory > -- > > Key: IGNITE-14774 > URL: https://issues.apache.org/jira/browse/IGNITE-14774 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.11 >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > Expose the number of index pages currently loaded into memory on per-cache > group and per-data region basis. > h3. Implementation details > # PageMetrics - an aggregation of all page-related metrics. At the moment of > writing, contains the total number of pages and the number of index pages. > # DataRegionMetricsImpl now contains page metrics related to every created > cache group in a form of an immutable copy-on-write IntMap. It also contains > an aggregation over these metrics that can be used as metrics for the whole > data region. > # Index pages allocation is tracked through the PageIO#initNewPage method, > which can later be used to track other kinds of pages. > # Index pages de-allocation is tracked in various places like replacing a > page or adding it to a free list as I couldn’t find a single suitable place > for this logic. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14774) Add metrics for index pages loaded into memory
[
https://issues.apache.org/jira/browse/IGNITE-14774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351633#comment-17351633
]
Ignite TC Bot commented on IGNITE-14774:
{panel:title=Branch: [pull/9125/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9125/head] Base: [master] : New Tests
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 7{color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=6022390]]
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPersistentTest.testStoreAndDeleteCacheGrp[numCaches = 1] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPersistentTest.testStoreAndRemoveSomeEntries[numCaches = 3] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPersistentTest.testStoreAndRemoveSomeEntries[numCaches = 1] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPersistentTest.testStoreAndDeleteEntries[numCaches = 1] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPageDisplacementTest.testPageDisplacement - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPersistentTest.testStoreAndDeleteEntries[numCaches = 3] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
IndexPagesMetricsPersistentTest.testStoreAndDeleteCacheGrp[numCaches = 3] -
PASSED{color}
{color:#8b}Cache 5{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6021326]]
* {color:#013220}IgniteCacheWithIndexingTestSuite:
IndexPagesMetricsInMemoryTest.testStoreAndRemoveSomeEntries[numCaches = 1] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingTestSuite:
IndexPagesMetricsInMemoryTest.testStoreAndDeleteEntries[numCaches = 1] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingTestSuite:
IndexPagesMetricsInMemoryTest.testStoreAndDeleteEntries[numCaches = 3] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingTestSuite:
IndexPagesMetricsInMemoryTest.testStoreAndDeleteCacheGrp[numCaches = 3] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingTestSuite:
IndexPagesMetricsInMemoryTest.testStoreAndDeleteCacheGrp[numCaches = 1] -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingTestSuite:
IndexPagesMetricsInMemoryTest.testStoreAndRemoveSomeEntries[numCaches = 3] -
PASSED{color}
{color:#8b}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6021306]]
* {color:#013220}IgniteBasicTestSuite: IntHashMapTest.testCopyConstructor -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6021368&buildTypeId=IgniteTests24Java8_RunAll]
> Add metrics for index pages loaded into memory
> --
>
> Key: IGNITE-14774
> URL: https://issues.apache.org/jira/browse/IGNITE-14774
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.11
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Expose the number of index pages currently loaded into memory on per-cache
> group and per-data region basis.
> h3. Implementation details
> # PageMetrics - an aggregation of all page-related metrics. At the moment of
> writing, contains the total number of pages and the number of index pages.
> # DataRegionMetricsImpl now contains page metrics related to every created
> cache group in a form of an immutable copy-on-write IntMap. It also contains
> an aggregation over these metrics that can be used as metrics for the whole
> data region.
> # Index pages allocation is tracked through the PageIO#initNewPage method,
> which can later be used to track other kinds of pages.
> # Index pages de-allocation is tracked in various places like replacing a
> page or adding it to a free list as I couldn’t find a single suitable place
> for this logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14259) Ducktests pre-merge presentation
[ https://issues.apache.org/jira/browse/IGNITE-14259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov resolved IGNITE-14259. --- Resolution: Fixed > Ducktests pre-merge presentation > > > Key: IGNITE-14259 > URL: https://issues.apache.org/jira/browse/IGNITE-14259 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > A webinar-like presentation is required to discuss what we got before the > merge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14781) Ignite examples from binary package fail to build due to ClientKubernetesPutGetExample
[
https://issues.apache.org/jira/browse/IGNITE-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-14781:
Reviewer: Ilya Kasnacheev
> Ignite examples from binary package fail to build due to
> ClientKubernetesPutGetExample
> --
>
> Key: IGNITE-14781
> URL: https://issues.apache.org/jira/browse/IGNITE-14781
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Blocker
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.11.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ignite-examples ---
> [INFO]
> [INFO] --- build-helper-maven-plugin:3.2.0:add-source (add-sources) @
> ignite-examples ---
> [INFO] Source directory:
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java
> added.
> [INFO] Source directory:
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java
> added.
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> ignite-examples ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 14 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 266 source files to
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/target/classes
> [INFO] -
> [WARNING] COMPILATION WARNING :
> [INFO] -
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheAsyncApiExample.java:
> Some input files use or override a deprecated API.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheAsyncApiExample.java:
> Recompile with -Xlint:deprecation for details.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/store/CacheLoadOnlyStoreExample.java:
> Some input files use unchecked or unsafe operations.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/store/CacheLoadOnlyStoreExample.java:
> Recompile with -Xlint:unchecked for details.
> [INFO] 4 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[23,32]
> cannot find symbol
> symbol: class ThinClientKubernetesAddressFinder
> location: package org.apache.ignite.client
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[26,50]
> package org.apache.ignite.kubernetes.configuration does not exist
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[42,9]
> cannot find symbol
> symbol: class KubernetesConnectionConfiguration
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[42,54]
> cannot find symbol
> symbol: class KubernetesConnectionConfiguration
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[46,36]
> cannot find symbol
> symbol: class ThinClientKubernetesAddressFinder
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [INFO] 5 errors
[jira] [Commented] (IGNITE-14781) Ignite examples from binary package fail to build due to ClientKubernetesPutGetExample
[
https://issues.apache.org/jira/browse/IGNITE-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351605#comment-17351605
]
Maksim Timonin commented on IGNITE-14781:
-
Hi [~ilyak]! I've submitted a fix, please have a look.
> Ignite examples from binary package fail to build due to
> ClientKubernetesPutGetExample
> --
>
> Key: IGNITE-14781
> URL: https://issues.apache.org/jira/browse/IGNITE-14781
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Blocker
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code}
> ~/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples% mvn clean install
> [INFO]
> [INFO] -< org.apache.ignite:ignite-examples
> >--
> [INFO] Building ignite-examples 2.11.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ignite-examples ---
> [INFO]
> [INFO] --- build-helper-maven-plugin:3.2.0:add-source (add-sources) @
> ignite-examples ---
> [INFO] Source directory:
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java
> added.
> [INFO] Source directory:
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java
> added.
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> ignite-examples ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 14 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> ignite-examples ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 266 source files to
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/target/classes
> [INFO] -
> [WARNING] COMPILATION WARNING :
> [INFO] -
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheAsyncApiExample.java:
> Some input files use or override a deprecated API.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/CacheAsyncApiExample.java:
> Recompile with -Xlint:deprecation for details.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/store/CacheLoadOnlyStoreExample.java:
> Some input files use unchecked or unsafe operations.
> [WARNING]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/datagrid/store/CacheLoadOnlyStoreExample.java:
> Recompile with -Xlint:unchecked for details.
> [INFO] 4 warnings
> [INFO] -
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[23,32]
> cannot find symbol
> symbol: class ThinClientKubernetesAddressFinder
> location: package org.apache.ignite.client
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[26,50]
> package org.apache.ignite.kubernetes.configuration does not exist
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[42,9]
> cannot find symbol
> symbol: class KubernetesConnectionConfiguration
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[42,54]
> cannot find symbol
> symbol: class KubernetesConnectionConfiguration
> location: class
> org.apache.ignite.examples.client.ClientKubernetesPutGetExample
> [ERROR]
> /home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/examples/src/main/java/org/apache/ignite/examples/client/ClientKubernetesPutGetExample.java:[46,36]
> cannot find symbol
> symbol: class ThinClientKubernetesAddressFinder
> location: class
[jira] [Created] (IGNITE-14785) Switch table related tests from configuration API to SchemaBuilders
Alexander Belyak created IGNITE-14785: - Summary: Switch table related tests from configuration API to SchemaBuilders Key: IGNITE-14785 URL: https://issues.apache.org/jira/browse/IGNITE-14785 Project: Ignite Issue Type: Improvement Components: sql Reporter: Alexander Belyak Assignee: Alexander Belyak -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14638) Calcite engine. Support for INTERSECT operator
[
https://issues.apache.org/jira/browse/IGNITE-14638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351579#comment-17351579
]
Aleksey Plekhanov commented on IGNITE-14638:
[~tledkov-gridgain], thanks for your comments. I've created the ticket and
added the new check to the {{assertPlan}} method. Please have a look again.
> Calcite engine. Support for INTERSECT operator
> --
>
> Key: IGNITE-14638
> URL: https://issues.apache.org/jira/browse/IGNITE-14638
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, INTERSECT operator is not supported
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14784) Calcite engine. Add sorted set op (EXCEPT, INTERSECT) implementation
Aleksey Plekhanov created IGNITE-14784:
--
Summary: Calcite engine. Add sorted set op (EXCEPT, INTERSECT)
implementation
Key: IGNITE-14784
URL: https://issues.apache.org/jira/browse/IGNITE-14784
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Currently, we have hash-map based implementations for EXCEPT and INTERSECT
operators (see {{IgniteIntersect}}, {{IgniteMinus}}, {{AbstractSetOpNode}}
classes). But, if all inputs are sorted by all columns we can use that fact and
implement a sorted set-op algorithm (see sorted aggregates for example).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
