[jira] [Created] (IGNITE-8040) Add Ignite nightly builds references to the site

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8040:
---

 Summary: Add Ignite nightly builds references to the site
 Key: IGNITE-8040
 URL: https://issues.apache.org/jira/browse/IGNITE-8040
 Project: Ignite
  Issue Type: New Feature
  Components: site
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.5


We should add a link to the nightly builds somewhere on the site:
https://ci.ignite.apache.org/viewType.html?buildTypeId=Releases_NightlyRelease_RunApacheIgniteNightlyRelease

Here is a relevant discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-nightly-release-builds-td27966.html



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

[jira] [Closed] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-7466.
---

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Commented] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7466:
-

Looks good, thanks, closing the ticket.

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Assigned] (IGNITE-7466) Document Direct IO optional plugin: purpose, setup, effect to persitent data store

[Prachi Garg (JIRA)]

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

Prachi Garg reassigned IGNITE-7466:
---

Assignee: Denis Magda  (was: Prachi Garg)

> Document Direct IO optional plugin: purpose, setup, effect to persitent data 
> store
> --
>
> Key: IGNITE-7466
> URL: https://issues.apache.org/jira/browse/IGNITE-7466
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.5
>
>
> Direct IO was supported in Apache Ignite under task 
> https://issues.apache.org/jira/browse/IGNITE-6341
> Small description can be found in original ticket 
> https://issues.apache.org/jira/browse/IGNITE-6341?focusedCommentId=16330305=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16330305
> It is necessary to document this feature at least in wiki, at most at 
> readme.io
>  



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

[jira] [Updated] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-8039:

Fix Version/s: 2.5

> Binary Client Protocol spec: data types/format clarifications
> -
>
> Key: IGNITE-8039
> URL: https://issues.apache.org/jira/browse/IGNITE-8039
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, thin client
>Affects Versions: 2.4
>Reporter: Alexey Kosenchuk
>Priority: Major
> Fix For: 2.5
>
>
> Assuming the Binary Client Protocol spec should be detalized enough to allow 
> a client development basing on the spec only, w/o looking at other client 
> implementations and asking additional questions...
> The following should be clarified / corrected in the Binary Client Protocol 
> spec (v.2.4) 
> (https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):
> Type Codes table:
> -
> - UUID (Guid) size: should be 16 bytes, not 8 (?) 
> - what is Object array (type code 23) ? What is the difference between it and 
> Objects Wrapped In​ Array (type code 27) ?
> - what is Collection USER_SET ?
> - what is Collection USER_COL ?
> - what is Collection SINGLETON_LIST ?
> - Collection: misprint: should be "... + length ..."
> - what is Decimal ?
> - what is Timestamp ?
> - what is Time ?
> Complex Objects:
> 
> - what does flag USER_TYPE mean ?
> - Schema "field Id; Java-style hash code of field" -> should be "... of field 
> name".
> - "Repeat for as many times as the total number of schemas you have" -> 
> should be "... total number of fields you have".
> - is it mandated that the number of fields in the Schema must be equal to the 
> number of fields in the Data Object ?
> Objects Wrapped In​ Array
> 
> - may binary objects with different type codes be in the same array ?
> - may complex objects with different type ids be in the same array ?
> - "All cache operations return complex objects inside a wrapper (but not 
> primitives)." -> does it mean that in general a complex object (103) must 
> always be sent via the Binary Protocol in a wrapper (27)? 
> - "Byte array size" -> "Payload size" or "Size of the whole array with 
> header" ?
> - Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
> any relations ("graph") between data objects in the protocol.
> Terminology
> ---
> Not critical but would be really convenient to define and use the same terms 
> along the whole spec. For example:
> - "binary object" is always the same as "data object" of any type (?). Can be 
> "standard/predefined type object" or "complex object".
> - "cluster" or "server" ?
> - "cluster member" or "server nodes" ?



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

[jira] [Comment Edited] (IGNITE-8014) Node.js client: basic/minimal version

[Alexey Kosenchuk (JIRA)]

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

Alexey Kosenchuk edited comment on IGNITE-8014 at 3/23/18 6:29 PM:
---

[~vozerov] thanks for the comments...

> 1) CacheClient - what is the purpose of setKeyType and setValueType methods 
> from user perspective?

To be able to specify the Binary Protocol types (at least, types codes) of keys 
and values which user plans to send/receive.

Their usage is optional.
 When the types are not explicitly specified, the client will do automatic 
mapping between some of the JavaScript types and the Binary Protocol types (the 
mapping table is described in the header of the ObjectType class).
 But this mapping may not satisfy user's needs.

For example, javascript has only one numeric type (number) that is standard 
double. But user may want to send the protocol's INT, not DOUBLE.

Alternatively, every send/receive method could have the types (type codes) 
specification parameters. But that seems excessive.

User still can send/receive data of different types to/from the same cache:
 a) either call setKeyType()/setValueType() methods to change the types before 
sending/receiving.
 b) or use different CacheClient instances operated with the same cache, and 
set different key/value types in different instances.
 c) or use automatic mapping only if it's enough.

> 2) Errors - typically we try to have as least different error types as 
> possible.

Fully agree with this approach.

> IllegalStateError, LostConnectionError - appears to be the same thing - 
> client is not connected; I would merge it into a single entity

They are different.
 IllegalStateError means an operation is not started at all (a request was not 
sent to the server).
 LostConnectionError means an operation was started (a request was sent to the 
server) but is not completed as the connection is lost (so, the response is not 
received).
 We believe it is an important difference for user.
 Will try to explain this more clearly in the comments.

> InternalError - I doubt user has any chance to react to this error in any way 
> except of logging or rethrowing; I would remove it and use base 
> IgniteClientError instead

The only reason was some consistency - base class error is never thrown, only 
subclasses. But this is not a strong reason)))

Actually, IllegalArgumentError, TypeCastError, UnsupportedTypeError are 
unlikely can be processed by user either. Usually just logged for debug purpose.
 Theoretically they also can be substituted by IgniteClientError with different 
messages.


was (Author: alexey.kosenchuk):
> 1) CacheClient - what is the purpose of setKeyType and setValueType methods 
> from user perspective?

To be able to specify the Binary Protocol types (at least, types codes) of keys 
and values which user plans to send/receive.

Their usage is optional.
 When the types are not explicitly specified, the client will do automatic 
mapping between some of the JavaScript types and the Binary Protocol types (the 
mapping table is described in the header of the ObjectType class).
 But this mapping may not satisfy user's needs.

For example, javascript has only one numeric type (number) that is standard 
double. But user may want to send the protocol's INT, not DOUBLE.

Alternatively, every send/receive method could have the types (type codes) 
specification parameters. But that seems excessive.

User still can send/receive data of different types to/from the same cache:
 a) either call setKeyType()/setValueType() methods to change the types before 
sending/receiving.
 b) or use different CacheClient instances operated with the same cache, and 
set different key/value types in different instances.
 c) or use automatic mapping only if it's enough.

> 2) Errors - typically we try to have as least different error types as 
> possible.

Fully agree with this approach.

> IllegalStateError, LostConnectionError - appears to be the same thing - 
> client is not connected; I would merge it into a single entity

They are different.
 IllegalStateError means an operation is not started at all (a request was not 
sent to the server).
 LostConnectionError means an operation was started (a request was sent to the 
server) but is not completed as the connection is lost (so, the response is not 
received).
 We believe it is an important difference for user.
 Will try to explain this more clearly in the comments.

> InternalError - I doubt user has any chance to react to this error in any way 
> except of logging or rethrowing; I would remove it and use base 
> IgniteClientError instead

The only reason was some consistency - base class error is never thrown, only 
subclasses. But this is not a strong reason)))

Actually, IllegalArgumentError, TypeCastError, UnsupportedTypeError are 
unlikely can be processed by user either. Usually just 

[jira] [Commented] (IGNITE-8014) Node.js client: basic/minimal version

[Alexey Kosenchuk (JIRA)]

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

Alexey Kosenchuk commented on IGNITE-8014:
--

> 1) CacheClient - what is the purpose of setKeyType and setValueType methods 
> from user perspective?

To be able to specify the Binary Protocol types (at least, types codes) of keys 
and values which user plans to send/receive.

Their usage is optional.
 When the types are not explicitly specified, the client will do automatic 
mapping between some of the JavaScript types and the Binary Protocol types (the 
mapping table is described in the header of the ObjectType class).
 But this mapping may not satisfy user's needs.

For example, javascript has only one numeric type (number) that is standard 
double. But user may want to send the protocol's INT, not DOUBLE.

Alternatively, every send/receive method could have the types (type codes) 
specification parameters. But that seems excessive.

User still can send/receive data of different types to/from the same cache:
 a) either call setKeyType()/setValueType() methods to change the types before 
sending/receiving.
 b) or use different CacheClient instances operated with the same cache, and 
set different key/value types in different instances.
 c) or use automatic mapping only if it's enough.

> 2) Errors - typically we try to have as least different error types as 
> possible.

Fully agree with this approach.

> IllegalStateError, LostConnectionError - appears to be the same thing - 
> client is not connected; I would merge it into a single entity

They are different.
 IllegalStateError means an operation is not started at all (a request was not 
sent to the server).
 LostConnectionError means an operation was started (a request was sent to the 
server) but is not completed as the connection is lost (so, the response is not 
received).
 We believe it is an important difference for user.
 Will try to explain this more clearly in the comments.

> InternalError - I doubt user has any chance to react to this error in any way 
> except of logging or rethrowing; I would remove it and use base 
> IgniteClientError instead

The only reason was some consistency - base class error is never thrown, only 
subclasses. But this is not a strong reason)))

Actually, IllegalArgumentError, TypeCastError, UnsupportedTypeError are 
unlikely can be processed by user either. Usually just logged for debug purpose.
 Theoretically they also can be substituted by IgniteClientError with different 
messages.

> Node.js client: basic/minimal version
> -
>
> Key: IGNITE-8014
> URL: https://issues.apache.org/jira/browse/IGNITE-8014
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Alexey Kosenchuk
>Assignee: Alexey Kosenchuk
>Priority: Major
>
> Develop the first basic/minimal version - for initial review/feedback.



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

[jira] [Created] (IGNITE-8039) Binary Client Protocol spec: data types/format clarifications

[Alexey Kosenchuk (JIRA)]

Alexey Kosenchuk created IGNITE-8039:


 Summary: Binary Client Protocol spec: data types/format 
clarifications
 Key: IGNITE-8039
 URL: https://issues.apache.org/jira/browse/IGNITE-8039
 Project: Ignite
  Issue Type: Bug
  Components: documentation, thin client
Affects Versions: 2.4
Reporter: Alexey Kosenchuk


Assuming the Binary Client Protocol spec should be detalized enough to allow a 
client development basing on the spec only, w/o looking at other client 
implementations and asking additional questions...

The following should be clarified / corrected in the Binary Client Protocol 
spec (v.2.4) 
(https://apacheignite.readme.io/v2.4/docs/binary-client-protocol#section-data-format):

Type Codes table:
-

- UUID (Guid) size: should be 16 bytes, not 8 (?) 

- what is Object array (type code 23) ? What is the difference between it and 
Objects Wrapped In​ Array (type code 27) ?

- what is Collection USER_SET ?

- what is Collection USER_COL ?

- what is Collection SINGLETON_LIST ?

- Collection: misprint: should be "... + length ..."

- what is Decimal ?

- what is Timestamp ?

- what is Time ?

Complex Objects:


- what does flag USER_TYPE mean ?

- Schema "field Id; Java-style hash code of field" -> should be "... of field 
name".

- "Repeat for as many times as the total number of schemas you have" -> should 
be "... total number of fields you have".

- is it mandated that the number of fields in the Schema must be equal to the 
number of fields in the Data Object ?

Objects Wrapped In​ Array


- may binary objects with different type codes be in the same array ?

- may complex objects with different type ids be in the same array ?

- "All cache operations return complex objects inside a wrapper (but not 
primitives)." -> does it mean that in general a complex object (103) must 
always be sent via the Binary Protocol in a wrapper (27)? 

- "Byte array size" -> "Payload size" or "Size of the whole array with header" ?

- Offset. What is "object graph" here ? The Binary Protocol nowhere describes 
any relations ("graph") between data objects in the protocol.

Terminology
---

Not critical but would be really convenient to define and use the same terms 
along the whole spec. For example:

- "binary object" is always the same as "data object" of any type (?). Can be 
"standard/predefined type object" or "complex object".

- "cluster" or "server" ?

- "cluster member" or "server nodes" ?




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

[jira] [Updated] (IGNITE-7969) Flaky failure of IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-7969:

Fix Version/s: 2.5

> Flaky failure of 
> IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup
> --
>
> Key: IGNITE-7969
> URL: https://issues.apache.org/jira/browse/IGNITE-7969
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test fails on TeamCity with exception:
> {noformat}
> java.lang.AssertionError: Successful tryPut after failure [gridIdx=2, 
> sucessful puts = 50]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:491)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidator0(IgniteTopologyValidatorGridSplitCacheTest.java:281)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup(IgniteTopologyValidatorGridSplitCacheTest.java:234)
> ...
> Caused by: class org.apache.ignite.IgniteException: Failed to put entry
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:498)
>   ... 11 more
>   Suppressed: class org.apache.ignite.IgniteException: Failed to put 
> entry [node=cache.IgniteTopologyValidatorGridSplitCacheTest0]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:463)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:488)
>   ... 11 more
>   Suppressed: junit.framework.AssertionFailedError: expected:<1> 
> but was:<2>
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at 
> junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:448)
>   ... 12 more
> ...
> {noformat}
> Sometimes reproduces locally.



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

[jira] [Commented] (IGNITE-7969) Flaky failure of IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7969:
-

[~alex_pl] LGTM! Merged to master branch. Thanks for contribution!

> Flaky failure of 
> IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup
> --
>
> Key: IGNITE-7969
> URL: https://issues.apache.org/jira/browse/IGNITE-7969
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Test fails on TeamCity with exception:
> {noformat}
> java.lang.AssertionError: Successful tryPut after failure [gridIdx=2, 
> sucessful puts = 50]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:491)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidator0(IgniteTopologyValidatorGridSplitCacheTest.java:281)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup(IgniteTopologyValidatorGridSplitCacheTest.java:234)
> ...
> Caused by: class org.apache.ignite.IgniteException: Failed to put entry
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:498)
>   ... 11 more
>   Suppressed: class org.apache.ignite.IgniteException: Failed to put 
> entry [node=cache.IgniteTopologyValidatorGridSplitCacheTest0]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:463)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:488)
>   ... 11 more
>   Suppressed: junit.framework.AssertionFailedError: expected:<1> 
> but was:<2>
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at 
> junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteTopologyValidatorGridSplitCacheTest.tryPut(IgniteTopologyValidatorGridSplitCacheTest.java:448)
>   ... 12 more
> ...
> {noformat}
> Sometimes reproduces locally.



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

[jira] [Updated] (IGNITE-8038) DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testDropColumnCoordinatorChange is flaky

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-8038:

Description: 
Test fails on TC as well as locally with the following error:
{noformat}
SchemaOperationException [code=1, msg=Cache doesn't exist: SQL_PUBLIC_PERSON
]
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.processSchemaOperationLocal(GridQueryProcessor.java:1419)
at 
org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745){noformat}

No other important exceptions are in the log.

  was:
Test fails on TC as well as locally with the following error:
{noformat}
SchemaOperationException [code=1, msg=Cache doesn't exist: SQL_PUBLIC_PERSON
]
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.processSchemaOperationLocal(GridQueryProcessor.java:1419)
at 
org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745){noformat}


> DynamicColumnsConcurrentTransactionalPartitionedSelfTest#testDropColumnCoordinatorChange
>  is flaky
> -
>
> Key: IGNITE-8038
> URL: https://issues.apache.org/jira/browse/IGNITE-8038
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>
> Test fails on TC as well as locally with the following error:
> {noformat}
> SchemaOperationException [code=1, msg=Cache doesn't exist: SQL_PUBLIC_PERSON
> ]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processSchemaOperationLocal(GridQueryProcessor.java:1419)
> at 
> org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745){noformat}
> No other important exceptions are in the log.



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

[jira] [Commented] (IGNITE-8036) DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-8036:
-

Artifacts: [PR|https://github.com/apache/ignite/pull/3693], [TC 
run|https://ci.ignite.apache.org/viewQueued.html?itemId=1154905=queuedBuildOverviewTab].

 

Decided to not create upsource review for this tiny change. Also TC Run is only 
for Ignite Queries [2] suite; it is the only one affected.

> DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder
> -
>
> Key: IGNITE-8036
> URL: https://issues.apache.org/jira/browse/IGNITE-8036
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> It turned out that DynamicColumnsAbstractConcurrentSelfTest prepares 
> IgniteConfiguration without redefining default MulticastIpFinder which causes 
> flaky fails of tests later.
>  
> VmIpFinder should be used instead of MulticastIpFinder.



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

[jira] [Commented] (IGNITE-8036) DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8036:


GitHub user sergey-chugunov-1985 opened a pull request:

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

IGNITE-8036 MulticastIpFinder is replaced with VmIpFinder



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

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

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

https://github.com/apache/ignite/pull/3693.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 #3693


commit 870d7256c64c20b8c09c263f8f83bd5ec179d7a3
Author: Sergey Chugunov 
Date:   2018-03-23T16:22:05Z

IGNITE-8036 MulticastIpFinder is replaced with VmIpFinder




> DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder
> -
>
> Key: IGNITE-8036
> URL: https://issues.apache.org/jira/browse/IGNITE-8036
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> It turned out that DynamicColumnsAbstractConcurrentSelfTest prepares 
> IgniteConfiguration without redefining default MulticastIpFinder which causes 
> flaky fails of tests later.
>  
> VmIpFinder should be used instead of MulticastIpFinder.



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

[jira] [Assigned] (IGNITE-8036) DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov reassigned IGNITE-8036:
---

Assignee: Sergey Chugunov

> DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder
> -
>
> Key: IGNITE-8036
> URL: https://issues.apache.org/jira/browse/IGNITE-8036
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> It turned out that DynamicColumnsAbstractConcurrentSelfTest prepares 
> IgniteConfiguration without redefining default MulticastIpFinder which causes 
> flaky fails of tests later.
>  
> VmIpFinder should be used instead of MulticastIpFinder.



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

[jira] [Created] (IGNITE-8036) DynamicColumnsAbstractConcurrentSelfTest should not use MulticastIpFinder

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-8036:
---

 Summary: DynamicColumnsAbstractConcurrentSelfTest should not use 
MulticastIpFinder
 Key: IGNITE-8036
 URL: https://issues.apache.org/jira/browse/IGNITE-8036
 Project: Ignite
  Issue Type: Sub-task
Reporter: Sergey Chugunov


It turned out that DynamicColumnsAbstractConcurrentSelfTest prepares 
IgniteConfiguration without redefining default MulticastIpFinder which causes 
flaky fails of tests later.

 

VmIpFinder should be used instead of MulticastIpFinder.



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

[jira] [Assigned] (IGNITE-7834) Ignite Queries 2 fail rate is more than 95%: DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov reassigned IGNITE-7834:
---

Assignee: Sergey Chugunov

> Ignite Queries 2 fail rate is more than 95%: 
> DynamicColumnsAbstractConcurrentSelfTest and its subclasses are flaky
> --
>
> Key: IGNITE-7834
> URL: https://issues.apache.org/jira/browse/IGNITE-7834
> Project: Ignite
>  Issue Type: Test
>  Components: sql
>Reporter: Dmitriy Pavlov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Queries 2 suite has unstable tests DynamicColumns...
> Initially contrubuted by [~al.psc] in [IGNITE-5572]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgniteQueries2=%3Cdefault%3E=buildTypeStatusDiv
> Last 10 runs statistics:
> {noformat}
> Ignite Queries 2 [ tests 16 ]
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testAddColumnCoordinatorChange
>  (fail rate 5,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 5,8%) 
>  [2] IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testDropColumnCoordinatorChange
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicPartitionedSelfTest.testNodeJoinOnPendingDropOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testNodeJoinOnPendingAddOperation
>  (fail rate 3,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexPartitionedAtomicConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 3,6%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testAddConcurrentRebalance
>  (fail rate 2,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 2,5%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentPutRemove 
> (fail rate 2,2%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testDropConcurrentRebalance
>  (fail rate 1,9%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testClientReconnectWithCacheRestart
>  (fail rate 1,8%) 
>  IgniteBinaryCacheQueryTestSuite2: 
> DynamicColumnsConcurrentTransactionalPartitionedSelfTest.testDropConcurrentCacheDestroy
>  (fail rate 1,0%) 
> IgniteBinaryCacheQueryTestSuite2: 
> DynamicIndexReplicatedTransactionalConcurrentSelfTest.testClientReconnect 
> (fail rate 0,4%) 
> {noformat}



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

[jira] [Comment Edited] (IGNITE-8025) Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() implementation

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-8025 at 3/23/18 3:48 PM:
-

[~andrey-kuznetsov], I left one question in the review, will review later rest 
of this change.


was (Author: dpavlov):
[~andrey-kuznetsov], I left one question, will review later rest of this change.

> Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() 
> implementation
> --
>
> Key: IGNITE-8025
> URL: https://issues.apache.org/jira/browse/IGNITE-8025
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test
> Fix For: 2.5
>
> Attachments: BugRunMTAsyncTest.java
>
>
> GridTestUtils.runMultiThreadedAsync returns a future with cancel() support, 
> but cancellation implementation never interrupts threads that execute 
> user-provided tasks. That is, those threads can continue their execution even 
> after test method finishes.
> The reproducer attached demonstrates activity from threads created by test0 
> after test0 finished and test1 is being run.



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

[jira] [Commented] (IGNITE-8025) Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() implementation

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8025:


[~andrey-kuznetsov], I left one question, will review later rest of this change.

> Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() 
> implementation
> --
>
> Key: IGNITE-8025
> URL: https://issues.apache.org/jira/browse/IGNITE-8025
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test
> Fix For: 2.5
>
> Attachments: BugRunMTAsyncTest.java
>
>
> GridTestUtils.runMultiThreadedAsync returns a future with cancel() support, 
> but cancellation implementation never interrupts threads that execute 
> user-provided tasks. That is, those threads can continue their execution even 
> after test method finishes.
> The reproducer attached demonstrates activity from threads created by test0 
> after test0 finished and test1 is being run.



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

[jira] [Commented] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7928:


[~alexey.tank2] looks good to me.

> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
>          at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2142)
>          at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2231)
>          at 
> 

[jira] [Commented] (IGNITE-8004) Failed to find class BaselineTopology

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8004:


TC looks as red as usual. 

> Failed to find class BaselineTopology
> -
>
> Key: IGNITE-8004
> URL: https://issues.apache.org/jira/browse/IGNITE-8004
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>
> Broken compatibility when old node joining to cluster of new nodes.
>  
> {noformat}
> class org.apache.ignite.IgniteException: Failed to find class with given 
> class loader for unmarshalling (make sure same versions of all classes are 
> available on all nodes or enable peer-class-loading) 
> [clsLdr=sun.misc.Launcher$AppClassLoader@659e0bfd, cls=Unknown pair 
> [platformId=0, typeId=677944946]]
>     at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
>     at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.active(IgniteClusterImpl.java:315)
>     at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3462)
>     at 
> org.gridgain.grid.compatibility.tests.GridCompatibilitySnapshotOperationDifferentServersTest.start(GridCompatibilitySnapshotOperationDifferentServersTest.java:168)
>     at 
> org.gridgain.grid.compatibility.tests.GridCompatibilitySnapshotOperationDifferentServersTest.test(GridCompatibilitySnapshotOperationDifferentServersTest.java:86)
>     at 
> org.gridgain.grid.compatibility.tests.GridCompatibilitySnapshotOperationDifferentServersTest.testReverseOrderStart(GridCompatibilitySnapshotOperationDifferentServersTest.java:65)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>     at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>     at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>     at java.lang.reflect.Method.invoke(Method.java:498)
>     at junit.framework.TestCase.runTest(TestCase.java:176)
>     at 
> org.gridgain.grid.compatibility.tests.GridCompatibilityAbstractTest.runTestInternal(GridCompatibilityAbstractTest.java:137)
>     at 
> org.gridgain.grid.compatibility.tests.GridCompatibilityAbstractTest.access$000(GridCompatibilityAbstractTest.java:41)
>     at 
> org.gridgain.grid.compatibility.tests.GridCompatibilityAbstractTest$2.run(GridCompatibilityAbstractTest.java:168)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to find 
> class with given class loader for unmarshalling (make sure same versions of 
> all classes are available on all nodes or enable peer-class-loading) 
> [clsLdr=sun.misc.Launcher$AppClassLoader@659e0bfd, cls=Unknown pair 
> [platformId=0, typeId=677944946]]
>     at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:230)
>     at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
>     at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1775)
>     at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1962)
>     at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>     at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1791)
>     at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readObject(BinaryReaderExImpl.java:1329)
>     at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C4.readBinary(GridClosureProcessor.java:1959)
>     at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:833)
>     at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
>     at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>     at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:307)
>     at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
>     at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
>     at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9763)
>     at 
> org.apache.ignite.internal.processors.job.GridJobWorker.initialize(GridJobWorker.java:438)
>     at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1109)
>     at 
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
>     at 
> 

[jira] [Updated] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[Alexey Popov (JIRA)]

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

Alexey Popov updated IGNITE-7928:
-
Fix Version/s: 2.5

> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
>          at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2142)
>          at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2231)
>          at 
> 

[jira] [Assigned] (IGNITE-5466) Web Console: New Configuration Screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-5466:


Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web Console: New Configuration Screen
> -
>
> Key: IGNITE-5466
> URL: https://issues.apache.org/jira/browse/IGNITE-5466
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-5466) Web Console: New Configuration Screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-5466:
--

Migrations almost fixed (will fix remaining in separate issues).

> Web Console: New Configuration Screen
> -
>
> Key: IGNITE-5466
> URL: https://issues.apache.org/jira/browse/IGNITE-5466
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7902) Enable either swap space or persistence but not both

[Andrey Aleksandrov (JIRA)]

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

Andrey Aleksandrov commented on IGNITE-7902:


[~slukyanov] thank you for review. Your issues were fixed.

> Enable either swap space or persistence but not both 
> -
>
> Key: IGNITE-7902
> URL: https://issues.apache.org/jira/browse/IGNITE-7902
> Project: Ignite
>  Issue Type: Task
>Reporter: Prachi Garg
>Assignee: Andrey Aleksandrov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
>
> Enabling both swap and persistence at the same time for a data region does 
> not make sense. An exception should be thrown in this case.
> See discussion - 
> http://apache-ignite-developers.2346864.n4.nabble.com/Enabling-swap-space-and-Ignite-Persistence-td27595.html



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

[jira] [Comment Edited] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[Alexey Popov (JIRA)]

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

Alexey Popov edited comment on IGNITE-7928 at 3/23/18 3:21 PM:
---

TC run:

https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3690%2Fheadt


was (Author: alexey.tank2):
TC run:

https://ci.ignite.apache.org/viewLog.html?buildId=1154705=buildResultsDiv=IgniteTests24Java8_IgnitePlatformNet

> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
>          at 
> 

[jira] [Commented] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7928:
--

[~vozerov], [~ptupitsyn], please review the changes:
1) more clear error at .NET side in {{ReadUnregisteredType}} method
2) {{IgniteCheckedException}} is thrown if {{cacheStoreCreate}} JNI call fails. 
That helps to correctly handle error inside {{processClientCacheStartRequests}}
3) simple unit test added. It hungs before the fix.

> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
>          at 
> 

[jira] [Comment Edited] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[Alexey Popov (JIRA)]

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

Alexey Popov edited comment on IGNITE-7928 at 3/23/18 3:04 PM:
---

TC run:

https://ci.ignite.apache.org/viewLog.html?buildId=1154705=buildResultsDiv=IgniteTests24Java8_IgnitePlatformNet


was (Author: alexey.tank2):
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllNet=buildTypeStatusDiv_IgniteTests24Java8=pull%2F3690%2Fhead

> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
>          at 
> 

[jira] [Assigned] (IGNITE-8021) Destroyed caches can be return to life by restart grid

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy reassigned IGNITE-8021:


Assignee: Ivan Daschinskiy

> Destroyed caches can be return to life by restart grid
> --
>
> Key: IGNITE-8021
> URL: https://issues.apache.org/jira/browse/IGNITE-8021
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Ivan Daschinskiy
>Priority: Major
> Attachments: DstroedCacheReturnTest.java
>
>
> Cache configuration files stay stored on file system after invoke {{destroy}} 
> method.
> By the reason after restart grid all removed caches are start.
>  
> Look at the test [^DstroedCacheReturnTest.java]



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

[jira] [Commented] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7090:


[~ascherbakov], let me remind you about ASF Phylosophy 
https://www.apache.org/foundation/how-it-works.html and 
http://community.apache.org/projectIndependence.html 

So customer needs can't be an argument for speeding up any activities. You can 
suggest assistance, if you are interested in results. 

> Semaphore Stuck when no acquirers to assign permit
> --
>
> Key: IGNITE-7090
> URL: https://issues.apache.org/jira/browse/IGNITE-7090
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures
>Affects Versions: 2.1, 2.4
>Reporter: Tim Onyschak
>Assignee: Tim Onyschak
>Priority: Major
> Fix For: 2.5
>
> Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java
>
>
> If no acquirers are available to take permit of semaphore, the permit never 
> gets release and any further acquirerers will wait forever. 
> On node shut down DataStructuresProcessor.dsMap gets cleared out prior to 
> event listener being able to execute onNodeRemoved, hence owner is never 
> cleared out if it was unable to pass to a different acquirer. 
>  



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

[jira] [Updated] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-7786:

Description: 
Looks like there is hardcoded timeout for waiting result of change baseline 
operation

In big cluster there is following behaviour: (154 nodes)
 # Set new baseline topology version
 # Utility connects, but then fails by connection error
 # Cluster successfully activated

{code:java}
...Start node...
...Waiting for topology snapshot...

> control_utility.sh --baseline version 9
Control utility 
2017 Copyright(C) Apache Software Foundation
User: test

Failed to set baseline with specified topology version.
Connection to cluster failed.
Error: Failed to perform request (connection failed): /IP

...few milliseconds later...

> control_utility.sh --baseline version 9
Control utility 
2017 Copyright(C) Apache Software Foundation
User: test

Cluster state: active
Current topology version: 9
Baseline nodes:
ConsistentID=node1, STATE=ONLINE
ConsistentID=node10001, STATE=ONLINE
ConsistentID=node2, STATE=ONLINE
ConsistentID=node3, STATE=ONLINE
ConsistentID=node4, STATE=ONLINE

Number of baseline nodes: 5
Other nodes not found.{code}

  was:
Looks like there is hardcoded timeout for waiting result of change baseline 
operation

In big cluster there is following behaviour: (154 nodes)
 # Set new baseline topology version
 # Utility connects, but then fails by connection error
 # Cluster successfully activated


> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline 
> operation
> In big cluster there is following behaviour: (154 nodes)
>  # Set new baseline topology version
>  # Utility connects, but then fails by connection error
>  # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility 
> 2017 Copyright(C) Apache Software Foundation
> User: test
> 
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility 
> 2017 Copyright(C) Apache Software Foundation
> User: test
> 
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
> 
> Number of baseline nodes: 5
> Other nodes not found.{code}



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

[jira] [Updated] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-7786:

Description: 
Looks like there is hardcoded timeout for waiting result of change baseline 
operation

In cluster there is following behaviour: 
 # Set new baseline topology version
 # Utility starts, but then fails by connection error
 # Cluster successfully activated

{code:java}
...Start node...
...Waiting for topology snapshot...

> control_utility.sh --baseline version 9
Control utility 
2017 Copyright(C) Apache Software Foundation
User: test

Failed to set baseline with specified topology version.
Connection to cluster failed.
Error: Failed to perform request (connection failed): /IP

...few milliseconds later...

> control_utility.sh --baseline version 9
Control utility 
2017 Copyright(C) Apache Software Foundation
User: test

Cluster state: active
Current topology version: 9
Baseline nodes:
ConsistentID=node1, STATE=ONLINE
ConsistentID=node10001, STATE=ONLINE
ConsistentID=node2, STATE=ONLINE
ConsistentID=node3, STATE=ONLINE
ConsistentID=node4, STATE=ONLINE

Number of baseline nodes: 5
Other nodes not found.{code}

  was:
Looks like there is hardcoded timeout for waiting result of change baseline 
operation

In big cluster there is following behaviour: (154 nodes)
 # Set new baseline topology version
 # Utility connects, but then fails by connection error
 # Cluster successfully activated

{code:java}
...Start node...
...Waiting for topology snapshot...

> control_utility.sh --baseline version 9
Control utility 
2017 Copyright(C) Apache Software Foundation
User: test

Failed to set baseline with specified topology version.
Connection to cluster failed.
Error: Failed to perform request (connection failed): /IP

...few milliseconds later...

> control_utility.sh --baseline version 9
Control utility 
2017 Copyright(C) Apache Software Foundation
User: test

Cluster state: active
Current topology version: 9
Baseline nodes:
ConsistentID=node1, STATE=ONLINE
ConsistentID=node10001, STATE=ONLINE
ConsistentID=node2, STATE=ONLINE
ConsistentID=node3, STATE=ONLINE
ConsistentID=node4, STATE=ONLINE

Number of baseline nodes: 5
Other nodes not found.{code}


> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline 
> operation
> In cluster there is following behaviour: 
>  # Set new baseline topology version
>  # Utility starts, but then fails by connection error
>  # Cluster successfully activated
> {code:java}
> ...Start node...
> ...Waiting for topology snapshot...
> > control_utility.sh --baseline version 9
> Control utility 
> 2017 Copyright(C) Apache Software Foundation
> User: test
> 
> Failed to set baseline with specified topology version.
> Connection to cluster failed.
> Error: Failed to perform request (connection failed): /IP
> ...few milliseconds later...
> > control_utility.sh --baseline version 9
> Control utility 
> 2017 Copyright(C) Apache Software Foundation
> User: test
> 
> Cluster state: active
> Current topology version: 9
> Baseline nodes:
> ConsistentID=node1, STATE=ONLINE
> ConsistentID=node10001, STATE=ONLINE
> ConsistentID=node2, STATE=ONLINE
> ConsistentID=node3, STATE=ONLINE
> ConsistentID=node4, STATE=ONLINE
> 
> Number of baseline nodes: 5
> Other nodes not found.{code}



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

[jira] [Commented] (IGNITE-7852) ODBC: Support username/password authentication

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7852:
--

[~isapego] The patch is OK with me.

> ODBC: Support username/password authentication
> --
>
> Key: IGNITE-7852
> URL: https://issues.apache.org/jira/browse/IGNITE-7852
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-8035) Duplicated events in ContinuousQuery's Events Listener

[Ruslan Gilemzyanov (JIRA)]

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

Ruslan Gilemzyanov updated IGNITE-8035:
---
Affects Version/s: (was: 2.1)
   2.4

> Duplicated events in ContinuousQuery's Events Listener 
> ---
>
> Key: IGNITE-8035
> URL: https://issues.apache.org/jira/browse/IGNITE-8035
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Ruslan Gilemzyanov
>Priority: Major
>
> We faced with bug in ContinuousQuery's EventListener work in Ignite. I wrote 
> sample project to demonstrate it.
> We started 2 server nodes connected to the one cache.
> Topology snapshot became [ver=2, servers=2, clients=0, CPUs=4, heap=3.6GB]
> I have put elements in cache (about 50 elements). Elements were distributed 
> between two nodes approxiamtely in the same amount.
> After pushing every element to cache we waited 100ms (to ensure that Listener 
> did his work) and deleted element from cache. 
> Then we stopped one node. (Topology snapshot became [ver=3, servers=1, 
> clients=0, CPUs=4, heap=1.8GB])
> And then some absolutely randomly chosen (deleted from cache to this moment) 
> events came to other working node with status CREATED (Remind you that we 
> deleted them from cache to this moment). In our case it was 5 events.
> I think this is direct violation of Continuous Query's "exactly once 
> delivery" contract. 
> Source code is here: [https://github.com/ruslangm/ignite-sample]
>  



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

[jira] [Commented] (IGNITE-7912) control.sh script should show used WAL-segments

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy commented on IGNITE-7912:
--

Could you review my pull-request, please?

Tests seems to be ok.

> control.sh script should show used WAL-segments
> ---
>
> Key: IGNITE-7912
> URL: https://issues.apache.org/jira/browse/IGNITE-7912
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Filatov
>Assignee: Ivan Daschinskiy
>Priority: Minor
>
> We have to erase wal archive because wal archive can grow large and we must 
> have safe way to remove unused segments to free disk space.



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

[jira] [Commented] (IGNITE-5553) Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5553:


Hi [~ilantukh], 

I've checked changes but stil need advice if it safe to initialize set this way
https://reviews.ignite.apache.org/ignite/review/IGNT-CR-508

Could you please take a look to CacheDataStructuresManager and its 
initialization stages.

> Ignite PDS 2: IgnitePersistentStoreDataStructuresTest testSet assertion error
> -
>
> Key: IGNITE-5553
> URL: https://issues.apache.org/jira/browse/IGNITE-5553
> Project: Ignite
>  Issue Type: Bug
>  Components: data structures, persistence
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> h2. Notes-4435
> When IgniteSet is restored from persistence, size of set is always 0, [link 
> to test 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-7043871603266099589=testDetails].
> h2. Detailed description
> Unlike *IgniteQueue* which uses separate cache key to store its size 
> *IgniteSet* stores it in a field of some class.
> Test from the link above shows very clearly that after restoring memory state 
> from PDS all set values are restored correctly but size is lost.
> h2. Proposed solution
> One possible solution might be to do the same thing as *IgniteQueue* does: 
> size of *IgniteSet* must be stored is cache instead of volatile in-memory 
> fields of random classes.



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

[jira] [Assigned] (IGNITE-7628) SqlQuery hangs indefinitely with additional not registered in baseline node.

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin reassigned IGNITE-7628:
--

Assignee: (was: Dmitriy Govorukhin)

> SqlQuery hangs indefinitely with additional not registered in baseline node.
> 
>
> Key: IGNITE-7628
> URL: https://issues.apache.org/jira/browse/IGNITE-7628
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.5
>
> Attachments: 
> IgniteChangingBaselineCacheQueryAdditionalNodeSelfTest.java
>
>
> SqlQuery hangs indefinitely while additional node registered in topology but 
> still not in baseline.
> Reproducer attached. Apparently problem in 
> GridH2IndexRangeResponse#awaitForResponse func.



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

[jira] [Commented] (IGNITE-7090) Semaphore Stuck when no acquirers to assign permit

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7090:


Hi [~Timay], thank you.

This run loolks better than previous , but there are several failures in D
{noformat}
Ignite Data Structures [ tests 4 ]  
 IgniteCacheDataStructuresSelfTestSuite: 
GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreConstantTopologyChangeNonFailoverSafe
 (fail rate 3,0%) 
 IgniteCacheDataStructuresSelfTestSuite: 
GridCacheReplicatedDataStructuresFailoverSelfTest.testSemaphoreConstantTopologyChangeNonFailoverSafe
 (fail rate 1,8%) 
 IgniteCacheDataStructuresSelfTestSuite: 
GridCacheReplicatedDataStructuresFailoverSelfTest.testSemaphoreMultipleTopologyChangeNonFailoverSafe
 (fail rate 1,2%) 
IgniteCacheDataStructuresSelfTestSuite: 
GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreMultipleTopologyChangeNonFailoverSafe
 (fail rate 0,6%) 
{noformat}

Is it a separate issue, which is not to be fixed by your patch?


> Semaphore Stuck when no acquirers to assign permit
> --
>
> Key: IGNITE-7090
> URL: https://issues.apache.org/jira/browse/IGNITE-7090
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, data structures
>Affects Versions: 2.1, 2.4
>Reporter: Tim Onyschak
>Assignee: Tim Onyschak
>Priority: Major
> Fix For: 2.5
>
> Attachments: SemaphoreFailoverNoWaitingAcquirerTest.java
>
>
> If no acquirers are available to take permit of semaphore, the permit never 
> gets release and any further acquirerers will wait forever. 
> On node shut down DataStructuresProcessor.dsMap gets cleared out prior to 
> event listener being able to execute onNodeRemoved, hence owner is never 
> cleared out if it was unable to pass to a different acquirer. 
>  



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

[jira] [Updated] (IGNITE-8035) Duplicated events in ContinuousQuery's Events Listener

[Ruslan Gilemzyanov (JIRA)]

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

Ruslan Gilemzyanov updated IGNITE-8035:
---
Description: 
We faced with bug in ContinuousQuery's EventListener work in Ignite. I wrote 
sample project to demonstrate it.

We started 2 server nodes connected to the one cache.

Topology snapshot became [ver=2, servers=2, clients=0, CPUs=4, heap=3.6GB]

I have put elements in cache (about 50 elements). Elements were distributed 
between two nodes approxiamtely in the same amount.

After pushing every element to cache we waited 100ms (to ensure that Listener 
did his work) and deleted element from cache. 

Then we stopped one node. (Topology snapshot became [ver=3, servers=1, 
clients=0, CPUs=4, heap=1.8GB])

And then some absolutely randomly chosen (deleted from cache to this moment) 
events came to other working node with status CREATED (Remind you that we 
deleted them from cache to this moment). In our case it was 5 events.

I think this is direct violation of Continuous Query's "exactly once delivery" 
contract. 

Source code is here: [https://github.com/ruslangm/ignite-sample]

 

  was:
We faced with bug in ContinuousQuery's EventListener work in Ignite. I wrote 
sample project to demonstrate it.

We started 2 server nodes connected to the one cache.

Topology snapshot became [ver=2, servers=2, clients=0, CPUs=4, heap=3.6GB]

I have put elements in cache (about 50 elements). Elements were distributed 
between two nodes approxiamtely in the same amount.

After pushing every element to cache we waited 100ms (to ensure that Listener 
did his work) and deleted element from cache. 

Then we stopped one node. (Topology snapshot became [ver=3, servers=1, 
clients=0, CPUs=4, heap=1.8GB])

And then some absolutely randomly chosen (deleted from cache to this moment) 
events came to other working node with status CREATED (Remind you that we 
deleted them from cache to this moment). In our case it was 5 events.

I think this is direct violation of Continuous Query's "exactly once delivery" 
contract. 

Source code here: https://github.com/ruslangm/ignite-sample

 


> Duplicated events in ContinuousQuery's Events Listener 
> ---
>
> Key: IGNITE-8035
> URL: https://issues.apache.org/jira/browse/IGNITE-8035
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.1
>Reporter: Ruslan Gilemzyanov
>Priority: Major
>
> We faced with bug in ContinuousQuery's EventListener work in Ignite. I wrote 
> sample project to demonstrate it.
> We started 2 server nodes connected to the one cache.
> Topology snapshot became [ver=2, servers=2, clients=0, CPUs=4, heap=3.6GB]
> I have put elements in cache (about 50 elements). Elements were distributed 
> between two nodes approxiamtely in the same amount.
> After pushing every element to cache we waited 100ms (to ensure that Listener 
> did his work) and deleted element from cache. 
> Then we stopped one node. (Topology snapshot became [ver=3, servers=1, 
> clients=0, CPUs=4, heap=1.8GB])
> And then some absolutely randomly chosen (deleted from cache to this moment) 
> events came to other working node with status CREATED (Remind you that we 
> deleted them from cache to this moment). In our case it was 5 events.
> I think this is direct violation of Continuous Query's "exactly once 
> delivery" contract. 
> Source code is here: [https://github.com/ruslangm/ignite-sample]
>  



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

[jira] [Created] (IGNITE-8035) Duplicated events in ContinuousQuery's Events Listener

[Ruslan Gilemzyanov (JIRA)]

Ruslan Gilemzyanov created IGNITE-8035:
--

 Summary: Duplicated events in ContinuousQuery's Events Listener 
 Key: IGNITE-8035
 URL: https://issues.apache.org/jira/browse/IGNITE-8035
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.1
Reporter: Ruslan Gilemzyanov


We faced with bug in ContinuousQuery's EventListener work in Ignite. I wrote 
sample project to demonstrate it.

We started 2 server nodes connected to the one cache.

Topology snapshot became [ver=2, servers=2, clients=0, CPUs=4, heap=3.6GB]

I have put elements in cache (about 50 elements). Elements were distributed 
between two nodes approxiamtely in the same amount.

After pushing every element to cache we waited 100ms (to ensure that Listener 
did his work) and deleted element from cache. 

Then we stopped one node. (Topology snapshot became [ver=3, servers=1, 
clients=0, CPUs=4, heap=1.8GB])

And then some absolutely randomly chosen (deleted from cache to this moment) 
events came to other working node with status CREATED (Remind you that we 
deleted them from cache to this moment). In our case it was 5 events.

I think this is direct violation of Continuous Query's "exactly once delivery" 
contract. 

Source code here: https://github.com/ruslangm/ignite-sample

 



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

[jira] [Commented] (IGNITE-7682) C++: LocalSize cache functions

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov commented on IGNITE-7682:


[~isapego], Looks good to me.

> C++: LocalSize cache functions
> --
>
> Key: IGNITE-7682
> URL: https://issues.apache.org/jira/browse/IGNITE-7682
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 1.5.0.final
> Environment: Ignite builded by jdk1.8.0_152 with sources 
> tag:ignite-2.3
> cpp libs builded by Microsoft Visual Studio Enterprise 2015 Version 
> 14.0.25431.01 Update 3
> all x64
>Reporter: Roman Bastanov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> LocalSize functions with all variations of CachePeekMode returns same results.
> They always returns all cache size, the sum of all node caches.
> {code}
> auto cache = IgniteNode.GetCache<...>(cache_name);
> cache.LocalSize(ignite::cache::CachePeekMode::BACKUP)
> cache.LocalSize(ignite::cache::CachePeekMode::NEAR_CACHE)
> cache.LocalSize(ignite::cache::CachePeekMode::OFFHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::ONHEAP)
> cache.LocalSize(ignite::cache::CachePeekMode::PRIMARY)
> cache.LocalSize(ignite::cache::CachePeekMode::SWAP)
> {code}
> Despite this, manually calculations are correct, and returns local size(cache 
> on this node).
> {code}
> auto query = cache::query::ScanQuery();
> query.SetLocal(true);
> auto cursor = cache.Query(query);
> while (cursor.HasNext()) {
> cache_size++;
> }{code}



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

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7581:


Github user asfgit closed the pull request at:

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


> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> 

[jira] [Updated] (IGNITE-7786) Changing baseline topology on cluster may have error in control.sh utility

[Dmitry Sherstobitov (JIRA)]

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

Dmitry Sherstobitov updated IGNITE-7786:

Summary: Changing baseline topology on cluster may have error in control.sh 
utility  (was: Changing baseline topology on big cluster may have error in 
control.sh utility)

> Changing baseline topology on cluster may have error in control.sh utility
> --
>
> Key: IGNITE-7786
> URL: https://issues.apache.org/jira/browse/IGNITE-7786
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Dmitry Sherstobitov
>Priority: Major
>
> Looks like there is hardcoded timeout for waiting result of change baseline 
> operation
> In big cluster there is following behaviour: (154 nodes)
>  # Set new baseline topology version
>  # Utility connects, but then fails by connection error
>  # Cluster successfully activated



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

[jira] [Updated] (IGNITE-8034) .NET: Add "authenticationEnabled" flag to IgniteConfiguration

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-8034:

Description: Need to pass flag added as a part of IGNITE-7436.

> .NET: Add "authenticationEnabled" flag to IgniteConfiguration
> -
>
> Key: IGNITE-8034
> URL: https://issues.apache.org/jira/browse/IGNITE-8034
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Need to pass flag added as a part of IGNITE-7436.



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

[jira] [Assigned] (IGNITE-8034) .NET: Add "authenticationEnabled" flag to IgniteConfiguration

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-8034:
--

Assignee: Pavel Tupitsyn

> .NET: Add "authenticationEnabled" flag to IgniteConfiguration
> -
>
> Key: IGNITE-8034
> URL: https://issues.apache.org/jira/browse/IGNITE-8034
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov commented on IGNITE-7581:
-

[~dpavlov], thanks for review! I addressed both of your comments and kicked off 
new TC run to verify that nothing is broken.

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   

[jira] [Updated] (IGNITE-7770) Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 removal

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7770:
-
Description: 
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily 
due to resulting future timeout. It's caused by poor reproducible infinite 
park's in optimistic TX commit:

sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.commit(TransactionProxyImpl.java:293)
org.apache.ignite.internal.processors.cache.transactions.TxRollbackOnTimeoutTest$4.run(TxRollbackOnTimeoutTest.java:444)
org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)

There is also another failure for this test, it's described in separate ticket 
attached to this one.

  was:
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily 
due to resulting future timeout. It's caused by poor reproducible infinite 
park's in optimistic TX commit:




> Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 
> removal
> 
>
> Key: IGNITE-7770
> URL: https://issues.apache.org/jira/browse/IGNITE-7770
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails 
> flakily due to resulting future timeout. It's caused by poor reproducible 
> infinite park's in optimistic TX commit:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.commit(TransactionProxyImpl.java:293)
> org.apache.ignite.internal.processors.cache.transactions.TxRollbackOnTimeoutTest$4.run(TxRollbackOnTimeoutTest.java:444)
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> There is also another failure for this test, it's described in separate 
> ticket attached to this one.



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

[jira] [Commented] (IGNITE-7774) Missing Google Cloud libraries at binary release

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7774:


[~guseinov], sure.

> Missing Google Cloud libraries at binary release
> 
>
> Key: IGNITE-7774
> URL: https://issues.apache.org/jira/browse/IGNITE-7774
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.3
> Environment: * Ubuntu 16.04.3 LTS
> * Apache Ignite 2.3.0
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>  Labels: build
> Fix For: 2.5
>
>
> It looks like following libraries aren't included in the build:
>  * google-http-client-1.22.0.jar
>  * google-http-client-jackson2-1.22.0.jar
>  * google-oauth-client-1.22.0.jar
> Steps to reproduce:
> 1. Download apache-ignite-fabric-2.3.0-bin.zip 
> ([http://apache-mirror.rbc.ru/pub/apache//ignite/2.3.0/apache-ignite-fabric-2.3.0-bin.zip]).
> 2. Unzip archive.
> 3. Move ignite-rest-http from /libs/optional to /libs
> 4. Move ignite-gce from /libs/optional to /libs
> 5. Update IgniteConfiguration in default-config.xml:
> {code:xml}
> 
>   
> 
>class="org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder">
> 
> 
> 
>  value="discovery-sp...@apache-ignite.iam.gserviceaccount.com"/>
>   
> 
>   
> 
> {code}
> 6. Copy  into $IGNITE_HOME
> 7. Run bin/ignite.sh
> 8. Log:
> {code:java}
> class org.apache.ignite.IgniteException: Failed to instantiate Spring XML 
> application context (make sure all classes used in Spring configuration are 
> present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>  at org.apache.ignite.Ignition.start(Ignition.java:350)
>  at 
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
> instantiate Spring XML application context (make sure all classes used in 
> Spring configuration are present at CLASSPATH) 
> [springUrl=file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.applicationContext(IgniteSpringHelperImpl.java:387)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:104)
>  at 
> org.apache.ignite.internal.util.spring.IgniteSpringHelperImpl.loadConfigurations(IgniteSpringHelperImpl.java:98)
>  at 
> org.apache.ignite.internal.IgnitionEx.loadConfigurations(IgnitionEx.java:673)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:874)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>  at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>  at org.apache.ignite.Ignition.start(Ignition.java:347)
>  ... 1 more
> Caused by: org.springframework.beans.factory.BeanCreationException: Error 
> creating bean with name 
> 'org.apache.ignite.configuration.IgniteConfiguration#0' defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' of type 
> [org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi] while setting bean 
> property 'discoverySpi'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#65e2dbf3' 
> defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Cannot create inner bean 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  of type 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]
>  while setting bean property 'ipFinder'; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder#1d16f93d'
>  defined in URL 
> [file:/home/roman/Desktop/releases/gridgain-professional-fabric-2.3.3/config/default-config.xml]:
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> [org.apache.ignite.spi.discovery.tcp.ipfinder.gce.TcpDiscoveryGoogleStorageIpFinder]:
>  No default constructor found; nested exception is 

[jira] [Updated] (IGNITE-7770) Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 removal

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-7770:
-
Description: 
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily 
due to resulting future timeout. It's caused by poor reproducible infinite 
park's in optimistic TX commit:



  was:
Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 
removal
After appying IGNITE-7518 Get rid of org.jsr166.LongAdder8, 
 IgniteCacheTestSuite6: 
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations (fail rate 
38,6%) 

https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3733584033131292028=%3Cdefault%3E=testDetails



> Ignite Cache 6: testRandomMixedTxConfigurations failed probably after jsr166 
> removal
> 
>
> Key: IGNITE-7770
> URL: https://issues.apache.org/jira/browse/IGNITE-7770
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails 
> flakily due to resulting future timeout. It's caused by poor reproducible 
> infinite park's in optimistic TX commit:



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

[jira] [Commented] (IGNITE-7718) Collections.singleton() and Collections.singletonMap() are not properly serialized by binary marshaller

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7718:


[~vozerov], it seems code style is fixed now, could you please take a look if 
it is safe change?

> Collections.singleton() and Collections.singletonMap() are not properly 
> serialized by binary marshaller
> ---
>
> Key: IGNITE-7718
> URL: https://issues.apache.org/jira/browse/IGNITE-7718
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.3
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>
> After desialization collections obtained by Collections.singleton() and  
> Collections.singletonMap() does not return collection of binary objects, but 
> rather collection of deserialized objects. 



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

[jira] [Updated] (IGNITE-8017) Disable WAL during initial preloading

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh updated IGNITE-8017:
-
Description: 
While handling SupplyMessage, node handles each supplied data entry separately, 
which causes a WAL record for each entry to be written. It significantly limits 
preloading speed.
We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
until all data is loaded. The disadvantage of this approach is that data might 
get corrupted if node crashes - but node that crashed during preloading has to 
clear all it's data anyway. However, it is important to distinguish situations 
when new node joined cluster or added to baseline topology (and doesn't hold 
any data) and when additional partitions got assigned to node after baseline 
topology changed (in this case node has to keep all data in consistent state).

  was:
While handling SupplyMessage, node handles each supplied data entry separately, 
which causes a WAL record for each entry to be written. It significantly limits 
preloading speed, especially with WALMode == FSYNC - it will perform fsync for 
every entry!
We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
until all data is loaded. The disadvantage of this approach is that data might 
get corrupted if node crashes - but node that crashed during preloading has to 
clear all it's data anyway. However, it is important to distinguish situations 
when new node joined cluster or added to baseline topology (and doesn't hold 
any data) and when additional partitions got assigned to node after baseline 
topology changed (in this case node has to keep all data in consistent state).


> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be written. It 
> significantly limits preloading speed.
> We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
> until all data is loaded. The disadvantage of this approach is that data 
> might get corrupted if node crashes - but node that crashed during preloading 
> has to clear all it's data anyway. However, it is important to distinguish 
> situations when new node joined cluster or added to baseline topology (and 
> doesn't hold any data) and when additional partitions got assigned to node 
> after baseline topology changed (in this case node has to keep all data in 
> consistent state).



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

[jira] [Assigned] (IGNITE-8017) Disable WAL during initial preloading

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh reassigned IGNITE-8017:


Assignee: Ilya Lantukh

> Disable WAL during initial preloading
> -
>
> Key: IGNITE-8017
> URL: https://issues.apache.org/jira/browse/IGNITE-8017
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> While handling SupplyMessage, node handles each supplied data entry 
> separately, which causes a WAL record for each entry to be written. It 
> significantly limits preloading speed, especially with WALMode == FSYNC - it 
> will perform fsync for every entry!
> We can improve rebalancing speed and reduce pressure on disk by disabling WAL 
> until all data is loaded. The disadvantage of this approach is that data 
> might get corrupted if node crashes - but node that crashed during preloading 
> has to clear all it's data anyway. However, it is important to distinguish 
> situations when new node joined cluster or added to baseline topology (and 
> doesn't hold any data) and when additional partitions got assigned to node 
> after baseline topology changed (in this case node has to keep all data in 
> consistent state).



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

[jira] [Commented] (IGNITE-6807) NPE is thrown if local query is executed on client

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-6807:
-

Created test for this.At current master actual part of stacktrace:
{noformat}
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.segmentsCount(H2TreeIndex.java:187)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.threadLocalSegment(GridH2IndexBase.java:182)
at 
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find(H2TreeIndex.java:195)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2ProxyIndex.find(GridH2ProxyIndex.java:99)
at org.h2.index.BaseIndex.find(BaseIndex.java:128)
at org.h2.index.IndexCursor.find(IndexCursor.java:169)
at org.h2.table.TableFilter.next(TableFilter.java:468)
at org.h2.command.dml.Select.queryGroup(Select.java:311)
at org.h2.command.dml.Select.queryWithoutCache(Select.java:620)
at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
at org.h2.command.dml.Query.query(Query.java:352)
at org.h2.command.dml.Query.query(Query.java:333)
at org.h2.command.CommandContainer.query(CommandContainer.java:113)
at org.h2.command.Command.executeQuery(Command.java:201)
... 19 more
{noformat}

> NPE is thrown if local query is executed on client
> --
>
> Key: IGNITE-6807
> URL: https://issues.apache.org/jira/browse/IGNITE-6807
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
>
> If a local query is executed on client node by mistake, ugly NPE is thrown:
> {noformat}
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.segmentsCount(H2TreeIndex.java:162)
>   at 
> org.apache.ignite.internal.processors.query.h2.opt.GridH2IndexBase.threadLocalSegment(GridH2IndexBase.java:172)
>   at 
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find(H2TreeIndex.java:177)
>   at org.h2.index.BaseIndex.find(BaseIndex.java:128)
>   at org.h2.index.IndexCursor.find(IndexCursor.java:169)
>   at org.h2.table.TableFilter.next(TableFilter.java:468)
>   at 
> org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1452)
>   at org.h2.result.LazyResult.hasNext(LazyResult.java:79)
>   at org.h2.result.LazyResult.next(LazyResult.java:59)
>   at org.h2.command.dml.Select.queryFlat(Select.java:519)
>   at org.h2.command.dml.Select.queryWithoutCache(Select.java:625)
>   at org.h2.command.dml.Query.queryWithoutCacheLazyCheck(Query.java:114)
>   at org.h2.command.dml.Query.query(Query.java:352)
>   at org.h2.command.dml.Query.query(Query.java:333)
>   at org.h2.command.CommandContainer.query(CommandContainer.java:113)
>   at org.h2.command.Command.executeQuery(Command.java:201)
>   ... 21 more
> {noformat}
> We should detect this situation and throw proper exception instead.



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

[jira] [Commented] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7963:


[~ilyak], I've checked 
https://ci.ignite.apache.org/viewLog.html?buildId=1152323=buildResultsDiv=IgniteTests24Java8_RunAll

Unfortunately It is too much test failure there  [tests 72 suites 4]. 
Especially suspicious are
 IgniteCacheTestSuite2: CachePartitionStateTest.testPartitionState1_1 (fail 
rate 0,0%) 
  IgniteSpiTestSuite: 
GridTcpCommunicationSpiConcurrentConnectSslSelfTest.testWithLoad (fail rate 
0,0%) 
  IgnitePdsTestSuite2: 
IgnitePdsPageEvictionDuringPartitionClearTest.testPageEvictionOnNodeStart (fail 
rate 0,0%) 
  IgniteCacheQuerySelfTestSuite3: 
CacheContinuousQueryExecuteInPrimaryTest.testReplicatedCache (fail rate 0,0%) 
  IgniteBinaryCacheTestSuite: 
GridCacheBalancingStoreSelfTest.testConcurrentLoadAll (fail rate 0,0%) 

As simplest step you can merge current master into your branch and re-run 
tests. Probably these tests were already fixed.

Also feel free to create investigations for remaining failures to component 
mainteiners.

> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() 
> is never called
> 
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
>  futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE), 
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().



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

[jira] [Assigned] (IGNITE-5466) Web Console: New Configuration Screen

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-5466:
--

Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

> Web Console: New Configuration Screen
> -
>
> Key: IGNITE-5466
> URL: https://issues.apache.org/jira/browse/IGNITE-5466
> Project: Ignite
>  Issue Type: Task
>  Components: UI, wizards
>Reporter: Vica Abramova
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-8034) .NET: Add "authenticationEnabled" flag to IgniteConfiguration

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-8034:
---
Labels: MakeTeamcityGreenAgain  (was: )

> .NET: Add "authenticationEnabled" flag to IgniteConfiguration
> -
>
> Key: IGNITE-8034
> URL: https://issues.apache.org/jira/browse/IGNITE-8034
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Vladimir Ozerov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7962) More cases of suppressed exceptions in IsolatedUpdater

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7962:


[~gvvinblade], change seems reasonable to me, but I would like to hear expert 
opinion. Could you please take a look?

> More cases of suppressed exceptions in IsolatedUpdater
> --
>
> Key: IGNITE-7962
> URL: https://issues.apache.org/jira/browse/IGNITE-7962
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> IsolatedUpdater is a StreamReciever.
> The contract for StreamReciever.recieve() is, @throws 
> org.apache.ignite.IgniteException If failed.
> However, there's a number of cases where this doesn't happen and exceptions 
> are suppressed after being written in server log. Should replace (or augment) 
> log.error()'s with throw new IgniteException().
> See maillist discussion.



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

[jira] [Created] (IGNITE-8034) .NET: Add "authenticationEnabled" flag to IgniteConfiguration

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8034:
---

 Summary: .NET: Add "authenticationEnabled" flag to 
IgniteConfiguration
 Key: IGNITE-8034
 URL: https://issues.apache.org/jira/browse/IGNITE-8034
 Project: Ignite
  Issue Type: Task
  Components: platforms
Reporter: Vladimir Ozerov
 Fix For: 2.5






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

[jira] [Commented] (IGNITE-7814) Lost scala211.library.version parameter

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7814:


Github user asfgit closed the pull request at:

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


> Lost scala211.library.version parameter
> ---
>
> Key: IGNITE-7814
> URL: https://issues.apache.org/jira/browse/IGNITE-7814
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> How we can see in test 
> https://ci.ignite.apache.org/viewLog.html?buildId=1109854#testNameId451522206339372479.
>  We use
> scala211.library.version but I see that some time ago it was renamed to 
> scala.library.version at determination place.
> I think we can't use scala.library.version parameter and we will should 
> return scala211.library.version parameter because it is using at specific 
> place for scala2.11 .



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

[jira] [Commented] (IGNITE-7814) Lost scala211.library.version parameter

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7814:


[~akalashnikov], it seems this change will have impact only to osgi-karaf, so I 
am ok if it fixes test.

> Lost scala211.library.version parameter
> ---
>
> Key: IGNITE-7814
> URL: https://issues.apache.org/jira/browse/IGNITE-7814
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> How we can see in test 
> https://ci.ignite.apache.org/viewLog.html?buildId=1109854#testNameId451522206339372479.
>  We use
> scala211.library.version but I see that some time ago it was renamed to 
> scala.library.version at determination place.
> I think we can't use scala.library.version parameter and we will should 
> return scala211.library.version parameter because it is using at specific 
> place for scala2.11 .



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

[jira] [Updated] (IGNITE-7814) Lost scala211.library.version parameter

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7814:
---
Fix Version/s: 2.5

> Lost scala211.library.version parameter
> ---
>
> Key: IGNITE-7814
> URL: https://issues.apache.org/jira/browse/IGNITE-7814
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> How we can see in test 
> https://ci.ignite.apache.org/viewLog.html?buildId=1109854#testNameId451522206339372479.
>  We use
> scala211.library.version but I see that some time ago it was renamed to 
> scala.library.version at determination place.
> I think we can't use scala.library.version parameter and we will should 
> return scala211.library.version parameter because it is using at specific 
> place for scala2.11 .



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

[jira] [Assigned] (IGNITE-7119) Web Agent: Implement support for comma-delimited list of node URIs

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7119:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Web Agent: Implement support for comma-delimited list of node URIs
> --
>
> Key: IGNITE-7119
> URL: https://issues.apache.org/jira/browse/IGNITE-7119
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> We need to support several URLs for load-balancing and fault tolerance:
> It could look like this:
> {code}
> node-uri=http://10.1.1.1:8080,http://10.1.1.2:8080
> {code}



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

[jira] [Commented] (IGNITE-7581) TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7581:


TC looks as red as usual. I've left 2 questoins in review

> TxPessimisticDeadlockDetectionTest.testDeadlocksLocal hangs on TC
> -
>
> Key: IGNITE-7581
> URL: https://issues.apache.org/jira/browse/IGNITE-7581
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The test hangs because the ConcurrentModificationException happens:
> {code}
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:502)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.util.ArrayList$Itr.next(ArrayList.java:851)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.undoLocks(GridLocalLockFuture.java:297)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.onComplete(GridLocalLockFuture.java:437)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture.access$700(GridLocalLockFuture.java:57)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:510)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject$1.apply(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.cache.local.GridLocalLockFuture$LockTimeoutObject.onTimeout(GridLocalLockFuture.java:493)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:163)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> java.lang.Thread.run(Thread.java:745)
> [10:33:20]W:   [org.apache.ignite:ignite-core] [2018-01-31 
> 07:33:20,502][ERROR][grid-timeout-worker-#1556%transactions.TxPessimisticDeadlockDetectionTest0%][GridTimeoutProcessor]
>  Error when executing timeout callback: LockTimeoutObject []
> [10:33:20]W:   [org.apache.ignite:ignite-core] 
> java.util.ConcurrentModificationException
> [10:33:20]W:   [org.apache.ignite:ignite-core]at 
> 

[jira] [Commented] (IGNITE-7691) Provide info about DECIMAL column scale and precision

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7691:


GitHub user nizhikov opened a pull request:

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

IGNITE-7691: Provide info about DECIMAL column scale and precision



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

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

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

https://github.com/apache/ignite/pull/3691.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 #3691


commit a9c9548301056172454d83cb191a4866e37cb828
Author: Nikolay Izhikov 
Date:   2018-03-07T14:02:00Z

IGNITE-7691: Wrote some tests and empty implementation

commit 1b7604462321e40ea331e28be3f7d6352ffbd65c
Author: Nikolay Izhikov 
Date:   2018-03-14T19:31:38Z

IGNITE-7691: commit in the middle of development

commit 7bf4aee3db6362958c133c23f0efdd8fc8ef11fa
Author: Nikolay Izhikov 
Date:   2018-03-16T10:49:48Z

IGNITE-7691: Couple of edits to follow the way IGNITE-5623 follows.

commit 34b879264851d5b58133cd332d72fdfd2513d270
Author: Nikolay Izhikov 
Date:   2018-03-20T14:20:08Z

IGNITE-7691: One of failed tests fixed.

commit 8ec5d4508b60803dab0026ee1928e30207e4aa1b
Author: Nikolay Izhikov 
Date:   2018-03-22T19:12:45Z

Merge branch 'master' into IGNITE-7691

commit 496566a14ead99d368f8f933469ff7f63df9fa1d
Author: Nikolay Izhikov 
Date:   2018-03-23T09:16:41Z

Merge branch 'master' into IGNITE-7691

commit 4612eb7daad5bf31ccf0b603c2d66992f6185da5
Author: Nikolay Izhikov 
Date:   2018-03-23T10:44:15Z

IGNITE-7691: Tests seems to be OK




> Provide info about DECIMAL column scale and precision
> -
>
> Key: IGNITE-7691
> URL: https://issues.apache.org/jira/browse/IGNITE-7691
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.4
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Minor
> Fix For: 2.5
>
>
> Currently, it impossible to obtain scale and precision of DECIMAL column from 
> sql table metadata.
> Ignite should provide those type of meta information.



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

[jira] [Created] (IGNITE-8033) Flaky failure TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock on TC

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-8033:
-

 Summary: Flaky failure 
TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock on TC
 Key: IGNITE-8033
 URL: https://issues.apache.org/jira/browse/IGNITE-8033
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov


Test TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock flakily fail on 
TC. Sometimes with timeout, sometimes with the following error:

{noformat}
[2018-03-21 12:06:23,469][ERROR][main][root] Test failed.   

   
junit.framework.AssertionFailedError

   
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at 
org.apache.ignite.internal.processors.cache.transactions.TxOptimisticDeadlockDetectionCrossCacheTest.doTestDeadlock(TxOptimisticDeadlockDetectionCrossCacheTest.java:186)
at 
org.apache.ignite.internal.processors.cache.transactions.TxOptimisticDeadlockDetectionCrossCacheTest.testDeadlock(TxOptimisticDeadlockDetectionCrossCacheTest.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)   

 
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:745)
{noformat}




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

[jira] [Comment Edited] (IGNITE-8014) Node.js client: basic/minimal version

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov edited comment on IGNITE-8014 at 3/23/18 10:41 AM:
---

[~alexey.kosenchuk], in general code looks good. I have several comments 
regarding public API behavior:
1) {{CacheClient}} - what is the purpose of  {{setKeyType}} and 
{{setValueType}} methods from user perspective? In other languages we do not 
have such restriction and cache can store entries of different types (though, 
we tend to think of it as an antipattern). I am not an expert in NodeJS, may be 
this is a consequence of NodeJS type system?
2) {{Errors}} - typically we try to have as least different error types as 
possible. In this specific case:
- {{IllegalArgumentError}} - looks good
- {{OperationError}} - looks good
- {{TypeCastError}}, {{UnsupportedTypeError}} - looks good
- {{IllegalStateError}}, {{LostConnectionError}} - appears to be the same thing 
- client is not connected; I would merge it into a single entity
- {{InternalError}} - I doubt user has any chance to react to this error in any 
way except of logging or rethrowing; I would remove it and use base 
IgniteClientError instead


was (Author: vozerov):
[~alexey.kosenchuk], in general code looks good. I have several comments 
regarding public API behavior:
1) {{CacheClient}} - what is the purpose of  {{setKeyType}} and 
{{setValueType}} methods from user perspective? In other languages we do not 
have such restriction and cache can store entries of different types (though, 
we tend to think of it as an antipattern). I am not an expert in NodeJS, may be 
this is a consequence of NodeJS type system?
2) {{Errors}} - typically we try to have as least different error types as 
possible. In this specific case:
- {{IllegalArgumentError}} - looks good
- {{TypeCastError}}, {{UnsupportedTypeError}} - looks good
- {{IllegalStateError}}, {{LostConnectionError}} - appears to be the same thing 
- client is not connected; I would merge it into a single entity
- {{InternalError}} - I doubt user has any chance to react to this error in any 
way except of logging or rethrowing; I would remove it and use base 
IgniteClientError instead

> Node.js client: basic/minimal version
> -
>
> Key: IGNITE-8014
> URL: https://issues.apache.org/jira/browse/IGNITE-8014
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Alexey Kosenchuk
>Assignee: Alexey Kosenchuk
>Priority: Major
>
> Develop the first basic/minimal version - for initial review/feedback.



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

[jira] [Commented] (IGNITE-8014) Node.js client: basic/minimal version

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-8014:
-

[~alexey.kosenchuk], in general code looks good. I have several comments 
regarding public API behavior:
1) {{CacheClient}} - what is the purpose of  {{setKeyType}} and 
{{setValueType}} methods from user perspective? In other languages we do not 
have such restriction and cache can store entries of different types (though, 
we tend to think of it as an antipattern). I am not an expert in NodeJS, may be 
this is a consequence of NodeJS type system?
2) {{Errors}} - typically we try to have as least different error types as 
possible. In this specific case:
- {{IllegalArgumentError}} - looks good
- {{TypeCastError}}, {{UnsupportedTypeError}} - looks good
- {{IllegalStateError}}, {{LostConnectionError}} - appears to be the same thing 
- client is not connected; I would merge it into a single entity
- {{InternalError}} - I doubt user has any chance to react to this error in any 
way except of logging or rethrowing; I would remove it and use base 
IgniteClientError instead

> Node.js client: basic/minimal version
> -
>
> Key: IGNITE-8014
> URL: https://issues.apache.org/jira/browse/IGNITE-8014
> Project: Ignite
>  Issue Type: Sub-task
>  Components: thin client
>Reporter: Alexey Kosenchuk
>Assignee: Alexey Kosenchuk
>Priority: Major
>
> Develop the first basic/minimal version - for initial review/feedback.



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

[jira] [Updated] (IGNITE-8032) Fix issues within TX DML reducer.

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-8032:
---
Issue Type: Task  (was: Sub-task)
Parent: (was: IGNITE-4191)

> Fix issues within TX DML reducer.
> -
>
> Key: IGNITE-8032
> URL: https://issues.apache.org/jira/browse/IGNITE-8032
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Kalashnikov
>Assignee: Sergey Kalashnikov
>Priority: Major
>
> The following code review issues need to be addressed:
> 1. GridNearTxQueryResultsEnlistFuture
> 1.1. remove GridCacheCompoundIdentityFuture implementation.
> remote mini-futures.
> 1.2  Improve concurrency around sendNextBatches calls.
> 2. Refactor iterator UpdateIteratorAdapter/TxDmlReducerIterator to avoid 
> multi-level nesting.
> 3. Normalize usage of IgniteBiTuple(k,v)/Object(key) instead of Object[] to 
> represent rows.



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

[jira] [Created] (IGNITE-8032) Fix issues within TX DML reducer.

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-8032:
--

 Summary: Fix issues within TX DML reducer.
 Key: IGNITE-8032
 URL: https://issues.apache.org/jira/browse/IGNITE-8032
 Project: Ignite
  Issue Type: Sub-task
Reporter: Sergey Kalashnikov
Assignee: Sergey Kalashnikov


The following code review issues need to be addressed:

1. GridNearTxQueryResultsEnlistFuture

1.1. remove GridCacheCompoundIdentityFuture implementation.
remote mini-futures.
1.2  Improve concurrency around sendNextBatches calls.

2. Refactor iterator UpdateIteratorAdapter/TxDmlReducerIterator to avoid 
multi-level nesting.

3. Normalize usage of IgniteBiTuple(k,v)/Object(key) instead of Object[] to 
represent rows.




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

[jira] [Commented] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7928:
--

https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllNet=buildTypeStatusDiv_IgniteTests24Java8=pull%2F3690%2Fhead

> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428)
>          at 
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338)
>          at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2142)
>          at 
> 

[jira] [Commented] (IGNITE-7928) .NET: Exception is not propagated to the C# client and the app hangs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7928:


GitHub user apopovgg opened a pull request:

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

IGNITE-7928 .NET: Exception is not propagated to the C# client and th…

…e app hangs

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

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

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

https://github.com/apache/ignite/pull/3690.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 #3690


commit 7090407889d0ade418167054e7660c1af6cab48e
Author: apopov 
Date:   2018-03-23T10:24:50Z

IGNITE-7928 .NET: Exception is not propagated to the C# client and the app 
hangs




> .NET: Exception is not propagated to the C# client and the app hangs
> 
>
> Key: IGNITE-7928
> URL: https://issues.apache.org/jira/browse/IGNITE-7928
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> An exception like https://issues.apache.org/jira/browse/IGNITE-1903 is not 
> propagated to the C# client:
> the issue has happened during JNI call, that is why .NET hung.
> The marshaller is unable to unmarshal CacheStoreFactory class (it is absent 
> on the client node).
>  
> Stack trace:
>  
> {code:java}
> class org.apache.ignite.IgniteException: Platform 
> error:System.ArgumentNullException: Value cannot be null. Parameter name: key 
>    at System.ThrowHelper.ThrowArgumentNullException(ExceptionArgument 
> argument)    at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)   
>  at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& 
> value)    at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type 
> type)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadFullObject[T](Int32 pos, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Binary.BinaryReader.ReadBinaryObject[T](Boolean 
> doDetach)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.TryDeserialize[T](T& res, Type 
> typeOverride)    at 
> Apache.Ignite.Core.Impl.Binary.BinaryReader.Deserialize[T](Type typeOverride) 
>    at Apache.Ignite.Core.Impl.Cache.Store.CacheStore.CreateInstance(Int64 
> memPtr, HandleRegistry registry)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.CacheStoreCreate(Int64 
> memPtr)    at 
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.InLongOutLong(Void* 
> target, Int32 type, Int64 val)         at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:373)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:423)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:434)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
>          at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackUtils.inLongOutLong(Native
>  Method)         at 
> org.apache.ignite.internal.processors.platform.callback.PlatformCallbackGateway.cacheStoreCreate(PlatformCallbackGateway.java:65)
>          at 
> org.apache.ignite.internal.processors.platform.dotnet.PlatformDotNetCacheStore.initialize(PlatformDotNetCacheStore.java:403)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore0(PlatformProcessorImpl.java:650)
>          at 
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.registerStore(PlatformProcessorImpl.java:293)
>          at 
> org.apache.ignite.internal.processors.cache.store.CacheOsStoreManager.start0(CacheOsStoreManager.java:60)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:50)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCache(GridCacheProcessor.java:1097)
>          at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1826)
>          at 
> 

[jira] [Created] (IGNITE-8031) MVCC TX: TxLog does not support partitions rebalance at the moment. We need to implement it.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-8031:
--

 Summary: MVCC TX: TxLog does not support partitions rebalance at 
the moment. We need to implement it.
 Key: IGNITE-8031
 URL: https://issues.apache.org/jira/browse/IGNITE-8031
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Roman Kondakov


When new node joins to the cluster after the partitions rebalance it has empty 
TxLog. And therefore all transactions committed before this join are considered 
as uncommitted by this node.

We need to replicate TxLog to the new nodes as well as data partitions.



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

[jira] [Resolved] (IGNITE-7604) SQL TX: Allow DML operations with reducer

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov resolved IGNITE-7604.

Resolution: Fixed

> SQL TX: Allow DML operations with reducer
> -
>
> Key: IGNITE-7604
> URL: https://issues.apache.org/jira/browse/IGNITE-7604
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Sergey Kalashnikov
>Priority: Major
>
> The following protocol is proposed for DML request with non-trivial reduce 
> step within a transaction.
> 1. The SQL select part is deduced from a DML request and is split to form 
> two-step map/reduce request.
> 2. Map query requests are sent to data nodes which execute them locally.
> 3. Resulting data pages are sent to originating node (reducer), which 
> accumulates them.
> 4. Originating node performs reduce step on data received from map nodes and 
> forms batches of updates to apply to target table.
> 5. Lock requests containing delta updates are mapped and sent to data nodes 
> storing the corresponding keys.
> 6. Lock acks are received at originating node and accumulated there, 
> producing the total update counter.
> Note that no locks are acquired when map requests are processed. 
> This is consistent with what Oracle and PostgreSQL do (but not MySQL!) with 
> respect to locks within complex DML statements.
> The Oracle docs 
> (https://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT1351)
>  specifically states:
> The transaction that contains a DML statement does not need to acquire row 
> locks on any rows selected by a subquery or an implicit query, such as a 
> query in a WHERE clause. A subquery or implicit query in a DML statement is 
> guaranteed to be consistent as of the start of the query and does not see the 
> effects of the DML statement it is part of.



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

[jira] [Commented] (IGNITE-7962) More cases of suppressed exceptions in IsolatedUpdater

[Ilya Kasnacheev (JIRA)]

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

Ilya Kasnacheev commented on IGNITE-7962:
-

[~dpavlov] I expect a formal review from you.

No, I didn't perform performance testing, but I don't see why it will be 
affected.

> More cases of suppressed exceptions in IsolatedUpdater
> --
>
> Key: IGNITE-7962
> URL: https://issues.apache.org/jira/browse/IGNITE-7962
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> IsolatedUpdater is a StreamReciever.
> The contract for StreamReciever.recieve() is, @throws 
> org.apache.ignite.IgniteException If failed.
> However, there's a number of cases where this doesn't happen and exceptions 
> are suppressed after being written in server log. Should replace (or augment) 
> log.error()'s with throw new IgniteException().
> See maillist discussion.



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

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: 
{noformat}
"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000] 
java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method) - parking to wait for <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
 at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87) at 
org.h2.command.ddl.DropTable.update(DropTable.java:113) at 
org.h2.command.CommandContainer.update(CommandContainer.java:101) at 
org.h2.command.Command.executeUpdate(Command.java:260) - locked 
<0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137) - 
locked <0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122) at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
 - locked <0x7f0b69f822d0> (a java.lang.Object) at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:312)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2681)
 at 

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: 
{noformat}
"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87)
at org.h2.command.ddl.DropTable.update(DropTable.java:113)
at org.h2.command.CommandContainer.update(CommandContainer.java:101)
at org.h2.command.Command.executeUpdate(Command.java:260)
- locked <0x7f0c276c85b8> (a org.h2.engine.Session)
at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)
- locked <0x7f0c276c85b8> (a org.h2.engine.Session)
at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
- locked <0x7f0b69f822d0> (a java.lang.Object)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
at 

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: 
{noformat}

"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000] 
java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method) - parking to wait for <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
 at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87) at 
org.h2.command.ddl.DropTable.update(DropTable.java:113) at 
org.h2.command.CommandContainer.update(CommandContainer.java:101) at 
org.h2.command.Command.executeUpdate(Command.java:260) - locked 
<0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137) - 
locked <0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122) at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
 - locked <0x7f0b69f822d0> (a java.lang.Object) at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:312)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2681)
 at 

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: 
{noformat}
"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000] 
java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method) - parking to wait for <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
 at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87) at 
org.h2.command.ddl.DropTable.update(DropTable.java:113) at 
org.h2.command.CommandContainer.update(CommandContainer.java:101) at 
org.h2.command.Command.executeUpdate(Command.java:260) - locked 
<0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137) - 
locked <0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122) at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
 - locked <0x7f0b69f822d0> (a java.lang.Object) at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:312)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2681)
 at 

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: "sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000] 
java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method) - parking to wait for <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
 at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87) at 
org.h2.command.ddl.DropTable.update(DropTable.java:113) at 
org.h2.command.CommandContainer.update(CommandContainer.java:101) at 
org.h2.command.Command.executeUpdate(Command.java:260) - locked 
<0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137) - 
locked <0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122) at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
 - locked <0x7f0b69f822d0> (a java.lang.Object) at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:312)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2681)
 at 

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: 
"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000] 
java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method) - parking to wait for <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
 at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87) at 
org.h2.command.ddl.DropTable.update(DropTable.java:113) at 
org.h2.command.CommandContainer.update(CommandContainer.java:101) at 
org.h2.command.Command.executeUpdate(Command.java:260) - locked 
<0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137) - 
locked <0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122) at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
 - locked <0x7f0b69f822d0> (a java.lang.Object) at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:312)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2681)
 at 

[jira] [Updated] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8030:
--
Description: 
{noformat}

"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000] 
java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native 
Method) - parking to wait for <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)
 at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)
 at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)
 at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87) at 
org.h2.command.ddl.DropTable.update(DropTable.java:113) at 
org.h2.command.CommandContainer.update(CommandContainer.java:101) at 
org.h2.command.Command.executeUpdate(Command.java:260) - locked 
<0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137) - 
locked <0x7f0c276c85b8> (a org.h2.engine.Session) at 
org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122) at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)
 at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)
 at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)
 - locked <0x7f0b69f822d0> (a java.lang.Object) at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:332)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$2.onMessage(GridCachePartitionExchangeManager.java:312)
 at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2681)
 at 

[jira] [Commented] (IGNITE-8009) SQL local query to a cache with queryParallelism>1 doesn't use index

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-8009:
--

Looks like GridReduceQueryExecutor always force join order flag for map queries 
in query() method.

> SQL local query to a cache with queryParallelism>1  doesn't use index
> -
>
> Key: IGNITE-8009
> URL: https://issues.apache.org/jira/browse/IGNITE-8009
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3, 2.4
>Reporter: Pavel Vinokurov
>Priority: Major
> Attachments: ExplainAndIndexReproducer.java
>
>
> queryParallelism>1 + setLocal(true)  changes the query plan and exclude usage 
> of the sql index.
> Explain query with setLocal(false) and queryParallelism=1 :
> SELECT
> T__Z0.ID AS __C0_0
> FROM TABLE(COL VARCHAR='name0') I__Z1
> /* function */
> INNER JOIN PUBLIC.PERSON T__Z0
> /* PUBLIC.PERSON_NAME: NAME = I__Z1.COL */
> ON 1=1
> WHERE (T__Z0.SOURNAME = 'sourname0')
> AND (T__Z0.NAME = I__Z1.COL)
> Explain query with setLocal(true) and queryParallelism=2 :
> SELECT
> T__Z1.ID AS __C0_0
> FROM PUBLIC.PERSON T__Z1
> /* PUBLIC.PERSON.__SCAN_ */
> /* WHERE T__Z1.SOURNAME = 'sourname0'
> */
> INNER JOIN TABLE(COL VARCHAR='name0') I__Z0
> /* function: COL = T__Z1.NAME */
> ON 1=1
> WHERE (T__Z1.SOURNAME = 'sourname0')
> AND (T__Z1.NAME = I__Z0.COL)



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

[jira] [Created] (IGNITE-8030) Cluster hangs on deactivation process in time stopping indexed cache

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8030:
-

 Summary: Cluster hangs on deactivation process in time stopping 
indexed cache
 Key: IGNITE-8030
 URL: https://issues.apache.org/jira/browse/IGNITE-8030
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov
 Attachments: thrdump-server.log

{noformat}

"sys-#10283%DPL_GRID%DplGridNodeName%" #13068 prio=5 os_prio=0 
tid=0x7f07040eb000 nid=0x2e0f waiting on condition [0x7e6deb9b8000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x7f0bd2b0> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)

    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)

    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:897)

    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1222)

    at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lockInterruptibly(ReentrantReadWriteLock.java:998)

    at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:292)

    at 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.lock(GridH2Table.java:253)

    at org.h2.command.ddl.DropTable.prepareDrop(DropTable.java:87)

    at org.h2.command.ddl.DropTable.update(DropTable.java:113)

    at org.h2.command.CommandContainer.update(CommandContainer.java:101)

    at org.h2.command.Command.executeUpdate(Command.java:260)

    - locked <0x7f0c276c85b8> (a org.h2.engine.Session)

    at 
org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:137)

    - locked <0x7f0c276c85b8> (a org.h2.engine.Session)

    at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:122)

    at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dropTable(IgniteH2Indexing.java:654)

    at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.unregisterCache(IgniteH2Indexing.java:2482)

    at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop0(GridQueryProcessor.java:1684)

    - locked <0x7f0b69f822d0> (a java.lang.Object)

    at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.onCacheStop(GridQueryProcessor.java:879)

    at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1189)

    at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2063)

    at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onExchangeDone(GridCacheProcessor.java:2219)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:1518)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2538)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2297)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processSingleMessage(GridDhtPartitionsExchangeFuture.java:2034)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$100(GridDhtPartitionsExchangeFuture.java:122)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1891)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$2.apply(GridDhtPartitionsExchangeFuture.java:1879)

    at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)

    at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)

    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:1879)

    at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1523)

    at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1000(GridCachePartitionExchangeManager.java:133)

    at 

[jira] [Assigned] (IGNITE-8029) Web console: wrong behaviour of cluster activation component

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-8029:
--

Assignee: Dmitriy Shabalin  (was: Alexey Kuznetsov)

> Web console: wrong behaviour of cluster activation component
> 
>
> Key: IGNITE-8029
> URL: https://issues.apache.org/jira/browse/IGNITE-8029
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Dmitriy Shabalin
>Priority: Minor
> Fix For: 2.5
>
>
> I've noticed that during activation the text 'Deactivation' is printed for 
> ~0.5 second
> and else - during deactivation, the text 'Activation' is printed



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

[jira] [Closed] (IGNITE-8002) Authentication: add to REST support of new authentication

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-8002.


> Authentication:  add to REST support of new authentication
> --
>
> Key: IGNITE-8002
> URL: https://issues.apache.org/jira/browse/IGNITE-8002
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Assigned] (IGNITE-8002) Authentication: add to REST support of new authentication

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8002:


Assignee: Alexey Kuznetsov  (was: Taras Ledkov)

> Authentication:  add to REST support of new authentication
> --
>
> Key: IGNITE-8002
> URL: https://issues.apache.org/jira/browse/IGNITE-8002
> Project: Ignite
>  Issue Type: Task
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-8029) Web console: wrong behaviour of cluster activation component

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8029:
---
Affects Version/s: 2.4

> Web console: wrong behaviour of cluster activation component
> 
>
> Key: IGNITE-8029
> URL: https://issues.apache.org/jira/browse/IGNITE-8029
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
>
> I've noticed that during activation the text 'Deactivation' is printed for 
> ~0.5 second
> and else - during deactivation, the text 'Activation' is printed



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

[jira] [Updated] (IGNITE-8029) Web console: wrong behaviour of cluster activation component

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8029:
---
Fix Version/s: 2.5

> Web console: wrong behaviour of cluster activation component
> 
>
> Key: IGNITE-8029
> URL: https://issues.apache.org/jira/browse/IGNITE-8029
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
>
> I've noticed that during activation the text 'Deactivation' is printed for 
> ~0.5 second
> and else - during deactivation, the text 'Activation' is printed



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

[jira] [Created] (IGNITE-8029) Web console: wrong behaviour of cluster activation component

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8029:
--

 Summary: Web console: wrong behaviour of cluster activation 
component
 Key: IGNITE-8029
 URL: https://issues.apache.org/jira/browse/IGNITE-8029
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


I've noticed that during activation the text 'Deactivation' is printed for ~0.5 
second
and else - during deactivation, the text 'Activation' is printed



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

[jira] [Commented] (IGNITE-7993) Striped pool can't be disabled

[Andrew Mashenkov (JIRA)]

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

Andrew Mashenkov commented on IGNITE-7993:
--

Fix looks good to me.

Just one note, let's add performance opt. suggestion to 
IgniteKernal.suggestOptimizations(cfg)

> Striped pool can't be disabled
> --
>
> Key: IGNITE-7993
> URL: https://issues.apache.org/jira/browse/IGNITE-7993
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Roman Guseinov
>Priority: Major
> Fix For: 2.5
>
>
> Javadoc for {{IgniteConfiguration#setStripedPoolSize}} states that striped 
> pool can be disabled by providing value less or equal than zero:
> {noformat}
> If set to non-positive value then requests get processed in system pool.
> {noformat}
> However, doing that prevents node from startup, it fails with the following 
> exception:
> {noformat}
> Caused by: class org.apache.ignite.IgniteCheckedException: Invalid 
> stripedPool thread pool size (must be greater than 0), actual value: 0
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.validateThreadPoolSize(IgnitionEx.java:2061)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1799)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
>   at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:664)
>   at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589)
>   at org.apache.ignite.Ignition.start(Ignition.java:322)
>   ... 7 more
> {noformat}



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

[jira] [Assigned] (IGNITE-7119) Web Agent: Implement support for comma-delimited list of node URIs

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-7119:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

> Web Agent: Implement support for comma-delimited list of node URIs
> --
>
> Key: IGNITE-7119
> URL: https://issues.apache.org/jira/browse/IGNITE-7119
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to support several URLs for load-balancing and fault tolerance:
> It could look like this:
> {code}
> node-uri=http://10.1.1.1:8080,http://10.1.1.2:8080
> {code}



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

[jira] [Commented] (IGNITE-7119) Web Agent: Implement support for comma-delimited list of node URIs

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7119:


Tested on branch

> Web Agent: Implement support for comma-delimited list of node URIs
> --
>
> Key: IGNITE-7119
> URL: https://issues.apache.org/jira/browse/IGNITE-7119
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> We need to support several URLs for load-balancing and fault tolerance:
> It could look like this:
> {code}
> node-uri=http://10.1.1.1:8080,http://10.1.1.2:8080
> {code}



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

[jira] [Assigned] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7940:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().
> ---
>
> Key: IGNITE-7940
> URL: https://issues.apache.org/jira/browse/IGNITE-7940
> Project: Ignite
>  Issue Type: Task
>  Components: visor
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies



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

[jira] [Commented] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-7940:
---

Lost partitions not work for cluster with persistence.

> Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().
> ---
>
> Key: IGNITE-7940
> URL: https://issues.apache.org/jira/browse/IGNITE-7940
> Project: Ignite
>  Issue Type: Task
>  Components: visor
>Reporter: Alexey Kuznetsov
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.5
>
>
> See: https://apacheignite.readme.io/docs/partition-loss-policies



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

[jira] [Commented] (IGNITE-8025) Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() implementation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8025:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-8025 runMultiThreadedAsync cancellation fix.



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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-8025

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

https://github.com/apache/ignite/pull/3687.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 #3687


commit 2b6dd75e80a1b59ec04c2a5a8d9cf147b736822d
Author: Andrey Kuznetsov 
Date:   2018-03-23T06:46:41Z

IGNITE-8025 runMultiThreadedAsync cancellation fix.




> Result of GridTestUtils.runMultiThreadedAsync has a bug in cancel() 
> implementation
> --
>
> Key: IGNITE-8025
> URL: https://issues.apache.org/jira/browse/IGNITE-8025
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, test
> Fix For: 2.5
>
> Attachments: BugRunMTAsyncTest.java
>
>
> GridTestUtils.runMultiThreadedAsync returns a future with cancel() support, 
> but cancellation implementation never interrupts threads that execute 
> user-provided tasks. That is, those threads can continue their execution even 
> after test method finishes.
> The reproducer attached demonstrates activity from threads created by test0 
> after test0 finished and test1 is being run.



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