[jira] [Closed] (IGNITE-7803) REST: Add support to get values inserted via API or SQL

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-7803.
--

> REST: Add support to get values inserted via API or SQL
> ---
>
> Key: IGNITE-7803
> URL: https://issues.apache.org/jira/browse/IGNITE-7803
> Project: Ignite
>  Issue Type: Task
>  Components: rest
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Scenario 1:
>  # cache.put(1, new Person(1, Alex, 300))
>  # get via REST: 
> {{[http://host:port/ignite?cmd=get=SQL_PUBLIC_PERSON=int=1|http://hostport/]}}
> Scenario 2:
>  # create table person(id integer primary key, name varchar(100), salary 
> integer);
>  # insert into person(id, name, salary) values (1, Alex, 300)
>  # get via REST: 
> {{[http://host:port/ignite?cmd=get=SQL_PUBLIC_PERSON=int=1|http://hostport/]}}



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

[jira] [Commented] (IGNITE-7803) REST: Add support to get values inserted via API or SQL

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7803:


Re-tested on master

> REST: Add support to get values inserted via API or SQL
> ---
>
> Key: IGNITE-7803
> URL: https://issues.apache.org/jira/browse/IGNITE-7803
> Project: Ignite
>  Issue Type: Task
>  Components: rest
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Scenario 1:
>  # cache.put(1, new Person(1, Alex, 300))
>  # get via REST: 
> {{[http://host:port/ignite?cmd=get=SQL_PUBLIC_PERSON=int=1|http://hostport/]}}
> Scenario 2:
>  # create table person(id integer primary key, name varchar(100), salary 
> integer);
>  # insert into person(id, name, salary) values (1, Alex, 300)
>  # get via REST: 
> {{[http://host:port/ignite?cmd=get=SQL_PUBLIC_PERSON=int=1|http://hostport/]}}



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

[jira] [Updated] (IGNITE-7889) .NET: linq GroupBy and Where do not work together

[Alexey Popov (JIRA)]

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

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

> .NET: linq GroupBy and Where do not work together
> -
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
> Fix For: 2.5
>
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Updated] (IGNITE-7894) Web console: extract new design collapsible panels into component

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7894:
-
Description: 
Collapsible panels in new design still don't have a reusable component that 
encapsulates it's behavior and styles.

Where such panels are/will be used:
1. Redesigned cluster configuration forms.
 !image-2018-03-07-10-42-44-368.png! 
2. Current user profile.
 !image-2018-03-07-10-42-01-013.png! 
3. Upcoming queries screen redesign.
!image-2018-03-07-10-39-32-857.png! 

New component should:
1. Have bindings for opened state and opened/closed events.
2. Have a way to insert buttons to the right of header. 

Make sure that there are no leftover unused styles/code left.

What to test when the issue's done:
1. Panels on user profile page.
2. Panels on configuration screens should still have lazy panel content loading.
3. Legacy validation in clutser configuration / advanced / domain model form.

  was:
Collapsible panels in new design still don't have a reusable component that 
encapsulates it's behavior and styles.

Where such panels are/will be used:
1. Redesigned cluster configuration forms.
 !image-2018-03-07-10-42-44-368.png! 
2. Current user profile.
 !image-2018-03-07-10-42-01-013.png! 
3. Upcoming queries screen redesign.
!image-2018-03-07-10-39-32-857.png! 

New component should:
1. Have bindings for opened state and opened/closed events.
2. Have a way to insert buttons to the right of header. 

Make sure that there are no leftover unused styles/code left.

What to test when the issue's done:
1. Panels on user profile page.
2. Panels on configuration screens.
3. Legacy validation in clutser configuration / advanced / domain model form.


> Web console: extract new design collapsible panels into component
> -
>
> Key: IGNITE-7894
> URL: https://issues.apache.org/jira/browse/IGNITE-7894
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: image-2018-03-07-10-39-32-857.png, 
> image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png
>
>
> Collapsible panels in new design still don't have a reusable component that 
> encapsulates it's behavior and styles.
> Where such panels are/will be used:
> 1. Redesigned cluster configuration forms.
>  !image-2018-03-07-10-42-44-368.png! 
> 2. Current user profile.
>  !image-2018-03-07-10-42-01-013.png! 
> 3. Upcoming queries screen redesign.
> !image-2018-03-07-10-39-32-857.png! 
> New component should:
> 1. Have bindings for opened state and opened/closed events.
> 2. Have a way to insert buttons to the right of header. 
> Make sure that there are no leftover unused styles/code left.
> What to test when the issue's done:
> 1. Panels on user profile page.
> 2. Panels on configuration screens should still have lazy panel content 
> loading.
> 3. Legacy validation in clutser configuration / advanced / domain model form.



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

[jira] [Commented] (IGNITE-7892) Remove aquirence of any locks from toString methods

[Alexander Belyak (JIRA)]

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

Alexander Belyak commented on IGNITE-7892:
--

hanged thread stack example
{noformat}
"grid-timeout-worker-#119%DPL_GRID%DplGridNodeName%" #276 daemon prio=5 
os_prio=0 tid=0x7efee5ba8000 nid=0xd707 waiting on condition 
[0x7efd7c5c5000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x7f0182815ad8> (a 
java.util.concurrent.locks.ReentrantLock$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.acquireQueued(AbstractQueuedSynchronizer.java:870)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at 
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:4195)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.toString(GridDhtCacheEntry.java:815)
at java.lang.String.valueOf(String.java:2994)
at 
org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
at 
org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.toString(IgniteTxEntry.java:1267)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at java.util.AbstractCollection.toString(AbstractCollection.java:462)
at java.lang.String.valueOf(String.java:2994)
at 
org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
at 
org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:897)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.appendVals(GridToStringBuilder.java:1718)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1008)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:826)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:783)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxStateImpl.toString(IgniteTxStateImpl.java:466)
at java.lang.String.valueOf(String.java:2994)
at 
org.apache.ignite.internal.util.GridStringBuilder.a(GridStringBuilder.java:101)
at 
org.apache.ignite.internal.util.tostring.SBLimitedLength.a(SBLimitedLength.java:88)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:939)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toStringImpl(GridToStringBuilder.java:1005)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:762)
at 
org.apache.ignite.internal.util.tostring.GridToStringBuilder.toString(GridToStringBuilder.java:710)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.toString(IgniteTxLocalAdapter.java:1452)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.toString(GridDhtTxLocalAdapter.java:850)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.toString(GridDhtTxLocal.java:619)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.dumpLongRunningOperations0(GridCachePartitionExchangeManager.java:1644)
at 

[jira] [Updated] (IGNITE-7896) Files of evicted partitions do not remove from disk storage

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-7896:
--
Summary: Files of evicted partitions do not remove from disk storage  (was: 
Files of evicted partitions do not removed from disk storage)

> Files of evicted partitions do not remove from disk storage
> ---
>
> Key: IGNITE-7896
> URL: https://issues.apache.org/jira/browse/IGNITE-7896
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Attachments: IgnitePdsRebalanceCompletionAndPartitionFilesTest.java
>
>
> Look at test reproduction: 
> [^IgnitePdsRebalanceCompletionAndPartitionFilesTest.java]



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

[jira] [Created] (IGNITE-7896) Files of evicted partitions do not removed from disk storage

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-7896:
-

 Summary: Files of evicted partitions do not removed from disk 
storage
 Key: IGNITE-7896
 URL: https://issues.apache.org/jira/browse/IGNITE-7896
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov
 Attachments: IgnitePdsRebalanceCompletionAndPartitionFilesTest.java

Look at test reproduction: 
[^IgnitePdsRebalanceCompletionAndPartitionFilesTest.java]



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

[jira] [Updated] (IGNITE-7894) Web console: extract new design collapsible panels into component

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7894:
-
Description: 
Collapsible panels in new design still don't have a reusable component that 
encapsulates it's behavior and styles.

Where such panels are/will be used:
1. Redesigned cluster configuration forms.
 !image-2018-03-07-10-42-44-368.png! 
2. Current user profile.
 !image-2018-03-07-10-42-01-013.png! 
3. Upcoming queries screen redesign.
!image-2018-03-07-10-39-32-857.png! 

New component should:
1. Have bindings for opened state and opened/closed events.
2. Have a way to insert buttons to the right of header. 

Make sure that there are no leftover unused styles/code left.

What to test when the issue's done:
1. Panels on user profile page.
2. Panels on configuration screens.
3. Legacy validation in clutser configuration / advanced / domain model form.

  was:
Collapsible panels in new design still don't have a reusable component that 
encapsulates it's behavior and styles.

Where such panels are/will be used:
1. Redesigned cluster configuration forms.
 !image-2018-03-07-10-42-44-368.png! 
2. Current user profile.
 !image-2018-03-07-10-42-01-013.png! 
3. Upcoming queries screen redesign.
!image-2018-03-07-10-39-32-857.png! 

New component should:
1. Have bindings for opened state and opened/closed events.
2. Have a way to insert buttons to the right of header. 

Make sure that there are no leftover unused styles/code left.


> Web console: extract new design collapsible panels into component
> -
>
> Key: IGNITE-7894
> URL: https://issues.apache.org/jira/browse/IGNITE-7894
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: image-2018-03-07-10-39-32-857.png, 
> image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png
>
>
> Collapsible panels in new design still don't have a reusable component that 
> encapsulates it's behavior and styles.
> Where such panels are/will be used:
> 1. Redesigned cluster configuration forms.
>  !image-2018-03-07-10-42-44-368.png! 
> 2. Current user profile.
>  !image-2018-03-07-10-42-01-013.png! 
> 3. Upcoming queries screen redesign.
> !image-2018-03-07-10-39-32-857.png! 
> New component should:
> 1. Have bindings for opened state and opened/closed events.
> 2. Have a way to insert buttons to the right of header. 
> Make sure that there are no leftover unused styles/code left.
> What to test when the issue's done:
> 1. Panels on user profile page.
> 2. Panels on configuration screens.
> 3. Legacy validation in clutser configuration / advanced / domain model form.



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

[jira] [Created] (IGNITE-7895) Revise unit tests for Web Console.

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-7895:
-

 Summary: Revise unit tests for Web Console.
 Key: IGNITE-7895
 URL: https://issues.apache.org/jira/browse/IGNITE-7895
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin
 Fix For: 2.5






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

[jira] [Commented] (IGNITE-7894) Web console: extract new design collapsible panels into component

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-7894:
--

Configuration can be updated only after IGNITE-5466 lands.

> Web console: extract new design collapsible panels into component
> -
>
> Key: IGNITE-7894
> URL: https://issues.apache.org/jira/browse/IGNITE-7894
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: image-2018-03-07-10-39-32-857.png, 
> image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png
>
>
> Collapsible panels in new design still don't have a reusable component that 
> encapsulates it's behavior and styles.
> Where such panels are/will be used:
> 1. Redesigned cluster configuration forms.
>  !image-2018-03-07-10-42-44-368.png! 
> 2. Current user profile.
>  !image-2018-03-07-10-42-01-013.png! 
> 3. Upcoming queries screen redesign.
> !image-2018-03-07-10-39-32-857.png! 
> New component should:
> 1. Have bindings for opened state and opened/closed events.
> 2. Have a way to insert buttons to the right of header. 
> Make sure that there are no leftover unused styles/code left.



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

[jira] [Created] (IGNITE-7894) Web console: extract new design collapsible panels into component

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7894:


 Summary: Web console: extract new design collapsible panels into 
component
 Key: IGNITE-7894
 URL: https://issues.apache.org/jira/browse/IGNITE-7894
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Ilya Borisov
 Attachments: image-2018-03-07-10-39-32-857.png, 
image-2018-03-07-10-42-01-013.png, image-2018-03-07-10-42-44-368.png

Collapsible panels in new design still don't have a reusable component that 
encapsulates it's behavior and styles.

Where such panels are/will be used:
1. Redesigned cluster configuration forms.
 !image-2018-03-07-10-42-44-368.png! 
2. Current user profile.
 !image-2018-03-07-10-42-01-013.png! 
3. Upcoming queries screen redesign.
!image-2018-03-07-10-39-32-857.png! 

New component should:
1. Have bindings for opened state and opened/closed events.
2. Have a way to insert buttons to the right of header. 

Make sure that there are no leftover unused styles/code left.



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

[jira] [Resolved] (IGNITE-7419) Document swap usage in Ignite 2.x memory architecture

[Prachi Garg (JIRA)]

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

Prachi Garg resolved IGNITE-7419.
-
Resolution: Fixed

> Document swap usage in Ignite 2.x memory architecture
> -
>
> Key: IGNITE-7419
> URL: https://issues.apache.org/jira/browse/IGNITE-7419
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Explain how swap is supported and works in Ignite. Provide a rationale on 
> Ignite persistence vs swap.
> In addition, looks people don't catch what happens when memory region goes 
> beyond the maximum size. Revisit the persistence configuration:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-3-Swap-Path-configuration-is-causing-issue-td19040.html#a19046]



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

[jira] [Closed] (IGNITE-7419) Document swap usage in Ignite 2.x memory architecture

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-7419.
---

> Document swap usage in Ignite 2.x memory architecture
> -
>
> Key: IGNITE-7419
> URL: https://issues.apache.org/jira/browse/IGNITE-7419
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Explain how swap is supported and works in Ignite. Provide a rationale on 
> Ignite persistence vs swap.
> In addition, looks people don't catch what happens when memory region goes 
> beyond the maximum size. Revisit the persistence configuration:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-3-Swap-Path-configuration-is-causing-issue-td19040.html#a19046]



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

[jira] [Closed] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

[Prachi Garg (JIRA)]

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

Prachi Garg closed IGNITE-7536.
---

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Commented] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7536:
-

[~pgarg], let's a create a subsection for that so that it stands out. In that 
subsection provide a snippet for sh and bat files and show a possible produced 
output of the command.

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Commented] (IGNITE-5298) .NET: DML update via LINQ

[Sergey Stronchinskiy (JIRA)]

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

Sergey Stronchinskiy commented on IGNITE-5298:
--

Hi, [~ptupitsyn]

Thank you for feedback. Everything should be fixed, please check.

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, LINQ, important
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Commented] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

[Prachi Garg (JIRA)]

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

Prachi Garg commented on IGNITE-7536:
-

[~dmagda], It is mentioned in the `Set topology` section (First line) - 
https://apacheignite.readme.io/v2.3/docs/cluster-activation-24#section--set-the-topology-

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Created] (IGNITE-7893) Release Java Thin client documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7893:
---

 Summary: Release Java Thin client documentation
 Key: IGNITE-7893
 URL: https://issues.apache.org/jira/browse/IGNITE-7893
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Denis Magda
 Fix For: 2.5


Java thin client is already available for usage and documented:
https://apacheignite.readme.io/v2.3/docs/java-thin-client

It will be officially released in 2.5. For now, the users have to build it from 
sources.



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

[jira] [Commented] (IGNITE-6113) Partition eviction prevents exchange from completion

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6113:


Github user asfgit closed the pull request at:

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


> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> 

[jira] [Commented] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7536:
-

[~pgarg], I haven't found information on how to get a node's consistent id from 
the command line tool. Please explain this before showing how to add or remove 
nodes to/from the topology.

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Assigned] (IGNITE-7536) Document baseline topology feature and its WebConsole screen

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7536:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Document baseline topology feature and its WebConsole screen 
> -
>
> Key: IGNITE-7536
> URL: https://issues.apache.org/jira/browse/IGNITE-7536
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Document Baseline topology:
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches]
> and how to manage it with Web Console and control.sh script (Ignite 
> activation doc has to be updated).



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

[jira] [Commented] (IGNITE-7419) Document swap usage in Ignite 2.x memory architecture

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7419:
-

[~pgarg], thanks, I've altered this section below a bit:
https://apacheignite.readme.io/v2.3/docs/durable-memory#section-persistence-features

Released both pages because the content is relevant to 2.3.

Please, as a final thing, please update the same page on the site adding 
specific sections for Ignite persistence, 3rd party and swap:
https://ignite.apache.org/arch/durablememory.html

> Document swap usage in Ignite 2.x memory architecture
> -
>
> Key: IGNITE-7419
> URL: https://issues.apache.org/jira/browse/IGNITE-7419
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Explain how swap is supported and works in Ignite. Provide a rationale on 
> Ignite persistence vs swap.
> In addition, looks people don't catch what happens when memory region goes 
> beyond the maximum size. Revisit the persistence configuration:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-3-Swap-Path-configuration-is-causing-issue-td19040.html#a19046]



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

[jira] [Assigned] (IGNITE-7419) Document swap usage in Ignite 2.x memory architecture

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7419:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Document swap usage in Ignite 2.x memory architecture
> -
>
> Key: IGNITE-7419
> URL: https://issues.apache.org/jira/browse/IGNITE-7419
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Denis Magda
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> Explain how swap is supported and works in Ignite. Provide a rationale on 
> Ignite persistence vs swap.
> In addition, looks people don't catch what happens when memory region goes 
> beyond the maximum size. Revisit the persistence configuration:
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-3-Swap-Path-configuration-is-causing-issue-td19040.html#a19046]



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

[jira] [Commented] (IGNITE-7889) .NET: linq GroupBy and Where do not work together

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7889:


Github user asfgit closed the pull request at:

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


> .NET: linq GroupBy and Where do not work together
> -
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Resolved] (IGNITE-7889) .NET: linq GroupBy and Where do not work together

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7889.

Resolution: Fixed

> .NET: linq GroupBy and Where do not work together
> -
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Commented] (IGNITE-7889) .NET: linq GroupBy and Where do not work together

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7889:


TC looks good, merged to master: {{64d920bf59e18b383f7e2f230f8f4087406e38fe}}.

> .NET: linq GroupBy and Where do not work together
> -
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Updated] (IGNITE-7889) .NET: linq GroupBy and Where do not work together

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7889:
---
Summary: .NET: linq GroupBy and Where do not work together  (was: .NET: 
linq GroupBy and Where do not work together.)

> .NET: linq GroupBy and Where do not work together
> -
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Updated] (IGNITE-7889) .NET: linq GroupBy and Where do not work together

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7889:
---
Labels: .NET  (was: )

> .NET: linq GroupBy and Where do not work together
> -
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>  Labels: .NET
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7834:


[~vozerov], [~al.psc], who can take a look to these failures?

> 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
>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] [Commented] (IGNITE-7864) Control utility: Add confirm on dangerous operations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7864:


GitHub user macrergate opened a pull request:

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

IGNITE-7864 Control utility: Add confirm on dangerous operations



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

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

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

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


commit dd08ed09c4f770009b7764727b3ffe880f250d61
Author: macrergate 
Date:   2018-03-06T16:45:33Z

IGNITE-7864 Control utility: Add confirm on dangerous operations

commit a3528cd156cd4a1753b96e31727cf3c0ac8fdca7
Author: macrergate 
Date:   2018-03-06T16:48:02Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-7864




> Control utility: Add confirm on dangerous operations
> 
>
> Key: IGNITE-7864
> URL: https://issues.apache.org/jira/browse/IGNITE-7864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kosarev
>Priority: Major
> Fix For: 2.5
>
>
> control.sh can deactivate cluster.
> It could be very dangerous in some cases.
> Lets add manual confirmation for dangerous operations: deactivate, change 
> base line, ...
> Also, lets add "-force" option to not ask for confirmation (will be useful in 
> scripts).
>  



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

[jira] [Commented] (IGNITE-7851) .NET: linq query throws "Hexadecimal string with odd number of characters" exception

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7851:
--

changes done, waiting for TC run

> .NET: linq query throws "Hexadecimal string with odd number of characters" 
> exception
> 
>
> Key: IGNITE-7851
> URL: https://issues.apache.org/jira/browse/IGNITE-7851
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, sql
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
> Attachments: FirstOrDefaultKeyIssue.zip
>
>
> Simple linq query with .Key throws an exception
> {code}
> var models = cache.AsCacheQueryable();
> var entry = models.FirstOrDefault(m => m.Key == @"TST-1/1");
> {code}
> Apache.Ignite.Core.Common.IgniteException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195] ---> 
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:519)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1240)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:877)
> at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
> Caused by: javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1917)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:368)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1234)
> ... 2 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Hexadecimal string 
> with odd number of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2468)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> ... 5 more
> Caused by: org.h2.message.DbException: Hexadecimal string with odd number of 
> characters: "TST-1/1" [90003-195]
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at 
> org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:262)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.bindPartitionInfoParameter(IgniteH2Indexing.java:2520)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.calculateQueryPartitions(IgniteH2Indexing.java:2480)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeTwoStepsQuery(IgniteH2Indexing.java:1556)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1500)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> ... 6 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ... 19 more
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* 
> target, Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte* 
> errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32 
> stackTraceCharsLen, Void* errData, Int32 errDataLen)
>at 
> 

[jira] [Commented] (IGNITE-6113) Partition eviction prevents exchange from completion

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6113:


GitHub user Jokser opened a pull request:

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

IGNITE-6113 Return back old implementation instead of 'removeIf'



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

$ git pull https://github.com/gridgain/apache-ignite ignite-6113-micro-fix

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

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


commit 7aba97e0ecaa631c3951a45c43af91a08a89097a
Author: Pavel Kovalenko 
Date:   2018-03-06T16:06:04Z

IGNITE-6113 Return back old implementation instead of 'removeIf'




> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> 

[jira] [Commented] (IGNITE-7849) Generating a CacheEntryEventFilter from a SqlQuery

[Kevin Jin (JIRA)]

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

Kevin Jin commented on IGNITE-7849:
---

Ideally, I would like to be able to specify SqlQuery for the remote filter so 
that if I run an Ignite client node on .NET, I don't need to have a .NET Ignite 
server node in my cluster in order to evaluate the .NET predicate for the 
remote filter, but instead can just execute the SqlQuery on a Java server node.

> Generating a CacheEntryEventFilter from a SqlQuery
> --
>
> Key: IGNITE-7849
> URL: https://issues.apache.org/jira/browse/IGNITE-7849
> Project: Ignite
>  Issue Type: Wish
>  Components: cache, sql
>Affects Versions: 2.3
>Reporter: Kevin Jin
>Priority: Trivial
>  Labels: features, usability
> Fix For: None
>
>   Original Estimate: 0.2h
>  Remaining Estimate: 0.2h
>
> Currently when we want to use the same predicate for the continuous query and 
> initial query, it's easy enough to write something like this, assuming we are 
> fine with the performance of ScanQuery:
> {code:title=IgniteContinuousQueryExample.java|borderStyle=solid}
> import org.apache.ignite.Ignite;
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.query.ContinuousQuery;
> import org.apache.ignite.cache.query.QueryCursor;
> import org.apache.ignite.cache.query.ScanQuery;
> import javax.cache.Cache;
> import javax.cache.event.CacheEntryEvent;
> public class IgniteContinuousQueryExample {
> private static final String CLUSTER = "TESTGRID";
> private static final String TABLE = "TESTTABLE";
> private static boolean isInteresting(Integer key, String value) {
> return key > 10;
> }
> private static boolean isInteresting(CacheEntryEvent extends String> event) {
> return isInteresting(event.getKey(), event.getValue());
> }
> private static void handleEntry(Cache.Entry String> event) {
> System.out.println("Received value for " + event.getKey() + ": " + 
> event.getValue());
> }
> private static void handleExistingEntries(Iterable Cache.Entry> events) {
> events.forEach(IgniteContinuousQueryExample::handleEntry);
> }
> public static void main(String[] args) throws InterruptedException {
> try (Ignite client = Ignition.ignite(CLUSTER); IgniteCache String> cache = client.cache(TABLE)) {
> for (int i = 0; i < 20; i++)
> cache.put(i, Integer.toString(i));
> ContinuousQuery query = new ContinuousQuery<>();
> query.setRemoteFilterFactory(() -> 
> IgniteContinuousQueryExample::isInteresting);
> query.setInitialQuery(new 
> ScanQuery<>(IgniteContinuousQueryExample::isInteresting));
> 
> query.setLocalListener(IgniteContinuousQueryExample::handleExistingEntries);
> try (QueryCursor> resultSet = 
> cache.query(query)) {
> handleExistingEntries(resultSet);
> // Local listener callbacks will no longer be received once 
> resultSet is closed so
> //  these updates have to be inside the try-with-resources 
> block and we have to wait
> //  to close resultSet after the final update.
> for (int i = 20; i < 30; i++)
> cache.put(i, Integer.toString(i));
> Thread.sleep(6);
> }
> }
> }
> }
> {code}
> However, this becomes more inconvenient when we want to use SqlQuery in the 
> initial query to take advantage of indexing. This is the best that I can do:
> {noformat}
> query.setRemoteFilterFactory(() -> entry -> entry.getKey() > 10);
> query.setInitialQuery(new SqlQuery<>(String.sql, "`_key` > 10"));
> {noformat}
> This is obviously not ideal because we have to specify the predicate in two 
> different ways. A quick Google revealed that there are products out there 
> that more seamlessly support this use case of continuous querying. I 
> understand that Ignite isn't built on top of SQL, unlike the commercial 
> RDBMSes I found, so maybe this is an out-of-scope feature.



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

[jira] [Updated] (IGNITE-7889) .NET: linq GroupBy and Where do not work together.

[Alexey Popov (JIRA)]

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

Alexey Popov updated IGNITE-7889:
-
Summary: .NET: linq GroupBy and Where do not work together.  (was: .NET: 
linq GroupBy and Where does not work together.)

> .NET: linq GroupBy and Where do not work together.
> --
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Comment Edited] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-5298 at 3/6/18 3:04 PM:


[~GuruStron] looks good to me in general, awesome changes!
* Please split the test into multiple, it is too huge
* Make sure all class members have XMLDoc comments
* Some code lines exceed 120 char limit
* Why rename {{parenCount}}  to {{parentCount}} in {{CacheQueryModelVisitor}}?


was (Author: ptupitsyn):
[~GuruStron] looks good to me in general, awesome changes!
* Please split the test into multiple, it is too huge
* Make sure all class members have XMLDoc comments
* Why rename {{parenCount}}  to {{parentCount}} in {{CacheQueryModelVisitor}}?

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, LINQ, important
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Updated] (IGNITE-6890) General way for handling Ignite failures (NodeInvalidator should be replaced with IgniteFailureProcessor)

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-6890:

Description: 
Ignite failures which should be handled are:
 # Topology segmentation;
 # Exchange worker stop;
 # Errors currently covered by NodeInvalidator.

Proper behavior should be selected according to result of calling 
IgniteFailureHandler instance, custom implementation of which can be provided 
in IgniteConfiguration. It can be node stop, restart or nothing.

See also IEP-14 "Ignite failures handling": 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

  was:
Ignite failures which should be handled are:
 # Topology segmentation;
 # Exchange worker stop;
 # Errors currently covered by NodeInvalidator.

Proper behavior should be selected according to result of calling 
IgniteFailureHandler instance, custom implementation of which can be provided 
in IgniteConfiguration. It can be node stop, restart or nothing.


> General way for handling Ignite failures (NodeInvalidator should be replaced 
> with IgniteFailureProcessor)
> -
>
> Key: IGNITE-6890
> URL: https://issues.apache.org/jira/browse/IGNITE-6890
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> Ignite failures which should be handled are:
>  # Topology segmentation;
>  # Exchange worker stop;
>  # Errors currently covered by NodeInvalidator.
> Proper behavior should be selected according to result of calling 
> IgniteFailureHandler instance, custom implementation of which can be provided 
> in IgniteConfiguration. It can be node stop, restart or nothing.
> See also IEP-14 "Ignite failures handling": 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling



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

[jira] [Commented] (IGNITE-5298) .NET: DML update via LINQ

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-5298:


[~GuruStron] looks good to me in general, awesome changes!
* Please split the test into multiple, it is too huge
* Make sure all class members have XMLDoc comments
* Why rename {{parenCount}}  to {{parentCount}} in {{CacheQueryModelVisitor}}?

> .NET: DML update via LINQ
> -
>
> Key: IGNITE-5298
> URL: https://issues.apache.org/jira/browse/IGNITE-5298
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, LINQ, important
>
> Bulk update with LINQ:
> {code}
> var persons = ignite.GetCache("persons").AsCacheQueryable();
> int affectedRows = persons.Where(x => x.Key > 10).UpdateAll(x => 
> x.Value.OrgId = 7);
> {code}
> See bulk delete with {{RemoveAll}}, IGNITE-4904.



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

[jira] [Updated] (IGNITE-1553) Optimize transaction prepare step when store is enabled

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-1553:
-
Description: 
Currently entries are enlisted in a database transaction after grid transaction 
is in PREPARED state. We can do this in parallel in the following fashion 
(pseudo-code):
{code:java}
fut = tx.prepareAsync();

db.write(tx.writes());

fut.get();

try {
db.commit();

tx.commit();
}
catch (Exception e) {
tx.rollback();
}
{code}
If this approach is applied, we should be able to reduce latency for 
transactions when write-through is enabled.

 

store prepare works on primary nodes only

  was:
Currently entries are enlisted in a database transaction after grid transaction 
is in PREPARED state. We can do this in parallel in the following fashion 
(pseudo-code):

{code}
fut = tx.prepareAsync();

db.write(tx.writes());

fut.get();

try {
db.commit();

tx.commit();
}
catch (Exception e) {
tx.rollback();
}
{code}

If this approach is applied, we should be able to reduce latency for 
transactions when write-through is enabled.


> Optimize transaction prepare step when store is enabled
> ---
>
> Key: IGNITE-1553
> URL: https://issues.apache.org/jira/browse/IGNITE-1553
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
>Assignee: Alexey Kuznetsov
>Priority: Major
>  Labels: important
> Fix For: 2.5
>
>
> Currently entries are enlisted in a database transaction after grid 
> transaction is in PREPARED state. We can do this in parallel in the following 
> fashion (pseudo-code):
> {code:java}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
> db.commit();
> 
> tx.commit();
> }
> catch (Exception e) {
> tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for 
> transactions when write-through is enabled.
>  
> store prepare works on primary nodes only



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

[jira] [Created] (IGNITE-7892) Remove aquirence of any locks from toString methods

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-7892:


 Summary: Remove aquirence of any locks from toString methods
 Key: IGNITE-7892
 URL: https://issues.apache.org/jira/browse/IGNITE-7892
 Project: Ignite
  Issue Type: Wish
  Components: general
Affects Versions: 2.4
Reporter: Alexander Belyak


In org.apache.ignite.internal.processors.cache.GridCacheMapEntry we have thread 
safe toString() method that can lead to some hangs of monitoring threads like 
grid-timeout-worker if we try to dump LongRunningOperations with locked entry.
I think that toString methods will never need to be a thread safe and can throw 
ConcurrentModificationException or print inconsistent data, so we must remove 
synchronization from every toString methods in codebase. If we need some 
"consistent" string representation - let's add consistentToString methods or do 
external synchronization.



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

[jira] [Commented] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7889:


[~alexey.tank2] looks good to me.

> .NET: linq GroupBy and Where does not work together.
> 
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Updated] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7889:
---
Description: 
The following code completely ignores the Where condition:
{noformat}
var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 && 
m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
.Select(g => new KeyValuePair(g.Key, 
g.Select(m => m.Value.Version).Min()));
{noformat}

debugger shows SQL without WHERE:
{{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
[Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}


  was:
The following code completely ignores the Where condition:
{noformat}
var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 && 
m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
.Select(g => new KeyValuePair(g.Key, 
g.Select(m => m.Value.Version).Min()));
{noformat}

debugger shows SQL without WHERE:
{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
[Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}



> .NET: linq GroupBy and Where does not work together.
> 
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}}



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

[jira] [Commented] (IGNITE-7851) .NET: linq query throws "Hexadecimal string with odd number of characters" exception

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7851:


[~alexey.tank2] deprecating the constructor makes sense to me, please go ahead.

> .NET: linq query throws "Hexadecimal string with odd number of characters" 
> exception
> 
>
> Key: IGNITE-7851
> URL: https://issues.apache.org/jira/browse/IGNITE-7851
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, sql
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
> Attachments: FirstOrDefaultKeyIssue.zip
>
>
> Simple linq query with .Key throws an exception
> {code}
> var models = cache.AsCacheQueryable();
> var entry = models.FirstOrDefault(m => m.Key == @"TST-1/1");
> {code}
> Apache.Ignite.Core.Common.IgniteException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195] ---> 
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:519)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1240)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:877)
> at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
> Caused by: javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1917)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:368)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1234)
> ... 2 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Hexadecimal string 
> with odd number of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2468)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> ... 5 more
> Caused by: org.h2.message.DbException: Hexadecimal string with odd number of 
> characters: "TST-1/1" [90003-195]
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at 
> org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:262)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.bindPartitionInfoParameter(IgniteH2Indexing.java:2520)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.calculateQueryPartitions(IgniteH2Indexing.java:2480)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeTwoStepsQuery(IgniteH2Indexing.java:1556)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1500)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> ... 6 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ... 19 more
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* 
> target, Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte* 
> errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32 
> stackTraceCharsLen, 

[jira] [Commented] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7889:
--

TC run:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3608%2Fhead

> .NET: linq GroupBy and Where does not work together.
> 
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}



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

[jira] [Commented] (IGNITE-7845) Data race on atomicLong close

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7845:


Github user asfgit closed the pull request at:

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


> Data race on atomicLong close
> -
>
> Key: IGNITE-7845
> URL: https://issues.apache.org/jira/browse/IGNITE-7845
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Found by IgniteClientDataStructuresTest.testAtomicLong.
> *Given:*
> IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
> true)
> *When:*
> IgniteAtomicLong was closed e.g. atomicLong.close()
> *Then:*
> If you try to get this value again sometimes you will get null 
> IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong 
> value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes 
> not null
> But if we will get not null value IgniteAtomicLong and we will call method 
> "get" on it, we will have one of two exception 
> IllegalStateException("Sequence was removed from cache: " + name) if it 
> already marked as deleted, and IgniteException("Failed to find atomic long: " 
> + name) if it sill no marked as deleted but already deleted from cache.
> *Expected:*
> IgniteAtomicLong value always should be null(or not?)
> *Why it's happend:*
> When we close IgniteAtomicLong we removing value from cache in transaction 
> but removing from internal storage(dsMap) happen asynchroniously in 
> DataStructuresEntryListener for all nodes include local node. And when we try 
> get value after close we still sometimes able to get IgniteAtomicLong from 
> internal local storage.
> *Solution(In my opinion):*
> I guess in common case we don't  need call Ignite#atomicLong  every time when 
> we need value, but we should use IgniteAtomicLong object received after first 
> call. And if it is true, we can remove receiving IgniteAtomicLong from local 
> storage(dsMap) - this changes will fix problem



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

[jira] [Commented] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7889:
--

Changes:
1. Unit test is added
2. Fix is done in {{ProcessGroupings}} function

[~skalashnikov], [~isapego], [~ptupitsyn], please review

> .NET: linq GroupBy and Where does not work together.
> 
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}



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

[jira] [Commented] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7889:


GitHub user apopovgg opened a pull request:

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

IGNITE-7889: .NET: linq GroupBy and Where does not work together



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

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

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

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


commit 6156e04a4c8af1bc599cbbfeb30c7726264ab6ea
Author: apopov 
Date:   2018-03-06T14:38:31Z

IGNITE-7889: .NET: linq GroupBy and Where does not work together




> .NET: linq GroupBy and Where does not work together.
> 
>
> Key: IGNITE-7889
> URL: https://issues.apache.org/jira/browse/IGNITE-7889
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
>
> The following code completely ignores the Where condition:
> {noformat}
> var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 
> && m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
> .Select(g => new KeyValuePair(g.Key, 
> g.Select(m => m.Value.Version).Min()));
> {noformat}
> debugger shows SQL without WHERE:
> {CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
> [Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
> group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
> EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
> ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Labels: rebalance test  (was: )

> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kuznetsov
>Priority: Critical
>  Labels: rebalance
> Fix For: 2.5
>
>
> When cluster is started with partitioned cache with backups, 
>  awaitPartitionMapExchange(true, true, null) may work incorrectly : it 
> doesn't wait for full rebalance to be finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]
> Note that reproducer is flaky, it fails 80% of times



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Labels: rebalance  (was: rebalance test)

> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kuznetsov
>Priority: Critical
>  Labels: rebalance
> Fix For: 2.5
>
>
> When cluster is started with partitioned cache with backups, 
>  awaitPartitionMapExchange(true, true, null) may work incorrectly : it 
> doesn't wait for full rebalance to be finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]
> Note that reproducer is flaky, it fails 80% of times



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Affects Version/s: 2.5

> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.5
>
>
> When cluster is started with partitioned cache with backups, 
>  awaitPartitionMapExchange(true, true, null) may work incorrectly : it 
> doesn't wait for full rebalance to be finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]
> Note that reproducer is flaky, it fails 80% of times



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Fix Version/s: 2.5

> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.5
>
>
> When cluster is started with partitioned cache with backups, 
>  awaitPartitionMapExchange(true, true, null) may work incorrectly : it 
> doesn't wait for full rebalance to be finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]
> Note that reproducer is flaky, it fails 80% of times



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Description: 
When cluster is started with partitioned cache with backups, 
 awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance to be finished.

See 
[reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]

Note that reproducer is flaky, it fails 80% of times

  was:
When cluster is started with partitioned cache with backups, 
 awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance to be finished.

See 
[reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]


> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Priority: Critical
>
> When cluster is started with partitioned cache with backups, 
>  awaitPartitionMapExchange(true, true, null) may work incorrectly : it 
> doesn't wait for full rebalance to be finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]
> Note that reproducer is flaky, it fails 80% of times



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Description: 
When cluster is started with partitioned cache with backups, 
 awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance to be finished.

See 
[reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]

  was:
When cluster is started with partitioned cache with backups, 
awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance has finished.

See 
[reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]



> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Priority: Critical
>
> When cluster is started with partitioned cache with backups, 
>  awaitPartitionMapExchange(true, true, null) may work incorrectly : it 
> doesn't wait for full rebalance to be finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]



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

[jira] [Updated] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-7891:
-
Description: 
When cluster is started with partitioned cache with backups, 
awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance has finished.

See 
[reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]


  was:
When cluster is started with partitioned cache with backups, 
awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance has finished.




> awaitPartitionMapExchange works incorrectly if partitioned cache has backup
> ---
>
> Key: IGNITE-7891
> URL: https://issues.apache.org/jira/browse/IGNITE-7891
> Project: Ignite
>  Issue Type: Bug
>Reporter: Alexey Kuznetsov
>Priority: Critical
>
> When cluster is started with partitioned cache with backups, 
> awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
> wait for full rebalance has finished.
> See 
> [reproducer|https://github.com/voipp/ignite/commit/78d96c4950b7f82abea1d3cec8b508a96089f2a5]



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

[jira] [Created] (IGNITE-7891) awaitPartitionMapExchange works incorrectly if partitioned cache has backup

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7891:


 Summary: awaitPartitionMapExchange works incorrectly if 
partitioned cache has backup
 Key: IGNITE-7891
 URL: https://issues.apache.org/jira/browse/IGNITE-7891
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov


When cluster is started with partitioned cache with backups, 
awaitPartitionMapExchange(true, true, null) may work incorrectly : it doesn't 
wait for full rebalance has finished.





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

[jira] [Assigned] (IGNITE-6860) Lack of context information upon serializing and marshalling (writeObject and writeFields)

[Ivan Daschinskiy (JIRA)]

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

Ivan Daschinskiy reassigned IGNITE-6860:


Assignee: Ivan Daschinskiy

> Lack of context information upon serializing and marshalling (writeObject and 
> writeFields)
> --
>
> Key: IGNITE-6860
> URL: https://issues.apache.org/jira/browse/IGNITE-6860
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Fix For: 2.5
>
>
> Having the stack trace
> {noformat}
> Caused by: org.apache.ignite.binary.BinaryObjectException: Failed to marshal 
> object with optimized marshaller: 
> [org.apache.logging.log4j.core.config.AppenderControl@302e61a8]
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:186)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1160)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:663)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:793)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1160)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:663)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:793)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1160)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:663)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:793)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1160)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:663)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:793)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.writeObjectField(BinaryWriterExImpl.java:1160)
>   at 
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:663)
>   at 
> org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:793)
>   at 
> 

[jira] [Commented] (IGNITE-7845) Data race on atomicLong close

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7845:


[~akalashnikov], please set patch available if fix is ready

> Data race on atomicLong close
> -
>
> Key: IGNITE-7845
> URL: https://issues.apache.org/jira/browse/IGNITE-7845
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Found by IgniteClientDataStructuresTest.testAtomicLong.
> *Given:*
> IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
> true)
> *When:*
> IgniteAtomicLong was closed e.g. atomicLong.close()
> *Then:*
> If you try to get this value again sometimes you will get null 
> IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong 
> value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes 
> not null
> But if we will get not null value IgniteAtomicLong and we will call method 
> "get" on it, we will have one of two exception 
> IllegalStateException("Sequence was removed from cache: " + name) if it 
> already marked as deleted, and IgniteException("Failed to find atomic long: " 
> + name) if it sill no marked as deleted but already deleted from cache.
> *Expected:*
> IgniteAtomicLong value always should be null(or not?)
> *Why it's happend:*
> When we close IgniteAtomicLong we removing value from cache in transaction 
> but removing from internal storage(dsMap) happen asynchroniously in 
> DataStructuresEntryListener for all nodes include local node. And when we try 
> get value after close we still sometimes able to get IgniteAtomicLong from 
> internal local storage.
> *Solution(In my opinion):*
> I guess in common case we don't  need call Ignite#atomicLong  every time when 
> we need value, but we should use IgniteAtomicLong object received after first 
> call. And if it is true, we can remove receiving IgniteAtomicLong from local 
> storage(dsMap) - this changes will fix problem



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

[jira] [Updated] (IGNITE-7845) Data race on atomicLong close

[Dmitriy Pavlov (JIRA)]

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

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

> Data race on atomicLong close
> -
>
> Key: IGNITE-7845
> URL: https://issues.apache.org/jira/browse/IGNITE-7845
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Found by IgniteClientDataStructuresTest.testAtomicLong.
> *Given:*
> IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
> true)
> *When:*
> IgniteAtomicLong was closed e.g. atomicLong.close()
> *Then:*
> If you try to get this value again sometimes you will get null 
> IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong 
> value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes 
> not null
> But if we will get not null value IgniteAtomicLong and we will call method 
> "get" on it, we will have one of two exception 
> IllegalStateException("Sequence was removed from cache: " + name) if it 
> already marked as deleted, and IgniteException("Failed to find atomic long: " 
> + name) if it sill no marked as deleted but already deleted from cache.
> *Expected:*
> IgniteAtomicLong value always should be null(or not?)
> *Why it's happend:*
> When we close IgniteAtomicLong we removing value from cache in transaction 
> but removing from internal storage(dsMap) happen asynchroniously in 
> DataStructuresEntryListener for all nodes include local node. And when we try 
> get value after close we still sometimes able to get IgniteAtomicLong from 
> internal local storage.
> *Solution(In my opinion):*
> I guess in common case we don't  need call Ignite#atomicLong  every time when 
> we need value, but we should use IgniteAtomicLong object received after first 
> call. And if it is true, we can remove receiving IgniteAtomicLong from local 
> storage(dsMap) - this changes will fix problem



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

[jira] [Commented] (IGNITE-7890) Node start with corrupted pds hangs indefinitely.

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-7890:
-

[~ilantukh] Looks good for me.

> Node start with corrupted pds hangs indefinitely.
> -
>
> Key: IGNITE-7890
> URL: https://issues.apache.org/jira/browse/IGNITE-7890
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Starting node with corrupted PDS + WAL leads to cluster-wide hang-up.



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

[jira] [Commented] (IGNITE-7890) Node start with corrupted pds hangs indefinitely.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-7890:
--

I don't think that we should allow to start nodes with corrupted persistence. 
The only solution that I can suggest is to invalidate and stop node to avoid it 
hanging up.

> Node start with corrupted pds hangs indefinitely.
> -
>
> Key: IGNITE-7890
> URL: https://issues.apache.org/jira/browse/IGNITE-7890
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Starting node with corrupted PDS + WAL leads to cluster-wide hang-up.



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

[jira] [Commented] (IGNITE-7890) Node start with corrupted pds hangs indefinitely.

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-7890:
--

Hang-up is caused by this exception:
{noformat}
[2018-02-27 
15:36:10,973][ERROR][sys-#232%dbx%][GridDhtPartitionsExchangeFuture] Failed to 
notify listener (is grid stopped?) [fut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=true, hash=1680325664], 
lsnr=o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5@6018347c,
 err=Failed to get page IO instance (page content is corrupted)]
java.lang.IllegalStateException: Failed to get page IO instance (page content 
is corrupted)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:83)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:95)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.PagesList.init(PagesList.java:175)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.AbstractFreeList.(AbstractFreeList.java:367)
at 
org.apache.ignite.internal.processors.cache.persistence.freelist.CacheFreeListImpl.(CacheFreeListImpl.java:47)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore$1.(GridCacheOffheapManager.java:971)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:971)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:1208)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:824)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.casState(GridDhtLocalPartition.java:512)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.(GridDhtLocalPartition.java:207)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.createPartition(GridDhtPartitionTopologyImpl.java:750)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.createPartitions(GridDhtPartitionTopologyImpl.java:447)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitions0(GridDhtPartitionTopologyImpl.java:382)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.initPartitionsWhenAffinityReady(GridDhtPartitionTopologyImpl.java:316)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$13.applyx(CacheAffinitySharedManager.java:1342)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$13.applyx(CacheAffinitySharedManager.java:1306)
at 
org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1094)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onLocalJoin(CacheAffinitySharedManager.java:1306)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:2855)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$1400(GridDhtPartitionsExchangeFuture.java:121)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:2614)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$5.apply(GridDhtPartitionsExchangeFuture.java:2602)
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.onReceiveFullMessage(GridDhtPartitionsExchangeFuture.java:2602)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1439)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1100(GridCachePartitionExchangeManager.java:132)
at 

[jira] [Created] (IGNITE-7890) Node start with corrupted pds hangs indefinitely.

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-7890:


 Summary: Node start with corrupted pds hangs indefinitely.
 Key: IGNITE-7890
 URL: https://issues.apache.org/jira/browse/IGNITE-7890
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


Starting node with corrupted PDS + WAL leads to cluster-wide hang-up.



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

[jira] [Commented] (IGNITE-6113) Partition eviction prevents exchange from completion

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6113:


Github user asfgit closed the pull request at:

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


> Partition eviction prevents exchange from completion
> 
>
> Key: IGNITE-6113
> URL: https://issues.apache.org/jira/browse/IGNITE-6113
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, persistence
>Affects Versions: 2.1
>Reporter: Vladislav Pyatkov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>
> I has waited for 3 hours for completion without any success.
> exchange-worker is blocked.
> {noformat}
> "exchange-worker-#92%DPL_GRID%grid554.ca.sbrf.ru%" #173 prio=5 os_prio=0 
> tid=0x7f0835c2e000 nid=0xb907 runnable [0x7e74ab1d]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0x7efee630a7c0> (a 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition$1)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.assign(GridDhtPreloader.java:340)
> at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1801)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {noformat}
> {noformat}
> "sys-#124%DPL_GRID%grid554.ca.sbrf.ru%" #278 prio=5 os_prio=0 
> tid=0x7e731c02d000 nid=0xbf4d runnable [0x7e734e7f7000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.FileDispatcherImpl.write(FileDispatcherImpl.java:60)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:211)
> - locked <0x7f056161bf88> (a java.lang.Object)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.writeBuffer(FileWriteAheadLogManager.java:1829)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.flush(FileWriteAheadLogManager.java:1572)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.addRecord(FileWriteAheadLogManager.java:1421)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager$FileWriteHandle.access$800(FileWriteAheadLogManager.java:1331)
> at 
> org.gridgain.grid.cache.db.wal.FileWriteAheadLogManager.log(FileWriteAheadLogManager.java:339)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.beforeReleaseWrite(PageMemoryImpl.java:1287)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageMemoryImpl.writeUnlockPage(PageMemoryImpl.java:1142)
> at 
> org.gridgain.grid.internal.processors.cache.database.pagemem.PageImpl.releaseWrite(PageImpl.java:167)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writeUnlock(PageHandler.java:193)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:242)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.util.PageHandler.writePage(PageHandler.java:119)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.doRemoveFromLeaf(BPlusTree.java:2886)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.removeFromLeaf(BPlusTree.java:2865)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree$Remove.access$6900(BPlusTree.java:2515)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1607)
> at 
> org.apache.ignite.internal.processors.cache.database.tree.BPlusTree.removeDown(BPlusTree.java:1574)
> at 
> 

[jira] [Created] (IGNITE-7889) .NET: linq GroupBy and Where does not work together.

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7889:


 Summary: .NET: linq GroupBy and Where does not work together.
 Key: IGNITE-7889
 URL: https://issues.apache.org/jira/browse/IGNITE-7889
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.1
Reporter: Alexey Popov
Assignee: Alexey Popov


The following code completely ignores the Where condition:
{noformat}
var groupByQuery2 = models.Where(m => m.Value.DateTicks < 10 && 
m.Value.Dirty.HasValue).GroupBy(m => m.Value.ContractId)
.Select(g => new KeyValuePair(g.Key, 
g.Select(m => m.Value.Version).Min()));
{noformat}

debugger shows SQL without WHERE:
{CacheQueryable [CacheName=someCache, TableName=MODEL, Query=SqlFieldsQuery 
[Sql=select _T0.CONTRACTID, min (_T0.VERSION)  from "someCache".MODEL as _T0 
group by (_T0.CONTRACTID), Arguments=[], Local=False, PageSize=1024, 
EnableDistributedJoins=False, EnforceJoinOrder=False, Timeout=00:00:00, 
ReplicatedOnly=False, Colocated=False, Schema=, Lazy=False]]}




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

[jira] [Commented] (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:comment-tabpanel=16387722#comment-16387722
 ] 

Andrey Kuznetsov commented on IGNITE-7770:
--

There are at least two possible flaky failure scenarios.

1 - Most frequent. 

NPE; first {{get()}} in transaction returns {{null}}, this should be impossible 
due to test code structure.


2 - Less frequent. 

Timeout while waiting for {{multithreadedAsync()}} completion.
First, some optimistic transaction commits changed entry with key K and parks 
forever:
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)
This transaction keeps hanging even after its timeout occured.

Next, a bunch of pessimistic transactions also park forever on {{put()}} for 
the same key K:
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.GridCacheAdapter$22.op(GridCacheAdapter.java:2390)
org.apache.ignite.internal.processors.cache.GridCacheAdapter$22.op(GridCacheAdapter.java:2388)
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4088)
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2388)
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2369)
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2346)
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:886)
org.apache.ignite.internal.processors.cache.transactions.TxRollbackOnTimeoutTest$4.run(TxRollbackOnTimeoutTest.java:442)
org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)

And also there is a number of threads operating normally.

> 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
>
>
> 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



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

[jira] [Commented] (IGNITE-7851) .NET: linq query throws "Hexadecimal string with odd number of characters" exception

[Alexey Popov (JIRA)]

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

Alexey Popov commented on IGNITE-7851:
--

Discussed with [~vozerov]. It was decided to deprecate the constructor

{noformat}
public CacheConfiguration(string name, params Type[] queryTypes) : 
this(name)
{
QueryEntities = queryTypes.Select(type => new QueryEntity 
{ValueType = type}).ToArray();
}
{noformat}

and update all the samples that use it.

Thanks,
Alexey

> .NET: linq query throws "Hexadecimal string with odd number of characters" 
> exception
> 
>
> Key: IGNITE-7851
> URL: https://issues.apache.org/jira/browse/IGNITE-7851
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, sql
>Affects Versions: 2.3
>Reporter: Alexey Popov
>Assignee: Alexey Popov
>Priority: Major
> Attachments: FirstOrDefaultKeyIssue.zip
>
>
> Simple linq query with .Key throws an exception
> {code}
> var models = cache.AsCacheQueryable();
> var entry = models.FirstOrDefault(m => m.Key == @"TST-1/1");
> {code}
> Apache.Ignite.Core.Common.IgniteException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195] ---> 
> Apache.Ignite.Core.Common.JavaException: class 
> org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:519)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1240)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:877)
> at 
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
> Caused by: javax.cache.CacheException: class 
> org.apache.ignite.IgniteCheckedException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1917)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:368)
> at 
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runFieldsQuery(PlatformCache.java:1234)
> ... 2 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Hexadecimal string 
> with odd number of characters: "TST-1/1" [90003-195]
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2468)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> ... 5 more
> Caused by: org.h2.message.DbException: Hexadecimal string with odd number of 
> characters: "TST-1/1" [90003-195]
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.util.StringUtils.convertHexToBytes(StringUtils.java:930)
> at org.h2.value.Value.convertTo(Value.java:957)
> at 
> org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:262)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.bindPartitionInfoParameter(IgniteH2Indexing.java:2520)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.calculateQueryPartitions(IgniteH2Indexing.java:2480)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeTwoStepsQuery(IgniteH2Indexing.java:1556)
> at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1500)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> ... 6 more
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number 
> of characters: "TST-1/1" [90003-195]
> at 
> org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ... 19 more
>--- 

[jira] [Created] (IGNITE-7888) ODBC: Add support for SQL_ATTR_LOGIN_TIMEOUT

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7888:


 Summary: ODBC: Add support for SQL_ATTR_LOGIN_TIMEOUT
 Key: IGNITE-7888
 URL: https://issues.apache.org/jira/browse/IGNITE-7888
 Project: Ignite
  Issue Type: Improvement
  Components: odbc
Affects Versions: 2.1
Reporter: Alexey Popov
Assignee: Igor Sapego
 Fix For: 2.5


It would be great if we can support SQL_ATTR_LOGIN_TIMEOUT even without 
login/password connection parameter. Now we have some default timeout for 
initial ODBC connection establishment.



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

[jira] [Commented] (IGNITE-7638) Page replacement process in PDS mode affect segment loaded pages table performance

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7638:


https://reviews.ignite.apache.org/ignite/review/IGNT-CR-510
https://github.com/apache/ignite/pull/3481
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAll_IgniteTests24Java8=pull%2F3481%2Fhead=buildTypeStatusDiv


> Page replacement process in PDS mode affect segment loaded pages table 
> performance
> --
>
> Key: IGNITE-7638
> URL: https://issues.apache.org/jira/browse/IGNITE-7638
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> There is 
> - durable memory segment in PDS enabled data region 
> - page replacement started
> then Ignite performance slow down occurs, JFR & Visual VM shows get from 
> FullPageIdTable requires significiant time to be executed (~5-10% оf samples 
> count and up to 40% CPU usage)
> {noformat}
> Avg steps in loaded pages table, get: 9456 steps,  put: 20243 steps,  
> capacity: 20242 size: 7978
> {noformat}
> Effect of influence of FullPageID table is cumulative, once it starts to 
> grow, number of steps required grows also.



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

[jira] [Commented] (IGNITE-7876) [ML] Adopt SVM Linear Binary Classification Model and Trainer to the new Partitioned Dataset

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7876:


GitHub user zaleslaw opened a pull request:

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

IGNITE-7876

* Removed Multiclass-classification related code
* Fixed tests
* Adopted Model and Trainer


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

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

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

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


commit b13fbe8b0a44c6b133cb42480ae5c47bd9a36357
Author: zaleslaw 
Date:   2018-03-04T11:36:31Z

IGNITE-7452: added example

commit b33719c620d85146b12e74ad7a640f17e0a6229b
Author: zaleslaw 
Date:   2018-03-04T12:13:27Z

IGNITE-7876: fixed docs

commit 56a5f21be09b367742f01034b0ee1f5d7788672d
Author: zaleslaw 
Date:   2018-03-04T12:16:51Z

IGNITE-7876: fixed tests

commit 2d7d2958ceea6b6fe9cf6a1a30cde7aca145e4ff
Author: zaleslaw 
Date:   2018-03-06T10:29:01Z

IGNITE-7876: Remove unused code

commit 986a772708eebbd6c2a22cb4963ff56789972ead
Author: zaleslaw 
Date:   2018-03-06T11:39:42Z

IGNITE-7876: Remove unused code

commit 8e4a2b3fd4b2ad71717217ffe12f0324245ada4e
Author: zaleslaw 
Date:   2018-03-06T11:48:09Z

IGNITE-7876: Fix comments




> [ML] Adopt SVM Linear Binary Classification Model and Trainer to the new 
> Partitioned Dataset
> 
>
> Key: IGNITE-7876
> URL: https://issues.apache.org/jira/browse/IGNITE-7876
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Commented] (IGNITE-7485) add support for authentication parameters to control.sh utility

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7485:


Re-tested on master

> add support for authentication parameters to control.sh utility
> ---
>
> Key: IGNITE-7485
> URL: https://issues.apache.org/jira/browse/IGNITE-7485
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Sergey Kosarev
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Currently controls.sh utility does not work if cluster is running under 
> authentication.
> Error is shown:
> Failed to get cluster state.
> Authentication error.
>  
> it is suggested to introduce authentication parameters to the utitlity
> --login LOGIN
> --password PASSWORD
>  
> Main Utility class ( CommandHandler )  is located in ignite-core module 
> currently. 
>  



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

[jira] [Closed] (IGNITE-7485) add support for authentication parameters to control.sh utility

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-7485.
--

> add support for authentication parameters to control.sh utility
> ---
>
> Key: IGNITE-7485
> URL: https://issues.apache.org/jira/browse/IGNITE-7485
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Sergey Kosarev
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> Currently controls.sh utility does not work if cluster is running under 
> authentication.
> Error is shown:
> Failed to get cluster state.
> Authentication error.
>  
> it is suggested to introduce authentication parameters to the utitlity
> --login LOGIN
> --password PASSWORD
>  
> Main Utility class ( CommandHandler )  is located in ignite-core module 
> currently. 
>  



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

[jira] [Closed] (IGNITE-2093) Add support for scan near cache to VisorQueryTask

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-2093.
--

> Add support for scan near cache to VisorQueryTask
> -
>
> Key: IGNITE-2093
> URL: https://issues.apache.org/jira/browse/IGNITE-2093
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> VisorQueryTask can execute EXPLAIN, SQL and SCAN queries, but it is not so 
> hard add support for SCAN NEAR CACHE "pseudo query" that will work on some 
> node locally and will return 
> ccache.localEntries(CachePeekMode.NEAR).iterator().



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

[jira] [Commented] (IGNITE-2093) Add support for scan near cache to VisorQueryTask

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-2093:


Re-tested on master

> Add support for scan near cache to VisorQueryTask
> -
>
> Key: IGNITE-2093
> URL: https://issues.apache.org/jira/browse/IGNITE-2093
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Alexey Kuznetsov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> VisorQueryTask can execute EXPLAIN, SQL and SCAN queries, but it is not so 
> hard add support for SCAN NEAR CACHE "pseudo query" that will work on some 
> node locally and will return 
> ccache.localEntries(CachePeekMode.NEAR).iterator().



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

[jira] [Commented] (IGNITE-7531) SQL: Create data load benchmarks

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7531:
--

[~pkouznet], the patch is OK with me.

> SQL: Create data load benchmarks
> 
>
> Key: IGNITE-7531
> URL: https://issues.apache.org/jira/browse/IGNITE-7531
> Project: Ignite
>  Issue Type: Task
>  Components: sql, yardstick
>Reporter: Vladimir Ozerov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> We need to implement a set of data loading benchmarks to better understand 
> how fast Ignite is able to consume data. This task consists of two steps:
> 1) Extend Yardstick capabilities
> 2) Create set of benchmarks
> 1) Yardstick
> Data load benchmark should be executed in single-shot mode: only one 
> iteration, only total execution time is needed, start callback for setup and 
> warmup, stop callback for cleanup. 
> Currently Yardstick cannot do that, so we need to extend it. Possibly, we can 
> control this through new {{boolean BenchmarkDriver.isSingleShot()}} method.
> 2) Benchmarks 
> At first let's focus on thin JDBC driver. The following cases should be 
> executed:
> 2.1) Normal INSERT
> 2.2) Batched INSERT
> 2.3) Streaming INSERT (when IGNITE-7253 is ready)
> 2.4) P. 1-3 with and without dynamically disabled WAL (ALTER TABLE ... 
> NOLOGGING)
> 2.5) P. 1-3 with additional indexes - either created before data load on 
> empty table, or after load on table with data.



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

[jira] [Created] (IGNITE-7887) [ML] Adopt SVM Linear Multi-Class Classification Model and Trainer to the new Partitioned Dataset

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-7887:


 Summary: [ML] Adopt SVM Linear Multi-Class Classification Model 
and Trainer to the new Partitioned Dataset
 Key: IGNITE-7887
 URL: https://issues.apache.org/jira/browse/IGNITE-7887
 Project: Ignite
  Issue Type: Sub-task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Commented] (IGNITE-7845) Data race on atomicLong close

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7845:


GitHub user akalash opened a pull request:

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

IGNITE-7845 fix checking atomicLong in IgniteClientDataStructuresTest…

…#testAtomicLong.

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

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

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

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


commit 514de7920e5ee7c7d3d83d1687de71d664e72028
Author: Anton Kalashnikov 
Date:   2018-03-06T10:22:37Z

IGNITE-7845 fix checking atomicLong in 
IgniteClientDataStructuresTest#testAtomicLong.




> Data race on atomicLong close
> -
>
> Key: IGNITE-7845
> URL: https://issues.apache.org/jira/browse/IGNITE-7845
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Found by IgniteClientDataStructuresTest.testAtomicLong.
> *Given:*
> IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
> true)
> *When:*
> IgniteAtomicLong was closed e.g. atomicLong.close()
> *Then:*
> If you try to get this value again sometimes you will get null 
> IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong 
> value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes 
> not null
> But if we will get not null value IgniteAtomicLong and we will call method 
> "get" on it, we will have one of two exception 
> IllegalStateException("Sequence was removed from cache: " + name) if it 
> already marked as deleted, and IgniteException("Failed to find atomic long: " 
> + name) if it sill no marked as deleted but already deleted from cache.
> *Expected:*
> IgniteAtomicLong value always should be null(or not?)
> *Why it's happend:*
> When we close IgniteAtomicLong we removing value from cache in transaction 
> but removing from internal storage(dsMap) happen asynchroniously in 
> DataStructuresEntryListener for all nodes include local node. And when we try 
> get value after close we still sometimes able to get IgniteAtomicLong from 
> internal local storage.
> *Solution(In my opinion):*
> I guess in common case we don't  need call Ignite#atomicLong  every time when 
> we need value, but we should use IgniteAtomicLong object received after first 
> call. And if it is true, we can remove receiving IgniteAtomicLong from local 
> storage(dsMap) - this changes will fix problem



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

[jira] [Commented] (IGNITE-6094) Web console: Implement persistent store in demo mode.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-6094:


re-tested on master

> Web console: Implement persistent store in demo mode.
> -
>
> Key: IGNITE-6094
> URL: https://issues.apache.org/jira/browse/IGNITE-6094
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>




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

[jira] [Closed] (IGNITE-6094) Web console: Implement persistent store in demo mode.

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov closed IGNITE-6094.
--

> Web console: Implement persistent store in demo mode.
> -
>
> Key: IGNITE-6094
> URL: https://issues.apache.org/jira/browse/IGNITE-6094
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Affects Versions: 2.1
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
>




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

[jira] [Comment Edited] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 3/6/18 9:29 AM:
--

[~vkulichenko] Hi!

I updated PR on 26th of February 2018. There were no conflicts since then.
Are you looking at correct PR ? This is the  [correct link to 
PR|https://github.com/apache/ignite/pull/3148]
Also links in ticket header were updated more than a week ago.


was (Author: alexey kuznetsov):
[~vkulichenko] Hi!

I updated PR on 26th of February 2018. There were no conflicts since then.
Are you looking at correct PR ? This is the  [correct link to 
PR|https://github.com/apache/ignite/pull/3148]

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-6846:
--

[~vkulichenko] Hi!

I updated PR on 26th of February 2018. There were no conflicts since then.
Are you looking at correct PR ? This is the  [correct link to 
PR|https://github.com/apache/ignite/pull/3148]

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.5
>
>
> {{CacheMetrics}} object has multiple metrics for various cache operations 
> like {{get}}, {{put}} and {{remove}}, but nothing for 
> {{invoke}}/{{EntryProcessor}}. It makes sense to add such metrics, for 
> example:
> * Total number of `invoke` operations executed.
> * Number of `invoke` operations that included updates.
> * Number of read-only `invoke` operations.
> * Min/max/avg execution time.
> * ...



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

[jira] [Assigned] (IGNITE-7845) Data race on atomicLong close

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov reassigned IGNITE-7845:
-

Assignee: Anton Kalashnikov

> Data race on atomicLong close
> -
>
> Key: IGNITE-7845
> URL: https://issues.apache.org/jira/browse/IGNITE-7845
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> Found by IgniteClientDataStructuresTest.testAtomicLong.
> *Given:*
> IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", 1L, 
> true)
> *When:*
> IgniteAtomicLong was closed e.g. atomicLong.close()
> *Then:*
> If you try to get this value again sometimes you will get null 
> IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong 
> value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes 
> not null
> But if we will get not null value IgniteAtomicLong and we will call method 
> "get" on it, we will have one of two exception 
> IllegalStateException("Sequence was removed from cache: " + name) if it 
> already marked as deleted, and IgniteException("Failed to find atomic long: " 
> + name) if it sill no marked as deleted but already deleted from cache.
> *Expected:*
> IgniteAtomicLong value always should be null(or not?)
> *Why it's happend:*
> When we close IgniteAtomicLong we removing value from cache in transaction 
> but removing from internal storage(dsMap) happen asynchroniously in 
> DataStructuresEntryListener for all nodes include local node. And when we try 
> get value after close we still sometimes able to get IgniteAtomicLong from 
> internal local storage.
> *Solution(In my opinion):*
> I guess in common case we don't  need call Ignite#atomicLong  every time when 
> we need value, but we should use IgniteAtomicLong object received after first 
> call. And if it is true, we can remove receiving IgniteAtomicLong from local 
> storage(dsMap) - this changes will fix problem



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

[jira] [Closed] (IGNITE-7810) Web console: replace Roboto slab font with Roboto regular

[Andrey Novikov (JIRA)]

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

Andrey Novikov closed IGNITE-7810.
--

> Web console: replace Roboto slab font with Roboto regular
> -
>
> Key: IGNITE-7810
> URL: https://issues.apache.org/jira/browse/IGNITE-7810
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Minor
>
> Since the Roboto slab font is considered deprecated, it should be replaced 
> with Roboto regular.
> What to do:
> 1. Replace global font on  with Roboto.
> 2. Look for Roboto slab in other place and remove it too.
> 3. Remove Roboto slab from dependencies, if applicable.



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

[jira] [Assigned] (IGNITE-5916) Web console: incorrect default value for Cache-Queries & Indexing-SQL index max inline size = -1

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-5916:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

[~kuaw26] please review and merge.

> Web console: incorrect default value for Cache-Queries & Indexing-SQL index 
> max inline size = -1
> 
>
> Key: IGNITE-5916
> URL: https://issues.apache.org/jira/browse/IGNITE-5916
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Major
>
> If I set -1 as real value then field become incorrect (red border)



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

[jira] [Commented] (IGNITE-7517) Get rid of org.jsr166.ConcurrentLinkedDeque8

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7517:
-

Note: Some usages of {{ConcurrentLinkedDeque8}} can't be removed without 
performance degradation. E.g. {{FifoEvictionPolicy}} and {{LruEvitionPolicy}}. 
So {{ConcurrentLinkedDeque8}} class still exists in code base.

> Get rid of org.jsr166.ConcurrentLinkedDeque8
> 
>
> Key: IGNITE-7517
> URL: https://issues.apache.org/jira/browse/IGNITE-7517
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Replace usages of {{ConcurrentLinkedDeque8}} by {{ConcurrentLinkedDeque}} 
> Java 8 implementation.



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