[jira] [Commented] (IGNITE-14321) Forced index rebuilding does not work correctly
[ https://issues.apache.org/jira/browse/IGNITE-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17315285#comment-17315285 ] Stanilovsky Evgeny commented on IGNITE-14321: - [~ktkale...@gridgain.com] thanks ! check my comments plz. > Forced index rebuilding does not work correctly > --- > > Key: IGNITE-14321 > URL: https://issues.apache.org/jira/browse/IGNITE-14321 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 1.5h > Remaining Estimate: 0h > > At the moment, it is not possible to force an index rebuild twice (or more) > even if the first run fails, and this also applies to command *control.sh > --cache indexes_force_rebuild*. > Thus, we need to fix: > * *GridCacheDatabaseSharedManager#forceRebuildIndexes* > * *CacheIndexesForceRebuild#execute* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14454) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl resolved IGNITE-14454. - Resolution: Fixed > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-14454 > URL: https://issues.apache.org/jira/browse/IGNITE-14454 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Minor > > please update schedule [https://ignite.apache.org/events.html] with events > below: > *Distributed Java DBs Under the Hood: Components & Interactions Between Them* > London Java Community, Val Kulichenko > April 7, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Read > more=[https://www.eventbrite.co.uk/e/distributed-java-databases-under-the-hood-tickets-148903304793] > *Why Distributed SQL Is Not As Easy As It Looks* > Highload++, Stan Lukyanov > May 18, 2021 > In this talk, we'll cover why distributed SQL is needed, how it differs from > SQL in traditional databases, what it does well, and what doesn't. Apache > Ignite will be used as an example of distributed SQL support. > Read more = [https://www.highload.ru/spring/2021/abstracts/6686] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14454) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauricio Stekl reassigned IGNITE-14454: --- Assignee: Mauricio Stekl > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-14454 > URL: https://issues.apache.org/jira/browse/IGNITE-14454 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Assignee: Mauricio Stekl >Priority: Minor > > please update schedule [https://ignite.apache.org/events.html] with events > below: > *Distributed Java DBs Under the Hood: Components & Interactions Between Them* > London Java Community, Val Kulichenko > April 7, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Read > more=[https://www.eventbrite.co.uk/e/distributed-java-databases-under-the-hood-tickets-148903304793] > *Why Distributed SQL Is Not As Easy As It Looks* > Highload++, Stan Lukyanov > May 18, 2021 > In this talk, we'll cover why distributed SQL is needed, how it differs from > SQL in traditional databases, what it does well, and what doesn't. Apache > Ignite will be used as an example of distributed SQL support. > Read more = [https://www.highload.ru/spring/2021/abstracts/6686] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-8719: Component/s: sql > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Alexey Goncharuk >Assignee: Kirill Tkalenko >Priority: Critical > Fix For: 2.11 > > Attachments: IndexRebuildAfterNodeCrashTest.java, > IndexRebuildingTest.java > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-8719: Fix Version/s: 2.11 > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Kirill Tkalenko >Priority: Critical > Fix For: 2.11 > > Attachments: IndexRebuildAfterNodeCrashTest.java, > IndexRebuildingTest.java > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-8719: Ignite Flags: Release Notes Required > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Kirill Tkalenko >Priority: Critical > Fix For: 2.11 > > Attachments: IndexRebuildAfterNodeCrashTest.java, > IndexRebuildingTest.java > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14331:
-
Reviewer: Slava Koptilin (was: Vladislav Pyatkov)
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14482) Update the code snippet
Nikita Safonov created IGNITE-14482:
---
Summary: Update the code snippet
Key: IGNITE-14482
URL: https://issues.apache.org/jira/browse/IGNITE-14482
Project: Ignite
Issue Type: Bug
Components: documentation
Reporter: Nikita Safonov
See the XML code snippet of this section:
[https://ignite.apache.org/docs/latest/clustering/discovery-in-the-cloud#google-compute-discovery]
and change the line
{{}}
{code:java}
name="projectName" ref="YOUR_GOOGLE_PLATFORM_PROJECT_NAME"{code}
{{}} to{{}}
{code:java}
name="projectName" value="YOUR_GOOGLE_PLATFORM_PROJECT_NAME" on both pages{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14321) Forced index rebuilding does not work correctly
[ https://issues.apache.org/jira/browse/IGNITE-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-14321: - Reviewer: Stanilovsky Evgeny [~zstan] Please make code review. > Forced index rebuilding does not work correctly > --- > > Key: IGNITE-14321 > URL: https://issues.apache.org/jira/browse/IGNITE-14321 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > At the moment, it is not possible to force an index rebuild twice (or more) > even if the first run fails, and this also applies to command *control.sh > --cache indexes_force_rebuild*. > Thus, we need to fix: > * *GridCacheDatabaseSharedManager#forceRebuildIndexes* > * *CacheIndexesForceRebuild#execute* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14331:
-
Reviewer: Vladislav Pyatkov (was: Vyacheslav Koptilin)
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14321) Forced index rebuilding does not work correctly
[ https://issues.apache.org/jira/browse/IGNITE-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-14321: - Release Note: Fixes for the ability to force rebuild indexes for caches. > Forced index rebuilding does not work correctly > --- > > Key: IGNITE-14321 > URL: https://issues.apache.org/jira/browse/IGNITE-14321 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > At the moment, it is not possible to force an index rebuild twice (or more) > even if the first run fails, and this also applies to command *control.sh > --cache indexes_force_rebuild*. > Thus, we need to fix: > * *GridCacheDatabaseSharedManager#forceRebuildIndexes* > * *CacheIndexesForceRebuild#execute* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14481) Missing dependencies for JClouds discovery (ignite-cloud)
Ilya Kasnacheev created IGNITE-14481:
Summary: Missing dependencies for JClouds discovery (ignite-cloud)
Key: IGNITE-14481
URL: https://issues.apache.org/jira/browse/IGNITE-14481
Project: Ignite
Issue Type: Bug
Components: integrations
Affects Versions: 2.10
Reporter: Ilya Kasnacheev
We seem to skip some essential dependencies for jclouds-based discovery, since
trying to start a node results in the following error:
{code}
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name
'org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinder#1877ab81'
defined in URL
[file:/home/ikasnacheev/Downloads/apache-ignite-2.11.0-SNAPSHOT-bin/config/cloud-config.xml]:
Initialization of bean failed; nested exception is
java.lang.NoClassDefFoundError: Lorg/jclouds/compute/ComputeService;
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:562)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:481)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:299)
... 28 more
Caused by: java.lang.NoClassDefFoundError: Lorg/jclouds/compute/ComputeService;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredFields(Class.java:1916)
at
org.springframework.util.ReflectionUtils.getDeclaredFields(ReflectionUtils.java:713)
at
org.springframework.util.ReflectionUtils.findField(ReflectionUtils.java:97)
at
org.springframework.util.ReflectionUtils.findField(ReflectionUtils.java:80)
at org.springframework.core.convert.Property.getField(Property.java:225)
at
org.springframework.core.convert.Property.resolveAnnotations(Property.java:202)
at
org.springframework.core.convert.Property.getAnnotations(Property.java:123)
at
org.springframework.core.convert.TypeDescriptor.(TypeDescriptor.java:115)
at
org.springframework.beans.BeanWrapperImpl.convertForProperty(BeanWrapperImpl.java:214)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.convertForProperty(AbstractAutowireCapableBeanFactory.java:1568)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1527)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1269)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:551)
... 30 more
Caused by: java.lang.ClassNotFoundException: org.jclouds.compute.ComputeService
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 45 more
{code}
The following default config is used:
{code}
us-central1-a
asia-east1-a
{code}
By the way, there is extra closing slash in initial tag in
org.apache.ignite.spi.discovery.tcp.ipfinder.cloud.TcpDiscoveryCloudIpFinder
javadoc (line 112). Makes sense to fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-3173) IP Finder for Azure Cloud
[
https://issues.apache.org/jira/browse/IGNITE-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-3173:
---
Assignee: Atri Sharma
> IP Finder for Azure Cloud
> -
>
> Key: IGNITE-3173
> URL: https://issues.apache.org/jira/browse/IGNITE-3173
> Project: Ignite
> Issue Type: New Feature
>Reporter: Denis A. Magda
>Assignee: Atri Sharma
>Priority: Major
>
> {{TcpDiscoveryCloudIpFinder}} can't be used on Azure cloud because Compute
> Service functionality from JClouds is not supported for Azure. See
> ComputeService” list of supported providers [1].
> It means that we have to implement {{TcpDiscoveryAzureIpFinder}} in a similar
> way as it's done for AWS ({{TcpDiscoveryS3IpFinder}}) and Google Compute
> Engine ({{TcpDiscoveryGoogleStorageIpFinder}}).
> [1] http://jclouds.apache.org/reference/providers/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14477) Ducktape test of rebalance for persistent mode
[
https://issues.apache.org/jira/browse/IGNITE-14477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Sorokin updated IGNITE-14477:
-
Description:
This test should check the rebalance on persistent caches in basic scenario:
rebalance triggered by two event types: node join and node left the topology
(need to enable baseline auto-adjust and setting the small baseline auto-adjust
timeout).
The test should be able to run on large amounts of data enough to ensure
rebalancing time about of several minutes.
Test parameters:
# Initial node count (derived from test context);
# Cache count - the count of caches to create and data preload;
# Cache entry count - the count of entries per cache to preload;
# Cache entry size - the size of each cache entry in bytes;
# Rebalance thread pool size - the value for
{{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
rebalance thread pool
title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
expected that greater value makes rebalance faster.
# Rebalance batch size - the value for
{{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
expected that greater value makes rebalance faster on large data or
[throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
enabled (rebalanceThrottling > 0).
# Rebalance throttle - the value for {{IgniteConfiguration#rebalanceThrottle}}
property (see [rebalance message
throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
[other rebalance
properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
0 - throttling disabled, greater value makes rebalance slower.
# WAL rebalance - using WAL (historical) rebalance instead of full rebalance.
Test result: rebalance statistics.
> Ducktape test of rebalance for persistent mode
> --
>
> Key: IGNITE-14477
> URL: https://issues.apache.org/jira/browse/IGNITE-14477
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Sorokin
>Assignee: Dmitriy Sorokin
>Priority: Major
> Labels: IEP-56
>
> This test should check the rebalance on persistent caches in basic scenario:
> rebalance triggered by two event types: node join and node left the topology
> (need to enable baseline auto-adjust and setting the small baseline
> auto-adjust timeout).
> The test should be able to run on large amounts of data enough to ensure
> rebalancing time about of several minutes.
> Test parameters:
> # Initial node count (derived from test context);
> # Cache count - the count of caches to create and data preload;
> # Cache entry count - the count of entries per cache to preload;
> # Cache entry size - the size of each cache entry in bytes;
> # Rebalance thread pool size - the value for
> {{IgniteConfiguration#rebalanceThreadPoolSize}} property (see [configuring
> rebalance thread pool
> title|https://ignite.apache.org/docs/latest/data-rebalancing#configuring-rebalance-thread-pool]),
> expected that greater value makes rebalance faster.
> # Rebalance batch size - the value for
> {{IgniteConfiguration#rebalanceBatchSize}} property (see [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> expected that greater value makes rebalance faster on large data or
> [throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling]
> enabled (rebalanceThrottling > 0).
> # Rebalance throttle - the value for
> {{IgniteConfiguration#rebalanceThrottle}} property (see [rebalance message
> throttling|https://ignite.apache.org/docs/latest/data-rebalancing#throttling],
> [other rebalance
> properties|https://ignite.apache.org/docs/latest/data-rebalancing#other-properties]),
> 0 - throttling disabled, greater value makes rebalance slower.
> # WAL rebalance - using WAL (historical) rebalance instead of full rebalance.
> Test result: rebalance statistics.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14480) Add release notes for performance-statistics-ext, spring-data*-ext, spring-tx-ext extensions 1.0.0 version
[ https://issues.apache.org/jira/browse/IGNITE-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314935#comment-17314935 ] Mikhail Petrov commented on IGNITE-14480: - [~NSAmelchev] LGTM. > Add release notes for performance-statistics-ext, spring-data*-ext, > spring-tx-ext extensions 1.0.0 version > -- > > Key: IGNITE-14480 > URL: https://issues.apache.org/jira/browse/IGNITE-14480 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14321) Forced index rebuilding does not work correctly
[
https://issues.apache.org/jira/browse/IGNITE-14321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314931#comment-17314931
]
Ignite TC Bot commented on IGNITE-14321:
{panel:title=Branch: [pull/8962/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8962/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5952189]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ForceRebuildIndexTest.testForceRebuildIndexesAfterExchange - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ForceRebuildIndexTest.testSequentialForceRebuildIndexes - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ForceRebuildIndexTest.testSequentialRebuildIndexesOnExchange - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=595&buildTypeId=IgniteTests24Java8_RunAll]
> Forced index rebuilding does not work correctly
> ---
>
> Key: IGNITE-14321
> URL: https://issues.apache.org/jira/browse/IGNITE-14321
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> At the moment, it is not possible to force an index rebuild twice (or more)
> even if the first run fails, and this also applies to command *control.sh
> --cache indexes_force_rebuild*.
> Thus, we need to fix:
> * *GridCacheDatabaseSharedManager#forceRebuildIndexes*
> * *CacheIndexesForceRebuild#execute*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14283) Create the Sanity Checks job on TC
[ https://issues.apache.org/jira/browse/IGNITE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314926#comment-17314926 ] Maksim Timonin commented on IGNITE-14283: - Hi [~vveider] ! I've tested the job, LGTM. Thanks! Test PR is: [1] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Build?branch=pull%2F8967%2Fhead&mode=builds > Create the Sanity Checks job on TC > -- > > Key: IGNITE-14283 > URL: https://issues.apache.org/jira/browse/IGNITE-14283 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Peter Ivanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 1. The [Build] job runs without any checks. > 2. There will be a new job [Sanity Checks], that runs all checks - > checkstyle, licenses, javadoc, check-suites. > 3. [Sanity Checks] runs in parallel with [Build]. > 4. All TC jobs with tests depend on a result of the [Sanity Checks] job. If > the check job fails then a test job won't be started. > 5. Users can disable the [Sanity Checks] job with a selector on the > Parameters tab of custom TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14454) [Ignite Website] Update for events schedule
[ https://issues.apache.org/jira/browse/IGNITE-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314915#comment-17314915 ] Kseniya Romanova commented on IGNITE-14454: --- + 1 Apache Ignite Meetup Moscow Ivan Dashchinskiy, Grigory Domozhirov April 15, 2021 Join the Apache Ignite community meetup on April 15 at 18:00 Moscow time. Let's go over the latest release of this distributed database, talk about how to load data into Ignite faster, and tell about the hottest changes for data scientists and others working with Python - Apache Ignite Python Thin Client. Learn more = https://www.meetup.com/ru-RU/Moscow-Apache-Ignite-Meetup/events/277376724/ > [Ignite Website] Update for events schedule > --- > > Key: IGNITE-14454 > URL: https://issues.apache.org/jira/browse/IGNITE-14454 > Project: Ignite > Issue Type: Task > Components: website >Reporter: Kseniya Romanova >Priority: Minor > > please update schedule [https://ignite.apache.org/events.html] with events > below: > *Distributed Java DBs Under the Hood: Components & Interactions Between Them* > London Java Community, Val Kulichenko > April 7, 2021 > During the session, we create a simple (although fully workable) distributed > cache in Java, almost from scratch. We use the cache to demonstrate basic > CRUD operations, as well as to demonstrate how scalability can be improved by > adding resources to the system. > Read > more=[https://www.eventbrite.co.uk/e/distributed-java-databases-under-the-hood-tickets-148903304793] > *Why Distributed SQL Is Not As Easy As It Looks* > Highload++, Stan Lukyanov > May 18, 2021 > In this talk, we'll cover why distributed SQL is needed, how it differs from > SQL in traditional databases, what it does well, and what doesn't. Apache > Ignite will be used as an example of distributed SQL support. > Read more = [https://www.highload.ru/spring/2021/abstracts/6686] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14331:
-
Reviewer: Vyacheslav Koptilin (was: Vladislav Pyatkov)
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14331) Possible distributed race related to a data streamer flushing leading to a thread being stuck forever trying to close the streamer
[
https://issues.apache.org/jira/browse/IGNITE-14331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14331:
-
Reviewer: Vladislav Pyatkov
> Possible distributed race related to a data streamer flushing leading to a
> thread being stuck forever trying to close the streamer
> --
>
> Key: IGNITE-14331
> URL: https://issues.apache.org/jira/browse/IGNITE-14331
> Project: Ignite
> Issue Type: Bug
> Components: streaming
>Affects Versions: 2.10
>Reporter: Vladimir Pligin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that a streamer could stuck forever flushing internal buffers on a
> client side.
> It will stay in a busy-loop forever hoping on remapping but it's possible
> that it won't happen for example in case of long GC pauses on server(s) and
> long timeouts.
> It that case a streamer would be trapped inside this
> [loop|https://github.com/apache/ignite/blob/ignite-2.10/modules/core/src/main/java/org/apache/ignite/internal/processors/datastreamer/DataStreamerImpl.java#L1168].
> Stack trace snippet:
> {code:java}
> java.lang.Thread.State: RUNNABLE at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.flush(DataStreamerImpl.java:1706)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.doFlush(DataStreamerImpl.java:1170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1365)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.closeEx(DataStreamerImpl.java:1323)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1311)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.close(DataStreamerImpl.java:1415){code}
>
> It becomes possible when a
> IgniteSpiOperationTimeoutException
> is being thrown from
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic()
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14480) Add release notes for performance-statistics-ext, spring-data*-ext, spring-tx-ext extensions 1.0.0 version
[ https://issues.apache.org/jira/browse/IGNITE-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14480: - Ignite Flags: (was: Docs Required,Release Notes Required) > Add release notes for performance-statistics-ext, spring-data*-ext, > spring-tx-ext extensions 1.0.0 version > -- > > Key: IGNITE-14480 > URL: https://issues.apache.org/jira/browse/IGNITE-14480 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14480) Add release notes for performance-statistics-ext, spring-data*-ext, spring-tx-ext extensions 1.0.0 version
Amelchev Nikita created IGNITE-14480: Summary: Add release notes for performance-statistics-ext, spring-data*-ext, spring-tx-ext extensions 1.0.0 version Key: IGNITE-14480 URL: https://issues.apache.org/jira/browse/IGNITE-14480 Project: Ignite Issue Type: Task Reporter: Amelchev Nikita Assignee: Amelchev Nikita -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[ https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314892#comment-17314892 ] Taras Ledkov commented on IGNITE-14472: --- [~isapego], the patch is OK with me. > Performance drop on primitive operations. > - > > Key: IGNITE-14472 > URL: https://issues.apache.org/jira/browse/IGNITE-14472 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python, thin > Fix For: python-0.4.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Reason of performance drop: header struct of Response is not cached (now it > is instance variable, earlier it will be class variable) > Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14479) Add column default values support.
Andrey Mashenkov created IGNITE-14479: - Summary: Add column default values support. Key: IGNITE-14479 URL: https://issues.apache.org/jira/browse/IGNITE-14479 Project: Ignite Issue Type: New Feature Reporter: Andrey Mashenkov Let's add default column values support. Tuple has no default-value-map support (like null-map). Thus, we should be able to answer if a 'null' value was set or a value was not set to Tuple and write a default column value to Row explicitely if it was not specified in Tuple. This may require extending the Tuple contract, which is ok. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14283) Create the Sanity Checks job on TC
[ https://issues.apache.org/jira/browse/IGNITE-14283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314842#comment-17314842 ] Peter Ivanov commented on IGNITE-14283: --- Waiting for build configuration comparison results with current Sanity Check suites. > Create the Sanity Checks job on TC > -- > > Key: IGNITE-14283 > URL: https://issues.apache.org/jira/browse/IGNITE-14283 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Peter Ivanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > 1. The [Build] job runs without any checks. > 2. There will be a new job [Sanity Checks], that runs all checks - > checkstyle, licenses, javadoc, check-suites. > 3. [Sanity Checks] runs in parallel with [Build]. > 4. All TC jobs with tests depend on a result of the [Sanity Checks] job. If > the check job fails then a test job won't be started. > 5. Users can disable the [Sanity Checks] job with a selector on the > Parameters tab of custom TC build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14471) JDBCv2: query cursors leak when node to execute queries is specified
[ https://issues.apache.org/jira/browse/IGNITE-14471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314839#comment-17314839 ] Konstantin Orlov commented on IGNITE-14471: --- [~tledkov-gridgain], LGTM! > JDBCv2: query cursors leak when node to execute queries is specified > > > Key: IGNITE-14471 > URL: https://issues.apache.org/jira/browse/IGNITE-14471 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Query cursors leak when node to execute queries is specified. > In this case the query tasks are executed on the remote node instead of > client node launched by the JDBC v2 client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14478) Custom fork/Custom tests Documentation at README.MD
Anton Vinogradov created IGNITE-14478: - Summary: Custom fork/Custom tests Documentation at README.MD Key: IGNITE-14478 URL: https://issues.apache.org/jira/browse/IGNITE-14478 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Nikolay Izhikov We have to append a proper explanation of "Custom Ignites (forks) testing" to sections "Local run" and "# Real environment run". Currently "Custom Ignites (forks) testing" is a separate section which is not true anymore, let spread it to *run sections. P.s. Currently, we have a 4 options - Run AI tests versus AI - Run AI tests versus Fork - Run External (Fork's) tests versus AI - Run External (Fork's) tests versus Fork (this case requires no additional explanation since it obviously equals to first one). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14471) JDBCv2: query cursors leak when node to execute queries is specified
[
https://issues.apache.org/jira/browse/IGNITE-14471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314802#comment-17314802
]
Ignite TC Bot commented on IGNITE-14471:
{panel:title=Branch: [pull/8966/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8966/head] Base: [master] : New Tests
(32)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}JDBC Driver{color} [[tests
32|https://ci.ignite.apache.org/viewLog.html?buildId=5951816]]
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement0[remote=false,
multipleStatement=false, distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement1[remote=false,
multipleStatement=false, distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement1[remote=true, multipleStatement=true,
distributedJoin=false] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testSingleQuery[remote=true, multipleStatement=true,
distributedJoin=false] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement1[remote=true,
multipleStatement=false, distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testSingleQuery[remote=true, multipleStatement=false,
distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testSingleQuery[remote=false, multipleStatement=false,
distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement0[remote=true,
multipleStatement=false, distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testSingleQuery[remote=false, multipleStatement=true,
distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement0[remote=true, multipleStatement=true,
distributedJoin=true] - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcCursorLeaksTest.testMultipleStatement0[remote=false,
multipleStatement=true, distributedJoin=true] - PASSED{color}
... and 21 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5951895&buildTypeId=IgniteTests24Java8_RunAll]
> JDBCv2: query cursors leak when node to execute queries is specified
>
>
> Key: IGNITE-14471
> URL: https://issues.apache.org/jira/browse/IGNITE-14471
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Query cursors leak when node to execute queries is specified.
> In this case the query tasks are executed on the remote node instead of
> client node launched by the JDBC v2 client.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13605) Ducktests test: PDS compatibility for ignite versions
[ https://issues.apache.org/jira/browse/IGNITE-13605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-13605: - Sprint: Ducktape Sprint 1, Ducktape Sprint 2, Ducktape Sprint 7 (was: Ducktape Sprint 1, Ducktape Sprint 2) > Ducktests test: PDS compatibility for ignite versions > - > > Key: IGNITE-13605 > URL: https://issues.apache.org/jira/browse/IGNITE-13605 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Mikhail Filatov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > A simple test to check PDS compatibility of different Ignite versions > Ignite versions "from_version" and "to_version" are set via test parameters > # Start Ignite cluster version "from_version" with PDS enabled > # Start a client application that puts prepared data looks like > User (1, "John Connor") > User (2, "Sarah Connor") > User (3, "Kyle Reese") > # Stop cluster and client > # Start Ignite cluster version "to_version" without PDS clearing > # Start client that reads data and checks that it can be read and have not > changed > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14470) Thin client application service
[ https://issues.apache.org/jira/browse/IGNITE-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-14470: - Assignee: (was: Anton Vinogradov) > Thin client application service > --- > > Key: IGNITE-14470 > URL: https://issues.apache.org/jira/browse/IGNITE-14470 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Priority: Major > > Allow starting thin client within the java application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14451) PK becomes corrupted after node restart
[ https://issues.apache.org/jira/browse/IGNITE-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314792#comment-17314792 ] Konstantin Orlov commented on IGNITE-14451: --- [~tledkov-gridgain], in general LGTM, but if left a minor remark. Please see PR. > PK becomes corrupted after node restart > --- > > Key: IGNITE-14451 > URL: https://issues.apache.org/jira/browse/IGNITE-14451 > Project: Ignite > Issue Type: Bug >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > PK index tree becomes corrupted after node restart in case it was created > through SQL API and it's fields order differs from the one in field list. For > example: > CREATE TABLE t (id1 INTEGER, id2 INTEGER, val VARCHAR, CONSTRAINT PK PRIMARY > KEY (id2, id1)) - this won't survive restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14451) PK becomes corrupted after node restart
[ https://issues.apache.org/jira/browse/IGNITE-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314792#comment-17314792 ] Konstantin Orlov edited comment on IGNITE-14451 at 4/5/21, 11:12 AM: - [~tledkov-gridgain], LGTM in general, but i left a minor remark. Please see PR. was (Author: korlov): [~tledkov-gridgain], in general LGTM, but if left a minor remark. Please see PR. > PK becomes corrupted after node restart > --- > > Key: IGNITE-14451 > URL: https://issues.apache.org/jira/browse/IGNITE-14451 > Project: Ignite > Issue Type: Bug >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > PK index tree becomes corrupted after node restart in case it was created > through SQL API and it's fields order differs from the one in field list. For > example: > CREATE TABLE t (id1 INTEGER, id2 INTEGER, val VARCHAR, CONSTRAINT PK PRIMARY > KEY (id2, id1)) - this won't survive restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14472) Performance drop on primitive operations.
[ https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14472: -- Fix Version/s: python-0.4.0 > Performance drop on primitive operations. > - > > Key: IGNITE-14472 > URL: https://issues.apache.org/jira/browse/IGNITE-14472 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Blocker > Labels: python, thin > Fix For: python-0.4.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Reason of performance drop: header struct of Response is not cached (now it > is instance variable, earlier it will be class variable) > Performance drop approx 15 %. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14477) Ducktape test of rebalance for persistent mode
Dmitriy Sorokin created IGNITE-14477: Summary: Ducktape test of rebalance for persistent mode Key: IGNITE-14477 URL: https://issues.apache.org/jira/browse/IGNITE-14477 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14451) PK becomes corrupted after node restart
[ https://issues.apache.org/jira/browse/IGNITE-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314785#comment-17314785 ] Taras Ledkov commented on IGNITE-14451: --- [~korlov], please review the patch. > PK becomes corrupted after node restart > --- > > Key: IGNITE-14451 > URL: https://issues.apache.org/jira/browse/IGNITE-14451 > Project: Ignite > Issue Type: Bug >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > PK index tree becomes corrupted after node restart in case it was created > through SQL API and it's fields order differs from the one in field list. For > example: > CREATE TABLE t (id1 INTEGER, id2 INTEGER, val VARCHAR, CONSTRAINT PK PRIMARY > KEY (id2, id1)) - this won't survive restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14451) PK becomes corrupted after node restart
[
https://issues.apache.org/jira/browse/IGNITE-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314784#comment-17314784
]
Ignite TC Bot commented on IGNITE-14451:
{panel:title=Branch: [pull/8951/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8951/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5948045]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testCorrectPkFieldsSequenceAfterRestart - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testCorrectPkFieldsSequenceAfterRestart - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5948066&buildTypeId=IgniteTests24Java8_RunAll]
> PK becomes corrupted after node restart
> ---
>
> Key: IGNITE-14451
> URL: https://issues.apache.org/jira/browse/IGNITE-14451
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> PK index tree becomes corrupted after node restart in case it was created
> through SQL API and it's fields order differs from the one in field list. For
> example:
> CREATE TABLE t (id1 INTEGER, id2 INTEGER, val VARCHAR, CONSTRAINT PK PRIMARY
> KEY (id2, id1)) - this won't survive restart.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[
https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314748#comment-17314748
]
Ivan Daschinskiy commented on IGNITE-14472:
---
*before*
{code}
benchmark 'binary_object_get': 12 tests
Name (time in us) Min Max
Mean StdDevMedian
IQROutliers OPSRounds Iterations
-
benchmark_sync_binary_get[simple-1024] 503.3497 (1.0)542.5109
(1.0)524.7468 (1.0) 11.9913 (1.29) 527.0175 (1.0)
11.3102 (1.0) 4;0 1,905.6809 (1.0) 10 100
benchmark_sync_binary_get[simple-4096] 545.7228 (1.08) 681.6326
(1.26) 573.7108 (1.09) 38.6286 (4.17) 562.4087 (1.07)
11.4088 (1.01) 1;1 1,743.0386 (0.91) 10 100
benchmark_sync_binary_get[simple-10240] 557.1264 (1.11) 663.1032
(1.22) 597.0065 (1.14) 28.5202 (3.08) 592.0662 (1.12)
20.9598 (1.85) 2;1 1,675.0237 (0.88) 10 100
benchmark_async_binary_get[simple-1024] 709.6196 (1.41) 749.4574
(1.38) 722.3022 (1.38) 14.1358 (1.52) 716.2776 (1.36)
24.3055 (2.15) 3;0 1,384.4621 (0.73) 10 100
benchmark_async_binary_get[simple-4096] 749.6903 (1.49) 779.9036
(1.44) 764.4456 (1.46) 9.2736 (1.0)763.2206 (1.45)
11.5306 (1.02) 4;0 1,308.1376 (0.69) 10 100
benchmark_async_binary_get[simple-10240] 768.9985 (1.53) 796.4124
(1.47) 786.9617 (1.50) 10.5591 (1.14) 790.4466 (1.50)
16.7354 (1.48) 2;0 1,270.7099 (0.67) 10 100
benchmark 'binary_object_put': 12 tests
Name (time in us) Min Max
Mean StdDevMedian
IQROutliers OPSRounds Iterations
-
benchmark_sync_binary_put[simple-1024] 422.0449 (1.0)443.4763
(1.0)430.9277 (1.0)7.2775 (1.08) 429.2968 (1.0)
11.3402 (1.41) 3;0 2,320.5747 (1.0) 10 100
benchmark_sync_binary_put[simple-4096] 432.6478 (1.03) 454.3953
(1.02) 444.2581 (1.03) 6.7669 (1.0)445.7960 (1.04)
8.0276 (1.0) 3;0 2,250.9438 (0.97) 10 100
benchmark_sync_binary_put[simple-10240] 474.8603 (1.13) 515.2363
(1.16) 496.1305 (1.15) 13.6759 (2.02) 498.2116 (1.16)
20.8986 (2.60) 3;0 2,015.5987 (0.87) 10 100
benchmark_async_binary_put[simple-1024] 535.3795 (1.27) 685.1283
(1.54) 567.3985 (1.32) 44.3217 (6.55) 548.0161 (1.28)
33.4157 (4.16) 1;1 1,762.4297 (0.76) 10 100
benchmark_async_binary_put[simple-4096] 571.5587 (1.35) 616.8044
(1.39) 592.2703 (1.37) 14.5426 (2.15) 591.8616 (1.38)
18.8717 (2.35) 4;0 1,688.4183 (0.73) 10 100
benchmark_async_binary_put[simple-10240] 622.7088 (1.48) 714.9631
(1.61) 656.8940 (1.52) 26.2311 (3.88) 655.6965 (1.53)
33.0954 (4.12) 2;0 1,522.3156 (0.66) 10 100
{code}
*after*
{code}
benchmark 'binary_object_get': 12 tests
Name (time in us) Min Max
Mean StdDevMedian
IQROutliers OPSRounds Iterations
-
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[
https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314747#comment-17314747
]
Ivan Daschinskiy commented on IGNITE-14472:
---
*Before*:
{code}
--
benchmark 'string_get': 10 tests
--
Name (time in us)Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
--
benchmark_sync_string_get[simple-128] 352.9188 (1.0) 373.0795 (1.0)
361.5633 (1.0) 7.3642 (2.16) 361.9580 (1.0) 10.8843 (2.59)
3;02.7658 (1.0) 101000
benchmark_sync_string_get[simple-256] 358.5299 (1.02) 383.5096 (1.03)
370.6923 (1.03) 7.7361 (2.27) 370.2248 (1.02) 4.1944 (1.0)
3;32.6977 (0.98) 101000
benchmark_sync_string_get[simple-1024] 364.8562 (1.03) 388.6522 (1.04)
375.3570 (1.04) 7.2215 (2.12) 375.6628 (1.04) 9.5607 (2.28)
3;02.6641 (0.96) 101000
benchmark_sync_string_get[simple-2048] 392.4290 (1.11) 402.3911 (1.08)
396.3332 (1.10) 3.4034 (1.0) 395.3264 (1.09) 5.2861 (1.26)
3;02.5231 (0.91) 101000
benchmark_sync_string_get[simple-4096] 418.6008 (1.19) 452.7802 (1.21)
426.6729 (1.18) 10.5182 (3.09) 422.9948 (1.17) 10.8302 (2.58)
1;12.3437 (0.85) 101000
benchmark_async_string_get[simple-128] 516.2550 (1.46) 552.0531 (1.48)
530.5335 (1.47) 9.8132 (2.88) 531.2685 (1.47) 9.8281 (2.34)
2;11.8849 (0.68) 101000
benchmark_async_string_get[simple-256] 524.5846 (1.49) 572.8096 (1.54)
537.5614 (1.49) 13.5860 (3.99) 536.4263 (1.48) 11.1575 (2.66)
1;11.8603 (0.67) 101000
benchmark_async_string_get[simple-1024] 524.7691 (1.49) 560.3995 (1.50)
544.3051 (1.51) 12.3997 (3.64) 542.4853 (1.50) 21.1719 (5.05)
4;01.8372 (0.66) 101000
benchmark_async_string_get[simple-2048] 547.0813 (1.55) 586.5175 (1.57)
563.1756 (1.56) 13.3071 (3.91) 558.9927 (1.54) 17.0010 (4.05)
3;01.7756 (0.64) 101000
benchmark_async_string_get[simple-4096] 564.6848 (1.60) 615.9083 (1.65)
586.0929 (1.62) 17.1826 (5.05) 587.9250 (1.62) 28.2196 (6.73)
3;01.7062 (0.62) 101000
--
--
benchmark 'string_put': 10 tests
--
Name (time in us)Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
--
benchmark_sync_string_put[simple-256] 325.9658 (1.0) 351.0994 (1.0)
337.2916 (1.0) 8.5597 (1.32) 337.3050 (1.0) 9.4780 (1.68)
4;02.9648 (1.0) 101000
benchmark_sync_string_put[simple-128] 334.7044 (1.03) 357.9547 (1.02)
343.1400 (1.02) 7.7337 (1.19) 342.2236 (1.01) 5.6582 (1.0)
4;22.9143 (0.98) 101000
benchmark_sync_string_put[simple-1024] 339.7010 (1.04) 370.3226 (1.05)
352.4340 (1.04) 11.0125 (1.69) 350.4053 (1.04) 20.6439 (3.65)
5;02.8374 (0.96) 101000
benchmark_sync_string_put[simple-2048] 361.9507 (1.11) 384.4600 (1.10)
372.5959 (1.10) 6.5051 (1.0) 371.9587 (1.10) 8.3985 (1.48)
3;02.6839 (0.91) 101000
benchmark_sync_string_put[simple-4096] 388.3225 (1.19) 421.1529 (1.20)
399.8351 (1.19) 9.5191 (1.46) 399.2213 (1.18) 7.5771 (1.34)
[jira] [Commented] (IGNITE-14472) Performance drop on primitive operations.
[
https://issues.apache.org/jira/browse/IGNITE-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314745#comment-17314745
]
Ivan Daschinskiy commented on IGNITE-14472:
---
Benchmark examples
*before:*
{code}
benchmark 'long_get': 2 tests
Name (time in us) Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
---
benchmark_sync_long_get[simple] 335.3812 (1.0) 359.0669 (1.0)
343.4707 (1.0) 7.9492 (1.0) 341.8763 (1.0) 5.8493 (1.0)
3;22.9115 (1.0) 101000
benchmark_async_long_get[simple] 489.9539 (1.46) 532.6032 (1.48)
513.4271 (1.49) 12.8345 (1.61) 514.0811 (1.50) 20.5015 (3.50)
2;01.9477 (0.67) 101000
---
---
benchmark 'long_put': 2 tests
Name (time in us) Min Max
MeanStdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
--
benchmark_sync_long_put[simple] 310.4296 (1.0) 323.5723 (1.0)
316.5834 (1.0) 3.6066 (1.0) 316.7651 (1.0) 3.9376 (1.0)
2;03.1587 (1.0) 101000
benchmark_async_long_put[simple] 417.9511 (1.35) 442.7839 (1.37)
431.7079 (1.36) 9.5637 (2.65) 433.7149 (1.37) 20.4647 (5.20)
6;02.3164 (0.73) 101000
--
{code}
*after:*
{code}
benchmark 'long_get': 2 tests
Name (time in us) Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
---
benchmark_sync_long_get[simple] 282.0120 (1.0) 306.0031 (1.0)
291.5331 (1.0) 7.8233 (1.0) 290.0198 (1.0) 12.3822 (1.0)
3;03.4301 (1.0) 101000
benchmark_async_long_get[simple] 430.0521 (1.52) 484.0667 (1.58)
446.6028 (1.53) 19.2004 (2.45) 437.3707 (1.51) 20.9369 (1.69)
2;02.2391 (0.65) 101000
---
benchmark 'long_put': 2 tests
Name (time in us) Min Max
Mean StdDev MedianIQR
Outliers OPS (Kops/s)Rounds Iterations
---
benchmark_sync_long_put[simple] 283.3018 (1.0) 313.3918 (1.0)
296.9479 (1.0) 8.7095 (1.0) 295.4214 (1.0) 13.2546 (1.0)
2;03.3676 (1.0) 101000
benchmark_async_long_put[simple] 381.2551 (1.35) 419.1923 (1
[jira] [Commented] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314741#comment-17314741
]
Ignite TC Bot commented on IGNITE-14475:
{panel:title=Branch: [pull/8970/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Win x64 / Debug){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5951898]]
* IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLDriverConnect - New test
duration 63s is more that 1 minute
{panel}
{panel:title=Branch: [pull/8970/head] Base: [master] : New Tests
(1990)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
995|https://ci.ignite.apache.org/viewLog.html?buildId=5951905]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 984 new tests
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
995|https://ci.ignite.apache.org/viewLog.html?buildId=5951898]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 984 new tests
{panel}
[TeamCity *-> Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5951907&buildTypeId=IgniteTests24Java8_RunCpp]
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
[
https://issues.apache.org/jira/browse/IGNITE-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314724#comment-17314724
]
Ivan Daschinskiy commented on IGNITE-11854:
---
{code:java}
- benchmark
'binary_object_get': 1 tests
Name (time in ms) Min Max
Mean StdDev Median IQR Outliers OPS Rounds Iterations
-
benchmark_sync_binary_get[partition_aware-10485760] 44.4116 47.2139
45.2577 0.8969 44.9754 1.3467 1;0 22.0957 10 100
-
- benchmark
'binary_object_put': 1 tests
Name (time in ms) Min Max
Mean StdDev Median IQR Outliers OPS Rounds Iterations
-
benchmark_sync_binary_put[partition_aware-10485760] 35.5823 37.1995
36.4751 0.4259 36.5096 0.3459 2;2 27.4160 10 100
-
{code}
And this is for partition aware client, 4 ignite server nodes, 8Gb heap, 16 Gb
offheap
> Serialization of arrays of primitives in python thin client is not optimal
> --
>
> Key: IGNITE-11854
> URL: https://issues.apache.org/jira/browse/IGNITE-11854
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: python-0.4.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The following code hangs indefinitely inside of invocation to
> {{my_cache.put()}}
> {code:java}
> from pyignite import Client
> arr_len = 3_000_000
> content = bytearray(arr_len)
> for i in range(arr_len):
> content[i] = i % 256
> client = Client()
> client.connect('127.0.0.1', 10800)
> my_cache = client.get_or_create_cache('my cache')
> my_cache.put("key_bin", content){code}
> While the value is only 3MB in size. Implementation of serialization of
> primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14476) Get rid of using storage implementation explicitly in ConfigurationRoot annotation
Vladislav Pyatkov created IGNITE-14476:
--
Summary: Get rid of using storage implementation explicitly in
ConfigurationRoot annotation
Key: IGNITE-14476
URL: https://issues.apache.org/jira/browse/IGNITE-14476
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
Fix For: 3.0.0-alpha2
Today we are using generated schema classes in public API, but we don't want to
provide an implementation in it.
For example:
{code:java}
@ConfigurationRoot(rootName = "rest", storage =
InMemoryConfigurationStorage.class)
public class RestConfigurationSchema {
...
{code}
The mention of InMemoryConfigurationStorage should be changed to a specific
constant:
{code:java}
@ConfigurationRoot(rootName = "rest", storage =
IgniteConsts.MEMORY_CONFIGURATION_STORAGE)
public class RestConfigurationSchema {
...
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314718#comment-17314718
]
Taras Ledkov edited comment on IGNITE-14475 at 4/5/21, 8:39 AM:
[~isapego], the patch is OK with me.
was (Author: tledkov-gridgain):
[~isapego]m the patch is OK with me.
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314718#comment-17314718
]
Taras Ledkov commented on IGNITE-14475:
---
[~isapego]m the patch is OK with me.
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
[
https://issues.apache.org/jira/browse/IGNITE-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314717#comment-17314717
]
Ivan Daschinskiy commented on IGNITE-11854:
---
[~dmekhanikov] Currently, serialization-deserialization are fully reworked,
moreover, hashcode caclulation are now much faster due to C module
Here is some benchmarks (put-get) of BinaryObject with 10Mb field
{code:java}
benchmark 'binary_object_get':
1 tests
Name (time in ms) Min Max Mean
StdDev Median IQR Outliers OPS Rounds Iterations
benchmark_sync_binary_get[simple-10485760] 67.7753 73.2509 70.5726
1.6236 70.5608 1.9794 3;0 14.1698 10 100
benchmark 'binary_object_put':
1 tests
Name (time in ms) Min Max Mean
StdDev Median IQR Outliers OPS Rounds Iterations
benchmark_sync_binary_put[simple-10485760] 61.6861 66.3933 63.5946
1.7068 62.9506 3.0117 3;0 15.7246 10 100
{code}
70ms for get and 60ms for put doesn't seems to be infinite, does it? And this
is without partition awareness :)
> Serialization of arrays of primitives in python thin client is not optimal
> --
>
> Key: IGNITE-11854
> URL: https://issues.apache.org/jira/browse/IGNITE-11854
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Dmitry Melnichuk
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The following code hangs indefinitely inside of invocation to
> {{my_cache.put()}}
> {code:java}
> from pyignite import Client
> arr_len = 3_000_000
> content = bytearray(arr_len)
> for i in range(arr_len):
> content[i] = i % 256
> client = Client()
> client.connect('127.0.0.1', 10800)
> my_cache = client.get_or_create_cache('my cache')
> my_cache.put("key_bin", content){code}
> While the value is only 3MB in size. Implementation of serialization of
> primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-11854) Serialization of arrays of primitives in python thin client is not optimal
[
https://issues.apache.org/jira/browse/IGNITE-11854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-11854:
-
Fix Version/s: python-0.4.0
Assignee: Ivan Daschinskiy (was: Dmitry Melnichuk)
Resolution: Fixed
> Serialization of arrays of primitives in python thin client is not optimal
> --
>
> Key: IGNITE-11854
> URL: https://issues.apache.org/jira/browse/IGNITE-11854
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Denis Mekhanikov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: python-0.4.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The following code hangs indefinitely inside of invocation to
> {{my_cache.put()}}
> {code:java}
> from pyignite import Client
> arr_len = 3_000_000
> content = bytearray(arr_len)
> for i in range(arr_len):
> content[i] = i % 256
> client = Client()
> client.connect('127.0.0.1', 10800)
> my_cache = client.get_or_create_cache('my cache')
> my_cache.put("key_bin", content){code}
> While the value is only 3MB in size. Implementation of serialization of
> primitive arrays seems to be quadratic in length of the array.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13605) Ducktests test: PDS compatibility for ignite versions
[ https://issues.apache.org/jira/browse/IGNITE-13605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Filatov updated IGNITE-13605: - Description: A simple test to check PDS compatibility of different Ignite versions Ignite versions "from_version" and "to_version" are set via test parameters # Start Ignite cluster version "from_version" with PDS enabled # Start a client application that puts prepared data looks like User (1, "John Connor") User (2, "Sarah Connor") User (3, "Kyle Reese") # Stop cluster and client # Start Ignite cluster version "to_version" without PDS clearing # Start client that reads data and checks that it can be read and have not changed was: A simple test to check PDS compatibility of different Ignite versions # Start Ignite cluster with version 1, enabled PDS # Start client that put some data into cluster # Stop client and cluster # Start Ignite cluster with version 2, and PDS from previous cluster # Start client that reads data and checks that the data is same > Ducktests test: PDS compatibility for ignite versions > - > > Key: IGNITE-13605 > URL: https://issues.apache.org/jira/browse/IGNITE-13605 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Mikhail Filatov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > A simple test to check PDS compatibility of different Ignite versions > Ignite versions "from_version" and "to_version" are set via test parameters > # Start Ignite cluster version "from_version" with PDS enabled > # Start a client application that puts prepared data looks like > User (1, "John Connor") > User (2, "Sarah Connor") > User (3, "Kyle Reese") > # Stop cluster and client > # Start Ignite cluster version "to_version" without PDS clearing > # Start client that reads data and checks that it can be read and have not > changed > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-14475:
-
Reviewer: (was: Pavel Tupitsyn)
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314716#comment-17314716
]
Igor Sapego edited comment on IGNITE-14475 at 4/5/21, 8:33 AM:
---
[~tledkov-gridgain], please take a look
was (Author: isapego):
[~ptupitsyn], please take a look
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
[
https://issues.apache.org/jira/browse/IGNITE-14475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-14475:
-
Reviewer: Pavel Tupitsyn
> C++/dotnet query-example select result is various with additional node
> --
>
> Key: IGNITE-14475
> URL: https://issues.apache.org/jira/browse/IGNITE-14475
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Steps:
> Start some additional nodes
> Execute query-example
> Expected output:
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> Jane Smith is working in Other
> John Smith is working in Other
> {noformat}
> Actual (in 80% cases):
> {noformat}
> Names of all employees and organizations they belong to:
> Jane Doe is working in ApacheIgnite
> John Doe is working in ApacheIgnite
> John Smith is working in Other
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14475) C++/dotnet query-example select result is various with additional node
Igor Sapego created IGNITE-14475:
Summary: C++/dotnet query-example select result is various with
additional node
Key: IGNITE-14475
URL: https://issues.apache.org/jira/browse/IGNITE-14475
Project: Ignite
Issue Type: Bug
Components: platforms
Affects Versions: 2.10
Reporter: Igor Sapego
Assignee: Igor Sapego
Fix For: 2.11
Steps:
Start some additional nodes
Execute query-example
Expected output:
{noformat}
Names of all employees and organizations they belong to:
Jane Doe is working in ApacheIgnite
John Doe is working in ApacheIgnite
Jane Smith is working in Other
John Smith is working in Other
{noformat}
Actual (in 80% cases):
{noformat}
Names of all employees and organizations they belong to:
Jane Doe is working in ApacheIgnite
John Doe is working in ApacheIgnite
John Smith is working in Other
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-11897) Use `bytearray` as a Python type for Ignite `ByteArray`
[ https://issues.apache.org/jira/browse/IGNITE-11897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego resolved IGNITE-11897. -- Resolution: Cannot Reproduce Already supported. > Use `bytearray` as a Python type for Ignite `ByteArray` > --- > > Key: IGNITE-11897 > URL: https://issues.apache.org/jira/browse/IGNITE-11897 > Project: Ignite > Issue Type: Improvement > Components: thin client >Reporter: Dmitry Melnichuk >Assignee: Dmitry Melnichuk >Priority: Major > > This optimization will allow client to read and write `ByteArray` values > without iterating over single bytes, thereby improving performance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14474) Improve error message in case rebalance fails
Denis Chudov created IGNITE-14474:
-
Summary: Improve error message in case rebalance fails
Key: IGNITE-14474
URL: https://issues.apache.org/jira/browse/IGNITE-14474
Project: Ignite
Issue Type: Improvement
Reporter: Denis Chudov
Currently we can get a message like this when rebalance fails with an exception
(examples from ignite 2.5, in newer versions the log messages were changed but
the problem is still actual):
{code:java}
2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander]
Rebalancing from node cancelled [grp=ignite-sys-cache,
topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message
couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
unmarshal object with optimized marshaller
2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander]
Cancelled rebalancing [grp=ignite-sys-cache,
supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion
[topVer=1932, minorTopVer=1], time=88 ms]
2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander]
Rebalancing from node cancelled [grp=ignite-sys-cache,
topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message
couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
unmarshal object with optimized marshaller
{code}
In the case above, a marshalling exception leads to rebalance failure which
will never be resolved - i.e. the cluster enters into a erroneous state.
We should report issues like this as ERROR. The message should explain that the
rebalance has failed, data for the cache was not fully copied to the node, the
backup factor is not recovered and the cluster may not work correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13605) Ducktests test: PDS compatibility for ignite versions
[ https://issues.apache.org/jira/browse/IGNITE-13605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Filatov updated IGNITE-13605: - Description: A simple test to check PDS compatibility of different Ignite versions # Start Ignite cluster with version 1, enabled PDS # Start client that put some data into cluster # Stop client and cluster # Start Ignite cluster with version 2, and PDS from previous cluster # Start client that reads data and checks that the data is same > Ducktests test: PDS compatibility for ignite versions > - > > Key: IGNITE-13605 > URL: https://issues.apache.org/jira/browse/IGNITE-13605 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Mikhail Filatov >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > A simple test to check PDS compatibility of different Ignite versions > # Start Ignite cluster with version 1, enabled PDS > # Start client that put some data into cluster > # Stop client and cluster > # Start Ignite cluster with version 2, and PDS from previous cluster > # Start client that reads data and checks that the data is same -- This message was sent by Atlassian Jira (v8.3.4#803005)
