[jira] [Created] (IGNITE-14622) Snapshot test simplification

2021-04-22 Thread Anton Vinogradov (Jira)
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

2021-04-21 Thread Anton Vinogradov (Jira)
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.

2021-04-20 Thread Anton Vinogradov (Jira)
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

2021-04-08 Thread Anton Vinogradov (Jira)
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

2021-04-06 Thread Anton Vinogradov (Jira)
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

2021-04-06 Thread Anton Vinogradov (Jira)
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

2021-04-05 Thread Anton Vinogradov (Jira)
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

2021-04-02 Thread Anton Vinogradov (Jira)
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

2021-03-26 Thread Anton Vinogradov (Jira)
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

2021-03-18 Thread Anton Vinogradov (Jira)
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

2021-03-17 Thread Anton Vinogradov (Jira)
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

2021-03-17 Thread Anton Vinogradov (Jira)
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

2021-03-01 Thread Anton Vinogradov (Jira)
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

2021-02-28 Thread Anton Vinogradov (Jira)
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

2021-02-25 Thread Anton Vinogradov (Jira)
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

2021-02-19 Thread Anton Vinogradov (Jira)
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)

2021-02-08 Thread Anton Vinogradov (Jira)
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.

2021-02-01 Thread Anton Vinogradov (Jira)
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

2021-01-11 Thread Anton Vinogradov (Jira)
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]

2021-01-11 Thread Anton Vinogradov (Jira)
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

2020-12-17 Thread Anton Vinogradov (Jira)
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

2020-12-01 Thread Anton Vinogradov (Jira)
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

2020-11-13 Thread Anton Vinogradov (Jira)
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

2020-11-11 Thread Anton Vinogradov (Jira)
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)

2020-11-03 Thread Anton Vinogradov (Jira)
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

2020-10-20 Thread Anton Vinogradov (Jira)
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

2020-10-12 Thread Anton Vinogradov (Jira)
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)

2020-10-07 Thread Anton Vinogradov (Jira)
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

2020-09-14 Thread Anton Vinogradov (Jira)
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

2020-09-11 Thread Anton Vinogradov (Jira)
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

2020-05-13 Thread Anton Vinogradov (Jira)
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

2020-05-07 Thread Anton Vinogradov (Jira)
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

2020-04-30 Thread Anton Vinogradov (Jira)
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

2020-04-27 Thread Anton Vinogradov (Jira)
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

2020-03-16 Thread Anton Vinogradov (Jira)
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.

2020-02-03 Thread Anton Vinogradov (Jira)
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

2020-01-09 Thread Anton Vinogradov (Jira)
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

2019-12-19 Thread Anton Vinogradov (Jira)
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

2019-10-09 Thread Anton Vinogradov (Jira)
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

2019-10-09 Thread Anton Vinogradov (Jira)
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

2019-08-28 Thread Anton Vinogradov (Jira)
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

2019-08-21 Thread Anton Vinogradov (Jira)
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

2019-08-21 Thread Anton Vinogradov (Jira)
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

2019-08-21 Thread Anton Vinogradov (Jira)
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)

2019-07-15 Thread Anton Vinogradov (JIRA)
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

2019-07-10 Thread Anton Vinogradov (JIRA)
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

2019-07-10 Thread Anton Vinogradov (JIRA)
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

2019-07-10 Thread Anton Vinogradov (JIRA)
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

2018-12-12 Thread Anton Vinogradov (JIRA)
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

2018-09-12 Thread Anton Vinogradov (JIRA)
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

2018-08-22 Thread Anton Vinogradov (JIRA)
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

2018-07-23 Thread Anton Vinogradov (JIRA)
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

2018-05-07 Thread Anton Vinogradov (JIRA)
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

2018-04-28 Thread Anton Vinogradov (JIRA)
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

2018-02-22 Thread Anton Vinogradov (JIRA)
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

2018-02-20 Thread Anton Vinogradov (JIRA)
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

2018-02-13 Thread Anton Vinogradov (JIRA)
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)

2018-01-15 Thread Anton Vinogradov (JIRA)
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

2018-01-11 Thread Anton Vinogradov (JIRA)
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

2017-12-18 Thread Anton Vinogradov (JIRA)
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

2017-12-14 Thread Anton Vinogradov (JIRA)
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)

2017-11-23 Thread Anton Vinogradov (JIRA)
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)

2017-11-23 Thread Anton Vinogradov (JIRA)
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)

2017-11-23 Thread Anton Vinogradov (JIRA)
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

2017-11-20 Thread Anton Vinogradov (JIRA)
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

2017-11-14 Thread Anton Vinogradov (JIRA)
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

2017-11-14 Thread Anton Vinogradov (JIRA)
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

2017-11-13 Thread Anton Vinogradov (JIRA)
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

2017-11-13 Thread Anton Vinogradov (JIRA)
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

2017-11-13 Thread Anton Vinogradov (JIRA)
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

2017-11-13 Thread Anton Vinogradov (JIRA)
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

2017-11-13 Thread Anton Vinogradov (JIRA)
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

2017-11-13 Thread Anton Vinogradov (JIRA)
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

2017-10-26 Thread Anton Vinogradov (JIRA)
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

2017-10-26 Thread Anton Vinogradov (JIRA)
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

2017-10-24 Thread Anton Vinogradov (JIRA)
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

2017-10-24 Thread Anton Vinogradov (JIRA)
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

2017-09-07 Thread Anton Vinogradov (JIRA)
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

2017-05-31 Thread Anton Vinogradov (JIRA)
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.

2017-04-26 Thread Anton Vinogradov (JIRA)
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

2017-04-19 Thread Anton Vinogradov (JIRA)
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

2017-04-10 Thread Anton Vinogradov (JIRA)
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

2017-04-04 Thread Anton Vinogradov (JIRA)
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

2017-03-02 Thread Anton Vinogradov (JIRA)
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

2017-01-26 Thread Anton Vinogradov (JIRA)
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()

2016-12-13 Thread Anton Vinogradov (JIRA)
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

2016-11-17 Thread Anton Vinogradov (JIRA)
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

2016-11-15 Thread Anton Vinogradov (JIRA)
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.

2016-11-10 Thread Anton Vinogradov (JIRA)
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

2016-09-09 Thread Anton Vinogradov (JIRA)
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.

2016-08-29 Thread Anton Vinogradov (JIRA)
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

2016-07-11 Thread Anton Vinogradov (JIRA)
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.

2016-06-16 Thread Anton Vinogradov (JIRA)
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

2016-06-02 Thread Anton Vinogradov (JIRA)
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

2016-06-02 Thread Anton Vinogradov (JIRA)
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

2016-02-16 Thread Anton Vinogradov (JIRA)
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 Vinogradov 
Igniters,

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

2016-02-05 Thread Anton Vinogradov (JIRA)
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

2016-02-01 Thread Anton Vinogradov (JIRA)
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.

2015-12-28 Thread Anton Vinogradov (JIRA)
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

2015-12-08 Thread Anton Vinogradov (JIRA)
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)


  1   2   >