[jira] [Created] (IGNITE-14622) Snapshot test simplification
Anton Vinogradov created IGNITE-14622: - Summary: Snapshot test simplification Key: IGNITE-14622 URL: https://issues.apache.org/jira/browse/IGNITE-14622 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Just get rid of useless stuff %) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14618) Increase stop timeout to 60 seconds
Anton Vinogradov created IGNITE-14618: - Summary: Increase stop timeout to 60 seconds Key: IGNITE-14618 URL: https://issues.apache.org/jira/browse/IGNITE-14618 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Graceful stops may take 10+ seconds, so we should increase the timeout to have no false-negative results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14601) Specs should use service's params instead of copying.
Anton Vinogradov created IGNITE-14601: - Summary: Specs should use service's params instead of copying. Key: IGNITE-14601 URL: https://issues.apache.org/jira/browse/IGNITE-14601 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Currently a lot of params copied to spec. Need just to use {{self.service.xxx}} instead -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14503) Ability to specify project (fork) via the Version
Anton Vinogradov created IGNITE-14503: - Summary: Ability to specify project (fork) via the Version Key: IGNITE-14503 URL: https://issues.apache.org/jira/browse/IGNITE-14503 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Currently we able to define fork name via globals {{"project": "fork", "ignite_versions": "dev"}} This should be also possible to define a project by version {{ "ignite_versions": "[dev, ignite-2.8.1, fork-dev, superfork-9.999]"}} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14485) Docker execution fail on iptables change
Anton Vinogradov created IGNITE-14485: - Summary: Docker execution fail on iptables change Key: IGNITE-14485 URL: https://issues.apache.org/jira/browse/IGNITE-14485 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Vladimir Steshin Fail example: {noformat} [INFO:2021-04-06 12:21:56,650]: RunnerClient: 0425dc@ignitetest.tests.discovery_test.DiscoveryTest.test_2_nodes_fail_sequential_zk.load_type=ClusterLoad.ATOMIC.ignite_version=2.10.0: FAIL: AssertionError("Command failed: 'sudo iptables -L -n'.\nError: '# Warning: iptables-legacy tables present, use iptables-legacy to see them\n'") Traceback (most recent call last): File "/usr/local/lib/python3.7/dist-packages/ducktape/tests/runner_client.py", line 133, in run data = self.run_test() File "/usr/local/lib/python3.7/dist-packages/ducktape/tests/runner_client.py", line 190, in run_test return self.test_context.function(self.test) File "/usr/local/lib/python3.7/dist-packages/ducktape/mark/_mark.py", line 429, in wrapper return functools.partial(f, *args, **kwargs)(*w_args, **w_kwargs) File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/tests/discovery_test.py", line 173, in test_2_nodes_fail_sequential_zk return self._perform_node_fail_scenario(test_config) File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/tests/discovery_test.py", line 246, in _perform_node_fail_scenario test_config.net_part)) File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/tests/discovery_test.py", line 262, in _simulate_and_detect_failure _, first_terminated = servers.drop_network(failed_nodes, net_part=net_part) File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py", line 353, in drop_network self.__backup_iptables(nodes) File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py", line 414, in __backup_iptables self.logger.debug("Netfilter before launch on '%s': %s" % (node.name, self.__dump_netfilter_settings(node))) File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py", line 451, in __dump_netfilter_settings return IgniteAwareService.exec_command(node, "sudo iptables -L -n") File "/opt/ignite-dev/modules/ducktests/tests/ignitetest/services/utils/ignite_aware.py", line 481, in exec_command assert len(err) == 0, f"Command failed: '\{cmd}'.\nError: '\{err}'" AssertionError: Command failed: 'sudo iptables -L -n'. Error: '# Warning: iptables-legacy tables present, use iptables-legacy to see them ' {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14483) Ignite_app and ignite clean_up
Anton Vinogradov created IGNITE-14483: - Summary: Ignite_app and ignite clean_up Key: IGNITE-14483 URL: https://issues.apache.org/jira/browse/IGNITE-14483 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Clean up and simplify. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14478) Custom fork/Custom tests Documentation at README.MD
Anton Vinogradov created IGNITE-14478: - Summary: Custom fork/Custom tests Documentation at README.MD Key: IGNITE-14478 URL: https://issues.apache.org/jira/browse/IGNITE-14478 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Nikolay Izhikov We have to append a proper explanation of "Custom Ignites (forks) testing" to sections "Local run" and "# Real environment run". Currently "Custom Ignites (forks) testing" is a separate section which is not true anymore, let spread it to *run sections. P.s. Currently, we have a 4 options - Run AI tests versus AI - Run AI tests versus Fork - Run External (Fork's) tests versus AI - Run External (Fork's) tests versus Fork (this case requires no additional explanation since it obviously equals to first one). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14470) Thin client application service
Anton Vinogradov created IGNITE-14470: - Summary: Thin client application service Key: IGNITE-14470 URL: https://issues.apache.org/jira/browse/IGNITE-14470 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Allow starting thin client within the java application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14421) Get rid of useless waiting on grep
Anton Vinogradov created IGNITE-14421: - Summary: Get rid of useless waiting on grep Key: IGNITE-14421 URL: https://issues.apache.org/jira/browse/IGNITE-14421 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Currently, we wait 5 seconds after each grep miss {noformat} [DEBUG - 2021-03-25 18:08:09,577 - remoteaccount - _log - lineno:160]: ducker@ducker11: Running ssh command: jcmd | awk '/org.apache.ignite.internal.ducktest.utils.IgniteAwareApplicationService/ { print $1 }' [DEBUG - 2021-03-25 18:08:09,736 - remoteaccount - _log - lineno:160]: ducker@ducker11: Running ssh command: tail -c +1 /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_FINISHED\|IGNITE_APPLICATION_BROKEN' [DEBUG - 2021-03-25 18:08:09,783 - remoteaccount - _log - lineno:160]: ducker@ducker11: Running ssh command: tail -c +1 /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_BROKEN' [DEBUG - 2021-03-25 18:08:09,833 - remoteaccount - _log - lineno:160]: ducker@ducker11: Running ssh command 'tail -c +1 /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_BROKEN'' exited with status 1 and message: b'' [DEBUG - 2021-03-25 18:08:14,836 - remoteaccount - _log - lineno:160]: ducker@ducker11: Running ssh command: tail -c +1 /mnt/service/logs/console.log | grep 'IGNITE_APPLICATION_FINISHED' {noformat} Let's get rid of this {{backoff_sec=5}} by default. Need to make it 0 if possible, or as small as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14337) Increase default failure detection timeout to 2 seconds
Anton Vinogradov created IGNITE-14337: - Summary: Increase default failure detection timeout to 2 seconds Key: IGNITE-14337 URL: https://issues.apache.org/jira/browse/IGNITE-14337 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov This should fix nightly build failures because of VM's freezes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14333) Zookeeper uses kill -1
Anton Vinogradov created IGNITE-14333: - Summary: Zookeeper uses kill -1 Key: IGNITE-14333 URL: https://issues.apache.org/jira/browse/IGNITE-14333 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14329) Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST
Anton Vinogradov created IGNITE-14329: - Summary: Set 2.9.1 as LATEST_2.9 and 2.10 as LATEST Key: IGNITE-14329 URL: https://issues.apache.org/jira/browse/IGNITE-14329 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov This fixed nightly run failures fixed at IGNITE-13705. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14259) Ducktests pre-merge presentation
Anton Vinogradov created IGNITE-14259: - Summary: Ducktests pre-merge presentation Key: IGNITE-14259 URL: https://issues.apache.org/jira/browse/IGNITE-14259 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov A webinar-like presentation is required to discuss what we got before the merge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14258) Ducktests code de-duplication and simplification
Anton Vinogradov created IGNITE-14258: - Summary: Ducktests code de-duplication and simplification Key: IGNITE-14258 URL: https://issues.apache.org/jira/browse/IGNITE-14258 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov The goal is to perform pre-merge review of the whole ducktests code and refactor it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14242) Build ducktests with minimal required classpath
Anton Vinogradov created IGNITE-14242: - Summary: Build ducktests with minimal required classpath Key: IGNITE-14242 URL: https://issues.apache.org/jira/browse/IGNITE-14242 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov This fix will allow running changes from IGNITE-13492 at dev. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14212) New web documentation promotion
Anton Vinogradov created IGNITE-14212: - Summary: New web documentation promotion Key: IGNITE-14212 URL: https://issues.apache.org/jira/browse/IGNITE-14212 Project: Ignite Issue Type: Wish Reporter: Anton Vinogradov Assignee: Mauricio Stekl Fix For: 2.10 Since AI documentation hosting changed (from https://apacheignite.readme.io/docs to https://ignite.apache.org/docs) a lot of people faced with nonrelevant search results problems. Could we 1) Promote a new site https://ignite.apache.org/docs to have it on the first page of google results? 2) Have pop-up with proposal to go to the new site at https://apacheignite.readme.io/docs? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14137) Detect and fix failures reasons (nightly runs fails)
Anton Vinogradov created IGNITE-14137: - Summary: Detect and fix failures reasons (nightly runs fails) Key: IGNITE-14137 URL: https://issues.apache.org/jira/browse/IGNITE-14137 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14106) Get rid of obsolete version testing. All tests should be automatically tested on LATEST and DEV.
Anton Vinogradov created IGNITE-14106: - Summary: Get rid of obsolete version testing. All tests should be automatically tested on LATEST and DEV. Key: IGNITE-14106 URL: https://issues.apache.org/jira/browse/IGNITE-14106 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13970) [Ducktape: Thin client] Cache API Test
Anton Vinogradov created IGNITE-13970: - Summary: [Ducktape: Thin client] Cache API Test Key: IGNITE-13970 URL: https://issues.apache.org/jira/browse/IGNITE-13970 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Need to check put/get (atomic, tx) and other cache API works while the user uses TC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13969) Thin client test [umbrella]
Anton Vinogradov created IGNITE-13969: - Summary: Thin client test [umbrella] Key: IGNITE-13969 URL: https://issues.apache.org/jira/browse/IGNITE-13969 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Ensure Thin client work. Check the whole TC API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13873) Milti-cell transaction changes may be not visible (during some time) after the Cellular switch
Anton Vinogradov created IGNITE-13873: - Summary: Milti-cell transaction changes may be not visible (during some time) after the Cellular switch Key: IGNITE-13873 URL: https://issues.apache.org/jira/browse/IGNITE-13873 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Transactions over some cells may be recovered after the stale data read. For example: We have 2 cells, the first contains partitions for k1, second for k2. Tx with put(k1,v1) and put(k2,v2) started and prepared. Then node from the first cell, which is the primary for k1, failed. Currently, the second cell (with key2) may finish the cellular switch before tx recovered and stale data read is possible. Primaries from the {{tx.transactionNodes()}} should be taken into account instead of the current logic that awaits for all transactions located on nodes who are backups to the failed primary. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13790) Configured detection timeout at cellular switch test
Anton Vinogradov created IGNITE-13790: - Summary: Configured detection timeout at cellular switch test Key: IGNITE-13790 URL: https://issues.apache.org/jira/browse/IGNITE-13790 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13703) Check difference between TcpDiscovery and ZookeeperDiscovery at Cellular switch
Anton Vinogradov created IGNITE-13703: - Summary: Check difference between TcpDiscovery and ZookeeperDiscovery at Cellular switch Key: IGNITE-13703 URL: https://issues.apache.org/jira/browse/IGNITE-13703 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13694) Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch
Anton Vinogradov created IGNITE-13694: - Summary: Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch Key: IGNITE-13694 URL: https://issues.apache.org/jira/browse/IGNITE-13694 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13660) Unexpected NODE_LEFT on graceful stop (at ducktests)
Anton Vinogradov created IGNITE-13660: - Summary: Unexpected NODE_LEFT on graceful stop (at ducktests) Key: IGNITE-13660 URL: https://issues.apache.org/jira/browse/IGNITE-13660 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov 1) Graceful shutdown may cause NODE_LEFT. 2) Self-termination apps have logs till the end. Apps terminated by ducktape with SIGTERM stop their logging at node stop. Seems, shutdown hook stops kill the application before the Ignite stops. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13599) Switch tests should have better precision
Anton Vinogradov created IGNITE-13599: - Summary: Switch tests should have better precision Key: IGNITE-13599 URL: https://issues.apache.org/jira/browse/IGNITE-13599 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov The goal is to gain more relevant numbers. For example, see that latency drop equals to process (switch + xxx) duration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13571) Pme-free test should use 9 server nodes
Anton Vinogradov created IGNITE-13571: - Summary: Pme-free test should use 9 server nodes Key: IGNITE-13571 URL: https://issues.apache.org/jira/browse/IGNITE-13571 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13552) PME-free test should check both drops (PME duration vs PME-free, Tx wait vs wait-free)
Anton Vinogradov created IGNITE-13552: - Summary: PME-free test should check both drops (PME duration vs PME-free, Tx wait vs wait-free) Key: IGNITE-13552 URL: https://issues.apache.org/jira/browse/IGNITE-13552 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13446) Configs inside Ducktests logs should be pretty printed
Anton Vinogradov created IGNITE-13446: - Summary: Configs inside Ducktests logs should be pretty printed Key: IGNITE-13446 URL: https://issues.apache.org/jira/browse/IGNITE-13446 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Currently, I see the following inside the logs {code} http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd;> ducker02 ducker03 {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13433) Benchmark confirms operation's latency drop decrease on Cellular switch comparing to PME-free switch
Anton Vinogradov created IGNITE-13433: - Summary: Benchmark confirms operation's latency drop decrease on Cellular switch comparing to PME-free switch Key: IGNITE-13433 URL: https://issues.apache.org/jira/browse/IGNITE-13433 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13009) NoopTimeBag should be used if logging disabled
Anton Vinogradov created IGNITE-13009: - Summary: NoopTimeBag should be used if logging disabled Key: IGNITE-13009 URL: https://issues.apache.org/jira/browse/IGNITE-13009 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov TimeBag uses performs useless operations on finishGlobalStage if logging disabled. Better case is to use no-op realization instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12989) Tx recovery should log statuses to TimeBag
Anton Vinogradov created IGNITE-12989: - Summary: Tx recovery should log statuses to TimeBag Key: IGNITE-12989 URL: https://issues.apache.org/jira/browse/IGNITE-12989 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Timings, counters and other important info should be logged via TimeBag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12969) TxRecovery discovery listener should implement HighPriorityListener
Anton Vinogradov created IGNITE-12969: - Summary: TxRecovery discovery listener should implement HighPriorityListener Key: IGNITE-12969 URL: https://issues.apache.org/jira/browse/IGNITE-12969 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Currently, tx recovery delayed for 300+ ms because it starts at a low priority discovery listener. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12956) Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads
Anton Vinogradov created IGNITE-12956: - Summary: Fully prepared TX rolled back on recovery if TX coordinator failed and some primary has only reads Key: IGNITE-12956 URL: https://issues.apache.org/jira/browse/IGNITE-12956 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov We have 3 nodes with partitioned cache with 2 backups. A - tx coordinator. B and C - other nodes. Let's start tx from A and perform {noformat} cache.put(primaryKeyA, someVal); cache.get(primaryKeyB; tx.prepare(); {noformat} then kill A. Expected: tx recovered and {noformat} cache.get(primaryKeyA)!=null {noformat} Actual: tx rolled back and and {noformat} cache.get(primaryKeyA)==null {noformat} Reason: Node C has only 1 active transaction (because reads not propagated to backup), but expect to have 2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
Anton Vinogradov created IGNITE-12788: - Summary: Cluster achieved fully rebalanced (PME-free ready) state metric Key: IGNITE-12788 URL: https://issues.apache.org/jira/browse/IGNITE-12788 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Fix For: 2.9, 2.8.1 Currently, there is no metric responsible for "PME-free ready state achieved" delivery. {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such metric. Seems, we should update metric on each {{GridDhtPartitionsExchangeFuture#onDone}}. P.s. Late Affinity Assignment should should always set {{true}} to metric value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12617) PME-free switch should wait for recovery only at affected nodes.
Anton Vinogradov created IGNITE-12617: - Summary: PME-free switch should wait for recovery only at affected nodes. Key: IGNITE-12617 URL: https://issues.apache.org/jira/browse/IGNITE-12617 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Obviously, we should wait for recovery before finishing the switch. We should wait for replicated caches recovery globally. As to partitioned caches, we have to minimize the waiting group to allow upcoming operations where possible during the switch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12524) Partition reserve/release symmetry should be checked on release/destroy
Anton Vinogradov created IGNITE-12524: - Summary: Partition reserve/release symmetry should be checked on release/destroy Key: IGNITE-12524 URL: https://issues.apache.org/jira/browse/IGNITE-12524 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Current code never checks reservations zero bound on release/destroy. Checks should be added. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12470) Pme-free switch feature should be deactivatable
Anton Vinogradov created IGNITE-12470: - Summary: Pme-free switch feature should be deactivatable Key: IGNITE-12470 URL: https://issues.apache.org/jira/browse/IGNITE-12470 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov We should be able to disable this feature by some env/jvm property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12273) Slow TX recovery
Anton Vinogradov created IGNITE-12273: - Summary: Slow TX recovery Key: IGNITE-12273 URL: https://issues.apache.org/jira/browse/IGNITE-12273 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov TX recovery cause B*N*2 GridCacheTxRecoveryRequest messages sending (B - backups, N - prepared txs amount). Seems, we able to perform recovery more efficiently. For example, we may send only B*B*2 messages, accumulates txs together. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12272) Delayed TX recovery
Anton Vinogradov created IGNITE-12272: - Summary: Delayed TX recovery Key: IGNITE-12272 URL: https://issues.apache.org/jira/browse/IGNITE-12272 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov TX recovery now starts in delayed way. IGNITE_TX_SALVAGE_TIMEOUT = 100 which cause 100+ ms delay on recovery. Seems, we able to get rig of this delay to make recovery faster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12117) Historical rebalance should not be processed in striped way
Anton Vinogradov created IGNITE-12117: - Summary: Historical rebalance should not be processed in striped way Key: IGNITE-12117 URL: https://issues.apache.org/jira/browse/IGNITE-12117 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov We have to investigate is it possible to process historical rebalance like regular (using unstriped pool) and if possible then refactor it. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12093) Initial rebalance should be performed as efficiently as possible
Anton Vinogradov created IGNITE-12093: - Summary: Initial rebalance should be performed as efficiently as possible Key: IGNITE-12093 URL: https://issues.apache.org/jira/browse/IGNITE-12093 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov {{rebalanceThreadPoolSize}} setting should be ignored on initial rebalance for demanders. Maximum suitable thread pool size should be used during the initial rebalance to perform it asap. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12092) Single-partition-map should not be send earlier than initial rebalance is completed
Anton Vinogradov created IGNITE-12092: - Summary: Single-partition-map should not be send earlier than initial rebalance is completed Key: IGNITE-12092 URL: https://issues.apache.org/jira/browse/IGNITE-12092 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Currently, single partition map is sent to coordination if there wasn't partition owning for some period. See {{GridCachePartitionExchangeManager#scheduleResendPartitions}} and {{GridCachePartitionExchangeManager#sendLocalPartitions}} for details. This may (will) cause unexpected load at demander node and - decrease cluster performance (since some operations will be now served by demander) - rebalance duration will be increased. So, single-partition-map should be sent only on initial rebalance completion. Good place to fix this is to add one more if at {{GridCachePartitionExchangeManager#refreshPartitions}}. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-12091) Rebalance load should be spread across the cluster
Anton Vinogradov created IGNITE-12091: - Summary: Rebalance load should be spread across the cluster Key: IGNITE-12091 URL: https://issues.apache.org/jira/browse/IGNITE-12091 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Currently, suppliers are selected randomly between the owners and this may lead to - unbalanced grid load - unbalanced per-supplier supplying data amount So, we have to - seek to have the same partitions amount to be supplied by each supplier during same rebalance - seek to have the same partitions amount per supplier for each demander - demander should seek to demand partitions from the maximum amount of suppliers Seems we have to implement some function able to calculate global rebalance distribution. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (IGNITE-11980) Repairs count metric (ReadRepair)
Anton Vinogradov created IGNITE-11980: - Summary: Repairs count metric (ReadRepair) Key: IGNITE-11980 URL: https://issues.apache.org/jira/browse/IGNITE-11980 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Ignite should provide metric of how many repairs happened during ReadRepar feature usage. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (IGNITE-11973) testAccountTxNodeRestart cause unexpected repairs in case of ReadRepair usage
Anton Vinogradov created IGNITE-11973: - Summary: testAccountTxNodeRestart cause unexpected repairs in case of ReadRepair usage Key: IGNITE-11973 URL: https://issues.apache.org/jira/browse/IGNITE-11973 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Just add withReadRepair() proxy to test's cache and you'll see unexpected data repairs (values are differ on backups while primary is locked). To debug this add a breakpoint to {{GridNearReadRepairFuture#recordConsistencyViolation}} after fixedRaw.isEmpty() check. Not empty map means repair happened. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11972) Jepsen tests should check consistency
Anton Vinogradov created IGNITE-11972: - Summary: Jepsen tests should check consistency Key: IGNITE-11972 URL: https://issues.apache.org/jira/browse/IGNITE-11972 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov We have to check data is consistent during and after the tests. Good case is to use: - idle_verify of test finish - ReadRepair -- during the test (some/(all?) gets should be with RR proxy) -- after the test finish. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11971) Consistency check on test finish
Anton Vinogradov created IGNITE-11971: - Summary: Consistency check on test finish Key: IGNITE-11971 URL: https://issues.apache.org/jira/browse/IGNITE-11971 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Tests based on GridAbstractTest should automatically check cache's content too be consistent on test finish. Good place to check this is a tearDown method. Additional check can be add to awaitPartitionMapExchange() method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10663) Consistency check
Anton Vinogradov created IGNITE-10663: - Summary: Consistency check Key: IGNITE-10663 URL: https://issues.apache.org/jira/browse/IGNITE-10663 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Need to provide API to make sure that all data nodes contain the same value per key. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9560) Security permissions to restrict arbitrary code exectution
Anton Vinogradov created IGNITE-9560: Summary: Security permissions to restrict arbitrary code exectution Key: IGNITE-9560 URL: https://issues.apache.org/jira/browse/IGNITE-9560 Project: Ignite Issue Type: Task Components: security Affects Versions: 2.6 Reporter: Anton Vinogradov {{SecurityPermission}} class should be extended to cover all cases able to cause arbitrary code execution. 1) Restriction on listener registration - EventStorageSpi listener - CQ listener 2) Restriction on closure (able to be executed on the remote node) execution - Compute API (seems to be covered, should be rechecked) - Services - Entry processor 3) We have to make sure that cases listed at #1 and #2 are the all possible cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9346) md5 should be removed from release
Anton Vinogradov created IGNITE-9346: Summary: md5 should be removed from release Key: IGNITE-9346 URL: https://issues.apache.org/jira/browse/IGNITE-9346 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov The board communicated the following release policy changes: -- for new releases : -- you MUST supply a SHA-256 and/or SHA-512 file -- you SHOULD NOT supply MD5 or SHA-1 files So, we should get rid of md5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9053) testReentrantLockConstantTopologyChangeNonFailoverSafe can hang in case of broken tx
Anton Vinogradov created IGNITE-9053: Summary: testReentrantLockConstantTopologyChangeNonFailoverSafe can hang in case of broken tx Key: IGNITE-9053 URL: https://issues.apache.org/jira/browse/IGNITE-9053 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Anton Vinogradov -GridCachePartitionedDataStructuresFailoverSelfTest#testReentrantLockConstantTopologyChangeNonFailoverSafe -GridCachePartitionedDataStructuresFailoverSelfTest#testCountDownLatchConstantTopologyChange can hang in case of broken tx {noformat} Pending transactions: [2018-07-15 14:13:41,210][WARN ][exchange-worker-#1596354%partitioned.GridCachePartitionedDataStructuresFailoverSelfTest1%][diagnostic] >>> [txVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], exchWait=true, tx=GridDhtTxLocal [nearNodeId=1392b1bd-c807-4479-9bfe-fc9f7050, nearFutId=14ffca0a461-999e75d0-a333-4bd6-a2a2-7f143d0af773, nearMiniId=1, nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion [topVer=143133203, order=1531653200153, nodeOrder=1], super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[], dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter [completedBase=null, sndTransformedVals=false, depEnabled=false, txState=IgniteTxStateImpl [activeCacheIds=[1968300681], recovery=false, txMap=[IgniteTxEntry [key=KeyCacheObjectImpl [part=494, val=GridCacheInternalKeyImpl [name=structure, grpName=default-volatile-ds-group], hasValBytes=true], cacheId=1968300681, txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=494, val=GridCacheInternalKeyImpl [name=structure, grpName=default-volatile-ds-group], hasValBytes=true], cacheId=1968300681], val=[op=NOOP, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=494, super=GridDistributedCacheEntry [super=GridCacheMapEntry [key=KeyCacheObjectImpl [part=494, val=GridCacheInternalKeyImpl [name=structure, grpName=default-volatile-ds-group], hasValBytes=true], val=CacheObjectImpl [val=null, hasValBytes=true], ver=GridCacheVersion [topVer=143133201, order=1531653200154, nodeOrder=2], hash=2095426867, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=[GridCacheMvccCandidate [nodeId=1bf28b00-feed-412b-a20b-ca9fc111, ver=GridCacheVersion [topVer=143133203, order=1531653200157, nodeOrder=2], threadId=1947290, id=31143709, topVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], reentry=null, otherNodeId=1392b1bd-c807-4479-9bfe-fc9f7050, otherVer=GridCacheVersion [topVer=143133203, order=1531653200153, nodeOrder=1], mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, key=KeyCacheObjectImpl [part=494, val=GridCacheInternalKeyImpl [name=structure, grpName=default-volatile-ds-group], hasValBytes=true], masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0, prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=0, locked=false, nodeId=null, locMapped=false, expiryPlc=null, transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null, xidVer=GridCacheVersion [topVer=143133203, order=1531653200157, nodeOrder=2, super=IgniteTxAdapter [xidVer=GridCacheVersion [topVer=143133203, order=1531653200157, nodeOrder=2], writeVer=null, implicit=false, loc=true, threadId=1947290, startTime=1531653200578, nodeId=1bf28b00-feed-412b-a20b-ca9fc111, startVer=GridCacheVersion [topVer=143133203, order=1531653200157, nodeOrder=2], endVer=null, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0, sysInvalidate=false, sys=true, plc=2, commitVer=null, finalizing=NONE, invalidParts=null, state=ACTIVE, timedOut=false, topVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], duration=20632ms, onePhaseCommit=false], size=1 {noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8446) Ability to check and completely fill transactions on creation
Anton Vinogradov created IGNITE-8446: Summary: Ability to check and completely fill transactions on creation Key: IGNITE-8446 URL: https://issues.apache.org/jira/browse/IGNITE-8446 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Event EVT_USR_TX_START should be created. Tx.label should be recodred as a part of this event. Test, checking it's possible to restrict tx creation without filling the meta should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8419) Clear javadoc for tx markers
Anton Vinogradov created IGNITE-8419: Summary: Clear javadoc for tx markers Key: IGNITE-8419 URL: https://issues.apache.org/jira/browse/IGNITE-8419 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Currently, newcomers have problems with tx code understanding since markers are not clear I propose to write a clear javadoc for reasonable markers of IgniteInternalTx - local - near - dht - remote - colocated am I missed something? I see how it works, but it takes a time to understand it again each time I'm working with tx's. Some tips abouf flags: Tx created on originating node eg. GridNearTxLocal flags: near | local Tx created on primary node eg. GridDhtTxLocal flags: dht | local Tx created on primary - eg. GridDhtTxRemote flags: dht | remote -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7790) All critical errors health should be covered by IgniteFailureProcessor
Anton Vinogradov created IGNITE-7790: Summary: All critical errors health should be covered by IgniteFailureProcessor Key: IGNITE-7790 URL: https://issues.apache.org/jira/browse/IGNITE-7790 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov List of errors to be handled - Persistence errors - IOOM errors (part of persistence errors?) - IO errors (list to be provided) - Assertion errors (we should handle assertions as failures in case -ea flag set) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7772) All critical system workers health should be covered
Anton Vinogradov created IGNITE-7772: Summary: All critical system workers health should be covered Key: IGNITE-7772 URL: https://issues.apache.org/jira/browse/IGNITE-7772 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Dmitriy Sorokin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7685) Incorrect AllocationRate counting
Anton Vinogradov created IGNITE-7685: Summary: Incorrect AllocationRate counting Key: IGNITE-7685 URL: https://issues.apache.org/jira/browse/IGNITE-7685 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Andrey Kuznetsov Each call of {{org.apache.ignite.internal.processors.cache.persistence.DataRegionMetricsImpl#updateTotalAllocatedPages}} performs {{allocRate.onHit()}} call which is not correct since delta can be negative or bigger that 1. Need to fix allocationRate counting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7415) Ability to disable WAL (Documentation)
Anton Vinogradov created IGNITE-7415: Summary: Ability to disable WAL (Documentation) Key: IGNITE-7415 URL: https://issues.apache.org/jira/browse/IGNITE-7415 Project: Ignite Issue Type: Sub-task Environment: Need to update [https://apacheignite.readme.io/docs/write-ahead-log#section-wal-modes] [https://apacheignite.readme.io/docs/data-loading] Reporter: Anton Vinogradov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc
Anton Vinogradov created IGNITE-7386: Summary: Get rid of LongAdder8, ConcurrentHashMap8, etc Key: IGNITE-7386 URL: https://issues.apache.org/jira/browse/IGNITE-7386 Project: Ignite Issue Type: Task Affects Versions: 2.5 Reporter: Anton Vinogradov Since we're dripping java7 support there is no need now to use {{LongAdder8}}, {{ConcurrentHashMap8}}, ... We should remove all classes from {{org.jsr166}} namespace and use corresponding classes from jdk8. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7230) Improve rebalance logging and metrics
Anton Vinogradov created IGNITE-7230: Summary: Improve rebalance logging and metrics Key: IGNITE-7230 URL: https://issues.apache.org/jira/browse/IGNITE-7230 Project: Ignite Issue Type: New Feature Reporter: Anton Vinogradov 1) Node's log should contain messages that - local node finished rebalancing from other nodes - whole cluster finished rebalancing (awaitPartitionMaxExchange analogue) 2) We should be able to turn on same logging per cache group. - local node finished cache group rebalancing - whole cluster finished cache group rebalancing 3) We should update MBean to show progress - % of partitions rebalanced locally - % of partitions rebalanced at cluster -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7203) Java 8 by default
Anton Vinogradov created IGNITE-7203: Summary: Java 8 by default Key: IGNITE-7203 URL: https://issues.apache.org/jira/browse/IGNITE-7203 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov We should drop Java 7 support. Release process https://ci.ignite.apache.org/project.html?projectId=AssemblyAndRelease should be updated if necessary. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7005) Ability to disable WAL (Recoverable case)
Anton Vinogradov created IGNITE-7005: Summary: Ability to disable WAL (Recoverable case) Key: IGNITE-7005 URL: https://issues.apache.org/jira/browse/IGNITE-7005 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov In addition to non recoverable case: On WAL disabling we should (on each node) - trigger exchange to guarantie consistent state - schedule new checkpoint. This checkpoint should be recorded to special place (temporary checkpoint location), to prevent damage of latest one. All new checkpoints should update temporary checkpoint. On WAL enabling we should (on each node) after all nodes reported that checkpoints finished - merge temp checkpoint with stable (scheduled before WAL disabling) - clean WAL before enabling proxies On any failure during loading (while WAL disabled or enabling) we should be able to reactivate cluster with - data from original checkpoints & WAL for affected caches - latest state for non affected caches Failover: Any topology change should be covered(while WAL disabled or enabling) - Node(s) Left (inc. coordinator) - Node(s) Join -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7004) Ability to disable WAL (Cross-cache tx should be rescricted while WAL disabled)
Anton Vinogradov created IGNITE-7004: Summary: Ability to disable WAL (Cross-cache tx should be rescricted while WAL disabled) Key: IGNITE-7004 URL: https://issues.apache.org/jira/browse/IGNITE-7004 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Cross-cache transactions affecting caches with different modes (e.g. one enabled, another disabled) are not allowed -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7003) Ability to disable WAL (Non recoverable case)
Anton Vinogradov created IGNITE-7003: Summary: Ability to disable WAL (Non recoverable case) Key: IGNITE-7003 URL: https://issues.apache.org/jira/browse/IGNITE-7003 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov 1) WAL should be disabled by custom discovery message without - triggering exchange, - triggering checkpoint (since it's non recoverable case) In case someone is trying to disable already disabled WAL he should be notified that WAL already disabled Only cachegroups containing one cache can de disabled 2) WAL should be prepared to be enabled by custom discovery message with - triggering exchange, - disabling cache proxies, - waiting for checkpoints at every node. In case someone is trying to enable already enablling WAL he should be notified that enabling in progress. 3) WAL should be enabled by custom discovery message - without triggering exchange but - with enabling proxies once all nodes finished their checkpoints. Failover: On any failure during loading (while WAL disabled or enabling) we should be able to reactivate cluster without affected caches content. Originating node fail should be covered (at WAL disabled and enabling cases) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6961) Internal Problems should be covered by Monitoring tool
Anton Vinogradov created IGNITE-6961: Summary: Internal Problems should be covered by Monitoring tool Key: IGNITE-6961 URL: https://issues.apache.org/jira/browse/IGNITE-6961 Project: Ignite Issue Type: New Feature Reporter: Anton Vinogradov Assignee: Alexey Kuznetsov - Monitoring tool should provide UI which allows to view and manage: - active transactions (including: long-running) - locks aquired; - tasks performed; - deadlocks detected. - Moniroring tool should alert and keeps history of: - java level deadlocks; - GC- or STW- pauses; - threadpool starvation events. Best candidates (as monitoring tool) are WebConsole and VisorConsole -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6903) Implement new JMX metrics for Indexing
Anton Vinogradov created IGNITE-6903: Summary: Implement new JMX metrics for Indexing Key: IGNITE-6903 URL: https://issues.apache.org/jira/browse/IGNITE-6903 Project: Ignite Issue Type: New Feature Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov These additional metrics and methods should be implemented: - Space occupied by indexes. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6902) Implement new JMX metrics for Persistence
Anton Vinogradov created IGNITE-6902: Summary: Implement new JMX metrics for Persistence Key: IGNITE-6902 URL: https://issues.apache.org/jira/browse/IGNITE-6902 Project: Ignite Issue Type: New Feature Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov These additional metrics and methods should be implemented: - Bytes used per data region. - Bytes used per cache. - Size of checkpointing buffer. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6895) Provide metric to monitor any TX deadlock
Anton Vinogradov created IGNITE-6895: Summary: Provide metric to monitor any TX deadlock Key: IGNITE-6895 URL: https://issues.apache.org/jira/browse/IGNITE-6895 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6894) Provide metric to monitor Internal threads stuck
Anton Vinogradov created IGNITE-6894: Summary: Provide metric to monitor Internal threads stuck Key: IGNITE-6894 URL: https://issues.apache.org/jira/browse/IGNITE-6894 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6893) Provide metric to monitor Java Deadlocks
Anton Vinogradov created IGNITE-6893: Summary: Provide metric to monitor Java Deadlocks Key: IGNITE-6893 URL: https://issues.apache.org/jira/browse/IGNITE-6893 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6892) Proper behavior on OOM/IgniteOutOfMemoryException
Anton Vinogradov created IGNITE-6892: Summary: Proper behavior on OOM/IgniteOutOfMemoryException Key: IGNITE-6892 URL: https://issues.apache.org/jira/browse/IGNITE-6892 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov In case of any OOM node should be stopped anyway, what we can provide is user callback, something like 'beforeNodeStop'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6891) Proper behavior on Persistence errors
Anton Vinogradov created IGNITE-6891: Summary: Proper behavior on Persistence errors Key: IGNITE-6891 URL: https://issues.apache.org/jira/browse/IGNITE-6891 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov Node should be stopped anyway, what we can provide is user callback, something like beforeNodeStop'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6890) Proper behavior on ExchangeWorker exits with error
Anton Vinogradov created IGNITE-6890: Summary: Proper behavior on ExchangeWorker exits with error Key: IGNITE-6890 URL: https://issues.apache.org/jira/browse/IGNITE-6890 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov Node should be stopped anyway, what we can provide is user callback, something like beforeNodeStop'. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6766) RC check automation
Anton Vinogradov created IGNITE-6766: Summary: RC check automation Key: IGNITE-6766 URL: https://issues.apache.org/jira/browse/IGNITE-6766 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov Assignee: Oleg Ostanin Need to add task downloads RC from https://dist.apache.org/repos/dist/dev/ignite/X.Y.Z-rcK and checks that sha1, md5, gpg, src(license, build)) are ok. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6763) Release process automation
Anton Vinogradov created IGNITE-6763: Summary: Release process automation Key: IGNITE-6763 URL: https://issues.apache.org/jira/browse/IGNITE-6763 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov Assignee: Anton Vinogradov See devlist for details -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6727) Ignite assembly should not require ignite-tools installation
Anton Vinogradov created IGNITE-6727: Summary: Ignite assembly should not require ignite-tools installation Key: IGNITE-6727 URL: https://issues.apache.org/jira/browse/IGNITE-6727 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov Assignee: Oleg Ostanin Need to research how to solve this. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6725) Source release should be fixed
Anton Vinogradov created IGNITE-6725: Summary: Source release should be fixed Key: IGNITE-6725 URL: https://issues.apache.org/jira/browse/IGNITE-6725 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Anton Vinogradov Assignee: Oleg Ostanin Priority: Critical Fix For: 2.4 I see a lot of garbage at source release. Now source releasing using maven magic. Sources generation logic should be replaced with "git, give me source and I'll zip what you provide". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6300) BinaryObject's set size estimator
Anton Vinogradov created IGNITE-6300: Summary: BinaryObject's set size estimator Key: IGNITE-6300 URL: https://issues.apache.org/jira/browse/IGNITE-6300 Project: Ignite Issue Type: New Feature Reporter: Anton Vinogradov Assignee: Dmitriy Sorokin Need to provide some API to estimate requirements for any data model. For example: 1) You have classes A,B and C with known fields. 2) You know that you have to keep 1M of A, 2M of B and 45K of C. 3) BinarySizeEstimator should return you expected memory consumption on actual Ignite version without starting a node. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-5365) Build release artifacts once and use them for all editions
Anton Vinogradov created IGNITE-5365: Summary: Build release artifacts once and use them for all editions Key: IGNITE-5365 URL: https://issues.apache.org/jira/browse/IGNITE-5365 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Oleg Ostanin -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5092) TC should check Examples on each regression.
Anton Vinogradov created IGNITE-5092: Summary: TC should check Examples on each regression. Key: IGNITE-5092 URL: https://issues.apache.org/jira/browse/IGNITE-5092 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov Priority: Critical Fix For: 2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-5030) Support Spring @Cacheable(sync=true) annotation
Anton Vinogradov created IGNITE-5030: Summary: Support Spring @Cacheable(sync=true) annotation Key: IGNITE-5030 URL: https://issues.apache.org/jira/browse/IGNITE-5030 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov @Cacheable(sync=true) guarantee that only one thread (across the cluster) will fetch value for a key on get, even in case of some simultaneous gets. So, org.apache.ignite.cache.spring.SpringCache#get(java.lang.Object, java.util.concurrent.Callable) should be implemented to provide such guarantee. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4937) Deadlock detection should happens on each grid hang
Anton Vinogradov created IGNITE-4937: Summary: Deadlock detection should happens on each grid hang Key: IGNITE-4937 URL: https://issues.apache.org/jira/browse/IGNITE-4937 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Priority: Critical Each "Failed to wait for partition map exchange" or similar should cause such check. Check can be added to org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager#dumpPendingObjects or org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager#dumpLongRunningOperations -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4909) Get Rid of AssertionError as a positive warnings
Anton Vinogradov created IGNITE-4909: Summary: Get Rid of AssertionError as a positive warnings Key: IGNITE-4909 URL: https://issues.apache.org/jira/browse/IGNITE-4909 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov I found that some tests can cause AssertionError even in case everything is ok. Examples: 1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed with unhandled error (normal behaviour): java.lang.AssertionError: Test assertion (should be ignored). 2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught expected error: java.lang.AssertionError -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4770) Script inside javadoc bottom cause compilation error at 1.8.0_121-b13
Anton Vinogradov created IGNITE-4770: Summary: Script inside javadoc bottom cause compilation error at 1.8.0_121-b13 Key: IGNITE-4770 URL: https://issues.apache.org/jira/browse/IGNITE-4770 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov parent/pom.xml:455 contained following: {noformat} !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+'://platform.twitter.com/widgets.js';fjs.parentNode.insertBefore(js,fjs);}}(document, 'script', 'twitter-wjs'); {noformat} this cause compilation error during {noformat} mvn clean package -DskipTests {noformat} error {noformat} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.10.1:jar (module-javadoc) on project ignite-tools: MavenReportException: Error while creating archive: [ERROR] Exit code: 1 - javadoc: error - Argument for -bottom contains JavaScript. [ERROR] Use --allow-script-in-comments to allow use of JavaScript. {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (IGNITE-4621) Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true
Anton Vinogradov created IGNITE-4621: Summary: Hang on broadcast when BinaryUtils.FIELDS_SORTED_ORDER == true Key: IGNITE-4621 URL: https://issues.apache.org/jira/browse/IGNITE-4621 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Reproducer: {noformat} assert BinaryUtils.FIELDS_SORTED_ORDER; startGrids(GRIDS); //awaitPartitionMapExchange(); Ignite ignite = grid(0); ignite.compute(ignite.cluster().forServers()).broadcast(new JustAnotherCallable()); // hang here stopAllGrids(); {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4423) ignite.binary().type(entity.getKeyType())==null before first cache.put()
Anton Vinogradov created IGNITE-4423: Summary: ignite.binary().type(entity.getKeyType())==null before first cache.put() Key: IGNITE-4423 URL: https://issues.apache.org/jira/browse/IGNITE-4423 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Attachments: BinTest.java See attacheed test for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4242) ExchangeManager should wait for cache rebalancing in async way
Anton Vinogradov created IGNITE-4242: Summary: ExchangeManager should wait for cache rebalancing in async way Key: IGNITE-4242 URL: https://issues.apache.org/jira/browse/IGNITE-4242 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov Current code waits at system pool's thread, that unacceptable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4225) DataStreamer can hang on changing topology
Anton Vinogradov created IGNITE-4225: Summary: DataStreamer can hang on changing topology Key: IGNITE-4225 URL: https://issues.apache.org/jira/browse/IGNITE-4225 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov Priority: Critical Hang reason: Exchange cannot happen because some datastreamer futures not finished {noformat} Pending data streamer futures: [12:17:28,427][WARN ][exchange-worker-#106%distributed.CacheLoadingConcurrentGridStartSelfTest2%][GridCachePartitionExchangeManager] >>> DataStreamerFuture [topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], super=GridFutureAdapter [resFlag=0, res=null, startTime=1479201428401, endTime=0, ignoreInterrupts=false, state=INIT]] {noformat} Reason of notfinished futures: {noformat} - parking to wait for <0x000792e050b0> (a org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304) at org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:160) at org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:118) at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:538) at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:449) at org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:402) at org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodes(GridCacheAffinityManager.java:259) at org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:295) at org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:286) at org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:310) at org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$IsolatedUpdater.receive(DataStreamerImpl.java:1948) at org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:140) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:370) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56) at org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1080) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:708) at org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:101) at org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:671) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {noformat} Possible solution: Need to use topology instead of affinity to detect is node primary {noformat} boolean primary = cctx.affinity().primary(cctx.localNode(), entry.key(), topVer); {noformat} -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-4210) CacheLoadingConcurrentGridStartSelfTest.testLoadCacheFromStore() test lose data.
Anton Vinogradov created IGNITE-4210: Summary: CacheLoadingConcurrentGridStartSelfTest.testLoadCacheFromStore() test lose data. Key: IGNITE-4210 URL: https://issues.apache.org/jira/browse/IGNITE-4210 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov org.apache.ignite.internal.processors.cache.distributed.CacheLoadingConcurrentGridStartSelfTest#testLoadCacheFromStore have failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3874) sync putIfAbsent forever blocked on all nodes after one node is stopped
Anton Vinogradov created IGNITE-3874: Summary: sync putIfAbsent forever blocked on all nodes after one node is stopped Key: IGNITE-3874 URL: https://issues.apache.org/jira/browse/IGNITE-3874 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov First stacktrace: Failed to send prepare response for transaction: at org.apache.ignite.internal.processors.cache.GridCacheIoManager.send(GridCacheIoManager.java:800) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.sendPrepareResponse(GridDhtTxPrepareFuture.java:731) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onDone(GridDhtTxPrepareFuture.java:690) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onError(GridDhtTxPrepareFuture.java:457) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:424) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:298) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.prepare(IgniteTxLocalAdapter.java:594) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.salvageTx(IgniteTxManager.java:300) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.access$2200(IgniteTxManager.java:119) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2148) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$2400(IgniteTxManager.java:2113) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$2.run(IgniteTxManager.java:2188) at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6540) at org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:802) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Second: Failed to commit transaction: at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.finish(GridDhtTxLocalAdapter.java:750) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.finish(GridDhtTxLocal.java:649) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.commitAsync(GridDhtTxLocal.java:549) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.commit(IgniteTxLocalAdapter.java:585) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.salvageTx(IgniteTxManager.java:317) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.access$2200(IgniteTxManager.java:119) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.onTimeout0(IgniteTxManager.java:2148) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject.access$2400(IgniteTxManager.java:2113) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager$NodeFailureTimeoutObject$2.run(IgniteTxManager.java:2188) at org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6540) at org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:802) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) and finaly we see hanged 2pc TX with state MARKED_ROLLBACK. Rollback should happen, but doesn't happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3793) Need to fix dependencies and it's licenses.
Anton Vinogradov created IGNITE-3793: Summary: Need to fix dependencies and it's licenses. Key: IGNITE-3793 URL: https://issues.apache.org/jira/browse/IGNITE-3793 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Priority: Blocker 1) H2 license listed at LICENSE_FABRIC seems to be wrong. Need to make sure that correct one listed at ignite-indexing-licenses.txt and remove wrong at LICENSE_FABRIC. 2) We need to use geronimo instead of JTA dependency. License will be changed automativally in this case. Need to cleanup LICENSE_FABRIC. 3) Apache licenses should be always shown at ignite-*-licenses.txt. licenses.txt.vm should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3462) Cache is not empty after destroyCache & createCache in case Swap and EvictionPolicy used
Anton Vinogradov created IGNITE-3462: Summary: Cache is not empty after destroyCache & createCache in case Swap and EvictionPolicy used Key: IGNITE-3462 URL: https://issues.apache.org/jira/browse/IGNITE-3462 Project: Ignite Issue Type: Bug Affects Versions: 1.6 Reporter: Anton Vinogradov See org/apache/ignite/internal/processors/cache/query/continuous/CacheKeepBinaryIterationTest.java:282 for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3323) Get rid of copypasted JB annotations, use dependency instead.
Anton Vinogradov created IGNITE-3323: Summary: Get rid of copypasted JB annotations, use dependency instead. Key: IGNITE-3323 URL: https://issues.apache.org/jira/browse/IGNITE-3323 Project: Ignite Issue Type: Task Affects Versions: 1.5.0.final Reporter: Anton Vinogradov Assignee: Anton Vinogradov Priority: Minor Fix For: 1.7 >From user request: {quote} I've come across an issue where there are a couple of classes duplicated from org.jetbrains.annotations within the ignite-core module which conflict with other part of our code base. As these files are duplicated rather than being referenced as a maven dependency I am unable to exclude them or reference a specific version of the org.jetbrains.annotations artifact. Specifically, the included version cannot be used to annotate types ignite-core-1.6.0.jar:org.jetbrains.annotations.Nullable ... @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER, ElementType.LOCAL_VARIABLE}) annotations-15.0.jar:org.jetbrains.annotations.Nullable ... @Target({ElementType.METHOD, ElementType.FIELD, ElementType.PARAMETER, ElementType.LOCAL_VARIABLE, ElementType.TYPE_USE}) As far as I know there isn't an easy way of excluding these files from within the ignite-core module. Is there are reason why these "external" files have been duplicated within the ignite code base rather than being referenced as a maven dependency? Or alternatively, has anyone come across a way of avoiding these conflicts? {quote} Seems we have to remove these classes from Ignite code and use maven dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3238) Javadoc Warning due to cassandra libs usage
Anton Vinogradov created IGNITE-3238: Summary: Javadoc Warning due to cassandra libs usage Key: IGNITE-3238 URL: https://issues.apache.org/jira/browse/IGNITE-3238 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Igor Rudyak I found following at Ignite 1.6 build log: [WARNING] Javadoc Warnings [WARNING] warning: /home/teamcity/.m2/repository/org/apache/cassandra/cassandra-all/3.3/cassandra-all-3.3.jar(org/apache/cassandra/service/CassandraDaemon.class): major version 52 is newer than 51, the highest major version supported by this compiler. [WARNING] It is recommended that the compiler be upgraded. seems this warning related to https://issues.apache.org/jira/browse/IGNITE-1371. Command to gain this is: mvn clean package -DskipTests also you can use this TeamCity task: http://149.202.210.143:8111/viewType.html?buildTypeId=IgniteTests_RatJavadoc Need to fix it without using JDK 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3237) Javadoc Warning due to cassandra libs usage
Anton Vinogradov created IGNITE-3237: Summary: Javadoc Warning due to cassandra libs usage Key: IGNITE-3237 URL: https://issues.apache.org/jira/browse/IGNITE-3237 Project: Ignite Issue Type: Bug Affects Versions: 1.6 Reporter: Anton Vinogradov Assignee: Igor Rudyak Fix For: 1.7 I found following at Ignite 1.6 build log: [WARNING] Javadoc Warnings [WARNING] warning: /home/teamcity/.m2/repository/org/apache/cassandra/cassandra-all/3.3/cassandra-all-3.3.jar(org/apache/cassandra/service/CassandraDaemon.class): major version 52 is newer than 51, the highest major version supported by this compiler. [WARNING] It is recommended that the compiler be upgraded. seems this warning related to https://issues.apache.org/jira/browse/IGNITE-1371 Command to gain this is: mvn clean package -DskipTests also you can use this TeamCity task: http://149.202.210.143:8111/viewType.html?buildTypeId=IgniteTests_RatJavadoc Need to fix this without using JDK 8. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2660) Correct Grid behavior at key deserialization failure during rebalancing
Anton Vinogradov created IGNITE-2660: Summary: Correct Grid behavior at key deserialization failure during rebalancing Key: IGNITE-2660 URL: https://issues.apache.org/jira/browse/IGNITE-2660 Project: Ignite Issue Type: Task Affects Versions: 1.5.0.final Reporter: Anton Vinogradov Problem explanation: Anton VinogradovIgniters, At this moment key deserialization failure during rebalancing cause strange situation: Rebalancing from node sent supply message with broken key will be cancelled at current topology. All upcoming supply messages from this node will be be ignored, no new demand messages to this node will be sent. But when topology will be changed again, node with broken key will take path at rebalancing again, untill key deserialization failure happen ... again. Do we need to improve this situation, and if we have to how should be handled case with key deserialization failure? I see some ways: 1) We can inform user about data loss because of deserialization problems, but keep current rebalancing strategy 2) We can continue rebalancing from this node, but ignore messages with broken keys. And inform user about data loss. 3) We can pause rebalancing untill deserialization will be fixed somehow, for example by shutdowning demanding or supplying node. Thoughts? Dmitriy Setrakyan Anton, I am not sure I fully grok the use case. Can you please explain why a key can be broken? Anton Vinogradov Dmitriy, Key can be undeserializable during rebalancing because of many reasons. For example, 1) It was serialized with errors 2) Deserialization cause error 3) It based on classes unavailable at node trying to deserialize it Third is the most possible case. Dmitriy Setrakyan Anton, I am not sure why we would deserialize on the server side with Binary Marshaller. The data should remain in binary form. Do you know if we have a test for it? Anton Vinogradov Dmitry, I found such behavior at GridCacheRebalancingUnmarshallingFailedSelfTest. Seems we always unmarshalling keys at supply message handling in case of OptimizeMarshaller used. Also it happens when BinaryMarshaller used but key class implements Externalizable. Dmitriy Setrakyan Anton, If there is no deserialization for binary marshaller, then I would treat it as a low priority issue. We should file a ticket and get to it when it becomes more critical. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2565) TCK suite fail periodically
Anton Vinogradov created IGNITE-2565: Summary: TCK suite fail periodically Key: IGNITE-2565 URL: https://issues.apache.org/jira/browse/IGNITE-2565 Project: Ignite Issue Type: Bug Affects Versions: 1.5.0.final Reporter: Anton Vinogradov TCK suite fail periodically fails with assetrions about CacheHitPercentage. I see that a lot of changes was made last two months where added logic with invoking of metrics.onRead(); possible this affects statictic counting. Typical stacktrace: java.lang.AssertionError: expected:<100.0> but was:<50.0> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:144) at org.jsr107.tck.management.CacheMBStatisticsBeanTest.testCacheStatisticsInvokeEntryProcessorRemove(CacheMBStatisticsBeanTest.java:424) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2514) IgfsStartCacheTest.testCacheStart (IGFS test suite) fails periodically
Anton Vinogradov created IGNITE-2514: Summary: IgfsStartCacheTest.testCacheStart (IGFS test suite) fails periodically Key: IGNITE-2514 URL: https://issues.apache.org/jira/browse/IGNITE-2514 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Ivan Veselovsky IgfsStartCacheTest.testCacheStart test periodically fails at Ignite's TeamCity (http://204.14.53.151/viewType.html?buildTypeId=IgniteTests_IgniteGgfs) with stacktrace java.io.IOException: File was concurrently deleted: /test/test.file at org.apache.ignite.internal.processors.igfs.IgfsOutputStreamImpl.flush(IgfsOutputStreamImpl.java:283) at org.apache.ignite.internal.processors.igfs.IgfsOutputStreamAdapter.close(IgfsOutputStreamAdapter.java:182) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233) at java.io.BufferedWriter.close(BufferedWriter.java:266) at org.apache.ignite.internal.processors.igfs.IgfsStartCacheTest.testCacheStart(IgfsStartCacheTest.java:127) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2305) DEVNOTES.txt should contain infornation about platform build.
Anton Vinogradov created IGNITE-2305: Summary: DEVNOTES.txt should contain infornation about platform build. Key: IGNITE-2305 URL: https://issues.apache.org/jira/browse/IGNITE-2305 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Pavel Tupitsyn Priority: Blocker DEVNOTES.txt should explain how to build Ignite Dotnet & Cpp clients. It should be similar to "Ignite Fabric Maven Build Instructions" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2106) BinaryMarshaller: near cache mustn't keep a copy on put() operation
Anton Vinogradov created IGNITE-2106: Summary: BinaryMarshaller: near cache mustn't keep a copy on put() operation Key: IGNITE-2106 URL: https://issues.apache.org/jira/browse/IGNITE-2106 Project: Ignite Issue Type: Bug Reporter: Anton Vinogradov Assignee: Anton Vinogradov Priority: Blocker Binary marshaller is an opensouced Gridgain Prortable marshaller, So bug http://atlassian.gridgain.com/jira/browse/GG-10791 moved to Ignite jira. There are several deployment related tests that fail when PortableMarshaller is used. GridPortableCacheDeploymentSelftTest.testDeployment3()/testDeployemnt4(); GridPortableCacheDeploymentOffHeapSelfTest.testDeployment3()/testDeployemnt4(); The reason of the failure is that a near cache stores a copy of a cache entry when the cache.put() is being executed. No cache.get() was explicitly called during the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)