[jira] [Commented] (IGNITE-13331) Document .NET thin client features implemented in 2.9 release
[ https://issues.apache.org/jira/browse/IGNITE-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206505#comment-17206505 ] Denis A. Magda commented on IGNITE-13331: - [~ptupitsyn], thanks for taking care of the task. I've merged the PR and then went ahead by doing several tweaks. The review of similar contributions to the Java thin client missed my attention during the review phase and only now I spent some time reworking the Java docs which influenced the changes you can see on the .NET end. Hope you don't spot any inaccuracy: https://ignite.apache.org/docs/latest/thin-clients/dotnet-thin-client#using-cluster-api In case we need to fix anything, just send me a note. I'm going to integrate the branch into the master on Monday and would appreciate if you don't commit any changes to IGNITE-7595. As of now, I'm resolving the ticket. Thanks, again. > Document .NET thin client features implemented in 2.9 release > - > > Key: IGNITE-13331 > URL: https://issues.apache.org/jira/browse/IGNITE-13331 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Aleksey Plekhanov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: important > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > Document .NET thin client features: > * Cluster API > * Cluster group API > * Compute API > * Server discovery -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13037) .NET: Thin Client Near Cache
[ https://issues.apache.org/jira/browse/IGNITE-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206504#comment-17206504 ] Marty Jones commented on IGNITE-13037: -- That is excellent news for the thin client! I would rather not use the thick client since it requires a JVM to be installed on our production servers and would rather not have that overhead. I am available to beta test the .net think client for near caches once it is available if needed. > .NET: Thin Client Near Cache > > > Key: IGNITE-13037 > URL: https://issues.apache.org/jira/browse/IGNITE-13037 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Add near caching for thin clients: > * Clients can subscribe to change notifications for specific keys > * Clients use partition awareness to route subscriptions to primary nodes > * Use existing Thick .NET Client near caching mechanism to handle updates on > the server side > * Eviction policy is to be handled by the client code (because multiple > servers are involved) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13501) AssertionError: Invalid value in testMergeServersFail1_8
[ https://issues.apache.org/jira/browse/IGNITE-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206500#comment-17206500 ] Vladislav Pyatkov commented on IGNITE-13501: [~ascherbakov] I fixed your comment. Please look at this again. > AssertionError: Invalid value in testMergeServersFail1_8 > > > Key: IGNITE-13501 > URL: https://issues.apache.org/jira/browse/IGNITE-13501 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > java.lang.AssertionError: Invalid value > [node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c6] > expected:<1> but was: > Reproduced by [1] > [1] > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3187056670751319047=testDetails > Covered of case of one phase committed transaction with zero backups. The > reason of this issue in that a primary node fails during a near node is > sending a request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13501) AssertionError: Invalid value in testMergeServersFail1_8
[
https://issues.apache.org/jira/browse/IGNITE-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206499#comment-17206499
]
Ignite TC Bot commented on IGNITE-13501:
{panel:title=Branch: [pull/8296/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8296/head] Base: [master] : New Tests
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 6{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5636305]]
* {color:#013220}IgniteCacheTestSuite6:
OnePhaseCommitAndNodeLeftTest.testImplicitlyTxOneBackups - PASSED{color}
* {color:#013220}IgniteCacheTestSuite6:
OnePhaseCommitAndNodeLeftTest.testTxZeroBackups - PASSED{color}
* {color:#013220}IgniteCacheTestSuite6:
OnePhaseCommitAndNodeLeftTest.testImplicitlyTxZeroBackups - PASSED{color}
* {color:#013220}IgniteCacheTestSuite6:
OnePhaseCommitAndNodeLeftTest.testTxOneBackups - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5636357buildTypeId=IgniteTests24Java8_RunAll]
> AssertionError: Invalid value in testMergeServersFail1_8
>
>
> Key: IGNITE-13501
> URL: https://issues.apache.org/jira/browse/IGNITE-13501
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Invalid value
> [node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c6]
> expected:<1> but was:
> Reproduced by [1]
> [1]
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3187056670751319047=testDetails
> Covered of case of one phase committed transaction with zero backups. The
> reason of this issue in that a primary node fails during a near node is
> sending a request.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13515) Performance drop when there are many thin clients per server
[
https://issues.apache.org/jira/browse/IGNITE-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206407#comment-17206407
]
Igor Seliverstov commented on IGNITE-13515:
---
[~ptupitsyn], please look at
> Performance drop when there are many thin clients per server
>
>
> Key: IGNITE-13515
> URL: https://issues.apache.org/jira/browse/IGNITE-13515
> Project: Ignite
> Issue Type: Task
> Components: clients
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a performance drop when running many thin clients per node:
> {noformat}
> 4 nodes - 1 thin client java - ~5500 pps (put per second)
> 4 nodes - 2 thin clients java - ~5000 pps
> 4 nodes - 4 thin clients java - ~4000 pps
> 4 nodes - 10 thin clients java - ~1500 pps
> 4 nodes - ~100 thin clients java - ~100 pps
> {noformat}
> May be related to sync request processing in connection thread pool on server
> side. Need to investigate and fix if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12943:
---
Fix Version/s: (was: 2.9)
2.10
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Labels: IEP-35
> Fix For: 2.10
>
>
> As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter
> out metrics for a specific exporter instance. For instance, this is how we
> can ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add {{Metrics Filtering}} section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> {{MetricExporterSpi.setExportFilter}} JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> {{MetricExporterSpi.setMetricsFilter}} to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11427) Document custom node fail functional.
[ https://issues.apache.org/jira/browse/IGNITE-11427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11427: --- Fix Version/s: (was: 2.9) 2.10 > Document custom node fail functional. > - > > Key: IGNITE-11427 > URL: https://issues.apache.org/jira/browse/IGNITE-11427 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7 >Reporter: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.10 > > Attachments: Screenshot_20190227_100539.png > > > Append additional node fail documentation related to [1] > [1] https://issues.apache.org/jira/browse/IGNITE-11332 > > how it looks into jconsole: > !Screenshot_20190227_100539.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12368) .NET: Make sure units are specified in documentation where applicable
[ https://issues.apache.org/jira/browse/IGNITE-12368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12368: --- Fix Version/s: (was: 2.9) 2.10 > .NET: Make sure units are specified in documentation where applicable > - > > Key: IGNITE-12368 > URL: https://issues.apache.org/jira/browse/IGNITE-12368 > Project: Ignite > Issue Type: Improvement > Components: documentation, platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > > Units are missing in some docs. For example, XMLDoc for > DataRegionConfiguration does not specify that MaxSize is in bytes: > https://ignite.apache.org/releases/latest/dotnetdoc/api/Apache.Ignite.Core.Configuration.DataRegionConfiguration.html > Check entire documentation and add units where needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11487) Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property
[ https://issues.apache.org/jira/browse/IGNITE-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11487: --- Fix Version/s: (was: 2.9) 2.10 > Document IGNITE_SQL_MERGE_TABLE_MAX_SIZE property > - > > Key: IGNITE-11487 > URL: https://issues.apache.org/jira/browse/IGNITE-11487 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Evgenii Zhuravlev >Assignee: Artem Budnikov >Priority: Critical > Fix For: 2.10 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11628) Document the possibility to use JAR files in UriDeploymentSpi
[
https://issues.apache.org/jira/browse/IGNITE-11628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11628:
---
Fix Version/s: (was: 2.9)
2.10
> Document the possibility to use JAR files in UriDeploymentSpi
> -
>
> Key: IGNITE-11628
> URL: https://issues.apache.org/jira/browse/IGNITE-11628
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Mekhanikov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> {{UriDeploymentSpi}} got a possibility to support regular JAR files along
> with GARs in IGNITE-11380
> This possibility should be reflected in the documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11758) Python thin: a lot of documentation files without license header
[ https://issues.apache.org/jira/browse/IGNITE-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11758: --- Fix Version/s: (was: 2.9) 2.10 > Python thin: a lot of documentation files without license header > > > Key: IGNITE-11758 > URL: https://issues.apache.org/jira/browse/IGNITE-11758 > Project: Ignite > Issue Type: Bug > Components: documentation, thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Dmitry Melnichuk >Priority: Blocker > Fix For: 2.10 > > > There are a lot of .rst documentation files in modules/platforms/python/docs/ > that does not contain license header. We need either delete them if they are > auto generated or add headers to them if they are not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11060) Add documentation about CacheInterceptor.
[ https://issues.apache.org/jira/browse/IGNITE-11060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11060: --- Fix Version/s: (was: 2.9) 2.10 > Add documentation about CacheInterceptor. > - > > Key: IGNITE-11060 > URL: https://issues.apache.org/jira/browse/IGNITE-11060 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Sergey Antonov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > > I didn't find documentation about CacheInterceptor in > [https://apacheignite.readme.io/] > (search request [https://apacheignite.readme.io/v2.7/search?q=interceptor] ) > I think we should document this feature. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9984) Documentation for EVT_MANAGEMENT_TASK_STARTED will be required.
[
https://issues.apache.org/jira/browse/IGNITE-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9984:
--
Fix Version/s: (was: 2.9)
2.10
> Documentation for EVT_MANAGEMENT_TASK_STARTED will be required.
> ---
>
> Key: IGNITE-9984
> URL: https://issues.apache.org/jira/browse/IGNITE-9984
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.8
>Reporter: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.10
>
>
> New EVT_MANAGEMENT_TASK_STARTED will be added in future release.
> Documentation for it should be added too.
> Next information should be added to web console and visor documentation:
> EVT_MANAGEMENT_TASK_STARTED provide the possibility to track next tasks that
> could be started by the user from web console and visor during some
> operations:
> +Baseline:+
> VisorBaselineTask - Task that will collect information about baseline
> topology and can change its state
> +Binaries:+
> VisorBinaryMetadataCollectorTask - Task that collects binary metadata.
> +Services:+
> VisorCancelServiceTask - Task for cancel services with the specified name.
> +Metrics:+
> VisorComputeResetMetricsTask - Task for cancel services with specified name.
> +Caches:+
> VisorCacheLostPartitionsTask - Collect list of lost partitions.
> VisorCacheResetLostPartitionsTask - Reset lost partitions for caches.
> VisorCacheStartTask - Task that start cache or near cache with specified
> configuration.
> VisorCacheStopTask - Task that stop specified caches on specified node.
> VisorCacheAffinityNodeTask - Task that will find affinity node for key.
> VisorCacheModifyTask - Task that modify value in specified cache.
> VisorCacheRebalanceTask - Pre-loads caches. Made callable just to conform
> common pattern.
> VisorCacheLoadTask - Task to loads caches.
> VisorCacheClearTask - Task that clears specified caches on specified node.
> +Queries+:
> VisorQueryResetMetricsTask - Reset compute grid query metrics.
> VisorQueryTask - Task for executing SQL fields query and get the first page
> of results.
> VisorQueryCancelTask - Task to cancel queries.
> +Computes:+
> VisorComputeResetMetricsTask - Reset compute grid metrics.
> VisorComputeCancelSessionsTask - Cancels given tasks sessions.
> +DEBUG:+
> VisorThreadDumpTask - Creates a thread dump.
> +IGFS:+
> VisorIgfsFormatTask - Format IGFS instance.
> VisorIgfsProfilerClearTask - Remove all IGFS profiler logs.
> VisorIgfsResetMetricsTask - Resets IGFS metrics.
> +LOGS:+
> VisorLogSearchTask - Search text matching in logs
> +CLUSTER:+
> VisorChangeGridActiveStateTask - Task for changing grid active state.
> VisorNodeGcTask - Task to run gc on nodes.
> VisorNodeRestartTask - Restarts nodes.
> VisorNodeStopTask - Stops nodes.
>
> {color:#33}
> {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11076) Add documentation for control.sh idle_verify --exclude-caches and --cache-filter
[
https://issues.apache.org/jira/browse/IGNITE-11076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11076:
---
Fix Version/s: (was: 2.9)
2.10
> Add documentation for control.sh idle_verify --exclude-caches and
> --cache-filter
>
>
> Key: IGNITE-11076
> URL: https://issues.apache.org/jira/browse/IGNITE-11076
> Project: Ignite
> Issue Type: Task
> Components: control.sh, documentation
>Reporter: Sergey Antonov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> control.sh cache --help output
> {noformat}
> The '--cache subcommand' is used to get information about and perform actions
> with caches. The command has the following syntax:
> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]]
> [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]]
> [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type KEYSTORE_TYPE]
> [--keystore KEYSTORE_PATH] [--keystore-password KEYSTORE_PASSWORD]
> [--truststore-type TRUSTSTORE_TYPE] [--truststore TRUSTSTORE_PATH]
> [--truststore-password TRUSTSTORE_PASSWORD] --cache [subcommand]
>
> The subcommands that take [nodeId] as an argument ('list', 'contention' and
> 'validate_indexes') will be executed on the given node or on all server nodes
> if the option is not specified. Other commands will run on a random server
> node.
> Subcommands:
>
> --cache list regexPattern [--groups|--seq] [nodeId] [--config]
> [--output-format multi-line]
> Show information about caches, groups or sequences that match a regular
> expression. When executed without parameters, this subcommand prints the list
> of caches.
> Parameters:
> --config - print all configuration parameters for each cache.
> --output-format multi-line - print configuration parameters per line. This
> option has effect only when used with --config and without [--groups|--seq].
> --groups - print information about groups.
> --seq - print information about sequences.
>
> --cache contention minQueueSize [nodeId] [maxPrint]
> Show the keys that are point of contention for multiple transactions.
>
> --cache idle_verify [--dump] [--skip-zeros] [--check-crc] [(--exclude-caches
> cacheName1,...,cacheNameN)|(--cache-filter
> ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT)|cacheName1,...,cacheNameN]
> Verify counters and hash sums of primary and backup partitions for the
> specified caches on an idle cluster and print out the differences, if any.
> Parameters:
> --check-crc - check the CRC-sum of pages stored on disk before verifying data
> consistency in partitions between primary and backup nodes.
>
> --cache validate_indexes [cacheName1,...,cacheNameN] [nodeId] [--check-first
> N|--check-through K]
> Validate indexes on an idle cluster and print out the keys that are missing
> in the indexes.
> Parameters:
> --check-first N - validate only the first N keys
> --check-through K - validate every Kth key
>
> --cache distribution nodeId|null [cacheName1,...,cacheNameN]
> [--user-attributes attrName1,...,attrNameN]
> Prints the information about partition distribution.
>
> --cache reset_lost_partitions cacheName1,...,cacheNameN
> Reset the state of lost partitions for the specified caches.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9547) Document DML operations prohibited inside transaction
[ https://issues.apache.org/jira/browse/IGNITE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9547: -- Fix Version/s: (was: 2.9) 2.10 > Document DML operations prohibited inside transaction > - > > Key: IGNITE-9547 > URL: https://issues.apache.org/jira/browse/IGNITE-9547 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Reporter: Yury Gerzhedovich >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > > Docs says: > ""Presently, DML supports the atomic mode only meaning that if there is a DML > query that is executed as a part of an Ignite transaction then it will not be > enlisted in the transaction's writing queue and will be executed right away"" > However it's wrong. > We need to document that now any DML operations is prohibited and throw > Exception in case it will be executed inside a transaction. > > Also appeared new boolean property IGNITE_ALLOW_DML_INSIDE_TRANSACTION. it is > necessary to emulate the old behavior. In case value is true then DML > operation is allowed, but it be applied only after transaction will be > commited. > By default value is false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10880) Document how we should evolve our persistence functionality while keeping it compatible with files created by old versions
[ https://issues.apache.org/jira/browse/IGNITE-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10880: --- Fix Version/s: (was: 2.9) 2.10 > Document how we should evolve our persistence functionality while keeping it > compatible with files created by old versions > -- > > Key: IGNITE-10880 > URL: https://issues.apache.org/jira/browse/IGNITE-10880 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Eduard Shangareev >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.10 > > > It's not documented at all (???). > We need complete documentation to not break compatibility with previously > created database files while updating/evolving code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11404) Document CREATE TABLE "parallelism" option
[
https://issues.apache.org/jira/browse/IGNITE-11404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11404:
---
Fix Version/s: (was: 2.9)
2.10
> Document CREATE TABLE "parallelism" option
> --
>
> Key: IGNITE-11404
> URL: https://issues.apache.org/jira/browse/IGNITE-11404
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> We added new {{PARALLELISM}} option:
> {code}
> CREATE TABLE ... WITH "parallelism = 4"
> {code}
> This option affect query parallelism which is otherwise set from
> {{CacheConfiguration.queryParallelism}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11252) Docs: Index corruption recovery procedure
[ https://issues.apache.org/jira/browse/IGNITE-11252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11252: --- Fix Version/s: (was: 2.9) 2.10 > Docs: Index corruption recovery procedure > - > > Key: IGNITE-11252 > URL: https://issues.apache.org/jira/browse/IGNITE-11252 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.7 >Reporter: Denis A. Magda >Assignee: Prachi Garg >Priority: Critical > Fix For: 2.10 > > > We need to document a recovery procedure if an index corruption happens. > Refer to this thread for details and examples of the exception dumped to the > logs if the issue occurs: > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-index-corruption-issue-gt-unrecoverable-cluster-td39869.html > # Recovering from an index corruption > ## Applicable if > It is known that an index of a cache is corrupted, but the main data > (partition files and WAL) is fine. Show code snippets of possible examples. > Find via the references shared in the dev list discussion. > ## Steps to recover > 1. Stop the node > 2. Delete index.bin of the affected caches (path is > db//cache-/index.bin) > 3. Start the node > - Note: At this point the node is active in the cluster but don’t have > indexes. > It means that it serves SQL queries but their performance can be low. > Avoid running SQL queries on large tables at this point > 4. Wait for message “Finished indexes rebuilding for cache ” in > the Ignite log > # Recovering from a persistent storage corruption > ## Applicable if > A part of the persistent storage (partition files, checkpoint markers or WAL) > was corrupted > and there is no other way to recover it, but there are healthy copies of all > data on other nodes. > ## Steps to recover > 1. Stop the node > 2. Delete all persistence files of the node (best to clear Ignite working > directory, storage directory, WAL and WAL archive directories) > 3. Make sure consistentId is explicitly set in the configuration of the node > - If it isn’t, lookup the generated consistentId using control.sh and set it > explicitly in the config or via IGNITE_CONSISTENT_ID (2.8+ only) > 4. Start the node > 5. Wait for messages for all caches -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10845) Ignite Production Readiness Section Enhancement
[ https://issues.apache.org/jira/browse/IGNITE-10845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10845: --- Fix Version/s: (was: 2.9) 2.10 > Ignite Production Readiness Section Enhancement > --- > > Key: IGNITE-10845 > URL: https://issues.apache.org/jira/browse/IGNITE-10845 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.10 > > > Enhance Ignite production readiness section with points from here: > https://www.gridgain.com/resources/blog/checklist-assembling-your-first-apacher-ignitetm-cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11694) Add documentation for SqlFieldsQuery.updateBatchSize into thin clients docs
[
https://issues.apache.org/jira/browse/IGNITE-11694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11694:
---
Fix Version/s: (was: 2.9)
2.10
> Add documentation for SqlFieldsQuery.updateBatchSize into thin clients docs
> ---
>
> Key: IGNITE-11694
> URL: https://issues.apache.org/jira/browse/IGNITE-11694
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.7
>Reporter: Taras Ledkov
>Priority: Major
> Fix For: 2.10
>
>
> The property {{SqlFieldsQuery.updateBatchSize}} is introduced by the patch
> IGNITE-11499.
> ODBC, thin JDBC, thin client documentation should be changed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11187) Additional documentation for re-balancing is canceled if client node joins.
[ https://issues.apache.org/jira/browse/IGNITE-11187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11187: --- Fix Version/s: (was: 2.9) 2.10 > Additional documentation for re-balancing is canceled if client node joins. > --- > > Key: IGNITE-11187 > URL: https://issues.apache.org/jira/browse/IGNITE-11187 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7 >Reporter: Stanilovsky Evgeny >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.10 > > > Need additional documentation for [IGNITE-7165] Re-balancing is canceled if > client node joins. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11965) Pyton client: Expiration policies are missed
[ https://issues.apache.org/jira/browse/IGNITE-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11965: --- Fix Version/s: (was: 2.9) 2.10 > Pyton client: Expiration policies are missed > > > Key: IGNITE-11965 > URL: https://issues.apache.org/jira/browse/IGNITE-11965 > Project: Ignite > Issue Type: Bug > Components: documentation, thin client >Affects Versions: 2.7, 2.7.5 >Reporter: Andrey Aleksandrov >Priority: Major > Fix For: 2.10 > > > [https://apacheignite.readme.io/docs/expiry-policies] are missed but > [https://apacheignite.readme.io/docs/expiry-policies#section-eager-ttl] can > be set. > Should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9091) IEP-25: creating documentation
[ https://issues.apache.org/jira/browse/IGNITE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9091: -- Fix Version/s: (was: 2.9) 2.10 > IEP-25: creating documentation > -- > > Key: IGNITE-9091 > URL: https://issues.apache.org/jira/browse/IGNITE-9091 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alex Volkov >Assignee: Artem Budnikov >Priority: Major > Labels: iep-25 > Fix For: 2.10 > > > It would be great to have proper documentation for IEP-25: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-25:+Partition+Map+Exchange+hangs+resolving] > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9716) Document partition distribution and reset lost partitions commands of control script
[ https://issues.apache.org/jira/browse/IGNITE-9716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9716: -- Fix Version/s: (was: 2.9) 2.10 > Document partition distribution and reset lost partitions commands of control > script > > > Key: IGNITE-9716 > URL: https://issues.apache.org/jira/browse/IGNITE-9716 > Project: Ignite > Issue Type: Task > Components: control.sh, documentation >Affects Versions: 2.7 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.10 > > > See [IGNITE-9549] - > control.sh add command to collect information on the distribution of > partitions and reset lost partitions > for details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-7704) Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations
[ https://issues.apache.org/jira/browse/IGNITE-7704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-7704: -- Fix Version/s: (was: 2.9) 2.10 > Document IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpi timeouts > and their relations > --- > > Key: IGNITE-7704 > URL: https://issues.apache.org/jira/browse/IGNITE-7704 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.3 >Reporter: Alexey Popov >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.10 > > Attachments: timeouts.md, timeouts_v2.md > > > We often see similar questions related to IgniteConfiguration, > TcpDiscoverySpi, TcpCommunicationSpi timeouts and their relations. And we see > several side-effects after incorrect timeout configuration. > It looks like this question is not well documented. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10268) Remove documentation about "replicatedOnly" flag
[ https://issues.apache.org/jira/browse/IGNITE-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10268: --- Fix Version/s: (was: 2.9) 2.10 > Remove documentation about "replicatedOnly" flag > > > Key: IGNITE-10268 > URL: https://issues.apache.org/jira/browse/IGNITE-10268 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > > SqlQuery.replicatedOnly and SqlFieldsQuery.replicatedOnly flags were > deprecated. Need to remove all places where it is mentioned from docs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10649) Add documentation for control.sh about SSL
[
https://issues.apache.org/jira/browse/IGNITE-10649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10649:
---
Fix Version/s: (was: 2.9)
2.10
> Add documentation for control.sh about SSL
> --
>
> Key: IGNITE-10649
> URL: https://issues.apache.org/jira/browse/IGNITE-10649
> Project: Ignite
> Issue Type: Task
> Components: control.sh, documentation
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.10
>
>
> Control.sh help output:
> {noformat}
> Control.sh is used to execute admin commands on cluster or get common cluster
> info. The command has the following syntax:
> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]]
> [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]]
> [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type KEYSTORE_TYPE]
> [--keystore KEYSTORE_PATH] [--keystore-password KEYSTORE_PASSWORD]
> [--truststore-type TRUSTSTORE_TYPE] [--truststore TRUSTSTORE_PATH]
> [--truststore-password TRUSTSTORE_PASSWORD] [command]
> This utility can do the following commands:
> Activate cluster:
> control.sh --activate
> Deactivate cluster:
> control.sh --deactivate [--yes]
> Print current cluster state:
> control.sh --state
> Print cluster baseline topology:
> control.sh --baseline
> Add nodes into baseline topology:
> control.sh --baseline add consistentId1[,consistentId2,,consistentIdN]
> [--yes]
> Remove nodes from baseline topology:
> control.sh --baseline remove consistentId1[,consistentId2,,consistentIdN]
> [--yes]
> Set baseline topology:
> control.sh --baseline set consistentId1[,consistentId2,,consistentIdN]
> [--yes]
> Set baseline topology based on version:
> control.sh --baseline version topologyVersion [--yes]
> List or kill transactions:
> control.sh --tx [--xid XID] [--min-duration SECONDS] [--min-size SIZE]
> [--label PATTERN_REGEX] [--servers|--clients] [--nodes
> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
> DURATION|SIZE|START_TIME] [--kill] [--yes]
> Print absolute paths of unused archived wal segments on each node:
> control.sh --wal print [consistentId1,consistentId2,,consistentIdN]
> Delete unused archived wal segments on each node:
> control.sh --wal delete [consistentId1,consistentId2,,consistentIdN]
> [--yes]
> View caches information in a cluster. For more details type:
> control.sh --cache help
> By default commands affecting the cluster require interactive confirmation.
> Use --yes option to disable it.
> Default values:
> HOST_OR_IP=127.0.0.1
> PORT=11211
> PING_INTERVAL=5000
> PING_TIMEOUT=3
> SSL_PROTOCOL=TLS
> SSL_KEY_ALGORITHM=SunX509
> KEYSTORE_TYPE=JKS
> TRUSTSTORE_TYPE=JKS
> Exit codes:
> 0 - successful execution.
> 1 - invalid arguments.
> 2 - connection failed.
> 3 - authentication failed.
> 4 - unexpected error.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12955) Document a new command control.sh --cache check_index_inline_sizes
[ https://issues.apache.org/jira/browse/IGNITE-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12955: --- Fix Version/s: (was: 2.9) 2.10 > Document a new command control.sh --cache check_index_inline_sizes > -- > > Key: IGNITE-12955 > URL: https://issues.apache.org/jira/browse/IGNITE-12955 > Project: Ignite > Issue Type: New Feature > Components: control.sh, documentation >Reporter: Sergey Antonov >Priority: Major > Fix For: 2.10 > > > Please look at IGNITE-12942 and devlist discussion linked to IGNITE-12942 for > all information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6526) Ignite 2.x capacity planning guide
[ https://issues.apache.org/jira/browse/IGNITE-6526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-6526: -- Fix Version/s: (was: 2.9) 2.10 > Ignite 2.x capacity planning guide > -- > > Key: IGNITE-6526 > URL: https://issues.apache.org/jira/browse/IGNITE-6526 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis A. Magda >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > > Current capacity planning guide [1] is too high level and should be > elaborated considering durable memory's internals: > - memory pages overhead. > - per-entry overhead > (http://apache-ignite-users.70518.x6.nabble.com/Re-Memory-Overhead-per-entry-in-Apache-Ignite-td9498.html). > - space occupied for indexing needs. > - free lists > - etc. > The page has to include estimates for the Ignite Native Persistence: > - entry size and its overheads. > - index size and overheads. > - data files overheads. > - estimated WAL size and how to shrink it basing on checkpointing settings. > [1] https://apacheignite.readme.io/docs/capacity-planning -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-8411) Binary Client Protocol spec: other parts clarifications
[ https://issues.apache.org/jira/browse/IGNITE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-8411: -- Fix Version/s: (was: 2.9) 2.10 > Binary Client Protocol spec: other parts clarifications > --- > > Key: IGNITE-8411 > URL: https://issues.apache.org/jira/browse/IGNITE-8411 > Project: Ignite > Issue Type: Improvement > Components: documentation, thin client >Affects Versions: 2.4 >Reporter: Alexey Kosenchuk >Assignee: Igor Sapego >Priority: Major > Fix For: 2.10 > > > issues against previous parts: IGNITE-8039 IGNITE-8212 > Cache Configuration > --- > > [https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations] > - OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - > QueryEntity - Structure of QueryField: > absent "default value - type Object" - it is the last field of the > QueryField in reality. > - OP_CACHE_GET_CONFIGURATION - Structure of Cache Configuration: > Absent CacheAtomicityMode - is the first field in reality. > Absent MaxConcurrentAsyncOperations - is between DefaultLockTimeout and > MaxQueryIterators in reality. > "Invalidate" field - does not exist in reality. > - meaning and possible values of every configuration parameter must be > clarified. If clarified in other docs, this spec must have link(s) to that > docs. > - suggest to combine somehow Cache Configuration descriptions in > OP_CACHE_GET_CONFIGURATION and OP_CACHE_CREATE_WITH_CONFIGURATION - to avoid > duplicated descriptions. > SQL and Scan Queries > > [https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations] > - "Flag. Pass 0 for default, or 1 to keep the value in binary form.": > "the value in binary form" flag should be left end clarified in the > operations to which it is applicable for. > - OP_QUERY_SQL: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** "Name of a type or SQL table": name of what type? > - OP_QUERY_SQL_FIELDS: > most of the fields in the request must be clarified. If clarified in other > docs, this spec must have link(s) to that docs. > For example: > ** is there any correlation between "Query cursor page size" and "Max rows"? > ** "Statement type": why there are only three types? what about INSERT, etc.? > - OP_QUERY_SQL_FIELDS_CURSOR_GET_PAGE Response does not contain Cursor id. > But responses for all other query operations contain it. Is it intentional? > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Cursor id is absent in reality. > - OP_QUERY_SCAN_CURSOR_GET_PAGE Response - Row count field: says type > "long". Should be "int". > - OP_QUERY_SCAN: > format and rules of the Filter object must be clarified. If clarified in > other docs, this spec must have link(s) to that docs. > - OP_QUERY_SCAN: > in general, it's not clear how this operation should be supported on > platforms other than the mentioned in "Filter platform" field. > - OP_QUERY_SCAN: "Number of partitions to query" > Should be updated to "A partition number to query" > > Binary Types > > > [https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations] > - somewhere should be explained when and why these operations need to be > supported by a client. > - Type id and Field id: > should be clarified that before an Id calculation Type and Field names must > be updated to low case. > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - BinaryField - Type id: > in reality it is not a type id (hash code) but a type code (1, 2,... 10,... > 103,...). > - OP_GET_BINARY_TYPE and OP_PUT_BINARY_TYPE - "Affinity key field name": > should be explained what is it. If explained in other docs, this spec must > have link(s) to that docs. > - OP_PUT_BINARY_TYPE - schema id: > mandatory algorithm of schema Id calculation must be described somewhere. If > described in other docs, this spec must have link(s) to that docs. > - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME: > should be explained when and why these operations need to be supported by a > client. > How this operation should be supported on platforms other than the mentioned > in "Platform id" field. > - OP_REGISTER_BINARY_TYPE_NAME: > Type name - is it "full" or "short" name here? > Type id - is it a hash from "full" or "short" name here? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12846) Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description in binary release
[
https://issues.apache.org/jira/browse/IGNITE-12846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12846:
---
Fix Version/s: (was: 2.9)
2.10
> Docs: ml package org.apache.ignite.ml.knn.utils.indices have no description
> in binary release
> -
>
> Key: IGNITE-12846
> URL: https://issues.apache.org/jira/browse/IGNITE-12846
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.8
>Reporter: Stepan Pilschikov
>Assignee: Alexey Zinoviev
>Priority: Major
> Fix For: 2.10
>
>
> apache-ignite-2.8.0-bin/docs/javadoc/overview-summary.html does not contain
> description block for org.apache.ignite.ml.knn.utils.indices
> Actual:
> {code}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
>
> {code}
> Expected:
> {code}
>
>
> href="org/apache/ignite/ml/knn/utils/indices/package-summary.html">org.apache.ignite.ml.knn.utils.indices
>
> [Some description]
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9485) Update documentation for ScanQuery with setLocal flag
[ https://issues.apache.org/jira/browse/IGNITE-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9485: -- Fix Version/s: (was: 2.9) 2.10 > Update documentation for ScanQuery with setLocal flag > - > > Key: IGNITE-9485 > URL: https://issues.apache.org/jira/browse/IGNITE-9485 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11768) CPP documentation:mention default BinaryType methods implementation
[ https://issues.apache.org/jira/browse/IGNITE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11768: --- Fix Version/s: (was: 2.9) 2.10 > CPP documentation:mention default BinaryType methods implementation > --- > > Key: IGNITE-11768 > URL: https://issues.apache.org/jira/browse/IGNITE-11768 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.7 >Reporter: Igor Sapego >Priority: Major > Labels: cpp > Fix For: 2.10 > > > Mention BinaryTypeDefaultHashing, BinaryTypeNonNullableType and > BinaryTypeDefaultAll classes introduced in IGNITE-11703 in documentation. > Also, use them where it is possible and appropriate in code snippets. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10581) Document new flag to filter cache types in control.sh
[ https://issues.apache.org/jira/browse/IGNITE-10581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10581: --- Fix Version/s: (was: 2.9) 2.10 > Document new flag to filter cache types in control.sh > - > > Key: IGNITE-10581 > URL: https://issues.apache.org/jira/browse/IGNITE-10581 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Alexey Goncharuk >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10895) MVCC: Document several modes of pessimistic transactions are allowed for MVCC caches.
[ https://issues.apache.org/jira/browse/IGNITE-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10895: --- Fix Version/s: (was: 2.9) 2.10 > MVCC: Document several modes of pessimistic transactions are allowed for MVCC > caches. > - > > Key: IGNITE-10895 > URL: https://issues.apache.org/jira/browse/IGNITE-10895 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Roman Kondakov >Priority: Major > Fix For: 2.10 > > > It is need to document that for MVCC caches optimistic transactions are > prohibited as before, but there are several isolation levels are allowed now: > * READ COMMITTED > * REPEATABLE READ > * SERIALIZABLE > Actually all these levels have the same implementation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-9406) Improve SQL "Performance and Debugging" page
[ https://issues.apache.org/jira/browse/IGNITE-9406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9406: -- Fix Version/s: (was: 2.9) 2.10 > Improve SQL "Performance and Debugging" page > > > Key: IGNITE-9406 > URL: https://issues.apache.org/jira/browse/IGNITE-9406 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > Attachments: ignite_sql_perf.txt > > > I prepared a document for one of Ignite clients with some advanced > information about how various performance optimizations work in Ignite SQL. > Let's compare this document with our "Performance and Debugging" page [1], > and enhance the latter with missing info (if any). > P.S.: Document is attached. Russian language. > [1] > https://apacheignite-sql.readme.io/docs/performance-and-debugging#query-execution-flow-optimizations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11184) add example of ssl rest protocol on ignite
[ https://issues.apache.org/jira/browse/IGNITE-11184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11184: --- Fix Version/s: (was: 2.9) 2.10 > add example of ssl rest protocol on ignite > -- > > Key: IGNITE-11184 > URL: https://issues.apache.org/jira/browse/IGNITE-11184 > Project: Ignite > Issue Type: Bug > Components: documentation >Affects Versions: 2.7 >Reporter: ARomantsov >Priority: Critical > Fix For: 2.10 > > > Add information about ssl Jetty configuration to ignite documentation about > restApi > https://apacheignite.readme.io/docs/rest-api#sample-jetty-xml-configuration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10699) Update documentation for control.sh
[
https://issues.apache.org/jira/browse/IGNITE-10699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10699:
---
Fix Version/s: (was: 2.9)
2.10
> Update documentation for control.sh
> ---
>
> Key: IGNITE-10699
> URL: https://issues.apache.org/jira/browse/IGNITE-10699
> Project: Ignite
> Issue Type: Task
> Components: control.sh, documentation
>Reporter: Sergey Antonov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> I renamed view parameters in control.sh utility. The changes are following:
> ||Was||Has been||
> |--skipZeros|--skip-zeros|
> |--cacheFilter|--cache-filter|
> |checkFirst|--check-first|
> |checkThrough|--check-through|
> |limit| --limit|
> |order|--order|
> |servers|--servers|
> |clients|--clients|
> |minDuration|--min-duration|
> |minSize|--min-size|
> |label|--label|
> |nodes|--nodes|
> |xid|--xid|
> |kill|--kill|
> |groups|--groups|
> |seq|--seq|
>
> You could find current output command {{control.sh --cache help}}
> {noformat}
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User: santonov
>
> The '--cache subcommand' is used to get information about and perform actions
> with caches. The command has the following syntax:
> control.sh [[--host HOST_OR_IP], [--port PORT], [--user USER], [--password
> PASSWORD], [--ping-interval PING_INTERVAL], [--ping-timeout PING_TIMEOUT],
> [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]],
> [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]],
> [--ssl-key-algorithm SSL_KEY_ALGORITHM], [--keystore-type KEYSTORE_TYPE],
> [--keystore KEYSTORE_PATH], [--keystore-password KEYSTORE_PASSWORD],
> [--truststore-type TRUSTSTORE_TYPE], [--truststore TRUSTSTORE_PATH],
> [--truststore-password TRUSTSTORE_PASSWORD]] --cache[subcommand]
>
> The subcommands that take [nodeId] as an argument ('list', 'contention' and
> 'validate_indexes') will be executed on the given node or on all server nodes
> if the option is not specified. Other commands will run on a random server
> node.
> Subcommands:
>
> --cache list regexPattern [groups|seq] [nodeId] [--config] [--output-format
> multi-line]
> Show information about caches, groups or sequences that match a regular
> expression. When executed without parameters, this subcommand prints the list
> of caches.
> Parameters:
> --config - print a all configuration parameters for each cache.
> --output-format multi-line - print configuration parameters per line. This
> option has effect only when used with --config and without [groups|seq].
>
> --cache contention minQueueSize [nodeId] [maxPrint]
> Show the keys that are point of contention for multiple transactions.
>
> --cache idle_verify [--dump] [--skip-zeros] [cache1,...,cacheN]
> [--cache-filter ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT]
> Verify counters and hash sums of primary and backup partitions for the
> specified caches on an idle cluster and print out the differences, if any.
>
> --cache validate_indexes [cache1,...,cacheN] [nodeId] [--check-first
> N|--check-through K]
> Validate indexes on an idle cluster and print out the keys that are missing
> in the indexes.
> Parameters:
> --check-first N - validate only the first N keys
> --check-through K - validate every Kth key
>
> --cache distribution nodeId|null [cacheName1,...,cacheNameN]
> [--user-attributes attrName1,...,attrNameN]
> Prints the information about partition distribution.
>
> --cache reset_lost_partitions cacheName1,...,cacheNameN
> Reset the state of lost partitions for the specified caches.{noformat}
> And {{control.sh --help}}
> {noformat}
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User: santonov
>
> Contol.sh is used to execute admin commands on cluster or get common cluster
> info. The command has the following syntax:
> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> [--ssl-protocol SSL_PROTOCOL[,
[jira] [Updated] (IGNITE-11057) Document new SQL system view "CACHE_GROUPS_IO"
[
https://issues.apache.org/jira/browse/IGNITE-11057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11057:
---
Fix Version/s: (was: 2.9)
2.10
> Document new SQL system view "CACHE_GROUPS_IO"
> --
>
> Key: IGNITE-11057
> URL: https://issues.apache.org/jira/browse/IGNITE-11057
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> See
> {{modules\indexing\src\main\java\org\apache\ignite\internal\processors\query\h2\sys\view\SqlSystemViewCacheGroupsIOStatistics.java}}
> # {{GROUP_ID}} - cache group ID
> # {{GROUP_ID}} - cache group name
> # {{PHYSICAL_READS}} - number of physical reads (i.e. block read from disk)
> for the given group
> # {{LOGICAL_READS}} - number of logical reads (i.e. from buffer cache) for
> the given group.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10947) CPP: Fix documentation on how to build Ignite C++ on Linux
[
https://issues.apache.org/jira/browse/IGNITE-10947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10947:
---
Fix Version/s: (was: 2.9)
2.10
> CPP: Fix documentation on how to build Ignite C++ on Linux
> --
>
> Key: IGNITE-10947
> URL: https://issues.apache.org/jira/browse/IGNITE-10947
> Project: Ignite
> Issue Type: Improvement
> Components: documentation, platforms
>Reporter: Igor Sapego
>Priority: Major
> Fix For: 2.10
>
>
> We now have build step (IGNITE-10940) that performs following steps during
> release of the binary package of the Ignite:
> {code}
> # libtoolize
> # aclocal
> # autoheader
> # automake --add-missing
> # autoreconf
> {code}
> So we now should change documentation, that users only need to run following
> commands to build Ignite C++ from binary distribution of Ignite.
> {code}
> # ./configure
> # make
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9856) Update documentation for control.sh --cache list
[
https://issues.apache.org/jira/browse/IGNITE-9856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9856:
--
Fix Version/s: (was: 2.9)
2.10
> Update documentation for control.sh --cache list
>
>
> Key: IGNITE-9856
> URL: https://issues.apache.org/jira/browse/IGNITE-9856
> Project: Ignite
> Issue Type: Improvement
> Components: control.sh, documentation
>Reporter: Sergey Antonov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> {{Documentation for option --cache list in control.sh}} must be updated.
> As reference could be used help message:
> {noformat}
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User: santonov
>
> The '--cache subcommand' is used to get information about and perform
> actions with caches. The command has the following syntax:
> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> --cache[subcommand]
> The subcommands that take [nodeId] as an argument ('list', 'contention' and
> 'validate_indexes') will be executed on the given node or on all server nodes
> if the option is not specified. Other commands will run on a random server
> node.
> Subcommands:
>
>
> --cache list regexPattern [groups|seq] [nodeId] [--config] [--output-format
> multi-line]
> Show information about caches, groups or sequences that match a regular
> expression. When executed without parameters, this subcommand prints the list
> of caches.
> Parameters:
> --config- print a all configuration parameters for
> each cache.
> --output-format multi-line - print configuration parameters per line.
> This option has effect only when used with --config and without [groups|seq].
>
>
> --cache contention minQueueSize [nodeId] [maxPrint]
> Show the keys that are point of contention for multiple transactions.
>
>
> --cache idle_verify [--dump] [--skipZeros] [cache1,...,cacheN]
> Verify counters and hash sums of primary and backup partitions for the
> specified caches on an idle cluster and print out the differences, if any.
>
>
> --cache validate_indexes [cache1,...,cacheN] [nodeId] [checkFirst
> N|checkThrough K]
> Validate indexes on an idle cluster and print out the keys that are
> missing in the indexes.
> Parameters:
> checkFirst N- validate only the first N keys
> checkThrough K - validate every Kth key
>
>
> --cache distribution nodeId|null [cacheName1,...,cacheNameN]
> [--user-attributes attName1,...,attrNameN]
> Prints the information about partition distribution.
>
>
> --cache reset_lost_partitions cacheName1,...,cacheNameN
> Reset the state of lost partitions for the specified caches.
> {noformat}
> And output example:
> {noformat}
> control.sh --cache list .* --config --yes
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User: santonov
>
> ignite-sys-cache: [name=ignite-sys-cache, grpName=null, mode=REPLICATED,
> atomicityMode=TRANSACTIONAL, eagerTtl=true,
> writeSynchronizationMode=FULL_SYNC, invalidate=false,
> maxConcurrentAsyncOps=500, interceptor=null, dfltLockTimeout=0,
> affinityCfg=VisorCacheAffinityConfiguration
> [function=o.a.i.cache.affinity.rendezvous.RendezvousAffinityFunction,
> mapper=o.a.i.i.processors.cache.GridCacheDefaultAffinityKeyMapper,
> partitionedBackups=2147483647, partitions=100, exclNeighbors=false],
> rebalanceCfg=VisorCacheRebalanceConfiguration [mode=SYNC, batchSize=524288,
> partitionedDelay=0, throttle=0, timeout=1, batchesPrefetchCnt=2,
> rebalanceOrder=-2], evictCfg=VisorCacheEvictionConfiguration [plc=null,
> plcMaxSize=null, filter=null], nearCfg=VisorCacheNearConfiguration
> [nearEnabled=false, nearStartSize=0, nearEvictPlc=null,
> nearEvictMaxSize=null], storeCfg=VisorCacheStoreConfiguration
> [jdbcStore=false, store=null, storeFactory=null, readThrough=false,
> writeThrough=false,
[jira] [Updated] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13206: --- Fix Version/s: (was: 2.9) 2.10 > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3' to detect failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10846) Improve docs for "Disabling WAL Archiving"
[ https://issues.apache.org/jira/browse/IGNITE-10846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10846: --- Fix Version/s: (was: 2.9) 2.10 > Improve docs for "Disabling WAL Archiving" > -- > > Key: IGNITE-10846 > URL: https://issues.apache.org/jira/browse/IGNITE-10846 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Prachi Garg >Assignee: Artem Budnikov >Priority: Critical > Fix For: 2.10 > > > Provide pros and cons of disabling WAL Archiving. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11789) Document changes of LRT diagnostic messages made in IGNITE-11392
[
https://issues.apache.org/jira/browse/IGNITE-11789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11789:
---
Fix Version/s: (was: 2.9)
2.10
> Document changes of LRT diagnostic messages made in IGNITE-11392
>
>
> Key: IGNITE-11789
> URL: https://issues.apache.org/jira/browse/IGNITE-11789
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis Chudov
>Priority: Major
> Fix For: 2.10
>
>
> When LRT is detected, in the case if it is active, local node creates a
> request to near (client) node to get the dump of a thread that created the
> transaction. Dump of the client node appears in server node log.
> There is new property in org.apache.ignite.mxbean.TransactionsMXBean class
> that shows is thread dumps requesting allowed or disallowed:
> *TxOwnerDumpRequestsAllowed*
> By default, dump requests are turned on.
> Log messages look like following:
> {code:java}
> Dumping the near node thread that started transaction [xidVer=]
> Stack trace of the transaction owner thread:
>
> {code}
> In case of client error or error while trying to read result:
> {code:java}
> Could not get thread dump from transaction owner near node:
> {code}
> In case of error while trying to send request:
> {code:java}
> Could not send dump request to transaction owner near node:
>
> {code}
> In case if client is already out of topology:
> {code:java}
> Could not get thread dump from transaction owner because near node is now out
> of topology. Node ID: {code}
> In case if client does not support this feature:
> {code:java}
> Could not send dump request to transaction owner near node: node does not
> support this feature.
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11630) Document changes to SQL views
[
https://issues.apache.org/jira/browse/IGNITE-11630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11630:
---
Fix Version/s: (was: 2.9)
2.10
> Document changes to SQL views
> -
>
> Key: IGNITE-11630
> URL: https://issues.apache.org/jira/browse/IGNITE-11630
> Project: Ignite
> Issue Type: Task
> Components: documentation, sql
>Reporter: Vladimir Ozerov
>Assignee: Artem Budnikov
>Priority: Major
> Fix For: 2.10
>
>
> The following changes were made to our views.
> {{CACHE_GROUPS}}
> # {{ID}} -> {{CACHE_GROUP_ID}}
> # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}}
> {{LOCAL_CACHE_GROUPS_IO}}
> # {{GROUP_ID}} -> {{CACHE_GROUP_ID}}
> # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}}
> {{CACHES}}
> # {{NAME}} -> {{CACHE_NAME}}
> # {{GROUP_ID}} -> {{CACHE_GROUP_ID}}
> # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}}
> {{INDEXES}}
> # {{GROUP_ID}} -> {{CACHE_GROUP_ID}}
> # {{GROUP_NAME}} -> {{CACHE_GROUP_NAME}}
> {{NODES}}
> # {{ID}} -> {{NODE_ID}}
> {{TABLES}}
> # Added {{CACHE_GROUP_ID}}
> # Added {{CACHE_GROUP_NAME}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10710) Document new REST API for baseline topology command.
[ https://issues.apache.org/jira/browse/IGNITE-10710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10710: --- Fix Version/s: (was: 2.9) 2.10 > Document new REST API for baseline topology command. > > > Key: IGNITE-10710 > URL: https://issues.apache.org/jira/browse/IGNITE-10710 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.8 >Reporter: Andrey Novikov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10887) .NET: Align .Net docs with Java
[ https://issues.apache.org/jira/browse/IGNITE-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10887: --- Fix Version/s: (was: 2.9) 2.10 > .NET: Align .Net docs with Java > --- > > Key: IGNITE-10887 > URL: https://issues.apache.org/jira/browse/IGNITE-10887 > Project: Ignite > Issue Type: Bug > Components: documentation >Reporter: Stanislav Lukyanov >Priority: Critical > Fix For: 2.10 > > > It seems that the .Net docs are a bit outdated compared to Java ones. > Need to align .Net and Java docs. .Net pages which are not specific to the > platform should be replaced with a simple link to the Java docs. The docs > that have .Net-specific things (e.g. code examples) should be reworked. > The pages with issues > - Performnace Tips page > (https://apacheignite-net.readme.io/docs/performance-tips) > - Off-heap memory (https://apacheignite-net.readme.io/docs/off-heap-memory) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10977) Document unsupported clear() call for MVCC caches
[
https://issues.apache.org/jira/browse/IGNITE-10977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10977:
---
Fix Version/s: (was: 2.9)
2.10
> Document unsupported clear() call for MVCC caches
> -
>
> Key: IGNITE-10977
> URL: https://issues.apache.org/jira/browse/IGNITE-10977
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Priority: Major
> Fix For: 2.10
>
>
> Now MVCC caches don't support {{cache.clear()}} by design. So let's document
> it as a known limitations (I suppose we should have such page on readme.io)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11729) Low description for lost policy functional
[
https://issues.apache.org/jira/browse/IGNITE-11729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11729:
---
Fix Version/s: (was: 2.9)
2.10
> Low description for lost policy functional
> --
>
> Key: IGNITE-11729
> URL: https://issues.apache.org/jira/browse/IGNITE-11729
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.7
>Reporter: ARomantsov
>Priority: Major
> Fix For: 2.10
>
>
> Current description in
> https://apacheignite.readme.io/docs/partition-loss-policies seems not covered
> persistence case and text description is not clear
> Probably we need to transform it into two tables (in-memory, persistence)
> Rows - cache_write, cache_read, cache_remove,sql_read, sql_write
> Columns - READ_ONLY_SAFE ,READ_ONLY_ALL, READ_WRITE_SAFE, etc
> {code:java}
> Policies
> Ignite supports the following PartitionLossPolicies:
> READ_ONLY_SAFE - all writes to a cache/table will fail with an exception.
> Reads will only be allowed for entries belonging to survived/alive
> partitions. Reads from lost partitions will fail with an exception.
> READ_ONLY_ALL - reads are allowed from any partition including the lost ones.
> An exception is thrown in an attempt to write to any partition. The result of
> reading from a lost partition is undefined and may be different on different
> nodes in the cluster.
> READ_WRITE_SAFE - all reads and writes are allowed for entries in
> survived/alive partitions. All reads and writes of entries belonging to the
> lost partitions will fail with an exception.
> READ_WRITE_ALL - all reads and writes will proceed as if all partitions were
> in a consistent state (as if no partition loss happened). The result of
> reading from a lost partition is undefined and may be different on different
> nodes in the cluster.
> IGNORE - this mode never marks a lost partition as lost, pretending that no
> partition loss has happened and clearing the partition loss state right away.
> Technically, the partition will not be added to the collection of
> lostPartitions which is the main difference from READ_WRITE_ALL mode. IGNORE
> mode is used by default.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9758) Document data injection via the REST API
[
https://issues.apache.org/jira/browse/IGNITE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9758:
--
Fix Version/s: (was: 2.9)
2.10
> Document data injection via the REST API
>
>
> Key: IGNITE-9758
> URL: https://issues.apache.org/jira/browse/IGNITE-9758
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.6
>Reporter: Pavel Petroshenko
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.10
>
>
> There should a documentation on how to post data via the REST API.
>
> Just to capture what was proposed by [~ilyak] over email:
>
> {quote}REST API will convert complex BinaryObjects into JSON by default. But
> to put such objects via REST you will need to define your own
> ConnectorMessageInterceptor and plug it in. You will need to define string to
> entity mapping in onReceive. You can leave onSend returning arg.
>
> This interface should be used:
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/ConnectorMessageInterceptor.html].
> You need to put it into ConnectorConfiguration, which you should put into
> IgniteConfiguration.{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10741) MVCC: Document disabled page evictions for in-memory MVCC caches.
[
https://issues.apache.org/jira/browse/IGNITE-10741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10741:
---
Fix Version/s: (was: 2.9)
2.10
> MVCC: Document disabled page evictions for in-memory MVCC caches.
> -
>
> Key: IGNITE-10741
> URL: https://issues.apache.org/jira/browse/IGNITE-10741
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Roman Kondakov
>Priority: Major
> Fix For: 2.10
>
>
> Currently data pages evictions are disabled for {{TRANSACTIONAL_SNAPSHOT}}
> caches because it can cause violations for repeatable read guarantees.
> User should either disable evictions or enable persistence in such cases.
> We should reflect it in our documentation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12575) Document @IgniteExperimental annotation
[ https://issues.apache.org/jira/browse/IGNITE-12575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12575: --- Fix Version/s: (was: 2.9) 2.10 > Document @IgniteExperimental annotation > --- > > Key: IGNITE-12575 > URL: https://issues.apache.org/jira/browse/IGNITE-12575 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.8 >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.10 > > > We introduced the annotation to mark APIs which are exposed to users to try > out new features, but the APIs are likely to evolve in the future. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11064) Add documentation for enabling cache statistics only on appropriate nodes.
[ https://issues.apache.org/jira/browse/IGNITE-11064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11064: --- Fix Version/s: (was: 2.9) 2.10 > Add documentation for enabling cache statistics only on appropriate nodes. > -- > > Key: IGNITE-11064 > URL: https://issues.apache.org/jira/browse/IGNITE-11064 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7 >Reporter: Stanilovsky Evgeny >Priority: Major > Fix For: 2.10 > > > System property: IGNITE_DISCOVERY_DISABLE_CACHE_METRICS_UPDATE (false > default) will disable statistic collecting even if statisticsEnabled flag is > true. > [IGNITE-10172|https://issues.apache.org/jira/browse/IGNITE-10172] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11747) Document --tx control script commands
[
https://issues.apache.org/jira/browse/IGNITE-11747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11747:
---
Fix Version/s: (was: 2.9)
2.10
> Document --tx control script commands
> -
>
> Key: IGNITE-11747
> URL: https://issues.apache.org/jira/browse/IGNITE-11747
> Project: Ignite
> Issue Type: Task
> Components: control.sh, documentation
>Reporter: Ivan Rakov
>Priority: Critical
> Fix For: 2.10
>
>
> Along with consistency check utilities, ./control.sh script has --tx command
> which allows to display info about active transactions and even kill hanging
> transactions directly.
> ./control.sh provides just brief description of options:
> {code:java}
> List or kill transactions:
> control.sh --tx [--xid XID] [--min-duration SECONDS] [--min-size SIZE]
> [--label PATTERN_REGEX] [--servers|--clients] [--nodes
> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
> DURATION|SIZE|START_TIME] [--kill] [--info] [--yes]
> {code}
> We should document possible use cases and options of the command, possibly
> somewhere close to [https://apacheignite-tools.readme.io/docs/control-script]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10979) Add documentation for control.sh idle_verify --check-crc
[ https://issues.apache.org/jira/browse/IGNITE-10979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10979: --- Fix Version/s: (was: 2.9) 2.10 > Add documentation for control.sh idle_verify --check-crc > > > Key: IGNITE-10979 > URL: https://issues.apache.org/jira/browse/IGNITE-10979 > Project: Ignite > Issue Type: New Feature > Components: control.sh, documentation >Reporter: Sergey Antonov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > > We should document new option --check-crc in control.sh idle_verify command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11020) Document edge-chasing deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-11020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11020: --- Fix Version/s: (was: 2.9) 2.10 > Document edge-chasing deadlock detection > > > Key: IGNITE-11020 > URL: https://issues.apache.org/jira/browse/IGNITE-11020 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Ivan Pavlukhin >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.10 > > > Documentation for deadlock detection implemented in related ticket is needed. > Initially detection was implemented for MVCC caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13499) Reconnected node sends old id as security subject id
[ https://issues.apache.org/jira/browse/IGNITE-13499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13499: --- Fix Version/s: (was: 2.9) 2.10 > Reconnected node sends old id as security subject id > > > Key: IGNITE-13499 > URL: https://issues.apache.org/jira/browse/IGNITE-13499 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 2.8.1 >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > After reconnection a client node send old security subject id. We must > invalidate inner structures. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13515) Performance drop when there are many thin clients per server
[
https://issues.apache.org/jira/browse/IGNITE-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13515:
---
Fix Version/s: (was: 2.9)
2.10
> Performance drop when there are many thin clients per server
>
>
> Key: IGNITE-13515
> URL: https://issues.apache.org/jira/browse/IGNITE-13515
> Project: Ignite
> Issue Type: Task
> Components: clients
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.10
>
>
> There is a performance drop when running many thin clients per node:
> {noformat}
> 4 nodes - 1 thin client java - ~5500 pps (put per second)
> 4 nodes - 2 thin clients java - ~5000 pps
> 4 nodes - 4 thin clients java - ~4000 pps
> 4 nodes - 10 thin clients java - ~1500 pps
> 4 nodes - ~100 thin clients java - ~100 pps
> {noformat}
> May be related to sync request processing in connection thread pool on server
> side. Need to investigate and fix if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13037) .NET: Thin Client Near Cache
[ https://issues.apache.org/jira/browse/IGNITE-13037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206301#comment-17206301 ] Pavel Tupitsyn commented on IGNITE-13037: - [~marty.jo...@newportgroup.com] Thank you for the reply. We'll consider this ticket for Ignite 2.10. Note that: * Near cache is available in Ignite thick client: https://apacheignite-net.readme.io/docs/near-caches * Further improvement is Platform Cache, which is coming soon in Ignite 2.9 (you can try a pre-release NuGet package right now): https://ignite.apache.org/docs/latest/platform-cache > .NET: Thin Client Near Cache > > > Key: IGNITE-13037 > URL: https://issues.apache.org/jira/browse/IGNITE-13037 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > > Add near caching for thin clients: > * Clients can subscribe to change notifications for specific keys > * Clients use partition awareness to route subscriptions to primary nodes > * Use existing Thick .NET Client near caching mechanism to handle updates on > the server side > * Eviction policy is to be handled by the client code (because multiple > servers are involved) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13515) Performance drop when there are many thin clients per server
[
https://issues.apache.org/jira/browse/IGNITE-13515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-13515:
--
Fix Version/s: 2.9
> Performance drop when there are many thin clients per server
>
>
> Key: IGNITE-13515
> URL: https://issues.apache.org/jira/browse/IGNITE-13515
> Project: Ignite
> Issue Type: Task
> Components: clients
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.9
>
>
> There is a performance drop when running many thin clients per node:
> {noformat}
> 4 nodes - 1 thin client java - ~5500 pps (put per second)
> 4 nodes - 2 thin clients java - ~5000 pps
> 4 nodes - 4 thin clients java - ~4000 pps
> 4 nodes - 10 thin clients java - ~1500 pps
> 4 nodes - ~100 thin clients java - ~100 pps
> {noformat}
> May be related to sync request processing in connection thread pool on server
> side. Need to investigate and fix if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13515) Performance drop when there are many thin clients per server
Igor Seliverstov created IGNITE-13515:
-
Summary: Performance drop when there are many thin clients per
server
Key: IGNITE-13515
URL: https://issues.apache.org/jira/browse/IGNITE-13515
Project: Ignite
Issue Type: Task
Components: clients
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov
There is a performance drop when running many thin clients per node:
{noformat}
4 nodes - 1 thin client java - ~5500 pps (put per second)
4 nodes - 2 thin clients java - ~5000 pps
4 nodes - 4 thin clients java - ~4000 pps
4 nodes - 10 thin clients java - ~1500 pps
4 nodes - ~100 thin clients java - ~100 pps
{noformat}
May be related to sync request processing in connection thread pool on server
side. Need to investigate and fix if possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13431) NPE during Cassandra Store initialization with PRIMITIVE strategy
[
https://issues.apache.org/jira/browse/IGNITE-13431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206243#comment-17206243
]
Ilya Kasnacheev commented on IGNITE-13431:
--
[~amashenkov]I have commented it.
> NPE during Cassandra Store initialization with PRIMITIVE strategy
> -
>
> Key: IGNITE-13431
> URL: https://issues.apache.org/jira/browse/IGNITE-13431
> Project: Ignite
> Issue Type: Bug
> Components: integrations
>Affects Versions: 2.8.1
>Reporter: Igor Belyakov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: IgnitePersistentStoreTest.java
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When trying to create a simple cache with Cassandra store and have value
> persistence strategy PRIMITIVE, the following exception occurs:
> {code:java}
> 17:29:20,059 ERROR [main] - Exception during start processors, node will be
> stopped and close connections17:29:20,059 ERROR [main] - Exception during
> start processors, node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter [] at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1981)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2045)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> org.apache.ignite.tests.IgnitePersistentStoreTest.directPersistenceConfigTest(IgnitePersistentStoreTest.java:807)
> 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:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:160) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to validate cache
> configuration. Cache store factory is not serializable. Cache name: cache1 at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4906)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:4937)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.addCacheFromConfiguration(GridLocalConfigManager.java:269)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:167)
> at
>
[jira] [Commented] (IGNITE-9215) Uncomment 23 test classes in various core suites (see inside)
[
https://issues.apache.org/jira/browse/IGNITE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206242#comment-17206242
]
Ilya Kasnacheev commented on IGNITE-9215:
-
Unfortunately I I have only noticed your comment after I have pushed the
change. If you mind, I can revert and push in 2 commits. WDYT [~amashenkov]?
> Uncomment 23 test classes in various core suites (see inside)
> -
>
> Key: IGNITE-9215
> URL: https://issues.apache.org/jira/browse/IGNITE-9215
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As per following test suites:
> {code}
> 3
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteComputeGridTestSuite.java
> 3
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteIgfsTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteP2PSelfTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgnitePdsTestSuite2.java
> 7
> modules/core/src/test/java/org/apache/ignite/testsuites/IgnitePdsTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteReproducingSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteSpiCheckpointSelfTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteSpiCommunicationSelfTestSuite.java
> 4
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteSpiDiscoverySelfTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/TxDeadlockDetectionTestSuite.java
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13470) .NET: Add async counterparts to all applicable thin client APIs
[ https://issues.apache.org/jira/browse/IGNITE-13470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Stronchinskiy updated IGNITE-13470: -- Component/s: thin client > .NET: Add async counterparts to all applicable thin client APIs > --- > > Key: IGNITE-13470 > URL: https://issues.apache.org/jira/browse/IGNITE-13470 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > > Add async counterparts to the following .NET Thin Client APIs > * ICacheClient.GetConfiguration > * IClientCluster - all methods > * IClientClusterGroup.GetNodes, GetNode > * IIgniteClient - CreateCache, GetOrCreateCache, DestroyCache -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13336) .NET: Misleading LINQ exception when expression can't be translated
[
https://issues.apache.org/jira/browse/IGNITE-13336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Stronchinskiy reassigned IGNITE-13336:
-
Assignee: Sergey Stronchinskiy (was: Pavel Tupitsyn)
> .NET: Misleading LINQ exception when expression can't be translated
> ---
>
> Key: IGNITE-13336
> URL: https://issues.apache.org/jira/browse/IGNITE-13336
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8.1
>Reporter: Pavel Tupitsyn
>Assignee: Sergey Stronchinskiy
>Priority: Minor
> Labels: .NET
> Fix For: 2.10
>
>
> The following program results in a cryptic exception, when the problem is
> simply lack of Expression<> wrapper around the query filter:
> {code}
> class Program
> {
> private static readonly IIgnite Ignite = Ignition.Start();
> static void Main(string[] args)
> {
> var cache = GetCache();
> cache["1"] = new Foo();
> var res = Where2(e => e.Value.X == 0);
> Console.WriteLine(res);
> }
> public static ICache GetCache()
> {
> var cacheName = typeof(T).Name;
> var cfg = new CacheConfiguration(cacheName, new
> QueryEntity(typeof(T)));
> return Ignite.GetOrCreateCache(cfg);
> }
> public static List Where2(Expression T>, bool>> query)
> {
> var queryResult = GetCache().AsCacheQueryable().Where(query);
> return queryResult.Select(x => x.Value).ToList();
> }
> }
> public class Foo
> {
> [QuerySqlField] public int X { get; set; }
> }
> {code}
> We should throw a better exception that says "LINQ expression can't be
> translated to SQL because of ..."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13384) Auto-generated README.txt contains invalid workingDirectory property name
[
https://issues.apache.org/jira/browse/IGNITE-13384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-13384:
-
Fix Version/s: 2.10
> Auto-generated README.txt contains invalid workingDirectory property name
> -
>
> Key: IGNITE-13384
> URL: https://issues.apache.org/jira/browse/IGNITE-13384
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Alexey Kukushkin
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running ignite when the ignite's work directory is missing creates the work
> directory and generates a README.txt inside. [Currently the README wrongly
> says|https://github.com/apache/ignite/blob/864220966caa4157c4fee8a1bc85171623963604/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L9425]:
>
> {{"You can change the location of working directory with \n" +}}
> {{ "
> igniteConfiguration.{color:#de350b}*setWorkingDirectory*{color}(location) or
> \n" +}}
> {{ " value=\"location\"/> in IgniteConfiguration .\n");}}
>
> The "workingDirectory" should be changed to "workDirectory":
>
> {{"You can change the location of working directory with \n" +}}
> {{ " igniteConfiguration.{color:#00875a}*setWorkDirectory*{color}(location)
> or \n" +}}
> {{ " value=\"location\"/> in IgniteConfiguration .\n");}}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13384) Auto-generated README.txt contains invalid workingDirectory property name
[
https://issues.apache.org/jira/browse/IGNITE-13384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206235#comment-17206235
]
Ilya Kasnacheev commented on IGNITE-13384:
--
Thank you for review [~amashenkov]
> Auto-generated README.txt contains invalid workingDirectory property name
> -
>
> Key: IGNITE-13384
> URL: https://issues.apache.org/jira/browse/IGNITE-13384
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Alexey Kukushkin
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Running ignite when the ignite's work directory is missing creates the work
> directory and generates a README.txt inside. [Currently the README wrongly
> says|https://github.com/apache/ignite/blob/864220966caa4157c4fee8a1bc85171623963604/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L9425]:
>
> {{"You can change the location of working directory with \n" +}}
> {{ "
> igniteConfiguration.{color:#de350b}*setWorkingDirectory*{color}(location) or
> \n" +}}
> {{ " value=\"location\"/> in IgniteConfiguration .\n");}}
>
> The "workingDirectory" should be changed to "workDirectory":
>
> {{"You can change the location of working directory with \n" +}}
> {{ " igniteConfiguration.{color:#00875a}*setWorkDirectory*{color}(location)
> or \n" +}}
> {{ " value=\"location\"/> in IgniteConfiguration .\n");}}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
[
https://issues.apache.org/jira/browse/IGNITE-13514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206221#comment-17206221
]
Aleksey Plekhanov commented on IGNITE-13514:
[~ilyak], can you please have a look?
> Apache Ignite Slim edition builds without config/default-config.xml
> ---
>
> Key: IGNITE-13514
> URL: https://issues.apache.org/jira/browse/IGNITE-13514
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
> {{config/default-config.xml}} is absent.
> Root cause: config file is edition dependent, see assembly/release-base.xml:
> {noformat}
>
> config/${ignite.edition}
> /config
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
[
https://issues.apache.org/jira/browse/IGNITE-13514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13514:
---
Fix Version/s: 2.9
> Apache Ignite Slim edition builds without config/default-config.xml
> ---
>
> Key: IGNITE-13514
> URL: https://issues.apache.org/jira/browse/IGNITE-13514
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Fix For: 2.9
>
>
> In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
> {{config/default-config.xml}} is absent.
> Root cause: config file is edition dependent, see assembly/release-base.xml:
> {noformat}
>
> config/${ignite.edition}
> /config
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
[
https://issues.apache.org/jira/browse/IGNITE-13514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13514:
---
Affects Version/s: 2.9
> Apache Ignite Slim edition builds without config/default-config.xml
> ---
>
> Key: IGNITE-13514
> URL: https://issues.apache.org/jira/browse/IGNITE-13514
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
>
> In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
> {{config/default-config.xml}} is absent.
> Root cause: config file is edition dependent, see assembly/release-base.xml:
> {noformat}
>
> config/${ignite.edition}
> /config
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
[
https://issues.apache.org/jira/browse/IGNITE-13514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13514:
---
Priority: Blocker (was: Major)
> Apache Ignite Slim edition builds without config/default-config.xml
> ---
>
> Key: IGNITE-13514
> URL: https://issues.apache.org/jira/browse/IGNITE-13514
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
>
> In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
> {{config/default-config.xml}} is absent.
> Root cause: config file is edition dependent, see assembly/release-base.xml:
> {noformat}
>
> config/${ignite.edition}
> /config
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
[
https://issues.apache.org/jira/browse/IGNITE-13514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13514:
---
Description:
In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
{{config/default-config.xml}} is absent.
Root cause: config file is edition dependent, see assembly/release-base.xml:
{noformat}
config/${ignite.edition}
/config
{noformat}
was:In Apache Ignite Slim Edition ignite.sh doesn't work from the box since
file {{config/default-config.xml}} is absent.
> Apache Ignite Slim edition builds without config/default-config.xml
> ---
>
> Key: IGNITE-13514
> URL: https://issues.apache.org/jira/browse/IGNITE-13514
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
> {{config/default-config.xml}} is absent.
> Root cause: config file is edition dependent, see assembly/release-base.xml:
> {noformat}
>
> config/${ignite.edition}
> /config
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13514) Apache Ignite Slim edition builds without config/default-config.xml
Aleksey Plekhanov created IGNITE-13514:
--
Summary: Apache Ignite Slim edition builds without
config/default-config.xml
Key: IGNITE-13514
URL: https://issues.apache.org/jira/browse/IGNITE-13514
Project: Ignite
Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
In Apache Ignite Slim Edition ignite.sh doesn't work from the box since file
{{config/default-config.xml}} is absent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13513) Remove WALPointer and use FileWALPointer
[ https://issues.apache.org/jira/browse/IGNITE-13513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206196#comment-17206196 ] Nikolay Izhikov commented on IGNITE-13513: -- Hello, [~ktkale...@gridgain.com] Can you, please, take a look at my changes? > Remove WALPointer and use FileWALPointer > > > Key: IGNITE-13513 > URL: https://issues.apache.org/jira/browse/IGNITE-13513 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > WALPointer interface has a single implementation FileWALPointer. > And WALPointer is cast to the FileWALPointer everywhere through code. > We should get rid of the WALPointer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-7798) Give user an ability to check driver metrics in Cassandra store
[
https://issues.apache.org/jira/browse/IGNITE-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Pligin reassigned IGNITE-7798:
---
Assignee: Vladimir Pligin
> Give user an ability to check driver metrics in Cassandra store
> ---
>
> Key: IGNITE-7798
> URL: https://issues.apache.org/jira/browse/IGNITE-7798
> Project: Ignite
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Pligin
>Priority: Major
> Fix For: 2.10
>
>
> Cassandra store uses generic client driver to connect to the cluster. The
> driver provides {{Metrics}} object which can be useful for monitoring,
> however there is no way for user to acquire it. Need to find a way to expose
> this information to public API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13479) Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start if JMX port was set
[ https://issues.apache.org/jira/browse/IGNITE-13479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206135#comment-17206135 ] Sergey Chugunov commented on IGNITE-13479: -- [~sdanilov], I reviewed your change, it looks fine and I don't expect it to bring new issues. Merged it to master branch in commit *ee645bda324771d4e24fb9670fad4d7f51fc6c34*. > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start > if JMX port was set > - > > Key: IGNITE-13479 > URL: https://issues.apache.org/jira/browse/IGNITE-13479 > Project: Ignite > Issue Type: Bug > Components: control.sh >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is no other way to set parameters for docker images, so, when you set > JMX port to JVM_OPTS, you can't start control.sh: > > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 49112; nested exception is: > java.net.BindException: Address in use (Bind failed) > sun.management.AgentConfigurationError: java.rmi.server.ExportException: Port > already in use: 49112; nested exception is: > java.net.BindException: Address in use (Bind failed) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13479) Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start if JMX port was set
[ https://issues.apache.org/jira/browse/IGNITE-13479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13479: - Reviewer: Sergey Chugunov > Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start > if JMX port was set > - > > Key: IGNITE-13479 > URL: https://issues.apache.org/jira/browse/IGNITE-13479 > Project: Ignite > Issue Type: Bug > Components: control.sh >Affects Versions: 2.8.1 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There is no other way to set parameters for docker images, so, when you set > JMX port to JVM_OPTS, you can't start control.sh: > > Error: Exception thrown by the agent : java.rmi.server.ExportException: Port > already in use: 49112; nested exception is: > java.net.BindException: Address in use (Bind failed) > sun.management.AgentConfigurationError: java.rmi.server.ExportException: Port > already in use: 49112; nested exception is: > java.net.BindException: Address in use (Bind failed) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13513) Remove WALPointer and use FileWALPointer
Nikolay Izhikov created IGNITE-13513: Summary: Remove WALPointer and use FileWALPointer Key: IGNITE-13513 URL: https://issues.apache.org/jira/browse/IGNITE-13513 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov WALPointer interface has a single implementation FileWALPointer. And WALPointer is cast to the FileWALPointer everywhere through code. We should get rid of the WALPointer. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13512) Provide a check that all test are part of any TestSuite. Alert otherwise
Maksim Timonin created IGNITE-13512: --- Summary: Provide a check that all test are part of any TestSuite. Alert otherwise Key: IGNITE-13512 URL: https://issues.apache.org/jira/browse/IGNITE-13512 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin Assignee: Maksim Timonin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13431) NPE during Cassandra Store initialization with PRIMITIVE strategy
[
https://issues.apache.org/jira/browse/IGNITE-13431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206108#comment-17206108
]
Andrey Mashenkov commented on IGNITE-13431:
---
[~ilyak], I've left a question in the PR.
> NPE during Cassandra Store initialization with PRIMITIVE strategy
> -
>
> Key: IGNITE-13431
> URL: https://issues.apache.org/jira/browse/IGNITE-13431
> Project: Ignite
> Issue Type: Bug
> Components: integrations
>Affects Versions: 2.8.1
>Reporter: Igor Belyakov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: IgnitePersistentStoreTest.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When trying to create a simple cache with Cassandra store and have value
> persistence strategy PRIMITIVE, the following exception occurs:
> {code:java}
> 17:29:20,059 ERROR [main] - Exception during start processors, node will be
> stopped and close connections17:29:20,059 ERROR [main] - Exception during
> start processors, node will be stopped and close connectionsclass
> org.apache.ignite.IgniteCheckedException: Failed to start processor:
> GridProcessorAdapter [] at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1981)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211) at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2045)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1703)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:637) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:563) at
> org.apache.ignite.Ignition.start(Ignition.java:321) at
> org.apache.ignite.tests.IgnitePersistentStoreTest.directPersistenceConfigTest(IgnitePersistentStoreTest.java:807)
> 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:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:160) at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)Caused
> by: class org.apache.ignite.IgniteCheckedException: Failed to validate cache
> configuration. Cache store factory is not serializable. Cache name: cache1 at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4906)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$8.applyx(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.withBinaryContext(GridCacheProcessor.java:4937)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cloneCheckSerializable(GridCacheProcessor.java:4892)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.addCacheFromConfiguration(GridLocalConfigManager.java:269)
> at
> org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:167)
> at
>
[jira] [Commented] (IGNITE-13467) Add events for snapshot operation state
[ https://issues.apache.org/jira/browse/IGNITE-13467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206098#comment-17206098 ] Amelchev Nikita commented on IGNITE-13467: -- [~mmuzaf], Looks good to me. > Add events for snapshot operation state > --- > > Key: IGNITE-13467 > URL: https://issues.apache.org/jira/browse/IGNITE-13467 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > The snapshot operation states must be exposed to the user by firing Ignite > events: > - snapshot operation started > - snapshot operation finished > - snapshot operation failed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9215) Uncomment 23 test classes in various core suites (see inside)
[
https://issues.apache.org/jira/browse/IGNITE-9215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206106#comment-17206106
]
Andrey Mashenkov commented on IGNITE-9215:
--
[~ilyak], PR looks good, can be merged.
Changes in SharedFsCheckpointSpi is a bug-fix, however other changes related to
tests themselves.
Would you mind to fix the bug within separate commit/ticket?
> Uncomment 23 test classes in various core suites (see inside)
> -
>
> Key: IGNITE-9215
> URL: https://issues.apache.org/jira/browse/IGNITE-9215
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As per following test suites:
> {code}
> 3
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteComputeGridTestSuite.java
> 3
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteIgfsTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteP2PSelfTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgnitePdsTestSuite2.java
> 7
> modules/core/src/test/java/org/apache/ignite/testsuites/IgnitePdsTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteReproducingSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteSpiCheckpointSelfTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteSpiCommunicationSelfTestSuite.java
> 4
> modules/core/src/test/java/org/apache/ignite/testsuites/IgniteSpiDiscoverySelfTestSuite.java
> 1
> modules/core/src/test/java/org/apache/ignite/testsuites/TxDeadlockDetectionTestSuite.java
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13510) Getting status of snapshot execution via command line and jmx
[ https://issues.apache.org/jira/browse/IGNITE-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-13510: --- Description: the control.sh utility immediately relinquishes control and without using metricExporter it is impossible to understand whether the snapshot completed or not was:the control.sh utility immediately gives up control and it is impossible to understand whether the snapshot has been completed or not > Getting status of snapshot execution via command line and jmx > - > > Key: IGNITE-13510 > URL: https://issues.apache.org/jira/browse/IGNITE-13510 > Project: Ignite > Issue Type: Task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Major > Labels: iep-43, snapshot > > the control.sh utility immediately relinquishes control > and without using metricExporter it is impossible to understand whether the > snapshot completed or not -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13476) Calcite improvements. Implement ProjectionNode.
[ https://issues.apache.org/jira/browse/IGNITE-13476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206094#comment-17206094 ] Stanilovsky Evgeny commented on IGNITE-13476: - [~gvvinblade] seems all ok now, append tests, checkstyle locally passed. Can u review it ? > Calcite improvements. Implement ProjectionNode. > --- > > Key: IGNITE-13476 > URL: https://issues.apache.org/jira/browse/IGNITE-13476 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.8.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently we have no functionality for filtering only useful columns in inner > representations. For further heap allocations reduction and as a consequence: > gc pressure, we need to implement such approach. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12451) Introduce deadlock detection for cache entry reentrant locks
[
https://issues.apache.org/jira/browse/IGNITE-12451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206092#comment-17206092
]
Aleksey Plekhanov commented on IGNITE-12451:
[~maliev], we've benchmarked by yardstick on the following configuration:
in-memory cluster, 6 servers, 3 clients (drivers), using IgnitePutAllBenchmark,
cache with 1 backup, batch size 2 and 1:
{noformat}
CONFIGS="\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -cwd -cl -nn ${nodesNum}
-b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -wm ${wm} -bs 2 -dn
IgnitePutAllBenchmark -sn IgniteNode -ds ${ver}-atomic-putAll-bs2_iter1,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -cwd -cl -nn ${nodesNum}
-b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -wm ${wm} -bs 2 -dn
IgnitePutAllBenchmark -sn IgniteNode -ds ${ver}-atomic-putAll-bs2_iter2,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -cwd -cl -nn ${nodesNum}
-b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -wm ${wm} -bs 2 -dn
IgnitePutAllBenchmark -sn IgniteNode -ds ${ver}-atomic-putAll-bs2_iter3,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -cwd -cl -nn ${nodesNum}
-b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -wm ${wm} -bs 1 -dn
IgnitePutAllBenchmark -sn IgniteNode -ds ${ver}-atomic-putAll-bs1_iter1,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -cwd -cl -nn ${nodesNum}
-b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -wm ${wm} -bs 1 -dn
IgnitePutAllBenchmark -sn IgniteNode -ds ${ver}-atomic-putAll-bs1_iter2,\
-cfg ${SCRIPT_DIR}/../config/ignite-remote-config.xml -cwd -cl -nn ${nodesNum}
-b ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -wm ${wm} -bs 1 -dn
IgnitePutAllBenchmark -sn IgniteNode -ds ${ver}-atomic-putAll-bs1_iter3\
"
{noformat}
Results:
||Iteration||Before, -bs2||Before, -bs1||After, -bs2||After, -bs1||
|1| 307433 | 135,91 | 307558 | 135,95 |
|2|308135|135,64|305367|127,89|
|3|303215|134,07|309356|135,96|
|avg|306261|135,21|307427|133,27|
Average comparison:
|| ||Before||After||Compare||
|IgnitePutAllBenchmark -bs2|306261|307427|0,38%|
|IgnitePutAllBenchmark -bs1|135,2|133,2|-1,50%|
> Introduce deadlock detection for cache entry reentrant locks
>
>
> Key: IGNITE-12451
> URL: https://issues.apache.org/jira/browse/IGNITE-12451
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.7.6
>Reporter: Ivan Rakov
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Aside from IGNITE-12365, we still have possible threat of cache-entry-level
> deadlock in case of careless usage of JCache mass operations (putAll,
> removeAll):
> 1. If two different user threads will perform putAll on the same two keys in
> reverse order (primary node for which is the same), there's a chance that
> sys-stripe threads will be deadlocked.
> 2. Even without direct contract violation from user side, HashMap can be
> passed as argument for putAll. Even if user threads have called mass
> operations with two keys in the same order, HashMap iteration order is not
> strictly defined, which may cause the same deadlock.
> Local deadlock detection should mitigate this issue. We can create a wrapper
> for ReentrantLock with logic that performs cycle detection in wait-for graph
> in case we are waiting for lock acquisition for too long. Exception will be
> thrown from one of the threads in such case, failing user operation, but
> letting the system make progress.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13511) Unified configuration
Anton Kalashnikov created IGNITE-13511: -- Summary: Unified configuration Key: IGNITE-13511 URL: https://issues.apache.org/jira/browse/IGNITE-13511 Project: Ignite Issue Type: New Feature Reporter: Anton Kalashnikov https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13510) Getting status of snapshot execution via command line and jmx
[ https://issues.apache.org/jira/browse/IGNITE-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-13510: --- Labels: iep-43 snapshot (was: ) > Getting status of snapshot execution via command line and jmx > - > > Key: IGNITE-13510 > URL: https://issues.apache.org/jira/browse/IGNITE-13510 > Project: Ignite > Issue Type: Task >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Major > Labels: iep-43, snapshot > > the control.sh utility immediately gives up control and it is impossible to > understand whether the snapshot has been completed or not -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13510) Getting status of snapshot execution via command line and jmx
Sergei Ryzhov created IGNITE-13510: -- Summary: Getting status of snapshot execution via command line and jmx Key: IGNITE-13510 URL: https://issues.apache.org/jira/browse/IGNITE-13510 Project: Ignite Issue Type: Task Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov the control.sh utility immediately gives up control and it is impossible to understand whether the snapshot has been completed or not -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13508) Test scenario of two-phased rebalance (PDS reduce)
[
https://issues.apache.org/jira/browse/IGNITE-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergei Ryzhov reassigned IGNITE-13508:
--
Assignee: Sergei Ryzhov
> Test scenario of two-phased rebalance (PDS reduce)
> --
>
> Key: IGNITE-13508
> URL: https://issues.apache.org/jira/browse/IGNITE-13508
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Daschinskiy
>Assignee: Sergei Ryzhov
>Priority: Major
> Labels: IEP-56, ducktape
>
> Let us assume a cluster of 16 affinity nodes.
> Lets divide cluster in 4 equal cells:
> Each node in cell has the same node attribute {{CELL=CELL_}}
> Caches, that will be started on nodes, should have affinity function with
> this backup filter:
> {code:java}
> public class CellularAffinityBackupFilter implements
> IgniteBiPredicate> {
> private static final long serialVersionUID = 1L;
> private final String attrName;
> public CellularAffinityBackupFilter(String attrName) {
> this.attrName = attrName;
> }
> @Override public boolean apply(ClusterNode candidate, List
> previouslySelected) {
> for (ClusterNode node : previouslySelected)
> return Objects.equals(candidate.attribute(attrName),
> node.attribute(attrName));
> return true;
> }
> }
> {code}
> Also, caches should be partitioned and have 3 backups.
> Steps:
> * Preparations.
> 1. Start all 4 cells.
> 2. Load data to cache with the mentioned above affinity function and fix PDS
> size on all nodes.
> 3. Delete 80% of data and fix PDS size on all nodes.
> * Phase 1
> 1. Stop two nodes in each cell, total a half of all nodes and clean PDS.
> 2. Start cleaned node with preservance of consistent id and cell attributes.
> 3. Wait for rebalance finished.
> * Phase 2
> Run steps 1-3 of Phase 2 on the other half of the cluster.
> * Verifications
> 1. Check that PDS size reduced (compare to step 3)
> 2. Check data consistency (idle_verify --dump)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13509) Support encrypted caches in ducktape tests
Pavel Pereslegin created IGNITE-13509: - Summary: Support encrypted caches in ducktape tests Key: IGNITE-13509 URL: https://issues.apache.org/jira/browse/IGNITE-13509 Project: Ignite Issue Type: Task Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin Add support for encrypted caches in ignite ducktape tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13508) Test scenario of two-phased rebalance (PDS reduce)
[
https://issues.apache.org/jira/browse/IGNITE-13508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13508:
--
Description:
Let us assume a cluster of 16 affinity nodes.
Lets divide cluster in 4 equal cells:
Each node in cell has the same node attribute {{CELL=CELL_}}
Caches, that will be started on nodes, should have affinity function with this
backup filter:
{code:java}
public class CellularAffinityBackupFilter implements
IgniteBiPredicate> {
private static final long serialVersionUID = 1L;
private final String attrName;
public CellularAffinityBackupFilter(String attrName) {
this.attrName = attrName;
}
@Override public boolean apply(ClusterNode candidate, List
previouslySelected) {
for (ClusterNode node : previouslySelected)
return Objects.equals(candidate.attribute(attrName),
node.attribute(attrName));
return true;
}
}
{code}
Also, caches should be partitioned and have 3 backups.
Steps:
* Preparations.
1. Start all 4 cells.
2. Load data to cache with the mentioned above affinity function and fix PDS
size on all nodes.
3. Delete 80% of data and fix PDS size on all nodes.
* Phase 1
1. Stop two nodes in each cell, total a half of all nodes and clean PDS.
2. Start cleaned node with preservance of consistent id and cell attributes.
3. Wait for rebalance finished.
* Phase 2
Run steps 1-3 of Phase 2 on the other half of the cluster.
* Verifications
1. Check that PDS size reduced (compare to step 3)
2. Check data consistency (idle_verify --dump)
was:
Let us assume a cluster of 16 affinity nodes.
Lets divide cluster in 4 equal cells:
Each node in cell has the same node attribute {{CELL=CELL_}}
Caches, that will be started on nodes, should have affinity function with this
backup filter:
{code:java}
public class CellularAffinityBackupFilter implements
IgniteBiPredicate> {
private static final long serialVersionUID = 1L;
private final String attrName;
public CellularAffinityBackupFilter(String attrName) {
this.attrName = attrName;
}
@Override public boolean apply(ClusterNode candidate, List
previouslySelected) {
for (ClusterNode node : previouslySelected)
return Objects.equals(candidate.attribute(attrName),
node.attribute(attrName));
return true;
}
}
{code}
Steps:
* Preparations.
1. Start all 4 cells.
2. Load data to cache with the mentioned above affinity function and fix PDS
size on all nodes.
3. Delete 80% of data and fix PDS size on all nodes.
* Phase 1
1. Stop two nodes in each cell, total a half of all nodes and clean PDS.
2. Start cleaned node with preservance of consistent id and cell attributes.
3. Wait for rebalance finished.
* Phase 2
Run steps 1-3 of Phase 2 on the other half of the cluster.
* Verifications
1. Check that PDS size reduced (compare to step 3)
2. Check data consistency (idle_verify --dump)
> Test scenario of two-phased rebalance (PDS reduce)
> --
>
> Key: IGNITE-13508
> URL: https://issues.apache.org/jira/browse/IGNITE-13508
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Daschinskiy
>Priority: Major
> Labels: IEP-56, ducktape
>
> Let us assume a cluster of 16 affinity nodes.
> Lets divide cluster in 4 equal cells:
> Each node in cell has the same node attribute {{CELL=CELL_}}
> Caches, that will be started on nodes, should have affinity function with
> this backup filter:
> {code:java}
> public class CellularAffinityBackupFilter implements
> IgniteBiPredicate> {
> private static final long serialVersionUID = 1L;
> private final String attrName;
> public CellularAffinityBackupFilter(String attrName) {
> this.attrName = attrName;
> }
> @Override public boolean apply(ClusterNode candidate, List
> previouslySelected) {
> for (ClusterNode node : previouslySelected)
> return Objects.equals(candidate.attribute(attrName),
> node.attribute(attrName));
> return true;
> }
> }
> {code}
> Also, caches should be partitioned and have 3 backups.
> Steps:
> * Preparations.
> 1. Start all 4 cells.
> 2. Load data to cache with the mentioned above affinity function and fix PDS
> size on all nodes.
> 3. Delete 80% of data and fix PDS size on all nodes.
> * Phase 1
> 1. Stop two nodes in each cell, total a half of all nodes and clean PDS.
> 2. Start cleaned node with preservance of consistent id and cell attributes.
> 3. Wait for rebalance finished.
> * Phase 2
> Run steps 1-3 of Phase 2 on the other half of the cluster.
> * Verifications
> 1. Check that PDS size reduced (compare to step 3)
> 2. Check data consistency (idle_verify --dump)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13206: -- Description: We should emphasize that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: _failureDetectionTimeout * addressesNumber_. "You should assing multiple addresses to a node only if they represent some real physical connections which can give more reliability. Several addresses prolong failure detection of current node. The timeouts and settings on network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, maxAckTimeout, reconCnt_) work per connection/address. The exception is _connRecoveryTimeout_. Example: if you have 3 ip addresses configured for a node, Tcp Discovery takes up to '_failureDetectionTimeout * 3' to detect failure of this node_". was: Current TcpDiscoverySpi can prolong detection of node failure which has several IP addresses. This happens because most of the timeouts like failureDetectionTimeout, sockTimeout, ackTimeout work per address. Actual failure detection delay is: failureDetectionTimeout*addressesNumber. And the node addresses are sorted out consistently. This affection on failure detection should be noted in the documentation. The suggestion is to represent this behavior in https://apacheignite.readme.io/docs/tcpip-discovery. The text might be: "_You should assing multiple addresses to a node only if they represent some real physical connections which can give more reliability. Providing several addresses can prolong failure detection of current node. The timeouts and settings on network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, maxAckTimeout, reconCnt_) work per connection/address. The exception is _connRecoveryTimeout_. And node addresses are sorted out sequentially. Example: if you use _failureDetectionTimeout _and have set 3 ip addresses for this node, previous node in the ring can take up to 'failureDetectionTimeout * 3' to detect failure of current node_." > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.9 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3' to detect failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13206: - Assignee: Vladimir Steshin (was: Denis A. Magda) > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.9 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3' to detect failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13206: -- Fix Version/s: 2.9 > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Minor > Labels: iep-45 > Fix For: 2.9 > > > Current TcpDiscoverySpi can prolong detection of node failure which has > several IP addresses. This happens because most of the timeouts like > failureDetectionTimeout, sockTimeout, ackTimeout work per address. Actual > failure detection delay is: failureDetectionTimeout*addressesNumber. And the > node addresses are sorted out consistently. This affection on failure > detection should be noted in the documentation. > The suggestion is to represent this behavior in > https://apacheignite.readme.io/docs/tcpip-discovery. The text might be: > "_You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Providing several > addresses can prolong failure detection of current node. The timeouts and > settings on network operations (_failureDetectionTimeout(), sockTimeout, > ackTimeout, maxAckTimeout, reconCnt_) work per connection/address. The > exception is _connRecoveryTimeout_. And node addresses are sorted out > sequentially. > Example: if you use _failureDetectionTimeout _and have set 3 ip > addresses for this node, previous node in the ring can take up to > 'failureDetectionTimeout * 3' to detect failure of current node_." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13206: -- Priority: Major (was: Minor) > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.9 > > > Current TcpDiscoverySpi can prolong detection of node failure which has > several IP addresses. This happens because most of the timeouts like > failureDetectionTimeout, sockTimeout, ackTimeout work per address. Actual > failure detection delay is: failureDetectionTimeout*addressesNumber. And the > node addresses are sorted out consistently. This affection on failure > detection should be noted in the documentation. > The suggestion is to represent this behavior in > https://apacheignite.readme.io/docs/tcpip-discovery. The text might be: > "_You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Providing several > addresses can prolong failure detection of current node. The timeouts and > settings on network operations (_failureDetectionTimeout(), sockTimeout, > ackTimeout, maxAckTimeout, reconCnt_) work per connection/address. The > exception is _connRecoveryTimeout_. And node addresses are sorted out > sequentially. > Example: if you use _failureDetectionTimeout _and have set 3 ip > addresses for this node, previous node in the ring can take up to > 'failureDetectionTimeout * 3' to detect failure of current node_." -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13508) Test scenario of two-phased rebalance (PDS reduce)
Ivan Daschinskiy created IGNITE-13508:
-
Summary: Test scenario of two-phased rebalance (PDS reduce)
Key: IGNITE-13508
URL: https://issues.apache.org/jira/browse/IGNITE-13508
Project: Ignite
Issue Type: Test
Reporter: Ivan Daschinskiy
Let us assume a cluster of 16 affinity nodes.
Lets divide cluster in 4 equal cells:
Each node in cell has the same node attribute {{CELL=CELL_}}
Caches, that will be started on nodes, should have affinity function with this
backup filter:
{code:java}
public class CellularAffinityBackupFilter implements
IgniteBiPredicate> {
private static final long serialVersionUID = 1L;
private final String attrName;
public CellularAffinityBackupFilter(String attrName) {
this.attrName = attrName;
}
@Override public boolean apply(ClusterNode candidate, List
previouslySelected) {
for (ClusterNode node : previouslySelected)
return Objects.equals(candidate.attribute(attrName),
node.attribute(attrName));
return true;
}
}
{code}
Steps:
* Preparations.
1. Start all 4 cells.
2. Load data to cache with the mentioned above affinity function and fix PDS
size on all nodes.
3. Delete 80% of data and fix PDS size on all nodes.
* Phase 1
1. Stop two nodes in each cell, total a half of all nodes and clean PDS.
2. Start cleaned node with preservance of consistent id and cell attributes.
3. Wait for rebalance finished.
* Phase 2
Run steps 1-3 of Phase 2 on the other half of the cluster.
* Verifications
1. Check that PDS size reduced (compare to step 3)
2. Check data consistency (idle_verify --dump)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13501) AssertionError: Invalid value in testMergeServersFail1_8
[ https://issues.apache.org/jira/browse/IGNITE-13501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17206001#comment-17206001 ] Alexey Scherbakov commented on IGNITE-13501: [~v.pyatkov] I've left 2 minor comments. > AssertionError: Invalid value in testMergeServersFail1_8 > > > Key: IGNITE-13501 > URL: https://issues.apache.org/jira/browse/IGNITE-13501 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > java.lang.AssertionError: Invalid value > [node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c6] > expected:<1> but was: > Reproduced by [1] > [1] > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3187056670751319047=testDetails > Covered of case of one phase committed transaction with zero backups. The > reason of this issue in that a primary node fails during a near node is > sending a request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
