[jira] [Updated] (IGNITE-7655) Spark Data Frames: saving data frames into Ignite needs to be documented

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7655:

Component/s: documentation

> Spark Data Frames: saving data frames into Ignite needs to be documented
> 
>
> Key: IGNITE-7655
> URL: https://issues.apache.org/jira/browse/IGNITE-7655
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation, spark
>Reporter: Nikolay Izhikov
>Assignee: Denis Magda
>Priority: Major
> Fix For: 2.4
>
>
> Once IGNITE-7337 is ready for merge.
> This new feature of Ignite needs to be documented.



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

[jira] [Closed] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6994.
---

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Commented] (IGNITE-6994) Need to document PartitionLossPolicy

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6994:
-

Good, closing the ticket.

[~vkulichenko], please assess the doc and let us know if you want to see more 
clarity:

https://apacheignite.readme.io/v2.3/docs/cache-modes-24#partition-loss-policies

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Denis Magda
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> [https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html]
> However, there is no mentioning in the documentation about this. Need to 
> provide an explanation of how and when it should be used and provide 
> configuration examples.
> The documentation has to address questions and misunderstandings asked in 
> these discussions:
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-how-to-use-td25341.html]
>  * 
> [http://apache-ignite-developers.2346864.n4.nabble.com/Partition-loss-policy-to-disable-cache-completely-td26212.html]
> Improve the JavaDoc too whenever is possible.



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

[jira] [Commented] (IGNITE-7415) Ability to disable WAL (Documentation)

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-7415:
-

[~pgarg] , thanks a lot! Did minor corrections. However, I'm not sure that it 
is {{LOGGING/NOLOGGING}} a right name for the SQL command.

Started a discussion to clarify it:

[http://apache-ignite-developers.2346864.n4.nabble.com/Not-the-best-name-for-WAL-on-off-command-in-SQL-td27384.html]

Please keep an eye and update the doc if the command name changes.

> Ability to disable WAL (Documentation)
> --
>
> Key: IGNITE-7415
> URL: https://issues.apache.org/jira/browse/IGNITE-7415
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Anton Vinogradov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.4
>
>
> Need to update
> [https://apacheignite.readme.io/docs/write-ahead-log#section-wal-modes]
> [https://apacheignite.readme.io/docs/data-loading]



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

[jira] [Assigned] (IGNITE-7415) Ability to disable WAL (Documentation)

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7415:
---

Assignee: Prachi Garg  (was: Denis Magda)

> Ability to disable WAL (Documentation)
> --
>
> Key: IGNITE-7415
> URL: https://issues.apache.org/jira/browse/IGNITE-7415
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Anton Vinogradov
>Assignee: Prachi Garg
>Priority: Critical
> Fix For: 2.4
>
>
> Need to update
> [https://apacheignite.readme.io/docs/write-ahead-log#section-wal-modes]
> [https://apacheignite.readme.io/docs/data-loading]



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

[jira] [Created] (IGNITE-7798) Give user an ability to check driver metrics in Cassandra store

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7798:
---

 Summary: Give user an ability to check driver metrics in Cassandra 
store
 Key: IGNITE-7798
 URL: https://issues.apache.org/jira/browse/IGNITE-7798
 Project: Ignite
  Issue Type: Improvement
  Components: cassandra
Affects Versions: 2.3
Reporter: Valentin Kulichenko
 Fix For: 2.5


Cassandra store uses generic client driver to connect to the cluster. The 
driver provides {{Metrics}} object which can be useful for monitoring, however 
there is no way for user to acquire it. Need to find a way to expose this 
information to public API.



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

[jira] [Closed] (IGNITE-4719) Add documentation of current checks at Ignite-startup

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-4719.
---

> Add documentation of current checks at Ignite-startup
> -
>
> Key: IGNITE-4719
> URL: https://issues.apache.org/jira/browse/IGNITE-4719
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Vyacheslav Daradur
>Assignee: Denis Magda
>Priority: Minor
> Attachments: suggestions.docx
>
>




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

[jira] [Comment Edited] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov edited comment on IGNITE-7698 at 2/22/18 5:55 PM:
-

*Note:* To backport issue it is required to cherrypick 2 commits:
master (commit 1761a3c66dfa42fffa35e5cc736e2420e22851b8)
master (commit 7288828c595d5f6b9b59eae4d2c54d16d9770833)


was (Author: dpavlov):
*Note: * To backport issue it is required to cherrypick 2 commits:
master (commit 1761a3c66dfa42fffa35e5cc736e2420e22851b8)
master (commit 7288828c595d5f6b9b59eae4d2c54d16d9770833)

> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Commented] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7698:


[~agoncharuk], thank you!

> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Resolved] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov resolved IGNITE-7698.

Resolution: Fixed

*Note: * To backport issue it is required to cherrypick 2 commits:
master (commit 1761a3c66dfa42fffa35e5cc736e2420e22851b8)
master (commit 7288828c595d5f6b9b59eae4d2c54d16d9770833)

> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Commented] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7698:


Github user asfgit closed the pull request at:

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


> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Resolved] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov resolved IGNITE-7686.

Resolution: Fixed

> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent
> https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796



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

[jira] [Commented] (IGNITE-7780) Fix ClientConnectorConfigurationValidationSelfTest#testJdbcConnectionDisabledForDaemon

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7780:


Github user asfgit closed the pull request at:

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


> Fix 
> ClientConnectorConfigurationValidationSelfTest#testJdbcConnectionDisabledForDaemon
> --
>
> Key: IGNITE-7780
> URL: https://issues.apache.org/jira/browse/IGNITE-7780
> Project: Ignite
>  Issue Type: Test
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>




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

[jira] [Comment Edited] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk edited comment on IGNITE-7698 at 2/22/18 5:51 PM:
---

Thanks, Dmitriy, merged your changes to master (commit 
1761a3c66dfa42fffa35e5cc736e2420e22851b8)


was (Author: agoncharuk):
Thanks, Dmitriy, merged your changes to master

> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Commented] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7698:
--

Pushed another commit: 7288828c595d5f6b9b59eae4d2c54d16d9770833

> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Commented] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7686:


Github user asfgit closed the pull request at:

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


> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent
> https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796



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

[jira] [Commented] (IGNITE-7702) Adopt KNN classification to the new Dataset from dataset package

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7702:


GitHub user zaleslaw opened a pull request:

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

IGNITE-7702: Adopt kNN classifcation to the new datasets



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

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

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

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


commit ae9741f36d360c2deada2804baa2cec1fb0254ea
Author: zaleslaw 
Date:   2018-02-14T14:42:16Z

Added draft sample

commit 531b336d569456fdee11a424878bd119b3b63c28
Author: Zinoviev Alexey 
Date:   2018-02-22T11:42:05Z

IGNITE-7702: Added tests

commit ad71203ca565f9ef688bea1924bc77052818e236
Author: Zinoviev Alexey 
Date:   2018-02-22T17:06:51Z

IGNITE-7702: Fixed bug

commit fd8f976f3d42066139b0359709fb8ea6eded2f0f
Author: Zinoviev Alexey 
Date:   2018-02-22T17:09:32Z

IGNITE-7702: remove incorrect examples

commit 4622dc6df0bf48c800dc413a24278d227e96f6aa
Author: Zinoviev Alexey 
Date:   2018-02-22T17:10:17Z

IGNITE-7702: Rewrite KNN classifications

commit 3a661d9e0627b8696c580d4f3587f51b30800166
Author: Zinoviev Alexey 
Date:   2018-02-22T17:11:28Z

IGNITE-7702: Delete incorrect benchmarks




> Adopt KNN classification to the new Dataset from dataset package
> 
>
> Key: IGNITE-7702
> URL: https://issues.apache.org/jira/browse/IGNITE-7702
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
>




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

[jira] [Created] (IGNITE-7797) Adopt yardstick tests for the new version of kNN classification algorithm

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-7797:


 Summary: Adopt yardstick tests for the new version of kNN 
classification algorithm
 Key: IGNITE-7797
 URL: https://issues.apache.org/jira/browse/IGNITE-7797
 Project: Ignite
  Issue Type: Sub-task
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Created] (IGNITE-7796) Adopt kNN classification example to the new datasets

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-7796:


 Summary: Adopt kNN classification example to the new datasets
 Key: IGNITE-7796
 URL: https://issues.apache.org/jira/browse/IGNITE-7796
 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-6113) Partition eviction prevents exchange from completion

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-6113:
-

[~agoncharuk] 
All PR concerns are resolved. Task is ready to merge. 
Last TC Run: 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8_IgniteTests24Java8=pull%2F3445%2Fhead



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

[jira] [Created] (IGNITE-7795) Correct handling partitions restored in RENTING state

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-7795:
---

 Summary: Correct handling partitions restored in RENTING state
 Key: IGNITE-7795
 URL: https://issues.apache.org/jira/browse/IGNITE-7795
 Project: Ignite
  Issue Type: Bug
  Components: cache, persistence
Affects Versions: 2.3, 2.2, 2.1, 2.4
Reporter: Pavel Kovalenko
 Fix For: 2.5


Let's we have node which has partition in state RENTING after start. It could 
happen if node was stopped during partition eviction.

Started up node is only one owner by affinity for this partition.

Currently we will own this partition during rebalance preparing phase which 
seems is not correct. 

If we don't have owners for some partitions we should fail activation process, 
move this partition to MOVING state and clear it.



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

[jira] [Reopened] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reopened IGNITE-7686:


> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent
> https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796



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

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

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov updated IGNITE-7604:
---
Description: 
The following protocol is proposed for DML request with non-trivial reduce step 
within a transaction.

1. The SQL select part is deduced from a DML request and is split to form 
two-step map/reduce request.

2. Map query requests are sent to data nodes which execute them locally.

3. Resulting data pages are sent to originating node (reducer), which 
accumulates them.

4. Originating node performs reduce step on data received from map nodes and 
forms batches of updates to apply to target table.

5. Lock requests containing delta updates are mapped and sent to data nodes 
storing the corresponding keys.

6. Lock acks are received at originating node and accumulated there, producing 
the total update counter.

Note that no locks are acquired when map requests are processed. 
This is consistent with what Oracle and PostgreSQL do (but not MySQL!) with 
respect to locks within complex DML statements.

The Oracle docs 
(https://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT1351) 
specifically states:

The transaction that contains a DML statement does not need to acquire row 
locks on any rows selected by a subquery or an implicit query, such as a query 
in a WHERE clause. A subquery or implicit query in a DML statement is 
guaranteed to be consistent as of the start of the query and does not see the 
effects of the DML statement it is part of.


  was:Allow DML operations with reducer


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



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

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

[Sergey Kalashnikov (JIRA)]

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

Sergey Kalashnikov reassigned IGNITE-7604:
--

Assignee: Sergey Kalashnikov

> SQL TX: Allow DML operations with reducer
> -
>
> Key: IGNITE-7604
> URL: https://issues.apache.org/jira/browse/IGNITE-7604
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Igor Seliverstov
>Assignee: Sergey Kalashnikov
>Priority: Major
>
> Allow DML operations with reducer



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

[jira] [Commented] (IGNITE-7193) IgniteReflectionFactory does not handle primitive data types.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7193:


Looks good to me, [~agoncharuk], could you please merge?

> IgniteReflectionFactory does not handle primitive data types.
> -
>
> Key: IGNITE-7193
> URL: https://issues.apache.org/jira/browse/IGNITE-7193
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Minor
> Fix For: 2.5
>
>
> {code:java}
> public class TestClass {
> public static final int INITIAL_VALUE = 12;
> public static final int UPDATED_VALUE = 42;
> private int field = INITIAL_VALUE;
> public void setField(int value) {
> this.field = value;
> }
> public int getField() {
> return this.field;
> }
> public static void main(String[] args) {
> Map props = new HashMap<>();
> props.put("field", UPDATED_VALUE);
> IgniteReflectionFactory factory = new 
> IgniteReflectionFactory<>(ExampleNodeStartup.TestClass.class);
> factory.setProperties(props);
> assertEquals(UPDATED_VALUE, factory.create().getField());
> }
> }
> {code}



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

[jira] [Created] (IGNITE-7794) Marshaller mappings are not saved to disk on joining nodes

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-7794:


 Summary: Marshaller mappings are not saved to disk on joining nodes
 Key: IGNITE-7794
 URL: https://issues.apache.org/jira/browse/IGNITE-7794
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Denis Mekhanikov
 Fix For: 2.5
 Attachments: GridMarshallerMappingConsistencyTest.java

Find attached test class.

When a node connects to a cluster, that already has some marshaller mappings, 
they are not saved to disk on the joining node. It may result in "Unknown pair" 
error, if a cluster has persistence enabled, and a nodes without needed 
mappings start and try to read persisted data.



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

[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko commented on IGNITE-7717:
-

[~agoncharuk]
We don't have information whether exchange was merged with others or not. This 
information is presented in merged exchanges, but not in current. It means that 
topology version might not change after merge (if no one exchange was merged). 
If we call updateTopologies if no exchanges were merged to current we get 
AssertionError, because topology version was not changed. That is why I relaxed 
assertion.
But I think we can avoid it. I can add boolean flag to ExchangeFuture indicates 
that this future was merged with others and call updateTopologies only if merge 
is actually happened.

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 

[jira] [Updated] (IGNITE-7790) All critical errors should be covered by IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7790:
-
Summary: All critical errors should be covered by IgniteFailureProcessor  
(was: All critical errors health should be covered by IgniteFailureProcessor)

> All critical errors should be covered by IgniteFailureProcessor
> ---
>
> Key: IGNITE-7790
> URL: https://issues.apache.org/jira/browse/IGNITE-7790
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-14
>
> List of errors to be handled 
> - Persistence errors
> - IOOM errors (part of persistence errors?)
> - IO errors (list to be provided)
> - Assertion errors (we should handle assertions as failures in case -ea flag 
> set)



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

[jira] [Reopened] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov reopened IGNITE-7698:


> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

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

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin reassigned IGNITE-7628:
--

Assignee: Dmitriy Govorukhin

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



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

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

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7628:
---
Fix Version/s: 2.5

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



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

[jira] [Assigned] (IGNITE-7005) Ability to disable WAL (Recoverable case)

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-7005:


Assignee: (was: Anton Vinogradov)

> Ability to disable WAL (Recoverable case)
> -
>
> Key: IGNITE-7005
> URL: https://issues.apache.org/jira/browse/IGNITE-7005
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Reporter: Anton Vinogradov
>Priority: Major
> Fix For: 2.5
>
>
> In addition to non recoverable case(IGNITE-7003):
> On WAL disabling we should (on each node)
> - trigger exchange to guarantie consistent state
> - schedule new checkpoint. This checkpoint should be recorded to special 
> place (temporary checkpoint location), to prevent damage of latest one.
> All new checkpoints should update temporary checkpoint.
> On WAL enabling we should (on each node) after all nodes reported that 
> checkpoints finished
> - merge temp checkpoint with stable (scheduled before WAL disabling)
> - clean WAL
> before enabling proxies 
> On any failure during loading (while WAL disabled or enabling) we should be 
> able to reactivate cluster with
> - data from original checkpoints & WAL for affected caches
> - latest state for non affected caches
> Failover:
> Any topology change should be covered(while WAL disabled or enabling)
> - Node(s) Left (inc. coordinator)
> - Node(s) Join



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

[jira] [Assigned] (IGNITE-3456) Make sure EntryProcessor is always running on a OWNING partition

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-3456:


Assignee: (was: Anton Vinogradov)

> Make sure EntryProcessor is always running on a OWNING partition
> 
>
> Key: IGNITE-3456
> URL: https://issues.apache.org/jira/browse/IGNITE-3456
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Reporter: Alexey Goncharuk
>Priority: Minor
>
> Let's say I need to maintain some sort of an aggregate function over a 
> partition. This aggregate is maintained using an entry processor, and before 
> an update this entry processor queries this local aggregate.
> If an entry processor is applied on a partition with a MOVING state, the 
> state of the local aggregate is not valid because not all data has been 
> preloaded. If entry processor is applied on an OWNING partition, the result 
> is guaranteed to be correct.
> Given that we have implemented late affinity assignment when a new node is 
> assigned primary only when rebalancing is finished, this should be already 
> maintained. We just need to add tests verifying the partition state in 
> EntryProcessor.



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

[jira] [Assigned] (IGNITE-3195) Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-3195:


Assignee: (was: Anton Vinogradov)

> Rebalancing: IgniteConfiguration.rebalanceThreadPoolSize is wrongly treated
> ---
>
> Key: IGNITE-3195
> URL: https://issues.apache.org/jira/browse/IGNITE-3195
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Reporter: Denis Magda
>Priority: Major
> Fix For: 2.5
>
>
> Presently it's considered that the maximum number of threads that has to 
> process all demand and supply messages coming from all the nodes must not be 
> bigger than {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> Current implementation relies on ordered messages functionality creating a 
> number of topics equal to {{IgniteConfiguration.rebalanceThreadPoolSize}}.
> However, the implementation doesn't take into account that ordered messages, 
> that correspond to a particular topic, are processed in parallel for 
> different nodes. Refer to the implementation of 
> {{GridIoManager.processOrderedMessage}} to see that for every topic there 
> will be a unique {{GridCommunicationMessageSet}} for every node.
> Also to prove that this is true you can refer to this execution stack 
> {noformat}
> java.lang.RuntimeException: HAPPENED DEMAND
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:378)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:364)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:622)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:320)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$300(GridCacheIoManager.java:81)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1219)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2456)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1179)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:105)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1148)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All this means that in fact the number of threads that will be busy with 
> replication activity will be equal to 
> {{IgniteConfiguration.rebalanceThreadPoolSize}} x 
> number_of_nodes_participated_in_rebalancing



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

[jira] [Assigned] (IGNITE-7230) Improve rebalance logging and metrics

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov reassigned IGNITE-7230:


Assignee: (was: Anton Vinogradov)

> Improve rebalance logging and metrics
> -
>
> Key: IGNITE-7230
> URL: https://issues.apache.org/jira/browse/IGNITE-7230
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Anton Vinogradov
>Priority: Major
>
> 1) Node's log should contain messages that
> - local node finished rebalancing from other nodes
> - whole cluster finished rebalancing (awaitPartitionMaxExchange analogue)
> 2) We should be able to turn on same logging per cache group.
> - local node finished cache group rebalancing 
> - whole cluster finished cache group rebalancing
> Since cache group is not public. We should log cache names.
> 3) We should update MBean to show progress 
> - % of partitions rebalanced locally 
> - % of partitions rebalanced at cluster



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

[jira] [Resolved] (IGNITE-6763) Release process automation

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov resolved IGNITE-6763.
--
Resolution: Fixed

Automation donated to https://github.com/apache/ignite-release
and included to 
https://ci.ignite.apache.org/project.html?projectId=ApacheIgniteReleaseJava8

> Release process automation
> --
>
> Key: IGNITE-6763
> URL: https://issues.apache.org/jira/browse/IGNITE-6763
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>  Labels: teamcity
> Fix For: 2.5
>
>
> See devlist for details



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

[jira] [Created] (IGNITE-7793) SQL does not work if value has index filed which name equals to affinity key name

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-7793:
-

 Summary: SQL does not work if value has index filed which name 
equals to affinity key name
 Key: IGNITE-7793
 URL: https://issues.apache.org/jira/browse/IGNITE-7793
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Mikhail Cherkasov
 Fix For: 2.5


SQL does not work if value has index filed which name equals to affinity key 
name:
{code:java}
public class AKey {
@AffinityKeyMapped
int a;
public AKey(int a) {
this.a = a;
}
}

public class AVal {
@QuerySqlField
int a;
public AVal(int a) {
this.a = a;
}
}

AKey aKey = new AKey(1);
AVal aVal = new AVal(0);

IgniteCache cache = ignite.cache("Instrument");
cache.put(aKey, aVal);

SqlFieldsQuery query = new SqlFieldsQuery("select * from \"Instrument\".AVal it 
where it.a=?");

List res = cache.query(query.setArgs(0)).getAll();

if(res.isEmpty()) {
System.out.println("! FAILED !!!");
}


{code}



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

[jira] [Commented] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7698:


GitHub user dspavlov opened a pull request:

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

IGNITE-7698: Fixed test hangup, avoid to double lock page in case of …

…restore is done.

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

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

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

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


commit aaff74d1c1e91559ffd2123d350ca0895e6d2f76
Author: dpavlov 
Date:   2018-02-22T13:15:10Z

IGNITE-7698: Fixed test hangup, avoid to double lock page in case of 
restore is done.




> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Commented] (IGNITE-7029) Add an ability to provide multiple connection addresses for thin JDBC driver

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7029:
--

[~vozerov]
I see at least two ways of the feature implementation:
1. Multiple addresses in connection properties.
2. Gather node addresses from Ignite cluster after connect to any node.
Any suggestion?

Should we implement load balance on multiple connection ow the first alive 
address should be used (for the fist implementation)?

> Add an ability to provide multiple connection addresses for thin JDBC driver
> 
>
> Key: IGNITE-7029
> URL: https://issues.apache.org/jira/browse/IGNITE-7029
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Major
>
> Currently we allow only to provide one address when connecting via thin JDBC 
> driver. This has to issues:
> * If node driver is connected to goes down, the driver stops working.
> * Driver has to always go though the same node - this is a bottleneck.
> As a simple solution we can allow to provide multiple addresses, like MySQL 
> does for example: 
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-usagenotes-j2ee-concepts-managing-load-balanced-connections.html



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6890 at 2/22/18 1:02 PM:
---

[~cyberdemon], 
I did some refactoring on your changes, please see result at 
https://github.com/apache/ignite/pull/3558
Origninal PR adress is https://github.com/apache/ignite/pull/3083


was (Author: avinogradov):
[~cyberdemon], 
I did some refactoring on your changes, please see result at 
https://github.com/apache/ignite/pull/3558

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6552:


GitHub user akalash opened a pull request:

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

IGNITE-6552 ability to set WAL history size in MBytes



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

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

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

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


commit 10a7221392d00caa25f99f7f1aa33408c085e759
Author: Anton Kalashnikov 
Date:   2018-02-22T11:57:38Z

IGNITE-6552 ability to set WAL history size in MBytes

commit 1bf01c091e064bc48fe49a3b750e1c47e68fbc4a
Author: Anton Kalashnikov 
Date:   2018-02-22T13:00:59Z

IGNITE-6552 change FileDescriptor header




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



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6890:
--

[~cyberdemon], 
I did some refactoring on your changes, please see result at 
https://github.com/apache/ignite/pull/3558

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



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6890:


GitHub user anton-vinogradov opened a pull request:

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

IGNITE-6890 General way for handling Ignite failures (NodeInvalidator…

… should be replaced with IgniteFailureProcessor)

Signed-off-by: Anton Vinogradov 

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

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

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

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


commit 4730f6c7511a715789fcf2ac1139f3c1526e7d19
Author: Anton Vinogradov 
Date:   2018-02-22T12:58:35Z

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

Signed-off-by: Anton Vinogradov 




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



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

[jira] [Commented] (IGNITE-7780) Fix ClientConnectorConfigurationValidationSelfTest#testJdbcConnectionDisabledForDaemon

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7780:


Test fixed, [~agoncharuk], could you please merge this fix?

[~pvinokurov] could you please set Patch Available status for issue.

> Fix 
> ClientConnectorConfigurationValidationSelfTest#testJdbcConnectionDisabledForDaemon
> --
>
> Key: IGNITE-7780
> URL: https://issues.apache.org/jira/browse/IGNITE-7780
> Project: Ignite
>  Issue Type: Test
>Reporter: Pavel Vinokurov
>Assignee: Pavel Vinokurov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>




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

[jira] [Assigned] (IGNITE-7029) Add an ability to provide multiple connection addresses for thin JDBC driver

[Taras Ledkov (JIRA)]

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

Taras Ledkov reassigned IGNITE-7029:


Assignee: Taras Ledkov

> Add an ability to provide multiple connection addresses for thin JDBC driver
> 
>
> Key: IGNITE-7029
> URL: https://issues.apache.org/jira/browse/IGNITE-7029
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
>Priority: Major
>
> Currently we allow only to provide one address when connecting via thin JDBC 
> driver. This has to issues:
> * If node driver is connected to goes down, the driver stops working.
> * Driver has to always go though the same node - this is a bottleneck.
> As a simple solution we can allow to provide multiple addresses, like MySQL 
> does for example: 
> https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-usagenotes-j2ee-concepts-managing-load-balanced-connections.html



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

[jira] [Created] (IGNITE-7792) IgniteDatabaseSharedManager refactoring

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-7792:


 Summary: IgniteDatabaseSharedManager refactoring
 Key: IGNITE-7792
 URL: https://issues.apache.org/jira/browse/IGNITE-7792
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Igor Seliverstov


Currently there is no mapping of cacheId to page memory which prevents adding 
custom persistent structures 
({{GridCacheDatabaseSharedManager.WriteCheckpointPages#run}}).



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

[jira] [Commented] (IGNITE-7489) Weird FillFactor metric fluctuation.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7489:


Github user asfgit closed the pull request at:

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


> Weird FillFactor metric fluctuation.
> 
>
> Key: IGNITE-7489
> URL: https://issues.apache.org/jira/browse/IGNITE-7489
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.5
>
> Attachments: FillFactorTest.java
>
>
> For now there is no way to get Used\FreeMemory for region in bytes. 
> MemoryMetrics.getPagesFillFactor() javadoc says that the method return the 
> percentage of space that is still free and can be filled in.
> So, I'd think used memory can be calculated as 
> PhysicalMemoryPages*PageSize*FillFactor.
> I've tried to use this, but found weir thing.
>  
> PFA a repro.
> There is 2 node grid with no persistence configure. Topology is stable.
> Cache is populated with unique keys (no updates) and observe allocated data 
> pages metric grows constantly as expected.
> But the error look too large, used memory (and FillFactor as well) may 2-10+ 
> time differs.
> E.g. allocated pages, fillFactor, usedMem (bytes):(
>  node-0: 13789 0.851563 48096032
>  node-1: 14447 0.781250 46230400
> In next second:
> node-0: 13958 0.039063 2233280
>  node-1: 14624 0.347656 20824576
>  



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

[jira] [Updated] (IGNITE-7489) Weird FillFactor metric fluctuation.

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk updated IGNITE-7489:
-
Fix Version/s: 2.5

> Weird FillFactor metric fluctuation.
> 
>
> Key: IGNITE-7489
> URL: https://issues.apache.org/jira/browse/IGNITE-7489
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.5
>
> Attachments: FillFactorTest.java
>
>
> For now there is no way to get Used\FreeMemory for region in bytes. 
> MemoryMetrics.getPagesFillFactor() javadoc says that the method return the 
> percentage of space that is still free and can be filled in.
> So, I'd think used memory can be calculated as 
> PhysicalMemoryPages*PageSize*FillFactor.
> I've tried to use this, but found weir thing.
>  
> PFA a repro.
> There is 2 node grid with no persistence configure. Topology is stable.
> Cache is populated with unique keys (no updates) and observe allocated data 
> pages metric grows constantly as expected.
> But the error look too large, used memory (and FillFactor as well) may 2-10+ 
> time differs.
> E.g. allocated pages, fillFactor, usedMem (bytes):(
>  node-0: 13789 0.851563 48096032
>  node-1: 14447 0.781250 46230400
> In next second:
> node-0: 13958 0.039063 2233280
>  node-1: 14624 0.347656 20824576
>  



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

[jira] [Updated] (IGNITE-7772) All critical system workers health should be covered by IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7772:
-
Description: 
List of system workers should be covered by this engine:

disco-event-worker
tcp-disco-sock-reader
tcp-disco-srvr
tcp-disco-msg-worker
tcp-comm-worker
grid-nio-worker-tcp-comm
exchange-worker
sys-stripe
grid-timeout-worker
db-checkpoint-thread
wal-file-archiver
ttl-cleanup-worker
nio-acceptor

> All critical system workers health should be covered by IgniteFailureProcessor
> --
>
> Key: IGNITE-7772
> URL: https://issues.apache.org/jira/browse/IGNITE-7772
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
>
> List of system workers should be covered by this engine:
> disco-event-worker
> tcp-disco-sock-reader
> tcp-disco-srvr
> tcp-disco-msg-worker
> tcp-comm-worker
> grid-nio-worker-tcp-comm
> exchange-worker
> sys-stripe
> grid-timeout-worker
> db-checkpoint-thread
> wal-file-archiver
> ttl-cleanup-worker
> nio-acceptor



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

[jira] [Commented] (IGNITE-7763) Ignite CPP tests win32 failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7763:


GitHub user isapego opened a pull request:

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

IGNITE-7763: Fixed C++ Win32 test failures



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

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

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

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


commit f7b5c71d76c01e84da6dedb0ba1dfedac79640eb
Author: Igor Sapego 
Date:   2018-02-21T17:08:35Z

IGNITE-7763: Fixed test configurations




> Ignite CPP tests win32 failure
> --
>
> Key: IGNITE-7763
> URL: https://issues.apache.org/jira/browse/IGNITE-7763
> Project: Ignite
>  Issue Type: Task
>Reporter: Dmitriy Pavlov
>Assignee: Igor Sapego
>Priority: Critical
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_IgnitePlatformCppWin32
>  
> aborted
> std::exception: Failed to load JVM library.



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

[jira] [Created] (IGNITE-7791) Ignite Client Nodes: failed test IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7791:
---

 Summary: Ignite Client Nodes: failed test 
IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated()
 Key: IGNITE-7791
 URL: https://issues.apache.org/jira/browse/IGNITE-7791
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Chugunov
 Fix For: 2.5


Test is flaky, success rate: 32.4%, test history is 
[here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-9174769196124217030=testDetails]

Reproducible locally.

Test fails on waiting for disco cache content:
{noformat}
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at junit.framework.TestCase.assertTrue(TestCase.java:201)
at 
org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkCacheDiscoveryData(IgniteClientReconnectCacheTest.java:1414)
at 
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:745)
{noformat}

This fail may be caused by another exception earlier in the log:
{noformat}
[2018-02-22 
14:32:57,972][ERROR][exchange-worker-#3025%internal.IgniteClientReconnectCacheTest3%][GridDhtPartitionsExchangeFuture]
 Failed to reinitialize local partitions (preloading will be stopped): 
GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=6, 
minorTopVer=1], discoEvt=DiscoveryCustomEvent 
[customMsg=CacheAffinityChangeMessage 
[id=3cea94db161-760b7b18-b776-4ee7-ae5a-64f9494eaa36, 
topVer=AffinityTopologyVersion [topVer=3, minorTopVer=0], exchId=null, 
partsMsg=null, exchangeNeeded=true], affTopVer=AffinityTopologyVersion 
[topVer=6, minorTopVer=1], super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=1b7f7330-69d8-4bd0-b2e9-71773610, addrs=[127.0.0.1], 
sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1519299177395, loc=false, ver=2.5.0#19700101-sha1:, 
isClient=false], topVer=6, nodeId8=658aeb36, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1519299177971]], nodeId=1b7f7330, 
evt=DISCOVERY_CUSTOM_EVT]
java.lang.AssertionError: 236160867
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$CachesInfo.group(CacheAffinitySharedManager.java:2636)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:989)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$8.applyx(CacheAffinitySharedManager.java:983)
at 
org.apache.ignite.internal.util.lang.IgniteInClosureX.apply(IgniteInClosureX.java:38)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllCacheGroups(CacheAffinitySharedManager.java:1118)
at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onChangeAffinityMessage(CacheAffinitySharedManager.java:983)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAffinityChangeRequest(GridDhtPartitionsExchangeFuture.java:992)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:648)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2337)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}



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

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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6890:
-
Summary: General way for handling Ignite failures (NodeInvalidator shuld be 
replaced with IgniteFailureProcessor)  (was: General way for handling Ignite 
failures (IgniteFailureProcessor )

> General way for handling Ignite failures (NodeInvalidator shuld 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.



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

[jira] [Updated] (IGNITE-6890) General way for handling Ignite failures (IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6890:
-
Summary: General way for handling Ignite failures (IgniteFailureProcessor   
(was: General way for handling Ignite failures)

> General way for handling Ignite failures (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.



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

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6890:
-
Summary: General way for handling Ignite failures (NodeInvalidator should 
be replaced with IgniteFailureProcessor)  (was: General way for handling Ignite 
failures (NodeInvalidator shuld be replaced with IgniteFailureProcessor))

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



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

[jira] [Updated] (IGNITE-7790) All critical errors health should be covered by IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7790:
-
Labels: iep-14  (was: )

> All critical errors health should be covered by IgniteFailureProcessor
> --
>
> Key: IGNITE-7790
> URL: https://issues.apache.org/jira/browse/IGNITE-7790
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-14
>
> List of errors to be handled 
> - Persistence errors
> - IOOM errors (part of persistence errors?)
> - IO errors (list to be provided)
> - Assertion errors (we should handle assertions as failures in case -ea flag 
> set)



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

[jira] [Updated] (IGNITE-6892) OOM should be covered by IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6892:
-
Summary: OOM should be covered by IgniteFailureProcessor  (was: Proper 
behavior on OOM)

> OOM should be covered by IgniteFailureProcessor
> ---
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> In case of any OOM node should be stopped anyway, what we can provide is user 
> callback, something like 'beforeNodeStop'.
> Some memory should be reserved at node start to increase chances of OOM 
> handling.



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

[jira] [Updated] (IGNITE-7789) Ignite Client Nodes: failed test IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7789:

Description: 
Test is flaky, success rate: 47.9%, test history is 
[here|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3790177050933093125=testDetails].

May fail in two different ways.

*1 Assertion error in test code*

Rarely reproducible locally.

{noformat}
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [1]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3073)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:285)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:280)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:745)
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
update keys on primary node.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKeys(UpdateErrors.java:124)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:342)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1785)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3055)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
... 12 more
Suppressed: java.lang.AssertionError: Assertion error on search row: 
org.apache.ignite.internal.processors.cache.tree.SearchRow@511c0beb
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1633)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1199)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1767)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
at 

[jira] [Created] (IGNITE-7790) All critical errors health should be covered by IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-7790:


 Summary: All critical errors health should be covered by 
IgniteFailureProcessor
 Key: IGNITE-7790
 URL: https://issues.apache.org/jira/browse/IGNITE-7790
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov


List of errors to be handled 

- Persistence errors
- IOOM errors (part of persistence errors?)
- IO errors (list to be provided)
- Assertion errors (we should handle assertions as failures in case -ea flag 
set)



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

[jira] [Updated] (IGNITE-7772) All critical system workers health should be covered by IgniteFailureProcessor

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-7772:
-
Summary: All critical system workers health should be covered by 
IgniteFailureProcessor  (was: All critical system workers health should be 
covered)

> All critical system workers health should be covered by IgniteFailureProcessor
> --
>
> Key: IGNITE-7772
> URL: https://issues.apache.org/jira/browse/IGNITE-7772
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-14
>




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

[jira] [Updated] (IGNITE-6890) General way for handling Ignite failures

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov 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.

  was:
Ignite failures which should be handled are:
 # Topology segmentation;
 # Exchange worker stop;
 # Persistence errors.

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



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

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

Alexey Kuznetsov commented on IGNITE-1553:
--

[~agoncharuk] 
I have implemented this optimisation, and i have a question.

This optimisation requires database to support prepare and commit phases. 
Suppose, we have some database `A`, we have no way to figure out whether it 
supports prepare and finish or not.

I propose to add some method 

{code:java}
boolean supports2PhaseCommit(){
   return true;// or false;
}
{code}

 to CacheStore interface. It will give us opportunity to optimize transaction 
prepare step given any cache store.

What do you think about it ?




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



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

[jira] [Updated] (IGNITE-7789) Ignite Client Nodes: failed test IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7789:

Description: 
Test is flaky, success rate: 47.9%

May fail in two different ways.

*1 Assertion error in test code*

Rarely reproducible locally.

{noformat}
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [1]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3073)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:285)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:280)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:745)
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
update keys on primary node.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKeys(UpdateErrors.java:124)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:342)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1785)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3055)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
... 12 more
Suppressed: java.lang.AssertionError: Assertion error on search row: 
org.apache.ignite.internal.processors.cache.tree.SearchRow@511c0beb
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1633)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1199)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1767)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1883)
at 

[jira] [Created] (IGNITE-7789) Ignite Client Nodes: failed test IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7789:
---

 Summary: Ignite Client Nodes: failed test 
IgniteClientReconnectApiExceptionTest.testErrorOnDisconnect()
 Key: IGNITE-7789
 URL: https://issues.apache.org/jira/browse/IGNITE-7789
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Chugunov
 Fix For: 2.5


Test is flaky, success rate: 47.9%

May fail in two different ways.
*1 Assertion error in test code*

Rarely reproducible locally.

{noformat}
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [1]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3073)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:285)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:280)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1089)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
at java.lang.Thread.run(Thread.java:745)
Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to 
update keys on primary node.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKeys(UpdateErrors.java:124)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKeys(GridNearAtomicUpdateResponse.java:342)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1785)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3055)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
... 12 more
Suppressed: java.lang.AssertionError: Assertion error on search row: 
org.apache.ignite.internal.processors.cache.tree.SearchRow@511c0beb
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1633)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1199)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:345)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1767)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2420)
at 

[jira] [Updated] (IGNITE-6892) Proper behavior on OOM

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6892:
-
Description: 
In case of any OOM node should be stopped anyway, what we can provide is user 
callback, something like 'beforeNodeStop'.

Some memory should be reserved at node start to increase chances of OOM 
handling.

  was:
In case of any OOM node should be stopped anyway, what we can provide is user 
callback, something like 'beforeNodeStop'.

IGNITE-6890 covers (should cover) IOOM case


> Proper behavior on OOM
> --
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> In case of any OOM node should be stopped anyway, what we can provide is user 
> callback, something like 'beforeNodeStop'.
> Some memory should be reserved at node start to increase chances of OOM 
> handling.



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

[jira] [Updated] (IGNITE-6892) Proper behavior on OOM

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6892:
-
Summary: Proper behavior on OOM  (was: Proper behavior on 
OOM/IgniteOutOfMemoryException)

> Proper behavior on OOM
> --
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> In case of any OOM node should be stopped anyway, what we can provide is user 
> callback, something like 'beforeNodeStop'.
> IGNITE-6890 covers (should cover) IOOM case



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

[jira] [Updated] (IGNITE-6892) Proper behavior on OOM/IgniteOutOfMemoryException

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov updated IGNITE-6892:
-
Labels: iep-14  (was: iep-7)

> Proper behavior on OOM/IgniteOutOfMemoryException
> -
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> In case of any OOM node should be stopped anyway, what we can provide is user 
> callback, something like 'beforeNodeStop'.
> IGNITE-6890 covers (should cover) IOOM case



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

[jira] [Commented] (IGNITE-3077) IgniteRDD data frame does not handle object fields

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3077:


Github user asfgit closed the pull request at:

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


> IgniteRDD data frame does not handle object fields
> --
>
> Key: IGNITE-3077
> URL: https://issues.apache.org/jira/browse/IGNITE-3077
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: bigdata
> Fix For: 2.5
>
>
> Added a corresponding test to IgniteRDDSpec
> I am not sure what causing this failure because sql returns a proper result 
> set on the Ignite side, and it cannot be converted to DataFrame row. Spark 
> dev list consultation needed most likely.



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

[jira] [Assigned] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin reassigned IGNITE-7788:
--

Assignee: Alexey Goncharuk

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexey Goncharuk
>Priority: Critical
> Attachments: IgnitePdsCacheRestoreTest.java
>
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Assigned] (IGNITE-6552) The ability to set WAL history size in time units

[Anton Kalashnikov (JIRA)]

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

Anton Kalashnikov reassigned IGNITE-6552:
-

Assignee: Anton Kalashnikov

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



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

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

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin reassigned IGNITE-7628:
--

Assignee: (was: Dmitriy Govorukhin)

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



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

[jira] [Commented] (IGNITE-7489) Weird FillFactor metric fluctuation.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7489:


Thanks to [~avinogradov] for his suggestions on how to improve test and test's 
code style.

Now it was fixed, [~agoncharuk], could merge?


> Weird FillFactor metric fluctuation.
> 
>
> Key: IGNITE-7489
> URL: https://issues.apache.org/jira/browse/IGNITE-7489
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1, 2.2, 2.3
>Reporter: Andrew Mashenkov
>Assignee: Ilya Kasnacheev
>Priority: Major
> Attachments: FillFactorTest.java
>
>
> For now there is no way to get Used\FreeMemory for region in bytes. 
> MemoryMetrics.getPagesFillFactor() javadoc says that the method return the 
> percentage of space that is still free and can be filled in.
> So, I'd think used memory can be calculated as 
> PhysicalMemoryPages*PageSize*FillFactor.
> I've tried to use this, but found weir thing.
>  
> PFA a repro.
> There is 2 node grid with no persistence configure. Topology is stable.
> Cache is populated with unique keys (no updates) and observe allocated data 
> pages metric grows constantly as expected.
> But the error look too large, used memory (and FillFactor as well) may 2-10+ 
> time differs.
> E.g. allocated pages, fillFactor, usedMem (bytes):(
>  node-0: 13789 0.851563 48096032
>  node-1: 14447 0.781250 46230400
> In next second:
> node-0: 13958 0.039063 2233280
>  node-1: 14624 0.347656 20824576
>  



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

[jira] [Updated] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-7788:
---
Attachment: IgnitePdsCacheRestoreTest.java

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Critical
> Attachments: IgnitePdsCacheRestoreTest.java
>
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Updated] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-7788:
---
Attachment: (was: IgnitePdsCacheRestoreTest.java)

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Critical
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Comment Edited] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin edited comment on IGNITE-7788 at 2/22/18 10:03 AM:
--

Changing group on both caches (c1 and c2) causes the error described in 
[IGNITE-7383|https://issues.apache.org/jira/browse/IGNITE-7383]


was (Author: ein):
Changing group on both caches (c1 and c2) causes the error

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Critical
> Attachments: IgnitePdsCacheRestoreTest.java
>
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Commented] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin commented on IGNITE-7788:


Changing group on both caches (c1 and c2) causes the error

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Critical
> Attachments: IgnitePdsCacheRestoreTest.java
>
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Updated] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

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

Alexandr Kuramshin updated IGNITE-7788:
---
Attachment: IgnitePdsCacheRestoreTest.java

> Data loss after cold restart with PDS and cache group change
> 
>
> Key: IGNITE-7788
> URL: https://issues.apache.org/jira/browse/IGNITE-7788
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Priority: Critical
> Attachments: IgnitePdsCacheRestoreTest.java
>
>
> Reproduced by improved test 
> {{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Created] (IGNITE-7788) Data loss after cold restart with PDS and cache group change

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-7788:
--

 Summary: Data loss after cold restart with PDS and cache group 
change
 Key: IGNITE-7788
 URL: https://issues.apache.org/jira/browse/IGNITE-7788
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.3
Reporter: Alexandr Kuramshin


Reproduced by improved test 
{{IgnitePdsCacheRestoreTest.testRestoreAndNewCache6}}



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

[jira] [Comment Edited] (IGNITE-5910) Method stopGrid(name) doesn't work in multiJvm mode

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur edited comment on IGNITE-5910 at 2/22/18 9:50 AM:
-

I have investigated the issue and found that stopping node in separate JVM may 
stuck thread or leave system process alive after test finished.


 The main reason is {{StopGridTask}} that we send from node in local JVM to 
node in separate JVM via remote computing. We send job synchronously to be sure 
that node will be stopped, but job calls synchronously 
{{G.stop(igniteInstanceName, cancel))}} with {{cancel = false}}, that means 
node must wait to compute jobs before it goes down what leads to some kind of 
deadlock. Using of {{cancel = true}} would solve the issue but may break some 
tests’ logic, for this reason, I've reworked the method’s synchronization logic.


 We have not noticed that before because we use only {{stopAllGrids()}} in out 
tests which stop local JVM without waiting for nodes in other JVMs.


 I believe this fix should reduce the number of flaky tests on TeamCity, 
especially which fails because of a cluster from the previous test has not been 
stopped properly.

[Ci.tests|https://ci.ignite.apache.org/viewLog.html?buildId=1105939] look a bit 
better than in master.

[~dpavlov], could you please review [the prepared 
PR|https://github.com/apache/ignite/pull/2382]?


was (Author: daradurvs):
I have investigated the issue and found that stopping node in separate JVM may 
stuck thread or leave system process alive after test finished.
The main reason is {{StopGridTask}} that we send from node in local JVM to node 
in separate JVM via remote computing.
We send job synchronously to be sure that node will be stopped, but job calls 
synchronously {{G.stop(igniteInstanceName, cancel))}} with {{cancel = false}}, 
that means node must wait to compute jobs before it goes down what leads to 
some kind of deadlock. Using of {{cancel = true}} would solve the issue but may 
break some tests’ logic, for this reason, I've reworked the method’s 
synchronization logic.
We have not noticed that before because we use only {{stopAllGrids()}} in out 
tests which stop local JVM without waiting for nodes in other JVMs.
I believe this fix should reduce the number of flaky tests on TeamCity, 
especially which fails because of a cluster from the previous test has not been 
stopped properly.

[Ci.tests|https://ci.ignite.apache.org/viewLog.html?buildId=1105939] look a bit 
better than in master.

[~dpavlov], could you please review [the prepared 
PR|https://github.com/apache/ignite/pull/2382]?

> Method stopGrid(name) doesn't work in multiJvm mode
> ---
>
> Key: IGNITE-5910
> URL: https://issues.apache.org/jira/browse/IGNITE-5910
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, tests
> Fix For: 2.5
>
>
> {code:title=Exception at call}
> java.lang.ClassCastException: 
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
> cast to org.apache.ignite.internal.IgniteKernal
> {code}
> {code:title=Reproducer snippet}
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> /**
>  * @throws Exception If failed.
>  */
> public void testGrid() throws Exception {
> try {
> startGrid(0);
> startGrid(1);
> }
> finally {
> stopGrid(1);
> stopGrid(0);
> }
> }
> {code}
> *UPD:* It is necessary to fix possibility of hangup of a system thread of 
> separate JVM at Ignite's node shutdown.



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

[jira] [Commented] (IGNITE-7717) testAssignmentAfterRestarts is flaky on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7717:
--

Pavel,

I do not like that we weakened the assertion in updateTopologyVersion method. I 
see that you added an additional callback only to mergedExchange() branch, why 
did you need to relax the assertion?

> testAssignmentAfterRestarts is flaky on TC
> --
>
> Key: IGNITE-7717
> URL: https://issues.apache.org/jira/browse/IGNITE-7717
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> There is infinite awaiting of partitions map exchange:
> {noformat}
> [2018-02-15 13:41:46,180][WARN 
> ][test-runner-#1%persistence.IgnitePdsCacheAssignmentNodeRestartsTest%][root] 
> Waiting for topology map update 
> [igniteInstanceName=persistence.IgnitePdsCacheAssignmentNodeRestartsTest0, 
> cache=ignite-sys-cache, cacheId=-2100569601, topVer=AffinityTopologyVersion 
> [topVer=11, minorTopVer=0], p=0, affNodesCnt=5, ownersCnt=3, 
> affNodes=[126cbc54-1b9f-46b8-a978-b6c61ee1, 
> 0971749e-e313-4c57-99ab-40400b10, 84f71ca6-6213-43a0-91ea-42eca512, 
> 3d781b31-ed38-49c8-8875-bdfa2fa3, 8f4bdf1c-a2c8-45e8-acd7-64bb4564], 
> owners=[0971749e-e313-4c57-99ab-40400b10, 
> 126cbc54-1b9f-46b8-a978-b6c61ee1, 3d781b31-ed38-49c8-8875-bdfa2fa3], 
> topFut=GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryEvent 
> [evtNode=TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, 
> intOrder=6, lastExchangeTime=1518691298151, loc=false, 
> ver=2.5.0#19700101-sha1:, isClient=false], topVer=9, 
> nodeId8=0971749e, msg=Node joined: TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], 
> crd=TcpDiscoveryNode [id=0971749e-e313-4c57-99ab-40400b10, 
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, 
> intOrder=1, lastExchangeTime=1518691306165, loc=true, 
> ver=2.5.0#19700101-sha1:, isClient=false], 
> exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=9, 
> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], topVer=9, nodeId8=0971749e, msg=Node joined: 
> TcpDiscoveryNode [id=3d781b31-ed38-49c8-8875-bdfa2fa3, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47502], discPort=47502, order=9, intOrder=6, 
> lastExchangeTime=1518691298151, loc=false, ver=2.5.0#19700101-sha1:, 
> isClient=false], type=NODE_JOINED, tstamp=1518691298244], nodeId=3d781b31, 
> evt=NODE_JOINED], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=true, hash=2121252210], init=true, 
> lastVer=GridCacheVersion [topVer=0, order=1518691297806, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=9, minorTopVer=0], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=9, minorTopVer=0], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1518691298244, 
> centralizedAff=false, forceAffReassignment=false, changeGlobalStateE=null, 
> done=true, state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=AffinityTopologyVersion [topVer=11, 
> minorTopVer=0], hash=1135515588]], locNode=TcpDiscoveryNode 
> [id=0971749e-e313-4c57-99ab-40400b10, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1518691306165, loc=true, ver=2.5.0#19700101-sha1:, 
> isClient=false]]
> {noformat}
> This happens because of inconsistency of discoCache (cacheGrpAffNodes map) on 
> different nodes after restart.



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

[jira] [Created] (IGNITE-7787) Better error reporting when issuing PDS corruptions.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-7787:
-

 Summary: Better error reporting when issuing PDS corruptions.
 Key: IGNITE-7787
 URL: https://issues.apache.org/jira/browse/IGNITE-7787
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Alexei Scherbakov
 Fix For: 2.5


If PDS is corrupted in any way and update hits bad page shown error message is 
not very helping, usually something like "Failed to get page IO instance (page 
content is corrupted)"

For corruptions related to CacheDataRowStore error should contain information 
about how to fix the issue: clear data for cache/group and restart node for 
partition reloading.

For corruptions related to H2Tree (SQL indexes) error should contain suggestion 
to remove index.bin for broken partition and restart node allowing index to 
rebuild.





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

[jira] [Commented] (IGNITE-6005) [Test failed] GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-6005:
-

[~agura], [~dpavlov]

TC run. Hanging test muted

https://ci.ignite.apache.org/viewQueued.html?itemId=1106624=queuedBuildOverviewTab

> [Test failed] 
> GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe
> -
>
> Key: IGNITE-6005
> URL: https://issues.apache.org/jira/browse/IGNITE-6005
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Example of fail
> https://ci.ignite.apache.org/viewLog.html?buildId=762788=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures
> Typical problem is 
> {code}
> org.apache.ignite.IgniteInterruptedException: Failed to wait for asynchronous 
> operation permit (thread got interrupted).
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:805)
> at 
> org.apache.ignite.internal.util.IgniteUtils$3.apply(IgniteUtils.java:803)
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:961)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1026)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.InterruptedException: null
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1301)
> at java.util.concurrent.Semaphore.acquire(Semaphore.java:317)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOpAcquire(GridCacheAdapter.java:4314)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.asyncOp(GridCacheAdapter.java:4177)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.getAsync(GridDhtColocatedCache.java:196)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4509)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4490)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1324)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProxyImpl.get(GridCacheProxyImpl.java:329)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor$5.applyx(DataStructuresProcessor.java:635)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.retryTopologySafe(DataStructuresProcessor.java:1519)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeDataStructure(DataStructuresProcessor.java:629)
> at 
> org.apache.ignite.internal.processors.datastructures.DataStructuresProcessor.removeSemaphore(DataStructuresProcessor.java:1188)
> at 
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.close(GridCacheSemaphoreImpl.java:1023)
> at 
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe(GridCacheAbstractDataStructuresFailoverSelfTest.java:458)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> 

[jira] [Commented] (IGNITE-4719) Add documentation of current checks at Ignite-startup

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-4719:


Hi, [~dmagda], I would like to close this ticket as {{won’t fix}} because I no 
longer see a need to document this checks.
 [The existing 
article|https://apacheignite.readme.io/docs/jvm-and-system-tuning] should be 
enough.

> Add documentation of current checks at Ignite-startup
> -
>
> Key: IGNITE-4719
> URL: https://issues.apache.org/jira/browse/IGNITE-4719
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Vyacheslav Daradur
>Assignee: Denis Magda
>Priority: Minor
> Attachments: suggestions.docx
>
>




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

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

[Dmitry Sherstobitov (JIRA)]

Dmitry Sherstobitov created IGNITE-7786:
---

 Summary: Changing baseline topology on big cluster may have error 
in control.sh utility
 Key: IGNITE-7786
 URL: https://issues.apache.org/jira/browse/IGNITE-7786
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Dmitry Sherstobitov


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

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



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

[jira] [Updated] (IGNITE-5910) Method stopGrid(name) doesn't work in multiJvm mode

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-5910:
---
Description: 
{code:title=Exception at call}
java.lang.ClassCastException: 
org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
cast to org.apache.ignite.internal.IgniteKernal
{code}

{code:title=Reproducer snippet}
/** {@inheritDoc} */
@Override protected boolean isMultiJvm() {
return true;
}

/**
 * @throws Exception If failed.
 */
public void testGrid() throws Exception {
try {
startGrid(0);

startGrid(1);
}
finally {
stopGrid(1);

stopGrid(0);
}
}
{code}

*UPD:* It is necessary to fix possibility of hangup of a system thread of 
separate JVM at Ignite's node shutdown.

  was:
{code:title=Exception at call}
java.lang.ClassCastException: 
org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
cast to org.apache.ignite.internal.IgniteKernal
{code}

{code:title=Reproducer snippet}
/** {@inheritDoc} */
@Override protected boolean isMultiJvm() {
return true;
}

/**
 * @throws Exception If failed.
 */
public void testGrid() throws Exception {
try {
startGrid(0);

startGrid(1);
}
finally {
stopGrid(1);

stopGrid(0);
}
}
{code}


> Method stopGrid(name) doesn't work in multiJvm mode
> ---
>
> Key: IGNITE-5910
> URL: https://issues.apache.org/jira/browse/IGNITE-5910
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, tests
> Fix For: 2.5
>
>
> {code:title=Exception at call}
> java.lang.ClassCastException: 
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
> cast to org.apache.ignite.internal.IgniteKernal
> {code}
> {code:title=Reproducer snippet}
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> /**
>  * @throws Exception If failed.
>  */
> public void testGrid() throws Exception {
> try {
> startGrid(0);
> startGrid(1);
> }
> finally {
> stopGrid(1);
> stopGrid(0);
> }
> }
> {code}
> *UPD:* It is necessary to fix possibility of hangup of a system thread of 
> separate JVM at Ignite's node shutdown.



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

[jira] [Commented] (IGNITE-3077) IgniteRDD data frame does not handle object fields

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3077:


GitHub user nizhikov opened a pull request:

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

IGNITE-3077: Test fixed



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

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

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

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


commit 0ca135a02aaad79260af140a709e0b2fcb60cab0
Author: Nikolay Izhikov 
Date:   2018-02-22T09:24:10Z

IGNITE-3077: Test fixed




> IgniteRDD data frame does not handle object fields
> --
>
> Key: IGNITE-3077
> URL: https://issues.apache.org/jira/browse/IGNITE-3077
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: bigdata
>
> Added a corresponding test to IgniteRDDSpec
> I am not sure what causing this failure because sql returns a proper result 
> set on the Ignite side, and it cannot be converted to DataFrame row. Spark 
> dev list consultation needed most likely.



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

[jira] [Commented] (IGNITE-7750) testMultiThreadStatisticsEnable is flaky on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7750:


Github user asfgit closed the pull request at:

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


> testMultiThreadStatisticsEnable is flaky on TC
> --
>
> Key: IGNITE-7750
> URL: https://issues.apache.org/jira/browse/IGNITE-7750
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {code:java}
> class org.apache.ignite.IgniteException: Cache not found [cacheName=cache2]
> at 
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:985)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:497)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsEnableRuntimeTest$3.run(CacheMetricsEnableRuntimeTest.java:181)
> at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1275)
> at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> Caused by: class org.apache.ignite.IgniteCheckedException: Cache not found 
> [cacheName=cache2]
> at 
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.enableStatistics(GridCacheProcessor.java:4227)
> at 
> org.apache.ignite.internal.cluster.IgniteClusterImpl.enableStatistics(IgniteClusterImpl.java:494)
> ... 3 more
> {code}
> The problem of the test:
> 1) We don't wait for exchange future completion after "cache2" is started and 
> it may lead to NullPointerException when we try to obtain reference to 
> "cache2" on the node which doesn't complete exchange future and initialize 
> cache proxy.



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

[jira] [Commented] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7749:


Github user asfgit closed the pull request at:

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


> testDiscoCacheReuseOnNodeJoin fails on TC
> -
>
> Key: IGNITE-7749
> URL: https://issues.apache.org/jira/browse/IGNITE-7749
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {code:java}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to 
> java.lang.String
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93)
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64)
> {code}
> There are 2 problems in the test.
> 1) We don't wait for final topology version is set on all nodes and start 
> checking discovery caches immediately after grids starting. It leads to 
> possible NullPointerException while accessing to discovery caches history.
> 2) We don't use explicit assertEquals(String, Object, Object) related to 
> comparing Objects, while Java can choose assertEquals(String, String) method 
> to compare discovery cache fields which we're getting in runtime using 
> reflection.



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

[jira] [Commented] (IGNITE-7749) testDiscoCacheReuseOnNodeJoin fails on TC

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7749:
--

Pavel, changes look good to me. Merged to master.

> testDiscoCacheReuseOnNodeJoin fails on TC
> -
>
> Key: IGNITE-7749
> URL: https://issues.apache.org/jira/browse/IGNITE-7749
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> {code:java}
> java.lang.ClassCastException: 
> org.apache.ignite.internal.util.GridConcurrentHashSet cannot be cast to 
> java.lang.String
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.assertDiscoCacheReuse(IgniteDiscoveryCacheReuseSelfTest.java:93)
> at 
> org.apache.ignite.spi.discovery.IgniteDiscoveryCacheReuseSelfTest.testDiscoCacheReuseOnNodeJoin(IgniteDiscoveryCacheReuseSelfTest.java:64)
> {code}
> There are 2 problems in the test.
> 1) We don't wait for final topology version is set on all nodes and start 
> checking discovery caches immediately after grids starting. It leads to 
> possible NullPointerException while accessing to discovery caches history.
> 2) We don't use explicit assertEquals(String, Object, Object) related to 
> comparing Objects, while Java can choose assertEquals(String, String) method 
> to compare discovery cache fields which we're getting in runtime using 
> reflection.



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

[jira] [Assigned] (IGNITE-7445) Thin client: SQL batching

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur reassigned IGNITE-7445:
--

Assignee: (was: Vyacheslav Daradur)

> Thin client: SQL batching
> -
>
> Key: IGNITE-7445
> URL: https://issues.apache.org/jira/browse/IGNITE-7445
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.5
>
>
> SQL batching allows executing multiple SQL queries in one client request, 
> improving performance.
> See how JDBC does it in {{JdbcBatchExecuteRequest}}, add a similar thing in 
> Thin Client protocol.



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

[jira] [Commented] (IGNITE-7686) PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7686:
--

Dmitriy, I merged the changes of IGNITE-7698, let's see if this fixes the TC

> PDS Direct IO failure: IgnitePdsEvictionTest.testPageEviction 
> --
>
> Key: IGNITE-7686
> URL: https://issues.apache.org/jira/browse/IGNITE-7686
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testPageEviction, timeout=30] 
> Reproduced only on TC agent
> https://ci.ignite.apache.org/viewLog.html?buildId=1090347=buildResultsDiv=IgniteTests24Java8_IgnitePds1DirectIo#testNameId3144891032708936796



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

[jira] [Commented] (IGNITE-7698) Page read during replacement should be outside of segment write lock

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7698:


Github user asfgit closed the pull request at:

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


> Page read during replacement should be outside of segment write lock
> 
>
> Key: IGNITE-7698
> URL: https://issues.apache.org/jira/browse/IGNITE-7698
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.5
>
>
> When a page is acquired, if it needs to be read from disk, we read it inside 
> the segment write lock which blocks other threads from acquiring pages that 
> are already in memory.
> This can be easily avoided: once we initialized the page's being loaded RW 
> lock, we can immediately acquire the write lock - no deadlocks can happen 
> here. Afterwards, we can release the segment write lock and read the page.
> The change seems to be very local.



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

[jira] [Commented] (IGNITE-5910) Method stopGrid(name) doesn't work in multiJvm mode

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur commented on IGNITE-5910:


I have investigated the issue and found that stopping node in separate JVM may 
stuck thread or leave system process alive after test finished.
The main reason is {{StopGridTask}} that we send from node in local JVM to node 
in separate JVM via remote computing.
We send job synchronously to be sure that node will be stopped, but job calls 
synchronously {{G.stop(igniteInstanceName, cancel))}} with {{cancel = false}}, 
that means node must wait to compute jobs before it goes down what leads to 
some kind of deadlock. Using of {{cancel = true}} would solve the issue but may 
break some tests’ logic, for this reason, I've reworked the method’s 
synchronization logic.
We have not noticed that before because we use only {{stopAllGrids()}} in out 
tests which stop local JVM without waiting for nodes in other JVMs.
I believe this fix should reduce the number of flaky tests on TeamCity, 
especially which fails because of a cluster from the previous test has not been 
stopped properly.

[Ci.tests|https://ci.ignite.apache.org/viewLog.html?buildId=1105939] look a bit 
better than in master.

[~dpavlov], could you please review [the prepared 
PR|https://github.com/apache/ignite/pull/2382]?

> Method stopGrid(name) doesn't work in multiJvm mode
> ---
>
> Key: IGNITE-5910
> URL: https://issues.apache.org/jira/browse/IGNITE-5910
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, tests
> Fix For: 2.5
>
>
> {code:title=Exception at call}
> java.lang.ClassCastException: 
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
> cast to org.apache.ignite.internal.IgniteKernal
> {code}
> {code:title=Reproducer snippet}
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> /**
>  * @throws Exception If failed.
>  */
> public void testGrid() throws Exception {
> try {
> startGrid(0);
> startGrid(1);
> }
> finally {
> stopGrid(1);
> stopGrid(0);
> }
> }
> {code}



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

[jira] [Assigned] (IGNITE-3077) IgniteRDD data frame does not handle object fields

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov reassigned IGNITE-3077:
---

Assignee: Nikolay Izhikov

> IgniteRDD data frame does not handle object fields
> --
>
> Key: IGNITE-3077
> URL: https://issues.apache.org/jira/browse/IGNITE-3077
> Project: Ignite
>  Issue Type: Bug
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Alexey Goncharuk
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: bigdata
>
> Added a corresponding test to IgniteRDDSpec
> I am not sure what causing this failure because sql returns a proper result 
> set on the Ignite side, and it cannot be converted to DataFrame row. Spark 
> dev list consultation needed most likely.



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

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

[Oleg Ostanin (JIRA)]

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

Oleg Ostanin commented on IGNITE-7774:
--

[~guseinov] Changes look good to me, please check if it works on your local 
environment.

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

[jira] [Commented] (IGNITE-7759) Logger does not print sockTimeout and ackTimeout default values for TcpDiscoverySpi

[Roman Guseinov (JIRA)]

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

Roman Guseinov commented on IGNITE-7759:


Hi Ruchir,

 

Sure. No prob.

 

Best Regards,

Roman

> Logger does not print sockTimeout and ackTimeout default values for 
> TcpDiscoverySpi
> ---
>
> Key: IGNITE-7759
> URL: https://issues.apache.org/jira/browse/IGNITE-7759
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 1.9, 2.1, 2.3
>Reporter: Roman Guseinov
>Priority: Minor
>  Labels: newbie
>
> Logger does not print sockTimeout and ackTimeout default values for 
> TcpDiscoverySpi
> Before starting TcpDiscoverySpi logger prints the following message (debug 
> mode is enabled):
> {code:java}
> [main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null, 
> sockTimeout=0, ackTimeout=0, marsh=JdkMarshaller 
> [clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10, 
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> {code}
> Note, that sockTimeout=0 and ackTimeout=0. Default values initializing 
> happens after TcpDiscoverySpi.spiStart is called:
> {code:java}
> public class TcpDiscoverySpi extends IgniteSpiAdapter implements DiscoverySpi 
> {
> /** Node attribute that is mapped to node's external addresses (value is 
> disc.tcp.ext-addrs). */
> /** {@inheritDoc} */
> @Override public void spiStart(@Nullable String igniteInstanceName) 
> throws IgniteSpiException {
> initializeImpl();
> }
> /**
>  *
>  */
> private void initializeImpl() {
> if (impl != null)
> return;
> initFailureDetectionTimeout();
> if (!forceSrvMode && 
> (Boolean.TRUE.equals(ignite.configuration().isClientMode( {
> if (ackTimeout == 0)
> ackTimeout = DFLT_ACK_TIMEOUT_CLIENT;
> if (sockTimeout == 0)
> sockTimeout = DFLT_SOCK_TIMEOUT_CLIENT;
> impl = new ClientImpl(this);
> ctxInitLatch.countDown();
> }
> else {
> if (ackTimeout == 0)
> ackTimeout = DFLT_ACK_TIMEOUT;
> if (sockTimeout == 0)
> sockTimeout = DFLT_SOCK_TIMEOUT;
> impl = new ServerImpl(this);
> }
>  
> }
> }
> {code}
> To avoid confusion I suggest printing default sockTimeout and ackTimeout if 
> they weren't changed like:
> {code:java}
> [main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null, 
> sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller 
> [clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10, 
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false, 
> clientReconnectDisabled=false]
> {code}



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

[jira] [Updated] (IGNITE-7785) SQL query with COUNT and UNION in sub-query produces JdbcSQLException

[Pavel Vinokurov (JIRA)]

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

Pavel Vinokurov updated IGNITE-7785:

Description: 
SQL initial script:

CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
 CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
 INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
 INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');

SQL Query:

SELECT count(1) FROM person p
 LEFT JOIN (select id from company union select id from company) as c on 
c.id=p.company_id

JDBC Exception:

Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
the GROUP BY list; SQL statement:
SELECT
P__Z0.COMPANY_ID __C0_0,
COUNT(1) __C0_1
FROM PUBLIC.PERSON P__Z0 [90016-195]

 

  was:
SQL initial script:

CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');

SQL Query:

SELECT count(*) FROM person p
LEFT JOIN (select id from company union select id from company) as c on 
c.id=p.company_id

SQL error:

Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
the GROUP BY list; SQL statement:
SELECT
P__Z0.COMPANY_ID __C0_0,
COUNT(*) __C0_1
FROM PUBLIC.PERSON P__Z0 [90016-195]

 


> SQL query with COUNT and UNION in sub-query produces JdbcSQLException
> -
>
> Key: IGNITE-7785
> URL: https://issues.apache.org/jira/browse/IGNITE-7785
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1, 2.3
>Reporter: Pavel Vinokurov
>Priority: Major
>
> SQL initial script:
> CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
>  CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
>  INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
>  INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');
> SQL Query:
> SELECT count(1) FROM person p
>  LEFT JOIN (select id from company union select id from company) as c on 
> c.id=p.company_id
> JDBC Exception:
> Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
> the GROUP BY list; SQL statement:
> SELECT
> P__Z0.COMPANY_ID __C0_0,
> COUNT(1) __C0_1
> FROM PUBLIC.PERSON P__Z0 [90016-195]
>  



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

[jira] [Created] (IGNITE-7785) SQL query with COUNT and UNION in sub-query produces JdbcSQLException

[Pavel Vinokurov (JIRA)]

Pavel Vinokurov created IGNITE-7785:
---

 Summary: SQL query with COUNT and UNION in sub-query produces 
JdbcSQLException
 Key: IGNITE-7785
 URL: https://issues.apache.org/jira/browse/IGNITE-7785
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3, 2.1
Reporter: Pavel Vinokurov


SQL initial script:

CREATE TABLE Person(id INTEGER PRIMARY KEY, company_id INTEGER);
CREATE TABLE Company(id INTEGER PRIMARY KEY, name VARCHAR);
INSERT INTO Person(id,company_id) VALUES (1, 1), (2, 2), (3, 3);
INSERT INTO Company(id,name) VALUES (1,'n1'), (2,'n2'), (3,'n3');

SQL Query:

SELECT count(*) FROM person p
LEFT JOIN (select id from company union select id from company) as c on 
c.id=p.company_id

SQL error:

Caused by: org.h2.jdbc.JdbcSQLException: Column "P__Z0.COMPANY_ID" must be in 
the GROUP BY list; SQL statement:
SELECT
P__Z0.COMPANY_ID __C0_0,
COUNT(*) __C0_1
FROM PUBLIC.PERSON P__Z0 [90016-195]

 



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

[jira] [Updated] (IGNITE-5910) Method stopGrid(name) doesn't work in multiJvm mode

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-5910:
---
Labels: MakeTeamcityGreenAgain tests  (was: tests)

> Method stopGrid(name) doesn't work in multiJvm mode
> ---
>
> Key: IGNITE-5910
> URL: https://issues.apache.org/jira/browse/IGNITE-5910
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, tests
> Fix For: 2.5
>
>
> {code:title=Exception at call}
> java.lang.ClassCastException: 
> org.apache.ignite.testframework.junits.multijvm.IgniteProcessProxy cannot be 
> cast to org.apache.ignite.internal.IgniteKernal
> {code}
> {code:title=Reproducer snippet}
> /** {@inheritDoc} */
> @Override protected boolean isMultiJvm() {
> return true;
> }
> /**
>  * @throws Exception If failed.
>  */
> public void testGrid() throws Exception {
> try {
> startGrid(0);
> startGrid(1);
> }
> finally {
> stopGrid(1);
> stopGrid(0);
> }
> }
> {code}



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