date:20180828



[ 
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595480#comment-16595480
 ] 

ASF GitHub Bot commented on IGNITE-1678:


GitHub user DmitriyGovorukhin opened a pull request:

https://github.com/apache/ignite/pull/4637

IGNITE-1678 IgniteAtomicSequence: make following reservations in advance



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-1678

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4637.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4637


commit ed9c2d27cdac5e65fe1689a4583678b9cbd1b3d1
Author: Dmitriy Govorukhin 
Date:   2018-08-26T07:35:01Z

IGNITE-1678 add percentage for atomic seq reservation in config + interfaces

commit cbfe5932a4b1230bb1aac8075004eea73479e7b2
Author: Dmitriy Govorukhin 
Date:   2018-08-26T07:53:47Z

IGNITE-1678 add percentage as parameter for atomic seq

commit 4a1d0c244fe015c7aaee7861857e84f05b985fc2
Author: Dmitriy Govorukhin 
Date:   2018-08-26T09:31:07Z

IGNITE-1678 add new test + small test updates

commit 839f43adf80a04e4a2778983560031592a20a89e
Author: Dmitriy Govorukhin 
Date:   2018-08-26T11:45:49Z

IGNITE-1678 first implementation (fully not working)

commit bd46569fc1e1f65709ac7a838f9b76d4df5c39d9
Author: Dmitriy Govorukhin 
Date:   2018-08-26T17:36:22Z

IGNITE-1678 minor test fix

commit 62bc2c94601d15a3eb3c939313ae88fbb81ca0fb
Author: Dmitriy Govorukhin 
Date:   2018-08-26T18:29:52Z

IGNITE-1678 fix config for chaining

commit 2d2627056ca288d95c68934286c0e80e66b4ca4e
Author: Dmitriy Govorukhin 
Date:   2018-08-26T18:48:07Z

IGNITE-1678 set default reservation percentage as 100

commit cf9a98f938f740c226b71ad73e734ac1834d97fe
Author: Dmitriy Govorukhin 
Date:   2018-08-27T10:44:39Z

IGNITE-1678 minor assert added + fix NPE

commit 0415064f4dbbfb3bea6d359467af1525af235b68
Author: Dmitriy Govorukhin 
Date:   2018-08-28T08:36:57Z

IGNITE-1678 rework reservation, add reservation context

commit 589297a406421a72254f949a1b0cb19cf14b9a26
Author: Dmitriy Govorukhin 
Date:   2018-08-28T09:42:21Z

IGNITE-1678 test refactoring

commit 4cdaf252de5526c19ba8672ac10819e9a983e1a1
Author: Dmitriy Govorukhin 
Date:   2018-08-28T16:50:00Z

Merge branch 'master' into ignite-1678

commit 7d1cf05c37867aab1a6496a97cf6ffc4727c8501
Author: Dmitriy Govorukhin 
Date:   2018-08-28T19:14:35Z

IGNITE-1678 add benchmarks




> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7783) Thin Client lib: PHP

2018-08-28 Thread Alexey Kosenchuk (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595476#comment-16595476
 ] 

Alexey Kosenchuk commented on IGNITE-7783:
--

Release on Packagist: [https://packagist.org/] is not possible at this moment.

As the current version of Packagist requires composer.json file to be at the 
root of a repository [https://github.com/composer/packagist/issues/472]

but Ignite PHP client is not in a dedicated repository.

 

> Thin Client lib: PHP
> 
>
> Key: IGNITE-7783
> URL: https://issues.apache.org/jira/browse/IGNITE-7783
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Alexey Kosenchuk
>Assignee: ekaterina.vergizova
>Priority: Major
> Fix For: 2.7
>
>
> Implement Thin (lightweight) Client lib in PHP programming language for 
> Ignite Binary Client Protocol.
> Functionality:
>  --
> Support all operations of the Ignite Binary Client Protocol 2.6:
>  [https://apacheignite.readme.io/v2.6/docs/binary-client-protocol]
> Except the following features which are not applicable to PHP client:
>  - Filter object for OP_QUERY_SCAN operation (OP_QUERY_SCAN operation itself 
> will be supported).
>  - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME operations.
>  - Registration of a new Ignite Enum type (reading and writing items of the 
> existing Ignite Enum types will be supported).
> Additionally support:
>  - SSL/TLS connection.
>  - "Failover re-connection algorithm": 
> https://issues.apache.org/jira/browse/IGNITE-7282
> Ignite Binary Client Protocol handshake versions: 1.2.0 only.
> Minimal required PHP version: 7.2
>  [http://php.net/supported-versions.php]
> PHP code-style standards: [https://www.php-fig.org/psr/]
> Synchronous API will be supported (asynchronous operations are not supported 
> by the standard PHP).
>  The API will not be thread-safe (threads are not available in the standard 
> PHP; pthreads extension is not available for the latest PHP version; 
> thread-safety is possible to support by an application).
> Examples:
>  -
> The set of examples will cover:
>  - cache get/create/destroy operations
>  - cache put/get operations
>  - SQL operations (create table/index, insert/select/drop)
>  - SQL Fields query and Scan query
>  - Authentication and TLS connection
>  - working with primitive and complex data types
> Tests:
>  --
> PHPUnit tests [https://phpunit.de|https://phpunit.de/] for all API methods 
> and all basic features. Including simple tests to start examples.
>  Tests will be integrated into the TeamCity with the help from the community.
> Docs:
>  --
> The provided docs will include:
>  - Auto-generated API spec using Doxygen: 
> [http://www.doxygen.org|http://www.doxygen.org/]
>  - Instruction how to generate the API spec.
>  - Instruction how to release PHP library on Packagist: 
> [https://packagist.org/]
>  - Readme for user with info how to install and use the client.
>  - Simple instruction how to setup/run examples.
>  - Simple instruction how to setup/run tests.
> All docs will be provided separately from the source code and will not be 
> merged to the target repository. Before the release all instructions and 
> readme will be moved to the readme.io with the help from the community.
> Release:
>  
> Location of the client:
>  /modules/platforms/php
> Will be released as PHP library on Packagist: [https://packagist.org/] by the 
> community.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-7783) Thin Client lib: PHP

2018-08-28 Thread Alexey Kosenchuk (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595458#comment-16595458
 ] 

Alexey Kosenchuk commented on IGNITE-7783:
--

Ignite Binary Client Protocol handshake version is changed in the scope to 
1.2.0. As it's the version to be released in Ignite 2.7.

> Thin Client lib: PHP
> 
>
> Key: IGNITE-7783
> URL: https://issues.apache.org/jira/browse/IGNITE-7783
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Alexey Kosenchuk
>Assignee: ekaterina.vergizova
>Priority: Major
> Fix For: 2.7
>
>
> Implement Thin (lightweight) Client lib in PHP programming language for 
> Ignite Binary Client Protocol.
> Functionality:
>  --
> Support all operations of the Ignite Binary Client Protocol 2.6:
>  [https://apacheignite.readme.io/v2.6/docs/binary-client-protocol]
> Except the following features which are not applicable to PHP client:
>  - Filter object for OP_QUERY_SCAN operation (OP_QUERY_SCAN operation itself 
> will be supported).
>  - OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME operations.
>  - Registration of a new Ignite Enum type (reading and writing items of the 
> existing Ignite Enum types will be supported).
> Additionally support:
>  - SSL/TLS connection.
>  - "Failover re-connection algorithm": 
> https://issues.apache.org/jira/browse/IGNITE-7282
> Ignite Binary Client Protocol handshake versions: 1.2.0 only.
> Minimal required PHP version: 7.2
>  [http://php.net/supported-versions.php]
> PHP code-style standards: [https://www.php-fig.org/psr/]
> Synchronous API will be supported (asynchronous operations are not supported 
> by the standard PHP).
>  The API will not be thread-safe (threads are not available in the standard 
> PHP; pthreads extension is not available for the latest PHP version; 
> thread-safety is possible to support by an application).
> Examples:
>  -
> The set of examples will cover:
>  - cache get/create/destroy operations
>  - cache put/get operations
>  - SQL operations (create table/index, insert/select/drop)
>  - SQL Fields query and Scan query
>  - Authentication and TLS connection
>  - working with primitive and complex data types
> Tests:
>  --
> PHPUnit tests [https://phpunit.de|https://phpunit.de/] for all API methods 
> and all basic features. Including simple tests to start examples.
>  Tests will be integrated into the TeamCity with the help from the community.
> Docs:
>  --
> The provided docs will include:
>  - Auto-generated API spec using Doxygen: 
> [http://www.doxygen.org|http://www.doxygen.org/]
>  - Instruction how to generate the API spec.
>  - Instruction how to release PHP library on Packagist: 
> [https://packagist.org/]
>  - Readme for user with info how to install and use the client.
>  - Simple instruction how to setup/run examples.
>  - Simple instruction how to setup/run tests.
> All docs will be provided separately from the source code and will not be 
> merged to the target repository. Before the release all instructions and 
> readme will be moved to the readme.io with the help from the community.
> Release:
>  
> Location of the client:
>  /modules/platforms/php
> Will be released as PHP library on Packagist: [https://packagist.org/] by the 
> community.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7783) Thin Client lib: PHP

2018-08-28 Thread Alexey Kosenchuk (JIRA)

[
https://issues.apache.org/jira/browse/IGNITE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alexey Kosenchuk updated IGNITE-7783:
-
Description:
Implement Thin (lightweight) Client lib in PHP programming language for Ignite
Binary Client Protocol.

Functionality:
--

Support all operations of the Ignite Binary Client Protocol 2.6:
[https://apacheignite.readme.io/v2.6/docs/binary-client-protocol]

Except the following features which are not applicable to PHP client:
- Filter object for OP_QUERY_SCAN operation (OP_QUERY_SCAN operation itself
will be supported).
- OP_REGISTER_BINARY_TYPE_NAME and OP_GET_BINARY_TYPE_NAME operations.
- Registration of a new Ignite Enum type (reading and writing items of the
existing Ignite Enum types will be supported).

Additionally support:
- SSL/TLS connection.
- "Failover re-connection algorithm":
https://issues.apache.org/jira/browse/IGNITE-7282

Ignite Binary Client Protocol handshake versions: 1.2.0 only.

Minimal required PHP version: 7.2
[http://php.net/supported-versions.php]

PHP code-style standards: [https://www.php-fig.org/psr/]

Synchronous API will be supported (asynchronous operations are not supported by
the standard PHP).
The API will not be thread-safe (threads are not available in the standard
PHP; pthreads extension is not available for the latest PHP version;
thread-safety is possible to support by an application).

Examples:
-

The set of examples will cover:
- cache get/create/destroy operations
- cache put/get operations
- SQL operations (create table/index, insert/select/drop)
- SQL Fields query and Scan query
- Authentication and TLS connection
- working with primitive and complex data types

Tests:
--

PHPUnit tests [https://phpunit.de|https://phpunit.de/] for all API methods and
all basic features. Including simple tests to start examples.
Tests will be integrated into the TeamCity with the help from the community.

Docs:
--

The provided docs will include:
- Auto-generated API spec using Doxygen:
[http://www.doxygen.org|http://www.doxygen.org/]
- Instruction how to generate the API spec.
- Instruction how to release PHP library on Packagist: [https://packagist.org/]
- Readme for user with info how to install and use the client.
- Simple instruction how to setup/run examples.
- Simple instruction how to setup/run tests.

All docs will be provided separately from the source code and will not be
merged to the target repository. Before the release all instructions and readme
will be moved to the readme.io with the help from the community.

Release:

Location of the client:
/modules/platforms/php

Will be released as PHP library on Packagist: [https://packagist.org/] by the
community.

was:
Implement Thin (lightweight) Client lib in PHP programming language for Ignite
Binary Client Protocol.

Functionality:
--

Support all operations of the Ignite Binary Client Protocol 2.6:
[https://apacheignite.readme.io/v2.6/docs/binary-client-protocol]

Additionally support:
- SSL/TLS connection.
- "Failover re-connection algorithm":
https://issues.apache.org/jira/browse/IGNITE-7282

Ignite Binary Client Protocol handshake versions: 1.1.0 only.

Minimal required PHP version: 7.2
[http://php.net/supported-versions.php]

PHP code-style standards: [https://www.php-fig.org/psr/]

Synchronous API will be supported (asynchronous operations are not supported by
the standard PHP).
The API will not be thread-safe (threads are not available in the standard PHP;
pthreads extension is not available for the latest PHP version; thread-safety
is possible to support by an application).

Examples:
-

Tests:
--

Docs:
--

[jira] [Updated] (IGNITE-9361) Remove IgniteInternalCache.isMongo*Cache() and other such stuff



 [ 
https://issues.apache.org/jira/browse/IGNITE-9361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-9361:

Ignite Flags:   (was: Docs Required)

> Remove IgniteInternalCache.isMongo*Cache() and other such stuff
> ---
>
> Key: IGNITE-9361
> URL: https://issues.apache.org/jira/browse/IGNITE-9361
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Fix For: 2.7
>
>
> Nobody needs it for a long time already. It's all internal API, we can drop 
> it outright.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9360) Destroy SnapTreeMap and related classes



 [ 
https://issues.apache.org/jira/browse/IGNITE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-9360:

Fix Version/s: 2.7

> Destroy SnapTreeMap and related classes
> ---
>
> Key: IGNITE-9360
> URL: https://issues.apache.org/jira/browse/IGNITE-9360
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Fix For: 2.7
>
>
> It's not used anywhere and noone wants it, and it's a solid block of code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9361) Remove IgniteInternalCache.isMongo*Cache() and other such stuff



 [ 
https://issues.apache.org/jira/browse/IGNITE-9361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-9361:

Fix Version/s: 2.7

> Remove IgniteInternalCache.isMongo*Cache() and other such stuff
> ---
>
> Key: IGNITE-9361
> URL: https://issues.apache.org/jira/browse/IGNITE-9361
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Fix For: 2.7
>
>
> Nobody needs it for a long time already. It's all internal API, we can drop 
> it outright.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9360) Destroy SnapTreeMap and related classes



 [ 
https://issues.apache.org/jira/browse/IGNITE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-9360:

Ignite Flags:   (was: Docs Required)

> Destroy SnapTreeMap and related classes
> ---
>
> Key: IGNITE-9360
> URL: https://issues.apache.org/jira/browse/IGNITE-9360
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Fix For: 2.7
>
>
> It's not used anywhere and noone wants it, and it's a solid block of code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9398) Reduce time on processing CustomDiscoveryMessage by discovery message worker



[ 
https://issues.apache.org/jira/browse/IGNITE-9398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595183#comment-16595183
 ] 

ASF GitHub Bot commented on IGNITE-9398:


GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/4636

IGNITE-9398 Async notification to discovery spi listener



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9398

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4636.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4636






> Reduce time on processing CustomDiscoveryMessage by discovery message worker
> 
>
> Key: IGNITE-9398
> URL: https://issues.apache.org/jira/browse/IGNITE-9398
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> Processing discovery CustomMessage may take significant values of time 
> (0.5-0.7 seconds) before sending to next node in the topology. This 
> significantly accumulates the total time of PME if topology has multiple 
> nodes.
> Let X = time of processing discovery message by discovery-msg-worker on each 
> node before sending to next node. 
> Let N = number of nodes in the topology.
> Then the minimal total time of exchange will be:
> T = N * X
> We shouldn't make heavy actions when process discovery message. Best solution 
> will be separated thread that will do it, while discovery-msg-worker will 
> just pass a message to that thread and send a message immediately to another 
> node in topology.
> This affects both TcpDiscoverySpi and ZkDiscoverySpi.
> {noformat}
> [11:59:33,134][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Enqueued 
> message type = TcpDiscoveryCustomEventMessage id = 
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 0
> [11:59:33,537][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
>  Received activate request with BaselineTopology[id=0]
> [11:59:33,549][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
>  Started state transition: true
> [11:59:33,752][INFO][exchange-worker-#62][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1], crd=true, 
> evt=DISCOVERY_CUSTOM_EVT, evtNode=a38dfe31-dcfd-430b-acb3-5a531db4197e, 
> customEvt=ChangeGlobalStateMessage 
> [id=cea542b6561-47395de6-c204-4576-a0a3-99ec53d41ac3, 
> reqId=5b651439-7a6a-43fc-9cb0-d646c3380576, 
> initiatingNodeId=a38dfe31-dcfd-430b-acb3-5a531db4197e, activate=true, 
> baselineTopology=BaselineTopology [id=0, branchingHash=-69412111965, 
> branchingType='New BaselineTopology', baselineNodes=[node42, node43, node44, 
> node45, node46, node47, node48, node49, node50, node51, node52, node53, 
> node54, node55, node56, node57, node58, node59, node1, node4, node5, node2, 
> node3, node8, node9, node6, node7, node60, node61, node62, node63, node64, 
> node65, node66, node67, node68, node69, node70, node71, node72, node73, 
> node74, node75, node76, node77, node78, node79, node80, node81, node82, 
> node83, node84, node85, node86, node87, node88, node89, node90, node91, 
> node92, node93, node94, node95, node96, node97, node10, node98, node11, 
> node99, node12, node13, node14, node15, node16, node100, node17, node18, 
> node19, node108, node107, node106, node105, node104, node103, node102, 
> node101, node109, node20, node21, node22, node23, node24, node25, node26, 
> node27, node28, node29, node110, node30, node31, node32, node33, node34, 
> node35, node36, node37, node38, node39, node40, node41]], 
> forceChangeBaselineTopology=false, timestamp=1535101173015], allowMerge=false]
> [11:59:33,753][INFO][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
> Start activation process [nodeId=1906b9c3-73f4-4c30-85cc-cf6b99c3bab9, 
> client=false, topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1]]
> [11:59:33,756][INFO][exchange-worker-#62][FilePageStoreManager] Resolved page 
> store work directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
> write ahead log work directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
> write ahead log archive directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/archive/node1
>

[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures

2018-08-28 Thread Amir Akhmedov (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595159#comment-16595159
 ] 

Amir Akhmedov commented on IGNITE-640:
--

[~avinogradov],

Work in progress, will have something to share by next week

> Implement IgniteMultimap data structures
> 
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
>  Issue Type: Sub-task
>  Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.7
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data 
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to 
> {{java.util.Map}} class in JDK, but support the semantics of multiple values 
> per key, similar to [Guava 
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>  
> However, unlike in Guava, our multi-map should work with Lists, not 
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range, 
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to 
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
>  and its implementation, 
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value 
> under a separate key in an Ignite cache. For example, let's say that we have 
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should 
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc. 
> This means that we need to wrap user key into our own, internal key, which 
> will also have {{index}} field. 
> Also note that we need to collocate all the values for the same key on the 
> same node, which means that we need to define user key K as the affinity key, 
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a 
> specific index to a key and do a cache lookup. Look ups for all values for a 
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch 
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of 
> keys, and maximum number of values for a key. The maximum number of keys 
> should be controlled by Ignite standard eviction policy. The maximum number 
> of values for a key should be controlled by the implementation of the 
> multi-map. Either eviction parameter should be configurable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9401) Newly added testRollbackOnTopologyLockPessimistic has a race which leads to suite hang.



[ 
https://issues.apache.org/jira/browse/IGNITE-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595157#comment-16595157
 ] 

ASF GitHub Bot commented on IGNITE-9401:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4633


> Newly added testRollbackOnTopologyLockPessimistic has a  race which leads to 
> suite hang.
> 
>
> Key: IGNITE-9401
> URL: https://issues.apache.org/jira/browse/IGNITE-9401
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9149) Get rid of logging remaining supplier nodes rebalance time



[ 
https://issues.apache.org/jira/browse/IGNITE-9149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595130#comment-16595130
 ] 

ASF GitHub Bot commented on IGNITE-9149:


GitHub user ololo3000 opened a pull request:

https://github.com/apache/ignite/pull/4635

IGNITE-9149 Get rid of logging remaining supplier nodes rebalance time



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ololo3000/ignite IGNITE-9149

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4635.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4635


commit f3320b678b9f1be17bff433b32d8cc2cf26d1ae2
Author: ololo3000 
Date:   2018-08-28T14:24:18Z

IGNITE-9149 Get rid of logging remaining supplier nodes rebalance time




> Get rid of logging remaining supplier nodes rebalance time
> --
>
> Key: IGNITE-9149
> URL: https://issues.apache.org/jira/browse/IGNITE-9149
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: rebalance
>
> Logging rebalance execution time in section of each supplier node have no 
> sence and provides no helpfull info for analyzing logs. It also 
> overcomplicates {{GridDhtPartitionDemander}}.
> I'm suggesting remove it by simplifying {{Map IgniteDhtDemandedPartitionsMap>>}} to {{Map IgniteDhtDemandedPartitionsMap>}}.
> {code:java}
> /** Remaining. T2: startTime, partitions */
> private final Map> remaining = 
> new HashMap<>();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-9149) Get rid of logging remaining supplier nodes rebalance time

2018-08-28 Thread PetrovMikhail (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

PetrovMikhail reassigned IGNITE-9149:
-

Assignee: PetrovMikhail

> Get rid of logging remaining supplier nodes rebalance time
> --
>
> Key: IGNITE-9149
> URL: https://issues.apache.org/jira/browse/IGNITE-9149
> Project: Ignite
>  Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>  Labels: rebalance
>
> Logging rebalance execution time in section of each supplier node have no 
> sence and provides no helpfull info for analyzing logs. It also 
> overcomplicates {{GridDhtPartitionDemander}}.
> I'm suggesting remove it by simplifying {{Map IgniteDhtDemandedPartitionsMap>>}} to {{Map IgniteDhtDemandedPartitionsMap>}}.
> {code:java}
> /** Remaining. T2: startTime, partitions */
> private final Map> remaining = 
> new HashMap<>();
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8485) TDE - Phase-1



[ 
https://issues.apache.org/jira/browse/IGNITE-8485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595122#comment-16595122
 ] 

ASF GitHub Bot commented on IGNITE-8485:


GitHub user nizhikov opened a pull request:

https://github.com/apache/ignite/pull/4634

IGNITE-8485: force encrypted mode for all caches



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nizhikov/ignite IGNITE-8485-forced

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4634.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4634


commit 241eeab3dea6dae3652d106e7f835be0f081f89a
Author: Nikolay Izhikov 
Date:   2018-06-25T10:22:59Z

IGNITE-8485: TDE Implementation

commit 763ebc413a6b9d395a71ac7024f028228f4dd710
Author: Nikolay Izhikov 
Date:   2018-06-25T19:46:41Z

Merge branch 'master' into IGNITE-8485

commit 410c7be5e0ebab67b0b74331559ed4f9548d2601
Author: Nikolay Izhikov 
Date:   2018-06-25T20:04:01Z

IGNITE-8485: Code review fixes.

commit 43b9cde1fc373cfecf7ebcf19b72d87e2e8653f4
Author: Nikolay Izhikov 
Date:   2018-06-26T08:33:59Z

IGNITE-8485: Code review fixes.

commit efac7b2b46729a73421b7738fea47171a71c2440
Author: Nikolay Izhikov 
Date:   2018-06-26T08:44:54Z

IGNITE-8485: Code review fixes.

commit 03855222fdab19c1173b9d2931d7b1db463f066e
Author: Nikolay Izhikov 
Date:   2018-06-26T08:45:39Z

IGNITE-8485: Code review fixes.

commit 02f7cffbee852345ed690e67100bbd701d03c429
Author: Nikolay Izhikov 
Date:   2018-06-26T08:58:07Z

IGNITE-8485: Code review fixes.

commit 6a884eaf9e3dfce7f177a59e591dd430b609a303
Author: Nikolay Izhikov 
Date:   2018-06-26T09:13:19Z

IGNITE-8485: Code review fixes.

commit 53a7eaaeb78190f69d2ecd8b3d775e7efc3dd65d
Author: Nikolay Izhikov 
Date:   2018-06-26T10:57:34Z

Merge branch 'master' into IGNITE-8485

commit f1581e53a6f6bcd066c9c2820570d11f586be516
Author: Nikolay Izhikov 
Date:   2018-06-26T11:03:28Z

IGNITE-8485: Code review fixes.

commit 4e4142eb28f3346e35a98d08ce65641c24834c4d
Author: Nikolay Izhikov 
Date:   2018-06-26T14:17:03Z

Merge branch 'master' into IGNITE-8485

commit 284177c8447f8baabab8d6553132c8c9da662359
Author: Nikolay Izhikov 
Date:   2018-06-26T14:28:45Z

IGNITE-8485: Code review fixes.

commit 9b222135db1a73d40c8973711581fe0768ad0528
Author: Nikolay Izhikov 
Date:   2018-06-26T14:34:30Z

IGNITE-8485: Code review fixes.

commit 5d237570ec02f53f4aadcc8f189e064bea45faa2
Author: Nikolay Izhikov 
Date:   2018-06-26T14:54:18Z

IGNITE-8485: Code review fixes.

commit 5894c498fa2516097256b0e1aa0ed67776dbab31
Author: Nikolay Izhikov 
Date:   2018-06-26T16:04:27Z

IGNITE-8485: Fix flaky test. Add encryption supported check.

commit 049cd0a554785511b2cadb0f90a8a4f60440dc93
Author: Nikolay Izhikov 
Date:   2018-06-26T16:30:34Z

IGNITE-8485: Code review fixes.

commit 4d4d0e2686b1f6c3894df90256493a8ea7d2b852
Author: Nikolay Izhikov 
Date:   2018-06-27T15:46:52Z

Merge branch 'master' into IGNITE-8485

commit 6af7e8be9f069ec5d6f1e9ee3457f67bc81f2763
Author: Nikolay Izhikov 
Date:   2018-06-28T15:43:49Z

IGNITE-8485: Code review fixes.

commit 6b6fb4d8eedc77d1be1490a5d45e4e2024ef1354
Author: Nikolay Izhikov 
Date:   2018-06-29T09:28:01Z

IGNITE-8485: Code review(In progress). Compilation failed.

commit fc6d0256b9b11dce822365b03798334f4a28f0c1
Author: Nikolay Izhikov 
Date:   2018-06-29T09:33:11Z

IGNITE-8485: revert unnecessary changes

commit af86e66bd4bf61e15e65cbc8ead95b0581e6fd2f
Author: Nikolay Izhikov 
Date:   2018-06-29T10:55:26Z

IGNITE-8485: Refactor encryption of DataRecord

commit 5127a6c03ef3aacbc179323c4e7737a045c481df
Author: Nikolay Izhikov 
Date:   2018-06-29T10:57:38Z

IGNITE-8485: Compilation fix

commit cde18b0127f8237c37bdace85e2659f826d6c75d
Author: Nikolay Izhikov 
Date:   2018-06-29T11:00:44Z

IGNITE-8485: minor fix

commit a20669026981141e70ab54956facc394536f6b2c
Author: Nikolay Izhikov 
Date:   2018-06-29T11:12:33Z

IGNITE-8485: minor fix

commit 4849f51067f040c514980d0734173c5ca98f13d4
Author: Nikolay Izhikov 
Date:   2018-06-29T15:04:33Z

IGNITE-8485: Test fixed.

commit bd312865091f6ed40e609b2e508754a92743c434
Author: Nikolay Izhikov 
Date:   2018-06-29T15:20:52Z

IGNITE-8485: minor fix.

commit 9cab4a1ccb1ef3b2b93f1da3f559e464a4ed157d
Author: Nikolay Izhikov 
Date:   2018-06-29T15:23:03Z

Undo edit

commit 9308e0f7e3f0ec07f126ea2d601ac625d0a1ef16
Author: Nikolay Izhikov 
Date:   2018-06-29T15:29:39Z

Merge branch 'master' into IGNITE-8485

commit eefa124153f6ad7529ef4991e7d391c09cc278de
Author: Nikolay Izhikov 
Date:   2018-06-29T16:13:40Z

IGNITE-8485: Test fix

commit 6acad7c10cd3a6b46382abd1e0dcef52eaded378
Author: Nikolay Izhikov 
Date:

[jira] [Commented] (IGNITE-9401) Newly added testRollbackOnTopologyLockPessimistic has a race which leads to suite hang.



[ 
https://issues.apache.org/jira/browse/IGNITE-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595121#comment-16595121
 ] 

ASF GitHub Bot commented on IGNITE-9401:


GitHub user ascherbakoff opened a pull request:

https://github.com/apache/ignite/pull/4633

IGNITE-9401 Race fix.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9401

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4633.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4633






> Newly added testRollbackOnTopologyLockPessimistic has a  race which leads to 
> suite hang.
> 
>
> Key: IGNITE-9401
> URL: https://issues.apache.org/jira/browse/IGNITE-9401
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9398) Reduce time on processing CustomDiscoveryMessage by discovery message worker

2018-08-28 Thread Pavel Kovalenko (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kovalenko updated IGNITE-9398:

Ignite Flags:   (was: Docs Required)

> Reduce time on processing CustomDiscoveryMessage by discovery message worker
> 
>
> Key: IGNITE-9398
> URL: https://issues.apache.org/jira/browse/IGNITE-9398
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> Processing discovery CustomMessage may take significant values of time 
> (0.5-0.7 seconds) before sending to next node in the topology. This 
> significantly accumulates the total time of PME if topology has multiple 
> nodes.
> Let X = time of processing discovery message by discovery-msg-worker on each 
> node before sending to next node. 
> Let N = number of nodes in the topology.
> Then the minimal total time of exchange will be:
> T = N * X
> We shouldn't make heavy actions when process discovery message. Best solution 
> will be separated thread that will do it, while discovery-msg-worker will 
> just pass a message to that thread and send a message immediately to another 
> node in topology.
> This affects both TcpDiscoverySpi and ZkDiscoverySpi.
> {noformat}
> [11:59:33,134][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Enqueued 
> message type = TcpDiscoveryCustomEventMessage id = 
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 0
> [11:59:33,537][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
>  Received activate request with BaselineTopology[id=0]
> [11:59:33,549][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
>  Started state transition: true
> [11:59:33,752][INFO][exchange-worker-#62][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1], crd=true, 
> evt=DISCOVERY_CUSTOM_EVT, evtNode=a38dfe31-dcfd-430b-acb3-5a531db4197e, 
> customEvt=ChangeGlobalStateMessage 
> [id=cea542b6561-47395de6-c204-4576-a0a3-99ec53d41ac3, 
> reqId=5b651439-7a6a-43fc-9cb0-d646c3380576, 
> initiatingNodeId=a38dfe31-dcfd-430b-acb3-5a531db4197e, activate=true, 
> baselineTopology=BaselineTopology [id=0, branchingHash=-69412111965, 
> branchingType='New BaselineTopology', baselineNodes=[node42, node43, node44, 
> node45, node46, node47, node48, node49, node50, node51, node52, node53, 
> node54, node55, node56, node57, node58, node59, node1, node4, node5, node2, 
> node3, node8, node9, node6, node7, node60, node61, node62, node63, node64, 
> node65, node66, node67, node68, node69, node70, node71, node72, node73, 
> node74, node75, node76, node77, node78, node79, node80, node81, node82, 
> node83, node84, node85, node86, node87, node88, node89, node90, node91, 
> node92, node93, node94, node95, node96, node97, node10, node98, node11, 
> node99, node12, node13, node14, node15, node16, node100, node17, node18, 
> node19, node108, node107, node106, node105, node104, node103, node102, 
> node101, node109, node20, node21, node22, node23, node24, node25, node26, 
> node27, node28, node29, node110, node30, node31, node32, node33, node34, 
> node35, node36, node37, node38, node39, node40, node41]], 
> forceChangeBaselineTopology=false, timestamp=1535101173015], allowMerge=false]
> [11:59:33,753][INFO][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
> Start activation process [nodeId=1906b9c3-73f4-4c30-85cc-cf6b99c3bab9, 
> client=false, topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1]]
> [11:59:33,756][INFO][exchange-worker-#62][FilePageStoreManager] Resolved page 
> store work directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
> write ahead log work directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
> write ahead log archive directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/archive/node1
> [11:59:33,757][INFO][exchange-worker-#62][FileWriteAheadLogManager] Started 
> write-ahead log manager [mode=LOG_ONLY]
> [11:59:33,763][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Processed 
> message type = TcpDiscoveryCustomEventMessage id = 
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 629
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9402) IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALWritingFail2 because of LogOnly mode

2018-08-28 Thread Anton Kalashnikov (JIRA)

Anton Kalashnikov created IGNITE-9402:
-

 Summary: 
IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALWritingFail2 because of 
LogOnly mode
 Key: IGNITE-9402
 URL: https://issues.apache.org/jira/browse/IGNITE-9402
 Project: Ignite
  Issue Type: Test
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


IgnitePdsDiskErrorsRecoveringTest.testRecoveringOnWALWritingFail2 failed 
because it can lost last WAL data which have not flushed yet.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9401) Newly added testRollbackOnTopologyLockPessimistic has a race which leads to suite hang.

2018-08-28 Thread Alexei Scherbakov (JIRA)

Alexei Scherbakov created IGNITE-9401:
-

 Summary: Newly added testRollbackOnTopologyLockPessimistic has a  
race which leads to suite hang.
 Key: IGNITE-9401
 URL: https://issues.apache.org/jira/browse/IGNITE-9401
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2.7






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9389) Concurrent Cache#close and put/get operations lead to a deadlock



 [ 
https://issues.apache.org/jira/browse/IGNITE-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Goncharuk updated IGNITE-9389:
-
Fix Version/s: 2.7

> Concurrent Cache#close and put/get operations lead to a deadlock
> 
>
> Key: IGNITE-9389
> URL: https://issues.apache.org/jira/browse/IGNITE-9389
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.7
>
> Attachments: CacheConcurrentUseAndCloseTest.java
>
>
> When cache is closed on a client node, while it is being used concurrently in 
> other threads, deadlock may occur.
> Test case, reproducing the problem is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9400) TC bot: add progress bar to history page

Ilya Lantukh created IGNITE-9400:


 Summary: TC bot: add progress bar to history page
 Key: IGNITE-9400
 URL: https://issues.apache.org/jira/browse/IGNITE-9400
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Lantukh


History page (like */all.html?branch=master*) takes significant amount of time 
to load, and it would be helpful to replace spinning wheel with progress bar.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9389) Concurrent Cache#close and put/get operations lead to a deadlock



[ 
https://issues.apache.org/jira/browse/IGNITE-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595091#comment-16595091
 ] 

ASF GitHub Bot commented on IGNITE-9389:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4626


> Concurrent Cache#close and put/get operations lead to a deadlock
> 
>
> Key: IGNITE-9389
> URL: https://issues.apache.org/jira/browse/IGNITE-9389
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Attachments: CacheConcurrentUseAndCloseTest.java
>
>
> When cache is closed on a client node, while it is being used concurrently in 
> other threads, deadlock may occur.
> Test case, reproducing the problem is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.



 [ 
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8841:
-
Description: 
At the moment read transactions that don't acquire topology lock will be 
forcibly rolled back on topology change as read tx can be in fly while topology 
being change.
 This is done to prevent having active transaction with stale snapshots on new 
topology in cases of TX coordinator or Near node were lost.

 

It would be nice to remap it somehow until they locked a topology or at least 
throw some meaningful exception to user.
 For example, it is possible to obtain a new "write" mvcc version from the new 
coordinator and use this version for all further writes while using "old" 
version for reads. In this case we need to change visibility rules a little: 
"old" version should see "own" updates made by "new" "write" version.

  was:
At the moment read transactions that don't acquire topology lock will be 
forcibly rolled back on topology change as read tx can be in fly while topology 
being change.
This is done to prevent having active transaction with stale snapshots on new 
topology in cases of TX coordinator or Near node were lost.

 

It would be nice to remap it somehow until they locked a topology.
 For example, it is possible to obtain a new "write" mvcc version from the new 
coordinator and use this version for all further writes while using "old" 
version for reads. In this case we need to change visibility rules a little: 
"old" version should see "own" updates made by "new" "write" version.


> MVCC TX: Read transactions remap when coordinator fails.
> 
>
> Key: IGNITE-8841
> URL: https://issues.apache.org/jira/browse/IGNITE-8841
> Project: Ignite
>  Issue Type: Improvement
>  Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
>  Labels: failover
>
> At the moment read transactions that don't acquire topology lock will be 
> forcibly rolled back on topology change as read tx can be in fly while 
> topology being change.
>  This is done to prevent having active transaction with stale snapshots on 
> new topology in cases of TX coordinator or Near node were lost.
>  
> It would be nice to remap it somehow until they locked a topology or at least 
> throw some meaningful exception to user.
>  For example, it is possible to obtain a new "write" mvcc version from the 
> new coordinator and use this version for all further writes while using "old" 
> version for reads. In this case we need to change visibility rules a little: 
> "old" version should see "own" updates made by "new" "write" version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9399) Document new WAL history size configuration parameter

Alexey Goncharuk created IGNITE-9399:


 Summary: Document new WAL history size configuration parameter
 Key: IGNITE-9399
 URL: https://issues.apache.org/jira/browse/IGNITE-9399
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Alexey Goncharuk






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.



 [ 
https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8841:
-
Description: 
At the moment read transactions that don't acquire topology lock will be 
forcibly rolled back on topology change as read tx can be in fly while topology 
being change.
This is done to prevent having active transaction with stale snapshots on new 
topology in cases of TX coordinator or Near node were lost.

 

It would be nice to remap it somehow until they locked a topology.
 For example, it is possible to obtain a new "write" mvcc version from the new 
coordinator and use this version for all further writes while using "old" 
version for reads. In this case we need to change visibility rules a little: 
"old" version should see "own" updates made by "new" "write" version.

  was:At the moment all read transactions are forcibly rolled back during 
coordinator change. It would be nice to remap it somehow until they locked a 
topology. For example, it is possible to obtain a new "write" mvcc version from 
the new coordinator and use this version for all further writes while using 
"old" version for reads. In this case we need to change visibility rules a 
little: "old" version should see "own" updates made by "new" "write" version.


> MVCC TX: Read transactions remap when coordinator fails.
> 
>
> Key: IGNITE-8841
> URL: https://issues.apache.org/jira/browse/IGNITE-8841
> Project: Ignite
>  Issue Type: Improvement
>  Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
>  Labels: failover
>
> At the moment read transactions that don't acquire topology lock will be 
> forcibly rolled back on topology change as read tx can be in fly while 
> topology being change.
> This is done to prevent having active transaction with stale snapshots on new 
> topology in cases of TX coordinator or Near node were lost.
>  
> It would be nice to remap it somehow until they locked a topology.
>  For example, it is possible to obtain a new "write" mvcc version from the 
> new coordinator and use this version for all further writes while using "old" 
> version for reads. In this case we need to change visibility rules a little: 
> "old" version should see "own" updates made by "new" "write" version.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-6552) The ability to set WAL history size in bytes



[ 
https://issues.apache.org/jira/browse/IGNITE-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595063#comment-16595063
 ] 

Alexey Goncharuk commented on IGNITE-6552:
--

[~akalashnikov],

New failed tests:
1) IgniteWalIteratorSwitchSegmentTest#test fails with NPE
2) DataStorageConfigurationParityTest.TestStorageConfiguration fails in .NET 
because new configuration parameters are not added to .NET. Either add new 
parameters to .NET (should be relatively simple) or mute the test (there are 
similar mutes already) and create a separate ticket.w

> The ability to set WAL history size in bytes
> 
>
> Key: IGNITE-6552
> URL: https://issues.apache.org/jira/browse/IGNITE-6552
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Vladislav Pyatkov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.7
>
>
> We can set size of WAL history in number of checkpoints.
> {code}
> org.apache.ignite.configuration.PersistentStoreConfiguration#setWalHistorySize
> {code}
> But it is not convenient fro end user. Nobody to say how many checkpoint to 
> occur over several minutes.
> I think, it will be better if we will have ability to set WAL history size in 
> bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-6552) The ability to set WAL history size in bytes



[ 
https://issues.apache.org/jira/browse/IGNITE-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595063#comment-16595063
 ] 

Alexey Goncharuk edited comment on IGNITE-6552 at 8/28/18 2:39 PM:
---

[~akalashnikov],

New failed tests:
1) IgniteWalIteratorSwitchSegmentTest#test fails with NPE
2) DataStorageConfigurationParityTest.TestStorageConfiguration fails in .NET 
because new configuration parameters are not added to .NET. Either add new 
parameters to .NET (should be relatively simple) or mute the test (there are 
similar mutes already) and create a separate ticket.


was (Author: agoncharuk):
[~akalashnikov],

New failed tests:
1) IgniteWalIteratorSwitchSegmentTest#test fails with NPE
2) DataStorageConfigurationParityTest.TestStorageConfiguration fails in .NET 
because new configuration parameters are not added to .NET. Either add new 
parameters to .NET (should be relatively simple) or mute the test (there are 
similar mutes already) and create a separate ticket.w

> The ability to set WAL history size in bytes
> 
>
> Key: IGNITE-6552
> URL: https://issues.apache.org/jira/browse/IGNITE-6552
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Vladislav Pyatkov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.7
>
>
> We can set size of WAL history in number of checkpoints.
> {code}
> org.apache.ignite.configuration.PersistentStoreConfiguration#setWalHistorySize
> {code}
> But it is not convenient fro end user. Nobody to say how many checkpoint to 
> occur over several minutes.
> I think, it will be better if we will have ability to set WAL history size in 
> bytes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9398) Reduce time on processing CustomDiscoveryMessage by discovery message worker

2018-08-28 Thread Pavel Kovalenko (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Kovalenko updated IGNITE-9398:

Summary: Reduce time on processing CustomDiscoveryMessage by discovery 
message worker  (was: Reduce time on processing CustomDiscoveryMessage by 
discovery worker)

> Reduce time on processing CustomDiscoveryMessage by discovery message worker
> 
>
> Key: IGNITE-9398
> URL: https://issues.apache.org/jira/browse/IGNITE-9398
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4, 2.5, 2.6
>Reporter: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> Processing discovery CustomMessage may take significant values of time 
> (0.5-0.7 seconds) before sending to next node in the topology. This 
> significantly accumulates the total time of PME if topology has multiple 
> nodes.
> Let X = time of processing discovery message by discovery-msg-worker on each 
> node before sending to next node. 
> Let N = number of nodes in the topology.
> Then the minimal total time of exchange will be:
> T = N * X
> We shouldn't make heavy actions when process discovery message. Best solution 
> will be separated thread that will do it, while discovery-msg-worker will 
> just pass a message to that thread and send a message immediately to another 
> node in topology.
> This affects both TcpDiscoverySpi and ZkDiscoverySpi.
> {noformat}
> [11:59:33,134][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Enqueued 
> message type = TcpDiscoveryCustomEventMessage id = 
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 0
> [11:59:33,537][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
>  Received activate request with BaselineTopology[id=0]
> [11:59:33,549][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
>  Started state transition: true
> [11:59:33,752][INFO][exchange-worker-#62][time] Started exchange init 
> [topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1], crd=true, 
> evt=DISCOVERY_CUSTOM_EVT, evtNode=a38dfe31-dcfd-430b-acb3-5a531db4197e, 
> customEvt=ChangeGlobalStateMessage 
> [id=cea542b6561-47395de6-c204-4576-a0a3-99ec53d41ac3, 
> reqId=5b651439-7a6a-43fc-9cb0-d646c3380576, 
> initiatingNodeId=a38dfe31-dcfd-430b-acb3-5a531db4197e, activate=true, 
> baselineTopology=BaselineTopology [id=0, branchingHash=-69412111965, 
> branchingType='New BaselineTopology', baselineNodes=[node42, node43, node44, 
> node45, node46, node47, node48, node49, node50, node51, node52, node53, 
> node54, node55, node56, node57, node58, node59, node1, node4, node5, node2, 
> node3, node8, node9, node6, node7, node60, node61, node62, node63, node64, 
> node65, node66, node67, node68, node69, node70, node71, node72, node73, 
> node74, node75, node76, node77, node78, node79, node80, node81, node82, 
> node83, node84, node85, node86, node87, node88, node89, node90, node91, 
> node92, node93, node94, node95, node96, node97, node10, node98, node11, 
> node99, node12, node13, node14, node15, node16, node100, node17, node18, 
> node19, node108, node107, node106, node105, node104, node103, node102, 
> node101, node109, node20, node21, node22, node23, node24, node25, node26, 
> node27, node28, node29, node110, node30, node31, node32, node33, node34, 
> node35, node36, node37, node38, node39, node40, node41]], 
> forceChangeBaselineTopology=false, timestamp=1535101173015], allowMerge=false]
> [11:59:33,753][INFO][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
> Start activation process [nodeId=1906b9c3-73f4-4c30-85cc-cf6b99c3bab9, 
> client=false, topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1]]
> [11:59:33,756][INFO][exchange-worker-#62][FilePageStoreManager] Resolved page 
> store work directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
> write ahead log work directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/node1
> [11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
> write ahead log archive directory: 
> /storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/archive/node1
> [11:59:33,757][INFO][exchange-worker-#62][FileWriteAheadLogManager] Started 
> write-ahead log manager [mode=LOG_ONLY]
> [11:59:33,763][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Processed 
> message type = TcpDiscoveryCustomEventMessage id = 
> e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 629
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9398) Reduce time on processing CustomDiscoveryMessage by discovery worker

2018-08-28 Thread Pavel Kovalenko (JIRA)

Pavel Kovalenko created IGNITE-9398:
---

 Summary: Reduce time on processing CustomDiscoveryMessage by 
discovery worker
 Key: IGNITE-9398
 URL: https://issues.apache.org/jira/browse/IGNITE-9398
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.6, 2.5, 2.4
Reporter: Pavel Kovalenko
 Fix For: 2.7


Processing discovery CustomMessage may take significant values of time (0.5-0.7 
seconds) before sending to next node in the topology. This significantly 
accumulates the total time of PME if topology has multiple nodes.
Let X = time of processing discovery message by discovery-msg-worker on each 
node before sending to next node. 
Let N = number of nodes in the topology.
Then the minimal total time of exchange will be:
T = N * X

We shouldn't make heavy actions when process discovery message. Best solution 
will be separated thread that will do it, while discovery-msg-worker will just 
pass a message to that thread and send a message immediately to another node in 
topology.

This affects both TcpDiscoverySpi and ZkDiscoverySpi.

{noformat}
[11:59:33,134][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Enqueued message 
type = TcpDiscoveryCustomEventMessage id = 
e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 0
[11:59:33,537][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
 Received activate request with BaselineTopology[id=0]
[11:59:33,549][INFO][tcp-disco-msg-worker-#2][GridSnapshotAwareClusterStateProcessorImpl]
 Started state transition: true
[11:59:33,752][INFO][exchange-worker-#62][time] Started exchange init 
[topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1], crd=true, 
evt=DISCOVERY_CUSTOM_EVT, evtNode=a38dfe31-dcfd-430b-acb3-5a531db4197e, 
customEvt=ChangeGlobalStateMessage 
[id=cea542b6561-47395de6-c204-4576-a0a3-99ec53d41ac3, 
reqId=5b651439-7a6a-43fc-9cb0-d646c3380576, 
initiatingNodeId=a38dfe31-dcfd-430b-acb3-5a531db4197e, activate=true, 
baselineTopology=BaselineTopology [id=0, branchingHash=-69412111965, 
branchingType='New BaselineTopology', baselineNodes=[node42, node43, node44, 
node45, node46, node47, node48, node49, node50, node51, node52, node53, node54, 
node55, node56, node57, node58, node59, node1, node4, node5, node2, node3, 
node8, node9, node6, node7, node60, node61, node62, node63, node64, node65, 
node66, node67, node68, node69, node70, node71, node72, node73, node74, node75, 
node76, node77, node78, node79, node80, node81, node82, node83, node84, node85, 
node86, node87, node88, node89, node90, node91, node92, node93, node94, node95, 
node96, node97, node10, node98, node11, node99, node12, node13, node14, node15, 
node16, node100, node17, node18, node19, node108, node107, node106, node105, 
node104, node103, node102, node101, node109, node20, node21, node22, node23, 
node24, node25, node26, node27, node28, node29, node110, node30, node31, 
node32, node33, node34, node35, node36, node37, node38, node39, node40, 
node41]], forceChangeBaselineTopology=false, timestamp=1535101173015], 
allowMerge=false]
[11:59:33,753][INFO][exchange-worker-#62][GridDhtPartitionsExchangeFuture] 
Start activation process [nodeId=1906b9c3-73f4-4c30-85cc-cf6b99c3bab9, 
client=false, topVer=AffinityTopologyVersion [topVer=110, minorTopVer=1]]
[11:59:33,756][INFO][exchange-worker-#62][FilePageStoreManager] Resolved page 
store work directory: 
/storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/node1
[11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
write ahead log work directory: 
/storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/node1
[11:59:33,756][INFO][exchange-worker-#62][FileWriteAheadLogManager] Resolved 
write ahead log archive directory: 
/storage/ssd/avolkov/tiden/snapshots-180824-114937/test_pitr/ignite.server.1/work/db/wal/archive/node1
[11:59:33,757][INFO][exchange-worker-#62][FileWriteAheadLogManager] Started 
write-ahead log manager [mode=LOG_ONLY]
[11:59:33,763][INFO][tcp-disco-msg-worker-#2][TcpDiscoverySpi] Processed 
message type = TcpDiscoveryCustomEventMessage id = 
e4b542b6561-a38dfe31-dcfd-430b-acb3-5a531db4197e time = 629
{noformat}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9392) CacheAsyncOperationsFailoverTxTest hangs on TC



 [ 
https://issues.apache.org/jira/browse/IGNITE-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Lantukh updated IGNITE-9392:
-
Labels: MakeTeamcityGreenAgain  (was: )

> CacheAsyncOperationsFailoverTxTest hangs on TC
> --
>
> Key: IGNITE-9392
> URL: https://issues.apache.org/jira/browse/IGNITE-9392
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Exchange worker hangs while waiting for partition release:
> {code}
> [13:42:50] :   [Step 3/4] Thread 
> [name="exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%",
>  id=245275, state=TIMED_WAITING, blockCnt=135, waitCnt=176]
> [13:42:50] :   [Step 3/4] at sun.misc.Unsafe.park(Native Method)
> [13:42:50] :   [Step 3/4] at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1367)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1211)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:752)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2525)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2405)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> [13:42:50] :   [Step 3/4] at java.lang.Thread.run(Thread.java:748)
> {code}
> At that moment there are lots of pending transactions and one pending TX 
> finish future:
> {code}
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,632][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Failed to wait for partition map exchange [topVer=AffinityTopologyVersion 
> [topVer=37, minorTopVer=0], node=98909049-bca4-4cba-b659-768ccfe0]. 
> Dumping pending objects that might be the cause: 
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,632][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Ready affinity version: AffinityTopologyVersion [topVer=36, minorTopVer=0]
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,633][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Last exchange future: GridDhtPartitionsExchangeFuture 
> [firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], type=NODE_LEFT, tstamp=1535366275135], crd=TcpDiscoveryNode 
> [id=98909049-bca4-4cba-b659-768ccfe0, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1535366575460, loc=true, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], exchId=GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0], 
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false,

[jira] [Updated] (IGNITE-9392) CacheAsyncOperationsFailoverTxTest hangs on TC



 [ 
https://issues.apache.org/jira/browse/IGNITE-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Lantukh updated IGNITE-9392:
-
Ignite Flags:   (was: Docs Required)

> CacheAsyncOperationsFailoverTxTest hangs on TC
> --
>
> Key: IGNITE-9392
> URL: https://issues.apache.org/jira/browse/IGNITE-9392
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Exchange worker hangs while waiting for partition release:
> {code}
> [13:42:50] :   [Step 3/4] Thread 
> [name="exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%",
>  id=245275, state=TIMED_WAITING, blockCnt=135, waitCnt=176]
> [13:42:50] :   [Step 3/4] at sun.misc.Unsafe.park(Native Method)
> [13:42:50] :   [Step 3/4] at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1367)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1211)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:752)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2525)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2405)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> [13:42:50] :   [Step 3/4] at java.lang.Thread.run(Thread.java:748)
> {code}
> At that moment there are lots of pending transactions and one pending TX 
> finish future:
> {code}
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,632][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Failed to wait for partition map exchange [topVer=AffinityTopologyVersion 
> [topVer=37, minorTopVer=0], node=98909049-bca4-4cba-b659-768ccfe0]. 
> Dumping pending objects that might be the cause: 
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,632][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Ready affinity version: AffinityTopologyVersion [topVer=36, minorTopVer=0]
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,633][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Last exchange future: GridDhtPartitionsExchangeFuture 
> [firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], type=NODE_LEFT, tstamp=1535366275135], crd=TcpDiscoveryNode 
> [id=98909049-bca4-4cba-b659-768ccfe0, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1535366575460, loc=true, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], exchId=GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0], 
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false,

[jira] [Updated] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException



 [ 
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Artukhov updated IGNITE-9397:
--
Ignite Flags:   (was: Docs Required)

> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
>  Issue Type: Bug
>  Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file which has the only benchmark with the following 
> parameters:
> {code}
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b 
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark 
> -sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
> "
> {code}
> *Steps*
> Run 
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at 
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at 
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException



 [ 
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Artukhov updated IGNITE-9397:
--
Description: 
*Setup*
1 server and 1 client node
Attached the property file which has the only benchmark with the following 
parameters:
{code}
CONFIGS="\
-cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b 
${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark 
-sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
"
{code}

*Steps*
Run 
{code}
$ bash bin/benchmark-run-all.sh config/r.properties
{code}

*Result*
An exception during warm-up:
{code}
Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:117)
at 
org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
{code}

  was:
*Setup*
1 server and 1 client node
Attached the property file

*Steps*
Run 
{code}
$ bash bin/benchmark-run-all.sh config/r.properties
{code}

*Result*
An exception during warm-up:
{code}
Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:117)
at 
org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
{code}


> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
>  Issue Type: Bug
>  Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file which has the only benchmark with the following 
> parameters:
> {code}
> CONFIGS="\
> -cfg ${SCRIPT_DIR}/../config/ignite-localhost-config.xml -nn ${nodesNum} -b 
> ${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -r 30 -dn IgniteSqlDeleteBenchmark 
> -sn IgniteNode -ds ${ver}sql-delete-${b}-backup,\
> "
> {code}
> *Steps*
> Run 
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at 
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at 
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException

Ivan Artukhov created IGNITE-9397:
-

 Summary: IgniteSqlDeleteBenchmark fails to run with 
java.util.NoSuchElementException
 Key: IGNITE-9397
 URL: https://issues.apache.org/jira/browse/IGNITE-9397
 Project: Ignite
  Issue Type: Bug
  Components: yardstick
Affects Versions: 2.6
Reporter: Ivan Artukhov
 Attachments: r.properties

*Setup*
1 server and 1 client node
Attached the property file

*Steps*
Run 
{code}
$ bash bin/benchmark-run-all.sh config/r.properties
{code}

*Result*
An exception during warm-up:
{code}
Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
ERROR: Shutting down benchmark driver to unexpected exception.
Type '--help' for usage.
java.util.NoSuchElementException
at java.util.AbstractQueue.remove(AbstractQueue.java:117)
at 
org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
at java.lang.Thread.run(Thread.java:748)
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9397) IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException



 [ 
https://issues.apache.org/jira/browse/IGNITE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Artukhov updated IGNITE-9397:
--
Attachment: r.properties

> IgniteSqlDeleteBenchmark fails to run with java.util.NoSuchElementException
> ---
>
> Key: IGNITE-9397
> URL: https://issues.apache.org/jira/browse/IGNITE-9397
> Project: Ignite
>  Issue Type: Bug
>  Components: yardstick
>Affects Versions: 2.6
>Reporter: Ivan Artukhov
>Priority: Major
> Attachments: r.properties
>
>
> *Setup*
> 1 server and 1 client node
> Attached the property file
> *Steps*
> Run 
> {code}
> $ bash bin/benchmark-run-all.sh config/r.properties
> {code}
> *Result*
> An exception during warm-up:
> {code}
> Finishing main test [ts=1535464476907, date=Tue Aug 28 16:54:36 MSK 2018]
> ERROR: Shutting down benchmark driver to unexpected exception.
> Type '--help' for usage.
> java.util.NoSuchElementException
> at java.util.AbstractQueue.remove(AbstractQueue.java:117)
> at 
> org.apache.ignite.yardstick.cache.dml.IgniteSqlDeleteBenchmark.test(IgniteSqlDeleteBenchmark.java:73)
> at 
> org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
> at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9396) ML Examples: can't run examples, not enough dependencies in pom.xml

2018-08-28 Thread Stepan Pilschikov (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stepan Pilschikov updated IGNITE-9396:
--
Affects Version/s: 2.7

> ML Examples: can't run examples, not enough dependencies in pom.xml
> ---
>
> Key: IGNITE-9396
> URL: https://issues.apache.org/jira/browse/IGNITE-9396
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Affects Versions: 2.7
>Reporter: Stepan Pilschikov
>Assignee: Oleg Ignatenko
>Priority: Major
>
> Trying to run ml-examples and can't compile example project because several 
> dependencies didn't added in pom.xml
> Execution:
>  Using JB IDEA Run->Run class to execute current class
>  or 
>  `java -classpath [all classpaths which are listed in pom file] class name`
>  or compile with maven also failed
>  `mvn clean compile`
> Exception:
>  Can't compile project. not enough dependencies
> Missing dependencies:
> {code:xml}
> 
> com.github.fommil.netlib
> core
> 
> 
> org.springframework.data
> spring-data-commons
> 
> 
> org.springframework
> spring-beans
> 
> 
> org.springframework
> spring-context
> 
> 
> com.h2database
> h2
> 
> {code}
> com.github.fommil.netlib, springframework.* and h2 need to run - 
> org.apache.ignite.examples.ml.dataset.AlgorithmSpecificDatasetExample



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8158) Missed cleanups if afterTestsStop throws exception



[ 
https://issues.apache.org/jira/browse/IGNITE-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590394#comment-16590394
 ] 

Nikolai Kulagin edited comment on IGNITE-8158 at 8/28/18 1:36 PM:
--

Wrap the method afterTestsStopped() call with try/catch block.

PR: [https://github.com/apache/ignite/pull/4464/]

TC: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1626362=buildResultsDiv=IgniteTests24Java8_RunAll]

Upsource: [https://reviews.ignite.apache.org/ignite/review/IGNT-CR-740]

Project is buildable, tests are ok, flacky as usual. [~Mmuzaf], please, review 
my change.


was (Author: zzzadruga):
Wrap the method afterTestsStopped() call with try/catch block.

PR: [https://github.com/apache/ignite/pull/4464/]

TC: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1626362=buildResultsDiv=IgniteTests24Java8_RunAll]

Project is buildable, tests are ok, flacky as usual. [~Mmuzaf], please, review 
my change.

> Missed cleanups if afterTestsStop throws exception
> --
>
> Key: IGNITE-8158
> URL: https://issues.apache.org/jira/browse/IGNITE-8158
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie, test
> Fix For: 2.7
>
> Attachments: StopAllGridsTest.java
>
>
> Method {{afterTestsStopped}} might throw exception. Contibutor should provide 
> solution for ensuring that all cleanups in {{tearDown}} method would be 
> executed in this case.
> {code:java|title=GridAbstractTest.java}
> /** {@inheritDoc} */
> @Override protected void tearDown() throws Exception {
> ...
> try {
> afterTest();
> }
> finally {
> serializedObj.clear();
> if (isLastTest()) {
> ...
> afterTestsStopped();
> if (startGrid)
> G.stop(getTestIgniteInstanceName(), true);
> // Remove counters.
> tests.remove(getClass());
> // Remove resources cached in static, if any.
> GridClassLoaderCache.clear();
> U.clearClassCache();
> MarshallerExclusions.clearCache();
> BinaryEnumCache.clear();
> }
> Thread.currentThread().setContextClassLoader(clsLdr);
> clsLdr = null;
> cleanReferences();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9396) ML Examples: can't run examples, not enough dependencies in pom.xml

2018-08-28 Thread Stepan Pilschikov (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stepan Pilschikov updated IGNITE-9396:
--
Description: 
Trying to run ml-examples and can't compile example project because several 
dependencies didn't added in pom.xml

Execution:
 Using JB IDEA Run->Run class to execute current class
 or 
 `java -classpath [all classpaths which are listed in pom file] class name`
 or compile with maven also failed
 `mvn clean compile`

Exception:
 Can't compile project. not enough dependencies

Missing dependencies:
{code:xml}

com.github.fommil.netlib
core



org.springframework.data
spring-data-commons



org.springframework
spring-beans



org.springframework
spring-context



com.h2database
h2

{code}

com.github.fommil.netlib, springframework.* and h2 need to run - 
org.apache.ignite.examples.ml.dataset.AlgorithmSpecificDatasetExample

  was:
Trying to run ml-examples and can't compile example project because several 
dependencies didn't added in pom.xml

Execution:
 Using JB IDEA Run->Run class to execute current class
 or 
 `java -classpath [all classpaths which are listed in pom file] class name`
 or compile with maven also failed
 `mvn clean compile`

Exception:
 Can't compile project. not enough dipendencies

Missing dependencies:
{code:xml}

com.github.fommil.netlib
core



org.springframework.data
spring-data-commons



org.springframework
spring-beans



org.springframework
spring-context



com.h2database
h2

{code}

com.github.fommil.netlib, springframework.* and h2 need to run - 
org.apache.ignite.examples.ml.dataset.AlgorithmSpecificDatasetExample


> ML Examples: can't run examples, not enough dependencies in pom.xml
> ---
>
> Key: IGNITE-9396
> URL: https://issues.apache.org/jira/browse/IGNITE-9396
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run ml-examples and can't compile example project because several 
> dependencies didn't added in pom.xml
> Execution:
>  Using JB IDEA Run->Run class to execute current class
>  or 
>  `java -classpath [all classpaths which are listed in pom file] class name`
>  or compile with maven also failed
>  `mvn clean compile`
> Exception:
>  Can't compile project. not enough dependencies
> Missing dependencies:
> {code:xml}
> 
> com.github.fommil.netlib
> core
> 
> 
> org.springframework.data
> spring-data-commons
> 
> 
> org.springframework
> spring-beans
> 
> 
> org.springframework
> spring-context
> 
> 
> com.h2database
> h2
> 
> {code}
> com.github.fommil.netlib, springframework.* and h2 need to run - 
> org.apache.ignite.examples.ml.dataset.AlgorithmSpecificDatasetExample



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-9396) ML Examples: can't run examples, not enough dependencies in pom.xml

2018-08-28 Thread Oleg Ignatenko (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Ignatenko reassigned IGNITE-9396:
--

Assignee: Oleg Ignatenko

> ML Examples: can't run examples, not enough dependencies in pom.xml
> ---
>
> Key: IGNITE-9396
> URL: https://issues.apache.org/jira/browse/IGNITE-9396
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Stepan Pilschikov
>Assignee: Oleg Ignatenko
>Priority: Major
>
> Trying to run ml-examples and can't compile example project because several 
> dependencies didn't added in pom.xml
> Execution:
>  Using JB IDEA Run->Run class to execute current class
>  or 
>  `java -classpath [all classpaths which are listed in pom file] class name`
>  or compile with maven also failed
>  `mvn clean compile`
> Exception:
>  Can't compile project. not enough dependencies
> Missing dependencies:
> {code:xml}
> 
> com.github.fommil.netlib
> core
> 
> 
> org.springframework.data
> spring-data-commons
> 
> 
> org.springframework
> spring-beans
> 
> 
> org.springframework
> spring-context
> 
> 
> com.h2database
> h2
> 
> {code}
> com.github.fommil.netlib, springframework.* and h2 need to run - 
> org.apache.ignite.examples.ml.dataset.AlgorithmSpecificDatasetExample



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9396) ML Examples: can't run examples, not enough dependencies in pom.xml

2018-08-28 Thread Stepan Pilschikov (JIRA)

Stepan Pilschikov created IGNITE-9396:
-

 Summary: ML Examples: can't run examples, not enough dependencies 
in pom.xml
 Key: IGNITE-9396
 URL: https://issues.apache.org/jira/browse/IGNITE-9396
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Stepan Pilschikov


Trying to run ml-examples and can't compile example project because several 
dependencies didn't added in pom.xml

Execution:
 Using JB IDEA Run->Run class to execute current class
 or 
 `java -classpath [all classpaths which are listed in pom file] class name`
 or compile with maven also failed
 `mvn clean compile`

Exception:
 Can't compile project. not enough dipendencies

Missing dependencies:
{code:xml}

com.github.fommil.netlib
core



org.springframework.data
spring-data-commons



org.springframework
spring-beans



org.springframework
spring-context



com.h2database
h2

{code}

com.github.fommil.netlib, springframework.* and h2 need to run - 
org.apache.ignite.examples.ml.dataset.AlgorithmSpecificDatasetExample



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7556) Docs should feature specifying SQL key more prominently



 [ 
https://issues.apache.org/jira/browse/IGNITE-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-7556:

Fix Version/s: (was: 2.7)

> Docs should feature specifying SQL key more prominently
> ---
>
> Key: IGNITE-7556
> URL: https://issues.apache.org/jira/browse/IGNITE-7556
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Ilya Kasnacheev
>Assignee: Artem Budnikov
>Priority: Minor
>
> Descriptions on [https://apacheignite-sql.readme.io/docs/schema-and-indexes] 
> are not DML-friendly
>  After reading this page and 
> [https://apacheignite-sql.readme.io/docs/insert], one would likely still 
> unable to write working INSERT because there won't be primary key in it.
> Their only chance is to spot _key reference in infoblock, or infer usability 
> of setKeyFields() with single key type. Both are unlikely, leading to 
> questions such as 
> [https://stackoverflow.com/questions/48460214/how-do-i-read-data-from-ignite-kv-storage-using-jdbc]
>  see {{Key is missing from query}}
> Such problems are hard to debug. They can be avoided if all examples of 
> QueryEntities in docs will contain setKeyFields, and INSERT docs page will 
> refer to _key field.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8309) Cannot change WAL mode from client node



 [ 
https://issues.apache.org/jira/browse/IGNITE-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-8309:

Fix Version/s: (was: 2.7)

> Cannot change WAL mode from client node
> ---
>
> Key: IGNITE-8309
> URL: https://issues.apache.org/jira/browse/IGNITE-8309
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Vladimir Ozerov
>Priority: Major
>
> I have cluster of a few nodes with persistence region, and a few clients, 
> obviously without persistence region.
> When I try to do disableWal(cacheName) on client node, I observe the 
> following exception:
> {code}
> Caused by: org.apache.ignite.IgniteCheckedException: Cannot change WAL mode 
> because persistence is not enabled for cache(s) [caches=[data0], 
> dataRegion=null]
> at 
> org.apache.ignite.internal.processors.cache.WalStateManager.errorFuture(WalStateManager.java:759)
>  ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at 
> org.apache.ignite.internal.processors.cache.WalStateManager.init(WalStateManager.java:292)
>  ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.changeWalMode(GridCacheProcessor.java:3045)
>  ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> {code}
> From server node I can disable and enable WAL without problems. Since it's a 
> cluster-wide operations, I expect it to be doable from client also.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-8936) Remove AffinityAssignment#clientEventChange as not used



[ 
https://issues.apache.org/jira/browse/IGNITE-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593304#comment-16593304
 ] 

Nikolai Kulagin edited comment on IGNITE-8936 at 8/28/18 1:30 PM:
--

Remove field clientEvtChange and method clientEventChange()

PR: 
[https://github.com/apache/ignite/pull/4448|https://github.com/apache/ignite/pull/4448]

TC: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1723097=buildResultsDiv=IgniteTests24Java8_RunAll=]

Upsource: [https://reviews.ignite.apache.org/ignite/review/IGNT-CR-738]

Project is buildable, tests are ok, flacky as usual. [~Mmuzaf], please, review 
my change.


was (Author: zzzadruga):
Remove field clientEvtChange and method clientEventChange()

PR: 
[https://github.com/apache/ignite/pull/4448|https://github.com/apache/ignite/pull/4448]

TC: 
[https://ci.ignite.apache.org/viewLog.html?buildId=1723097=buildResultsDiv=IgniteTests24Java8_RunAll=]

Project is buildable, tests are ok, flacky as usual. [~Mmuzaf], please, review 
my change.

> Remove AffinityAssignment#clientEventChange as not used
> ---
>
> Key: IGNITE-8936
> URL: https://issues.apache.org/jira/browse/IGNITE-8936
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Attachments: ClientEventChange (1).png
>
>
> We should try to keep Ignite project code as simple as possible.
> Motivation: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Cases-of-using-AffinityAssignment-clientEventChange-method-td32068.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module



[ 
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594675#comment-16594675
 ] 

Nikolai Kulagin edited comment on IGNITE-9165 at 8/28/18 1:28 PM:
--

Close streams in core module.
PR: https://github.com/apache/ignite/pull/4481
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1723203=buildResultsDiv=IgniteTests24Java8_RunAll
Upsorce: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-737
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.


was (Author: zzzadruga):
Close streams in core module.
PR: https://github.com/apache/ignite/pull/4481
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1723203=buildResultsDiv=IgniteTests24Java8_RunAll
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.

> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Fix For: 2.7
>
> Attachments: 
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields, 
> pass it to other methods that might close it, or return it, and does not 
> appear to close the stream on all paths out of the method.  This may result 
> in a file descriptor leak.
> Example:
>  
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
>  props.load(new FileReader(GridTestUtils.resolveIgnitePath(
>  "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
>  throw new RuntimeException(e);
> }{code}
>  
>  One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>   
>  +org.apache.ignite.internal:+   
>  * *BinaryContext*#classesInPackage(String)
>  * *GridClientJdkMarshaller*#marshal(Object, int)
>  * 
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
>  * *OptimizedObjectStreamSelfTest*#testReadLine()
>  * *PageIdDistributionTest*#_testRealHistory()
>  * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
>  * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
>  * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
>  * *GridTestUtils*.sslContext()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods



[ 
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594672#comment-16594672
 ] 

Nikolai Kulagin edited comment on IGNITE-9160 at 8/28/18 1:22 PM:
--

Fix equals() methods.
PR: https://github.com/apache/ignite/pull/4478
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1717616=buildResultsDiv=IgniteTests24Java8_RunAll
Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-736
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.


was (Author: zzzadruga):
Fix equals() methods.
PR: https://github.com/apache/ignite/pull/4478
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1717616=buildResultsDiv=IgniteTests24Java8_RunAll
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.

> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Fix For: 2.7
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE  
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object 
> cannot be cast to 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
>  Or NPE 
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
>  The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
>     return false;{code}
> + List of classes with similar problems: +
>  * *GridTopic$T1-T8* - NPE
>  * *GridCachePreloadLifecycleAbstractTest -* NPE
>  * *GridDhtPartitionFullMap -* NPE and CCE
>  * *GridDhtPartitionMap -* NPE and CCE
>  * *OptimizedMarshallerSelfTest -* NPE and CCE
>  * *GatewayProtectedCacheProxy -* NPE and CCE
>  * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
>  * *GridCacheDistributedQueryManager -* NPE and CCE
>  * *GridServiceMethodReflectKey -* NPE and CCE
>  *  *GridListSetSelfTest -* NPE and CCE
>  * *GridTestKey -* NPE and CCE
>  * *GridCacheMvccCandidate -* CCE
>  * *GridDhtPartitionExchangeId -* CCE
>  * *GridTuple6 -* CCE



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9120) Metadata writer does not propagate error to failure handler



[ 
https://issues.apache.org/jira/browse/IGNITE-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594926#comment-16594926
 ] 

Andrey Gura commented on IGNITE-9120:
-

[~a-polyakov] Is there any reproducer and full stack trace?

> Metadata writer does not propagate error to failure handler
> ---
>
> Key: IGNITE-9120
> URL: https://issues.apache.org/jira/browse/IGNITE-9120
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexand Polyakov
>Priority: Major
>
> In logs
> {code:java}
> [WARN] [tcp-disco-msg-worker- # 2% DPL_GRID% DplGridNodeName%] 
> [o.a.i.i.p.c.b.CacheObjectBinaryProcessorImpl] Failed to save metadata for 
> typeId: 978611101; The exception was selected: there was no space left on the 
> device{code}
> Node does not shut down
> The number of stalled transactions begins to grow.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9120) Metadata writer does not propagate error to failure handler



 [ 
https://issues.apache.org/jira/browse/IGNITE-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-9120:

Ignite Flags:   (was: Docs Required)

> Metadata writer does not propagate error to failure handler
> ---
>
> Key: IGNITE-9120
> URL: https://issues.apache.org/jira/browse/IGNITE-9120
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexand Polyakov
>Priority: Major
>
> In logs
> {code:java}
> [WARN] [tcp-disco-msg-worker- # 2% DPL_GRID% DplGridNodeName%] 
> [o.a.i.i.p.c.b.CacheObjectBinaryProcessorImpl] Failed to save metadata for 
> typeId: 978611101; The exception was selected: there was no space left on the 
> device{code}
> Node does not shut down
> The number of stalled transactions begins to grow.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9312) Remove unnecessary @SuppressWarnings annotation



[ 
https://issues.apache.org/jira/browse/IGNITE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594908#comment-16594908
 ] 

ASF GitHub Bot commented on IGNITE-9312:


GitHub user ololo3000 opened a pull request:

https://github.com/apache/ignite/pull/4632

IGNITE-9312 Remove unnecessary @SuppressWarnings annotation



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ololo3000/ignite IGNITE-9312

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4632.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4632


commit 70a3af50aa3703d4a4ada443e0a4ac1634598517
Author: ololo3000 
Date:   2018-08-28T12:08:50Z

IGNITE-9312 Remove unnecessary @SuppressWarnings annotation




> Remove unnecessary @SuppressWarnings annotation
> ---
>
> Key: IGNITE-9312
> URL: https://issues.apache.org/jira/browse/IGNITE-9312
> Project: Ignite
>  Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: PetrovMikhail
>Priority: Minor
>
> New `Code Inspections` profile can be found 
> \idea\ignite_inspections.xml.
> We will need to fix all methods with unnecessary {{@SuppressWarnings}} 
> annotation regarding this inscpetion profile.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9392) CacheAsyncOperationsFailoverTxTest hangs on TC



[ 
https://issues.apache.org/jira/browse/IGNITE-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594903#comment-16594903
 ] 

Ilya Lantukh commented on IGNITE-9392:
--

Looks like setting TX timeout resolves this issue.

> CacheAsyncOperationsFailoverTxTest hangs on TC
> --
>
> Key: IGNITE-9392
> URL: https://issues.apache.org/jira/browse/IGNITE-9392
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Exchange worker hangs while waiting for partition release:
> {code}
> [13:42:50] :   [Step 3/4] Thread 
> [name="exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%",
>  id=245275, state=TIMED_WAITING, blockCnt=135, waitCnt=176]
> [13:42:50] :   [Step 3/4] at sun.misc.Unsafe.park(Native Method)
> [13:42:50] :   [Step 3/4] at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:217)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.waitPartitionRelease(GridDhtPartitionsExchangeFuture.java:1367)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1211)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:752)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2525)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2405)
> [13:42:50] :   [Step 3/4] at 
> o.a.i.i.util.worker.GridWorker.run(GridWorker.java:110)
> [13:42:50] :   [Step 3/4] at java.lang.Thread.run(Thread.java:748)
> {code}
> At that moment there are lots of pending transactions and one pending TX 
> finish future:
> {code}
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,632][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Failed to wait for partition map exchange [topVer=AffinityTopologyVersion 
> [topVer=37, minorTopVer=0], node=98909049-bca4-4cba-b659-768ccfe0]. 
> Dumping pending objects that might be the cause: 
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,632][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Ready affinity version: AffinityTopologyVersion [topVer=36, minorTopVer=0]
> [13:43:14]W:   [org.apache.ignite:ignite-core] [2018-08-27 
> 10:43:14,633][WARN 
> ][exchange-worker-#214881%distributed.CacheAsyncOperationsFailoverTxTest0%][diagnostic]
>  Last exchange future: GridDhtPartitionsExchangeFuture 
> [firstDiscoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], type=NODE_LEFT, tstamp=1535366275135], crd=TcpDiscoveryNode 
> [id=98909049-bca4-4cba-b659-768ccfe0, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1535366575460, loc=true, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], exchId=GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0], 
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false, ver=2.7.0#20180824-sha1:b0175cf6, 
> isClient=false], topVer=37, nodeId8=98909049, msg=Node left: TcpDiscoveryNode 
> [id=387bab47-9542-4d98-8dda-03e3a3f3, addrs=ArrayList [127.0.0.1], 
> sockAddrs=HashSet [/127.0.0.1:47503], discPort=47503, order=4, intOrder=4, 
> lastExchangeTime=1535366199108, loc=false,

[jira] [Commented] (IGNITE-9382) Node.js fails to process large payloads

2018-08-28 Thread ekaterina.vergizova (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-9382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594866#comment-16594866
 ] 

ekaterina.vergizova commented on IGNITE-9382:
-

[~tyabuki], thanks!

I commented in the PR. Let me please implement the full solution.

> Node.js fails to process large payloads
> ---
>
> Key: IGNITE-9382
> URL: https://issues.apache.org/jira/browse/IGNITE-9382
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Roman Shtykh
>Assignee: Toru Yabuki
>Priority: Major
>
> Looks like finalizing response is done too early.
> This can be easily checked with an SQL _limit_ 1 and _limit 100_.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594862#comment-16594862
 ] 

ASF GitHub Bot commented on IGNITE-9367:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4621


> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection

2018-08-28 Thread Roman Guseinov (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594846#comment-16594846
 ] 

Roman Guseinov commented on IGNITE-9367:


[~isapego] , thank you.

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594844#comment-16594844
 ] 

Igor Sapego commented on IGNITE-9367:
-

[~guseinov] tests pass. Everything looks OK now.

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9393) [ML] KMeans fails on complex data in cache



[ 
https://issues.apache.org/jira/browse/IGNITE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594834#comment-16594834
 ] 

ASF GitHub Bot commented on IGNITE-9393:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4628


> [ML] KMeans fails on complex data in cache
> --
>
> Key: IGNITE-9393
> URL: https://issues.apache.org/jira/browse/IGNITE-9393
> Project: Ignite
>  Issue Type: Bug
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.7
>
>
> Described here 
> http://apache-ignite-users.70518.x6.nabble.com/NPE-exception-in-KMeansTrainer-td23504.html#a23512



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (IGNITE-7833) Find out possible ways to handle partition update counters inconsistency

2018-08-28 Thread Alexey Stelmak (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-7833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Stelmak resolved IGNITE-7833.

Resolution: Later

> Find out possible ways to handle partition update counters inconsistency
> 
>
> Key: IGNITE-7833
> URL: https://issues.apache.org/jira/browse/IGNITE-7833
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Pavel Kovalenko
>Assignee: Alexey Stelmak
>Priority: Major
>
> We should think about possible ways to resolve the situation when we observe 
> that partition update counters for the same partitions (primary-backup) are 
> different on some nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8642) Failure processor should dump state of all threads



 [ 
https://issues.apache.org/jira/browse/IGNITE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8642:

Ignite Flags: Docs Required

> Failure processor should dump state of all threads
> --
>
> Key: IGNITE-8642
> URL: https://issues.apache.org/jira/browse/IGNITE-8642
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.7
>
>
> Failure processor should dump state of all threads before failure handler is 
> invoked.
> Use {{org.apache.ignite.internal.util.IgniteUtils#dumpThreads}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9361) Remove IgniteInternalCache.isMongo*Cache() and other such stuff



[ 
https://issues.apache.org/jira/browse/IGNITE-9361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594808#comment-16594808
 ] 

Ilya Kasnacheev commented on IGNITE-9361:
-

[~dpavlov] please review dead code removal and internal API change.

> Remove IgniteInternalCache.isMongo*Cache() and other such stuff
> ---
>
> Key: IGNITE-9361
> URL: https://issues.apache.org/jira/browse/IGNITE-9361
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> Nobody needs it for a long time already. It's all internal API, we can drop 
> it outright.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9360) Destroy SnapTreeMap and related classes



[ 
https://issues.apache.org/jira/browse/IGNITE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594807#comment-16594807
 ] 

Ilya Kasnacheev commented on IGNITE-9360:
-

[~dpavlov] please review dead code removal and internal API change.

> Destroy SnapTreeMap and related classes
> ---
>
> Key: IGNITE-9360
> URL: https://issues.apache.org/jira/browse/IGNITE-9360
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> It's not used anywhere and noone wants it, and it's a solid block of code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6405) Deadlock is not detected if timed out on client.



 [ 
https://issues.apache.org/jira/browse/IGNITE-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-6405:

Fix Version/s: (was: 2.7)
   2.8

> Deadlock is not detected if timed out on client.
> 
>
> Key: IGNITE-6405
> URL: https://issues.apache.org/jira/browse/IGNITE-6405
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexei Scherbakov
>Assignee: Andrey Gura
>Priority: Minor
> Fix For: 2.8
>
>
> Timeout exception is thrown instead.
> Reproducer:
> {noformat}
> /*
>  * Licensed to the Apache Software Foundation (ASF) under one or more
>  * contributor license agreements.  See the NOTICE file distributed with
>  * this work for additional information regarding copyright ownership.
>  * The ASF licenses this file to You under the Apache License, Version 2.0
>  * (the "License"); you may not use this file except in compliance with
>  * the License.  You may obtain a copy of the License at
>  *
>  *  http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Unless required by applicable law or agreed to in writing, software
>  * distributed under the License is distributed on an "AS IS" BASIS,
>  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>  * See the License for the specific language governing permissions and
>  * limitations under the License.
>  */
> package org.apache.ignite.internal.processors.cache.transactions;
> import java.util.Collections;
> import java.util.concurrent.CountDownLatch;
> import javax.cache.CacheException;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.configuration.TransactionConfiguration;
> import org.apache.ignite.internal.IgniteInternalFuture;
> import org.apache.ignite.internal.util.typedef.internal.U;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionDeadlockException;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static 
> org.apache.ignite.transactions.TransactionConcurrency.PESSIMISTIC;
> import static 
> org.apache.ignite.transactions.TransactionIsolation.REPEATABLE_READ;
> /**
>  * Tests an ability to eagerly rollback timed out transactions.
>  */
> public class TxPessimisticDeadlockDetectionClient extends 
> GridCommonAbstractTest {
> /** */
> private static final long TX_MIN_TIMEOUT = 1;
> /** */
> private static final long TX_TIMEOUT = 300;
> /** */
> private static final long TX_DEFAULT_TIMEOUT = 3_000;
> /** */
> private static final String CACHE_NAME = "test";
> /** IP finder. */
> private static final TcpDiscoveryVmIpFinder IP_FINDER = new 
> TcpDiscoveryVmIpFinder(true);
> /** */
> private static final int GRID_CNT = 3;
> /** */
> private final CountDownLatch blocked = new CountDownLatch(1);
> /** */
> private final CountDownLatch unblocked = new CountDownLatch(1);
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String 
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setClientMode("client".equals(igniteInstanceName));
> ((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);
> TransactionConfiguration txCfg = new TransactionConfiguration();
> txCfg.setDefaultTxTimeout(TX_DEFAULT_TIMEOUT);
> cfg.setTransactionConfiguration(txCfg);
> CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);
> ccfg.setAtomicityMode(TRANSACTIONAL);
> ccfg.setBackups(2);
> cfg.setCacheConfiguration(ccfg);
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGridsMultiThreaded(GRID_CNT);
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> super.afterTest();
> stopAllGrids();
> }
> /** */
> protected void validateException(Exception e) {
> assertEquals("Deadlock report is expected",
> TransactionDeadlockException.class, 
> e.getCause().getCause().getClass());
> }
> /**
>  * Tests if deadlock is resolved on timeout with correct message.
>  *
>  * @throws Exception If failed.
>  */
> public void testDeadlockUnblockedOnTimeout() throws

[jira] [Commented] (IGNITE-6527) Deadlock detection works incorrectly with some timeouts that haven't caused by deadlocks.



[ 
https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594804#comment-16594804
 ] 

Andrey Gura commented on IGNITE-6527:
-

[~VitaliyB] Could you please move tickets to the "Path available" status in the 
future when your code is ready for review. Otherwise, nobody see this ticket in 
the boards.
Could you please also check that issue is sill reproducible and fixes are 
actual?

> Deadlock detection works incorrectly with some timeouts that haven't caused 
> by deadlocks.
> -
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Vitaliy Biryukov
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.8
>
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]
> 2) DD can detect another deadlock which was not the cause of timeout but it 
> would be the cause if the current deadlock did not happen.
> These are very rare situations, but they can happen.
> I see several solutions:
> * Just make a correct message.
> * log warn and continue detecting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7820) Investigate and fix perfromance drop of WAL for FSYNC mode



 [ 
https://issues.apache.org/jira/browse/IGNITE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-7820:

Fix Version/s: (was: 2.7)
   2.8

> Investigate and fix perfromance drop of WAL for FSYNC mode
> --
>
> Key: IGNITE-7820
> URL: https://issues.apache.org/jira/browse/IGNITE-7820
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.8
>
>
> WAL performance drop was introduced by 
> https://issues.apache.org/jira/browse/IGNITE-6339 fix. In order to provide 
> better performance for {{FSYNC}} WAL mode 
> {{FsyncModeFileWriteAheadLogManager}} implementation was added as result of 
> fix issue https://issues.apache.org/jira/browse/IGNITE-7594.
> *What we know about this performance drop:*
> * It affects {{IgnitePutAllBenchmark}} and {{IgnitePutAllTxBenchmark}} and 
> measurements show 10-15% drop and ~50% drop accordingly.
> * It is reproducible not for all hardware configuration. That is for some 
> configuration we see performance improvements instead of drop.
> * It is reproducible for [Many clients --> One server] topology.
> * If {{IGNITE_WAL_MMAP == false}} then we have better performance.
> * If {{fsyncDelay == 0}} then we have better performance.
> *What were tried during initial investigation:*
> * Replacing of {{LockSupport.park/unpark}} to spin leads to improvement about 
> 2%.
> * Using {{FileWriteHandle.fsync(null)}} (unconditional flush) instead of 
> {{FileWriteHandle.fsync(position)}} (conditional flush) doesn't affect 
> benchmarks.
> *What should we do:*
> Investigate the problem and provide fix or recommendation for system tuning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6527) Deadlock detection works incorrectly with some timeouts that haven't caused by deadlocks.



 [ 
https://issues.apache.org/jira/browse/IGNITE-6527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-6527:

Fix Version/s: (was: 2.7)
   2.8

> Deadlock detection works incorrectly with some timeouts that haven't caused 
> by deadlocks.
> -
>
> Key: IGNITE-6527
> URL: https://issues.apache.org/jira/browse/IGNITE-6527
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Vitaliy Biryukov
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.8
>
> Attachments: TxOptimisticDeadlockDetectionIncorrectMessageTest.java
>
>
> Deadlock detection works incorrectly with timeouts that haven't caused by 
> deadlocks. In case of a deadlock in future. Or can detect another deadlock 
> which was not the cause of timeout.
> *requested keys:* keys primary for the same node and blocking in sequential 
> order during the timeout (or all keys that haven't locked by an optimistic 
> transaction in case of near cache).
> *candidates:* keys candidates to be locked on a primary node (entries 
> contains in  GridDhtTxLocal). 
> In the process of updating the Wait-For-Graph requested keys used as 
> candidates.  But "TxDeadlock.toString" method use candidates which were 
> received from messages. 
> 1) It causes an incorrect error message.
> Example: 
> K1: TX1 holds lock, TX2 waits lock.
> K2: TX3 holds lock, TX1 waits lock.
> Transactions:
> TX1 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=1], nodeId=f03b1ae3-a100-479c-9671-11d5cef0, threadId=455]
> TX2 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=2], nodeId=2c0c0e78-cab2-4b23-a985-4965e421, threadId=456]
> TX3 [txId=GridCacheVersion [topVer=118090802, order=1506610794980, 
> nodeOrder=3], nodeId=3340dc48-f1a1-4ea8-8742-19b31432, threadId=457]
> Keys:
> K1 [key=6, cache=cache]
> K2 [key=1, cache=cache]
> 2) DD can detect another deadlock which was not the cause of timeout but it 
> would be the cause if the current deadlock did not happen.
> These are very rare situations, but they can happen.
> I see several solutions:
> * Just make a correct message.
> * log warn and continue detecting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8641) SpringDataExample should use example-ignite.xml config



 [ 
https://issues.apache.org/jira/browse/IGNITE-8641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Gura updated IGNITE-8641:

Fix Version/s: (was: 2.7)
   2.8

> SpringDataExample should use example-ignite.xml config
> --
>
> Key: IGNITE-8641
> URL: https://issues.apache.org/jira/browse/IGNITE-8641
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Chandresh Pancholi
>Priority: Major
>  Labels: newbie
> Fix For: 2.8
>
>
> {{SpringDataExample}} uses 
> {{org.apache.ignite.examples.springdata.SpringAppCfg}} as Spring 
> configuration while all other examples use {{example-ignite.xml}} 
> configuration file.
> It leads to inconsistent examples behaviour.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-9395) Incorrect link to javadoc

2018-08-28 Thread Yury Gerzhedovich (JIRA)

Yury Gerzhedovich created IGNITE-9395:
-

 Summary: Incorrect link to javadoc
 Key: IGNITE-9395
 URL: https://issues.apache.org/jira/browse/IGNITE-9395
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.6, 2.5
Reporter: Yury Gerzhedovich


Javadoc's links refer to 1.0.0 version of Ignite instead of latest one. 

For example at page [https://apacheignite.readme.io/docs/events]  there is link 
javadoc to [https://ignite.apache.org/releases/1.0.0/javadoc/] 

need to fix it to latest version of javadoc - 
[https://ignite.apache.org/releases/latest/javadoc/] 

Seems it issue for all other pages - need to recheck and fix it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594773#comment-16594773
 ] 

Igor Sapego commented on IGNITE-9367:
-

[~guseinov], I restarted tests for windows

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection

2018-08-28 Thread Roman Guseinov (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594772#comment-16594772
 ] 

Roman Guseinov commented on IGNITE-9367:


[~isapego] , thank you for the review. I've added the new test to MSVC solution.

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594758#comment-16594758
 ] 

Igor Sapego edited comment on IGNITE-9367 at 8/28/18 9:35 AM:
--

[~guseinov], looks good overall. The only thing I've noticed is that you have 
not added new test to MSVC solution. Check out the following files:

{{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj}}

{\{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj.filters}}


was (Author: isapego):
[~guseinov], looks good overall. The only thing I've noticed is that you have 
not added new test to MSVC solution. Check out the following files:

{\{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj}}

{\{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj.filters}}

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8628) Expose list of SQL (ODBC\JDBC\Thin) clients via JMX



 [ 
https://issues.apache.org/jira/browse/IGNITE-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8628:
-
Ignite Flags: Docs Required

> Expose list of SQL (ODBC\JDBC\Thin) clients via JMX
> ---
>
> Key: IGNITE-8628
> URL: https://issues.apache.org/jira/browse/IGNITE-8628
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, odbc, thin client
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.7
>
>
> For now, there is no way to know what  (ODBC\JDBC\Thin) clients are connected 
> to node.
>  Also, there is no way to drop slow or hanged clients manually via API.
> Let's make this possible via JMX way at least.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594758#comment-16594758
 ] 

Igor Sapego commented on IGNITE-9367:
-

[~guseinov], looks good overall. The only thing I've noticed is that you have 
not added new test to MSVC solution. Check out the following files:

{\{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj}}

{\{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj.filters}}

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-9367) CPP: ODBC client crashes after executing query with closed connection



[ 
https://issues.apache.org/jira/browse/IGNITE-9367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594758#comment-16594758
 ] 

Igor Sapego edited comment on IGNITE-9367 at 8/28/18 9:35 AM:
--

[~guseinov], looks good overall. The only thing I've noticed is that you have 
not added new test to MSVC solution. Check out the following files:

{{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj}}

{{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj.filters}}


was (Author: isapego):
[~guseinov], looks good overall. The only thing I've noticed is that you have 
not added new test to MSVC solution. Check out the following files:

{{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj}}

{\{modules/platforms/cpp/odbc-test/project/vs/odbc-test.vcxproj.filters}}

> CPP: ODBC client crashes after executing query with closed connection
> -
>
> Key: IGNITE-9367
> URL: https://issues.apache.org/jira/browse/IGNITE-9367
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.6
> Environment: Ubuntu 16.04
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: cpp
> Attachments: odbc-crash-reproducer.cpp, server-config.xml
>
>
> This scenario should not lead an application crash. It seems we should throw 
> an exception like "Connection is closed" instead.
> Thread dump:
> {code:java}
> Thread #1 [odbc-crash-repr] 18020 [core: 0] (Suspended : Signal : 
> SIGSEGV:Segmentation fault) 
> ignite::odbc::Connection::TryRestoreConnection() at connection.cpp:628 
> 0x454264   
> ignite::odbc::Connection::EnsureConnected() at connection.cpp:607 0x4549cd
> ignite::odbc::Connection::SyncMessage ignite::odbc::QueryExecuteResponse>() at connection.h:168 0x45c705   
> ignite::odbc::query::DataQuery::MakeRequestExecute() at data_query.cpp:217 
> 0x45c705   
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:629 
> 0x42d32e  
> ignite::odbc::Statement::InternalExecuteSqlQuery() at statement.cpp:586 
> 0x42d499  
> ignite::odbc::Statement::ExecuteSqlQuery() at statement.cpp:576 0x42d4c1  
> ignite::SQLExecDirect() at odbc.cpp:395 0x42614c  
> GetDataWithOdbc() at odbc-crash-reproducer.cpp:151 0x40898a   
> QueryData() at odbc-crash-reproducer.cpp:172 0x408af2 
> <...more frames...>
> {code}
> Reproducer is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-7752) Update Ignite KafkaStreamer to use new KafkaConsmer configuration.



 [ 
https://issues.apache.org/jira/browse/IGNITE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-7752:
-
Ignite Flags: Docs Required

> Update Ignite KafkaStreamer to use new KafkaConsmer configuration.
> --
>
> Key: IGNITE-7752
> URL: https://issues.apache.org/jira/browse/IGNITE-7752
> Project: Ignite
>  Issue Type: Task
>  Components: streaming
>Reporter: Andrew Mashenkov
>Assignee: Roman Shtykh
>Priority: Major
>  Labels: newbie, streaming
> Fix For: 2.7
>
>
> Seems, for now it is impossible to use new style KafkaConsumer configuration 
> in KafkaStreamer.
> The issue here is Ignite use 
> kafka.consumer.Consumer.createJavaConsumerConnector() method which creates 
> old consumer (ZookeeperConsumerConnector).
> We should create a new KafkaConsumer instead which looks like support both, 
> old and new style configs.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4809) Cache.getAll can return partially commited results.



 [ 
https://issues.apache.org/jira/browse/IGNITE-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-4809:
-
Fix Version/s: (was: 2.7)

> Cache.getAll can return partially commited results.
> ---
>
> Key: IGNITE-4809
> URL: https://issues.apache.org/jira/browse/IGNITE-4809
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 1.7
>Reporter: Andrew Mashenkov
>Priority: Major
> Attachments: DirtyReads2.java
>
>
> 1. Create tansactional cache with Long values and fill it with zeroes.
> 2. Start thread that would increment all values in single transaction.
> 3. Start thread that would check all values are same in single transaction.
> Second thread will see partial commits, but shouldn't.
> Seems, it is related to OPTIMISTIC concurrency level only.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-4918) ScanQuery filter class code is not updated on server once it has been changed on client.



 [ 
https://issues.apache.org/jira/browse/IGNITE-4918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-4918:
-
Fix Version/s: (was: 2.7)
   2.8

> ScanQuery filter class code is not updated on server once it has been changed 
> on client.
> 
>
> Key: IGNITE-4918
> URL: https://issues.apache.org/jira/browse/IGNITE-4918
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
> Attachments: ScanQueryFilter.java
>
>
> PFA reproducer attached. Peer class loading should be enabled on both, server 
> and client.
> Server should NOT has scan query filter class in its classpath.
> Steps to reproduce:
> - start standalone server
> - run repro, it should work fine.
> - run repro with changed filter code, it will return same results as on 
> previous step.
> Looks like filter code is cached on server and is never being updated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6781) Should we prohibit change of backups count if persistence is enabled?



 [ 
https://issues.apache.org/jira/browse/IGNITE-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6781:
-
Fix Version/s: (was: 2.8)

> Should we prohibit change of backups count if persistence is enabled?
> -
>
> Key: IGNITE-6781
> URL: https://issues.apache.org/jira/browse/IGNITE-6781
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Andrew Mashenkov
>Priority: Major
>
> For now Ignite allows to change number of backups in CacheConfiguration 
> between grid restarts with persistence enabled. I mean no error will be 
> thrown.
> If user get cache configuration object after restart it will see new 
> configuration,
> but user see restored configuration from persistence in Visor after grid 
> restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-6781) Should we prohibit change of backups count if persistence is enabled?



 [ 
https://issues.apache.org/jira/browse/IGNITE-6781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-6781:
-
Fix Version/s: (was: 2.7)
   2.8

> Should we prohibit change of backups count if persistence is enabled?
> -
>
> Key: IGNITE-6781
> URL: https://issues.apache.org/jira/browse/IGNITE-6781
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.2
>Reporter: Andrew Mashenkov
>Priority: Major
>
> For now Ignite allows to change number of backups in CacheConfiguration 
> between grid restarts with persistence enabled. I mean no error will be 
> thrown.
> If user get cache configuration object after restart it will see new 
> configuration,
> but user see restored configuration from persistence in Visor after grid 
> restart.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8596) SQL: remove unnecessary index lookups when query parallelism is enabled



 [ 
https://issues.apache.org/jira/browse/IGNITE-8596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8596:
-
Fix Version/s: (was: 2.7)
   2.8

> SQL: remove unnecessary index lookups when query parallelism is enabled
> ---
>
> Key: IGNITE-8596
> URL: https://issues.apache.org/jira/browse/IGNITE-8596
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Andrew Mashenkov
>Priority: Major
>  Labels: performance
> Fix For: 2.8
>
>
> See 
> {{org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor#onQueryRequest}}
>  method. If table is segmented, we will submit as many SQL requests as much 
> segments. But consider a case when target cache partition(s) is already 
> defined by user or derived through partition pruning. In this case most of 
> segments will not contain useful information and return empty result set. At 
> the same time these queries may impose index or data page scans, thus 
> consuming resources without a reason.
> To mitigate the problem we should not submit SQL requests to segments we are 
> not interested in.
> Note that it is not sufficient to simply skip SQL requests on mapper, because 
> reducer expects separate response for every message. We should fix both local 
> mapper logic as well as protocol.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-8878) Make WebConsole agent logging more verbose.



 [ 
https://issues.apache.org/jira/browse/IGNITE-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-8878:
-
Fix Version/s: (was: 2.7)
   2.8

> Make WebConsole agent logging more verbose.
> ---
>
> Key: IGNITE-8878
> URL: https://issues.apache.org/jira/browse/IGNITE-8878
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
>
> For now it is impossible to debug ssl handshake failures in console agent
> as it just log meaningless message with no cause and stacktrace and call 
> System.exit(1).
>  
> We have to make logging more verbose at debug level at least.
>  
> This is full log of failure:
>  
> [2018-06-26 15:01:54,060][INFO ][main][AgentLauncher] Connecting to: 
> [https://|https://10.44.38.53/] [x|http://10.44.38.53:8080/] 
> [.x.x.x|https://10.44.38.53/]
> [2018-06-26 15:01:54,233][ERROR][EventThread][AgentLauncher] Failed to 
> establish SSL connection to server, due to errors with SSL handshake.
> [2018-06-26 15:01:54,233][ERROR][EventThread][AgentLauncher] Add to 
> environment variable JVM_OPTS parameter "-Dtrust.all=true" to skip 
> certificate validation in case of using self-signed certificate.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9290) Make remove explicit locks async when node left.



 [ 
https://issues.apache.org/jira/browse/IGNITE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-9290:
-
Ignite Flags:   (was: Docs Required)

> Make remove explicit locks async when node left.
> 
>
> Key: IGNITE-9290
> URL: https://issues.apache.org/jira/browse/IGNITE-9290
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Critical
>  Labels: deadlock, iep-25
> Fix For: 2.7
>
>
> GridCacheMvccManager.removeExplicitNodeLocks() run synchronously in discovery 
> and exchange threads. This introduce unnecessary delays in discovery and 
> exchange process.
> Also, this may cause a deadlock on node stop if user transaction holds an 
> entry lock and awaits some Ignite manager response (e.g. cache store or DR or 
> CQ), as manager stops right after last exchange has finished so managers 
> can't detect node is stopping. 
>  
> [1] 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Synchronous-tx-entries-unlocking-in-discovery-exchange-threads-td33827.html]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-8502) Ignite client can hang during a rejoin



[ 
https://issues.apache.org/jira/browse/IGNITE-8502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594729#comment-16594729
 ] 

Alexey Goncharuk commented on IGNITE-8502:
--

Re-triggered TC, will merge after test results are ready.

> Ignite client can hang during a rejoin
> --
>
> Key: IGNITE-8502
> URL: https://issues.apache.org/jira/browse/IGNITE-8502
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> if server node doesn't response to client with 
> TcpDiscoveryNodeAddFinishedMessage, client can wait for ever if joinTimeout 
> == 0:
> [https://github.com/apache/ignite/blob/b6f1ab7a4cc3be5a09d14e4775a0f45ac09c87a5/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ClientImpl.java#L1866]
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9394) MVCC: pds corrupted after grid restart.



 [ 
https://issues.apache.org/jira/browse/IGNITE-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-9394:
-
Description: 
Ignite fails to apply unfinished checkpoint after restart. See stacktrace below.

 

java.lang.AssertionError: 
Assertion error on row: CacheObjectImpl [val=null, 
hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true], expireT
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2286)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2221)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.update(IgniteCacheOffheapManagerImpl.java:23
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.update(GridCacheOffheapManager.java:16
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.update(IgniteCacheOffheapManagerImpl.java:438)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:24
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.ja
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitio
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFutur
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: java.lang.AssertionError
 at 
org.apache.ignite.internal.processors.cache.tree.AbstractDataLeafIO.storeByOffset(AbstractDataLeafIO.java:67)
 at 
org.apache.ignite.internal.processors.cache.tree.AbstractDataLeafIO.storeByOffset(AbstractDataLeafIO.java:35)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.store(BPlusIO.java:183)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.insert(BPlusIO.java:270)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertSimple(BPlusTree.java:3395)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:3377)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:3257)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:435)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:416)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5594)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5579)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:346)
 at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:276)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$12300(BPlusTree.java:87)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3569)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7600(BPlusTree.java:3257)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2531)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2250)
 ... 14 more

  was:
Ignite fails to apply unfinished checkpoint after restart.



java.lang.AssertionError: Assertion error on row: CacheObjectImpl [val=null, 
hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true], expireT
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2286)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2221)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.update(IgniteCacheOffheapManagerImpl.java:23
 at

[jira] [Created] (IGNITE-9394) MVCC: pds corrupted after grid restart.

Andrew Mashenkov created IGNITE-9394:


 Summary: MVCC: pds corrupted after grid restart.
 Key: IGNITE-9394
 URL: https://issues.apache.org/jira/browse/IGNITE-9394
 Project: Ignite
  Issue Type: Bug
Reporter: Andrew Mashenkov


Ignite fails to apply unfinished checkpoint after restart.



java.lang.AssertionError: Assertion error on row: CacheObjectImpl [val=null, 
hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true], expireT
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2286)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2221)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.update(IgniteCacheOffheapManagerImpl.java:23
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.update(GridCacheOffheapManager.java:16
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.update(IgniteCacheOffheapManagerImpl.java:438)
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:24
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.ja
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1
 at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitio
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFutur
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:
 at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
 at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.AssertionError
 at 
org.apache.ignite.internal.processors.cache.tree.AbstractDataLeafIO.storeByOffset(AbstractDataLeafIO.java:67)
 at 
org.apache.ignite.internal.processors.cache.tree.AbstractDataLeafIO.storeByOffset(AbstractDataLeafIO.java:35)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.store(BPlusIO.java:183)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.insert(BPlusIO.java:270)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertSimple(BPlusTree.java:3395)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:3377)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:3257)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:435)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:416)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5594)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5579)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:346)
 at 
org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:276)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$12300(BPlusTree.java:87)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3569)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7600(BPlusTree.java:3257)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2531)
 at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2250)
 ... 14 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9394) MVCC: pds corrupted after grid restart.



 [ 
https://issues.apache.org/jira/browse/IGNITE-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Mashenkov updated IGNITE-9394:
-
Component/s: persistence
 mvcc

> MVCC: pds corrupted after grid restart.
> ---
>
> Key: IGNITE-9394
> URL: https://issues.apache.org/jira/browse/IGNITE-9394
> Project: Ignite
>  Issue Type: Bug
>  Components: mvcc, persistence
>Reporter: Andrew Mashenkov
>Priority: Critical
>
> Ignite fails to apply unfinished checkpoint after restart.
> java.lang.AssertionError: Assertion error on row: CacheObjectImpl [val=null, 
> hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true], expireT
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2286)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2221)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.update(IgniteCacheOffheapManagerImpl.java:23
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.update(GridCacheOffheapManager.java:16
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.update(IgniteCacheOffheapManagerImpl.java:438)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:24
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.ja
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1
>  at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitio
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFutur
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java
>  at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:
>  at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>  at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AssertionError
>  at 
> org.apache.ignite.internal.processors.cache.tree.AbstractDataLeafIO.storeByOffset(AbstractDataLeafIO.java:67)
>  at 
> org.apache.ignite.internal.processors.cache.tree.AbstractDataLeafIO.storeByOffset(AbstractDataLeafIO.java:35)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.store(BPlusIO.java:183)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusIO.insert(BPlusIO.java:270)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertSimple(BPlusTree.java:3395)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:3377)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:3257)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:435)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:416)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5594)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5579)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:346)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:276)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$12300(BPlusTree.java:87)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3569)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7600(BPlusTree.java:3257)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2531)
>  at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2250)
>  ... 14 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-3471) Do not send previous value to client node for invoke() when possible

2018-08-28 Thread Dmitry Karachentsev (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-3471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Karachentsev reassigned IGNITE-3471:
---

Assignee: (was: Dmitry Karachentsev)

> Do not send previous value to client node for invoke() when possible
> 
>
> Key: IGNITE-3471
> URL: https://issues.apache.org/jira/browse/IGNITE-3471
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Attachments: CacheEntryProcessorTxSelfTest.java
>
>
> Currently for invoke() or invokeAll() methods we send previous cache value to 
> near node and apply EntryProcessor locally to get a return value. This can 
> induce a significant overhead when cache value is much larger than entry 
> processor result.
> For many cases this can be avoided, e.g.
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in 
> this case.
> tx.commit();
> }
> {code}
> Note that we need to add additional handling of such a case:
> {code}
> try (tx = txStart()) {
> cache.invoke(key, EP); // No need to send previous value to client in 
> this case.
> cache.get(key); // This should actually get the current cache value from 
> primary node and apply an entry processor locally to get the updated value.
> tx.commit();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-336) We need to add dynamic turn on/off cache statistics for Visor.

2018-08-28 Thread Vasiliy Sisko (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594709#comment-16594709
 ] 

Vasiliy Sisko commented on IGNITE-336:
--

Fixed task options. Fixed toggle of statistics collection.

> We need to add dynamic turn on/off cache statistics for Visor.
> --
>
> Key: IGNITE-336
> URL: https://issues.apache.org/jira/browse/IGNITE-336
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-2
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Major
>
> We need create task to turn on/off of cache statistics collecting.
> Create Visor command for toggling.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (IGNITE-336) We need to add dynamic turn on/off cache statistics for Visor.

2018-08-28 Thread Vasiliy Sisko (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vasiliy Sisko reassigned IGNITE-336:


Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> We need to add dynamic turn on/off cache statistics for Visor.
> --
>
> Key: IGNITE-336
> URL: https://issues.apache.org/jira/browse/IGNITE-336
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: sprint-2
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
>
> We need create task to turn on/off of cache statistics collecting.
> Create Visor command for toggling.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9362) SQL: Remove NODES.IS_LOCAL attribute



[ 
https://issues.apache.org/jira/browse/IGNITE-9362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594683#comment-16594683
 ] 

ASF GitHub Bot commented on IGNITE-9362:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4610


> SQL: Remove NODES.IS_LOCAL attribute
> 
>
> Key: IGNITE-9362
> URL: https://issues.apache.org/jira/browse/IGNITE-9362
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-13
> Fix For: 2.7
>
>
> We need to remove {{IS_LOCAL}} attribute from {{NODES}} system view. This 
> attribute doesn't make sense: it depends on where SQL query is executed. When 
> executed from JDBC/ODBC driver user will received strange result, when remote 
> node is displayed as local.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9362) SQL: Remove NODES.IS_LOCAL attribute

2018-08-28 Thread Vladimir Ozerov (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-9362:

Ignite Flags:   (was: Docs Required)

> SQL: Remove NODES.IS_LOCAL attribute
> 
>
> Key: IGNITE-9362
> URL: https://issues.apache.org/jira/browse/IGNITE-9362
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-13
> Fix For: 2.7
>
>
> We need to remove {{IS_LOCAL}} attribute from {{NODES}} system view. This 
> attribute doesn't make sense: it depends on where SQL query is executed. When 
> executed from JDBC/ODBC driver user will received strange result, when remote 
> node is displayed as local.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module



[ 
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594675#comment-16594675
 ] 

Nikolai Kulagin commented on IGNITE-9165:
-

Close streams in core module.
PR: https://github.com/apache/ignite/pull/4478
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1723203=buildResultsDiv=IgniteTests24Java8_RunAll
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.

> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Fix For: 2.7
>
> Attachments: 
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields, 
> pass it to other methods that might close it, or return it, and does not 
> appear to close the stream on all paths out of the method.  This may result 
> in a file descriptor leak.
> Example:
>  
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
>  props.load(new FileReader(GridTestUtils.resolveIgnitePath(
>  "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
>  throw new RuntimeException(e);
> }{code}
>  
>  One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>   
>  +org.apache.ignite.internal:+   
>  * *BinaryContext*#classesInPackage(String)
>  * *GridClientJdkMarshaller*#marshal(Object, int)
>  * 
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
>  * *OptimizedObjectStreamSelfTest*#testReadLine()
>  * *PageIdDistributionTest*#_testRealHistory()
>  * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
>  * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
>  * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
>  * *GridTestUtils*.sslContext()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module



[ 
https://issues.apache.org/jira/browse/IGNITE-9165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594675#comment-16594675
 ] 

Nikolai Kulagin edited comment on IGNITE-9165 at 8/28/18 8:00 AM:
--

Close streams in core module.
PR: https://github.com/apache/ignite/pull/4481
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1723203=buildResultsDiv=IgniteTests24Java8_RunAll
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.


was (Author: zzzadruga):
Close streams in core module.
PR: https://github.com/apache/ignite/pull/4478
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1723203=buildResultsDiv=IgniteTests24Java8_RunAll
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.

> FindBugs: Methods may fail to close stream in core module
> -
>
> Key: IGNITE-9165
> URL: https://issues.apache.org/jira/browse/IGNITE-9165
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Fix For: 2.7
>
> Attachments: 
> findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html
>
>
> The method creates an IO stream object, does not assign it to any fields, 
> pass it to other methods that might close it, or return it, and does not 
> appear to close the stream on all paths out of the method.  This may result 
> in a file descriptor leak.
> Example:
>  
> {code:java}
> // GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()
> try {
>  props.load(new FileReader(GridTestUtils.resolveIgnitePath(
>  "modules/tests/config/cache-load.properties")));
> }
> catch (IOException e) {
>  throw new RuntimeException(e);
> }{code}
>  
>  One of possible solutions:
> {code:java}
> try (Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
> "modules/tests/config/cache-load.properties"))) {
> props.load(reader);
> }
> catch (IOException e) {
> throw new RuntimeException(e);
> }{code}
> List of classes in "core" module:
>   
>  +org.apache.ignite.internal:+   
>  * *BinaryContext*#classesInPackage(String)
>  * *GridClientJdkMarshaller*#marshal(Object, int)
>  * 
> *IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute()
>  * *OptimizedObjectStreamSelfTest*#testReadLine()
>  * *PageIdDistributionTest*#_testRealHistory()
>  * *HttpIgniteUpdatesChecker*#getUpdates(boolean)
>  * *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process)
> +org.apache.ignite:+
>  * *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest()
>  * *GridTestUtils*.sslContext()



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (IGNITE-9350) Web Console backend should not fail if null received via web sockets

2018-08-28 Thread Andrey Novikov (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Novikov closed IGNITE-9350.
--

> Web Console backend should not fail if null received via web sockets
> 
>
> Key: IGNITE-9350
> URL: https://issues.apache.org/jira/browse/IGNITE-9350
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.7
>
>
> Backend failed with error:
> {code}
> app/browsersHandler.js:207
>  sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
>  ^
> TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
> {code}
>  
> We should check  for null data received via web sockets



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance

2018-08-28 Thread Dmitriy Govorukhin (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin updated IGNITE-1678:
---
Ignite Flags: Docs Required

> IgniteAtomicSequence: make following reservations in advance
> 
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
>  Issue Type: Improvement
>  Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local 
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there 
> can be a situation when all the nodes start doing a new reservation at the 
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence 
> slot in advance (in background), like when around 80% of current reservation 
> has already been used. Probably we should add a special parameter to 
> {{AtomicConfiguration}} that will manage such behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9350) Web Console backend should not fail if null received via web sockets

2018-08-28 Thread Andrey Novikov (JIRA)



[ 
https://issues.apache.org/jira/browse/IGNITE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594671#comment-16594671
 ] 

Andrey Novikov commented on IGNITE-9350:


Reviewed. Looks good. Merged to master.

> Web Console backend should not fail if null received via web sockets
> 
>
> Key: IGNITE-9350
> URL: https://issues.apache.org/jira/browse/IGNITE-9350
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.7
>
>
> Backend failed with error:
> {code}
> app/browsersHandler.js:207
>  sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
>  ^
> TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
> {code}
>  
> We should check  for null data received via web sockets



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (IGNITE-9350) Web Console backend should not fail if null received via web sockets

2018-08-28 Thread Andrey Novikov (JIRA)



 [ 
https://issues.apache.org/jira/browse/IGNITE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrey Novikov updated IGNITE-9350:
---
Ignite Flags:   (was: Docs Required)

> Web Console backend should not fail if null received via web sockets
> 
>
> Key: IGNITE-9350
> URL: https://issues.apache.org/jira/browse/IGNITE-9350
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Andrey Novikov
>Priority: Major
> Fix For: 2.7
>
>
> Backend failed with error:
> {code}
> app/browsersHandler.js:207
>  sock.on('node:rest', (\{clusterId, params, credentials}, cb) => {
>  ^
> TypeError: Cannot destructure property `clusterId` of 'undefined' or 'null'.
> {code}
>  
> We should check  for null data received via web sockets



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods



[ 
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594672#comment-16594672
 ] 

Nikolai Kulagin commented on IGNITE-9160:
-

Fix equals() methods.
PR: https://github.com/apache/ignite/pull/4478
CI: 
https://ci.ignite.apache.org/viewLog.html?buildId=1717616=buildResultsDiv=IgniteTests24Java8_RunAll
Project is buildable, tests are ok, flacky as usual. [~garus.d.g], please, 
review my change.

> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
>  Labels: newbie
> Fix For: 2.7
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE  
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object 
> cannot be cast to 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
>  Or NPE 
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
>  The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
>     return false;{code}
> + List of classes with similar problems: +
>  * *GridTopic$T1-T8* - NPE
>  * *GridCachePreloadLifecycleAbstractTest -* NPE
>  * *GridDhtPartitionFullMap -* NPE and CCE
>  * *GridDhtPartitionMap -* NPE and CCE
>  * *OptimizedMarshallerSelfTest -* NPE and CCE
>  * *GatewayProtectedCacheProxy -* NPE and CCE
>  * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
>  * *GridCacheDistributedQueryManager -* NPE and CCE
>  * *GridServiceMethodReflectKey -* NPE and CCE
>  *  *GridListSetSelfTest -* NPE and CCE
>  * *GridTestKey -* NPE and CCE
>  * *GridCacheMvccCandidate -* CCE
>  * *GridDhtPartitionExchangeId -* CCE
>  * *GridTuple6 -* CCE



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Issue Comment Deleted] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods