[jira] [Commented] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1628:


Github user asfgit closed the pull request at:

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


> .NET: Ensure that Ignite works on Mono platform
> ---
>
> Key: IGNITE-1628
> URL: https://issues.apache.org/jira/browse/IGNITE-1628
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
> Fix For: 2.4
>
>
> *NOTE*: Targeted for 1.6, but could be moved even further in case of tight 
> release schedule.
> *Goal*
> As Microsoft is moving .Net towards open standards, Mono receives more an 
> more attention. 
> We need to ensure that our product works fine on this platform. This includes 
> both Windows, Linux and (possibly) Mac environments.
> *Tasks*
> - Ensure that Ignite works with Mono on Windows. This is the easiest task 
> because we only need to re-compile .Net part.
> - Ensure that Ignite works with Mono on Linux. This will require alternate 
> build procedure because CPP recompilation will be required as well.
> - Create relevant TC builds.



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

[jira] [Resolved] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-1628.

   Resolution: Fixed
Fix Version/s: 2.4

> .NET: Ensure that Ignite works on Mono platform
> ---
>
> Key: IGNITE-1628
> URL: https://issues.apache.org/jira/browse/IGNITE-1628
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
> Fix For: 2.4
>
>
> *NOTE*: Targeted for 1.6, but could be moved even further in case of tight 
> release schedule.
> *Goal*
> As Microsoft is moving .Net towards open standards, Mono receives more an 
> more attention. 
> We need to ensure that our product works fine on this platform. This includes 
> both Windows, Linux and (possibly) Mac environments.
> *Tasks*
> - Ensure that Ignite works with Mono on Windows. This is the easiest task 
> because we only need to re-compile .Net part.
> - Ensure that Ignite works with Mono on Linux. This will require alternate 
> build procedure because CPP recompilation will be required as well.
> - Create relevant TC builds.



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

[jira] [Commented] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1628:


Merged to master: {{b38fe30d6ac32bd243ef87950f000a81403e97cb}}.

> .NET: Ensure that Ignite works on Mono platform
> ---
>
> Key: IGNITE-1628
> URL: https://issues.apache.org/jira/browse/IGNITE-1628
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
>
> *NOTE*: Targeted for 1.6, but could be moved even further in case of tight 
> release schedule.
> *Goal*
> As Microsoft is moving .Net towards open standards, Mono receives more an 
> more attention. 
> We need to ensure that our product works fine on this platform. This includes 
> both Windows, Linux and (possibly) Mac environments.
> *Tasks*
> - Ensure that Ignite works with Mono on Windows. This is the easiest task 
> because we only need to re-compile .Net part.
> - Ensure that Ignite works with Mono on Linux. This will require alternate 
> build procedure because CPP recompilation will be required as well.
> - Create relevant TC builds.



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

[jira] [Assigned] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7031:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Fixed some bug. Please test.

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Assigned] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7031:
-

Assignee: Alexander Kalinin  (was: Pavel Konstantinov)

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Alexander Kalinin
>Priority: Major
> Attachments: screenshot-1.png
>
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session

[Igor Rudyak (JIRA)]

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

Igor Rudyak commented on IGNITE-6853:
-

I think you can just manually implement analogs of mocks created by Mockito 
(inheriting mock classes from Cassandra Session, Cluster and etc.) and use them 
the same way like you already doing it in your tests.

> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session
> 
>
> Key: IGNITE-6853
> URL: https://issues.apache.org/jira/browse/IGNITE-6853
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Jason Man
>Priority: Major
>  Labels: important
> Fix For: 2.4
>
>
> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session which can lead to:
>  Prepared
> statement cluster error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute
> unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have
> used a PreparedStatement that was created with another Cluster instance.



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

[jira] [Assigned] (IGNITE-7274) Web Agent: Support multiple statements on Queries screen.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7274:


Assignee: Vladimir Ozerov  (was: Alexey Kuznetsov)

[~vozerov] Please review my changed in branch ignite-7274 (compare with master).

> Web Agent: Support multiple statements on Queries screen.
> -
>
> Key: IGNITE-7274
> URL: https://issues.apache.org/jira/browse/IGNITE-7274
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.4
>
>
> See IGNITE-6046 for API



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

[jira] [Closed] (IGNITE-7407) Cancelling Query notebook deletion doesn't work

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin closed IGNITE-7407.
-

Issue is not reproduced anymore.

> Cancelling Query notebook deletion doesn't work
> ---
>
> Key: IGNITE-7407
> URL: https://issues.apache.org/jira/browse/IGNITE-7407
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Major
>
> Steps to reproduce:
> 1) Create a query notebook
> 2) Open this notebook in Queries page
> 3) Click "delete" (trash bin icon)
> 4) In confirmation window click "Cancel"
>  
> Actual:
> Notebook is deleted
> Expected:
> Notebook is not deleted.



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

[jira] [Resolved] (IGNITE-7407) Cancelling Query notebook deletion doesn't work

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin resolved IGNITE-7407.
---
Resolution: Cannot Reproduce

Is not reproduced after master update.

> Cancelling Query notebook deletion doesn't work
> ---
>
> Key: IGNITE-7407
> URL: https://issues.apache.org/jira/browse/IGNITE-7407
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Alexander Kalinin
>Priority: Major
>
> Steps to reproduce:
> 1) Create a query notebook
> 2) Open this notebook in Queries page
> 3) Click "delete" (trash bin icon)
> 4) In confirmation window click "Cancel"
>  
> Actual:
> Notebook is deleted
> Expected:
> Notebook is not deleted.



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

[jira] [Assigned] (IGNITE-7420) Too thick modal body

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7420:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Fixed. Please verify.

> Too thick modal body
> 
>
> Key: IGNITE-7420
> URL: https://issues.apache.org/jira/browse/IGNITE-7420
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Alexander Kalinin
>Assignee: Pavel Konstantinov
>Priority: Minor
> Attachments: yz0r1o.jpg
>
>
> !yz0r1o.jpg!



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

[jira] [Comment Edited] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin edited comment on IGNITE-6816 at 1/16/18 4:03 AM:


[~Dmitriyff] Auto DLL module has been fixed. Tested. Please review,


was (Author: alexdel):
Auto DLL module has been fixed. Tested. Please review,

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Dmitriy Shabalin
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Assigned] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6816:
-

Assignee: Dmitriy Shabalin  (was: Ilya Borisov)

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Dmitriy Shabalin
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Assigned] (IGNITE-6816) Webconsole: investigate/integrate Webpack dll-plugin

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-6816:
-

Assignee: Ilya Borisov  (was: Alexander Kalinin)

Auto DLL module has been fixed. Tested. Please review,

> Webconsole: investigate/integrate Webpack dll-plugin
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Trivial
>
> As the webconsole frontend app size grows, it takes more and more time to 
> incrementally rebuild after each source code change in development 
> environment. Let's investigate this plugin 
> https://webpack.js.org/plugins/dll-plugin/ and integrate it into webpack 
> build pipeline if it offers measureable performance improvements.



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

[jira] [Created] (IGNITE-7420) Too thick modal body

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-7420:
-

 Summary: Too thick modal body
 Key: IGNITE-7420
 URL: https://issues.apache.org/jira/browse/IGNITE-7420
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin
 Attachments: yz0r1o.jpg

!yz0r1o.jpg!



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

[jira] [Commented] (IGNITE-6853) Cassandra cache store does not clean prepared statements cache when remove old cassandra session

[Jason Man (JIRA)]

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

Jason Man commented on IGNITE-6853:
---

It's difficult to simulate the Cassandra errors without using a mocking 
framework.  I think this is why currently there is a lack of 'negative' tests 
covering the ignite-cassandra module, and why this bug was not discovered/fixed 
earlier.

Perhaps we could start discussing this in the community dev email list?

> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session
> 
>
> Key: IGNITE-6853
> URL: https://issues.apache.org/jira/browse/IGNITE-6853
> Project: Ignite
>  Issue Type: Bug
>  Components: cassandra
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Jason Man
>Priority: Major
>  Labels: important
> Fix For: 2.4
>
>
> Cassandra cache store does not clean prepared statements cache when remove 
> old cassandra session which can lead to:
>  Prepared
> statement cluster error detected, refreshing Cassandra session
> com.datastax.driver.core.exceptions.InvalidQueryException: Tried to execute
> unknown prepared query : 0xcad5832309a512feeb602eec67408130. You may have
> used a PreparedStatement that was created with another Cluster instance.



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

[jira] [Commented] (IGNITE-6022) SQL: add native batch execution support for DML statements

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-6022:


[~vozerov], [~al.psc], please review. Tests are ok, except one flaky test in 
Query 2 suite. 

I also found some problem with an SQL wrong error state and error code when 
distributed query execution fails on remote nodes. For example in 
{{JdbcThinBatchSelfTest#testBatchUpdateExceptionPrepared}} test an error should 
be {{SqlStateCode.CONVERSION_FAILED}} (due to wrong value was supplied as an 
argument), but we have  {{SqlStateCode.INTERNAL_ERROR}}. Should I add a new 
ticket for this?

> SQL: add native batch execution support for DML statements
> --
>
> Key: IGNITE-6022
> URL: https://issues.apache.org/jira/browse/IGNITE-6022
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> We have batch execution support for JDBC and ODBC drivers. This decreases 
> number of network hops. However, we do not have any batch execution support 
> on the server side. It means that for batch of N similar statements, every 
> statement will go through the whole execution chain - parsing, splitting, 
> communication with servers. And while parsing and splitting might be avoided 
> with help of statement cache, the most heavy part - network communication - 
> is still there.
> We need to investigate how to optimize the flow for batch updates. Possible 
> improvements:
> 1) Execute statements with certain degree of parallelism;
> 2) Send several query execution requests to the server at once;
> 3) Ensure that caches are used properly for batching - we should not parse 
> the same request multiple times.



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

[jira] [Commented] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6953:
-

[~VitaliyB] , thanks for reproducing and looking into this. [~agoncharuk] could 
you chime in please.

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: OOMETest.java, ignite-0590a557.log, ignite-5df99d7b.log, 
> ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Updated] (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 updated IGNITE-7415:

Environment: (was: Need to update
[https://apacheignite.readme.io/docs/write-ahead-log#section-wal-modes]
[https://apacheignite.readme.io/docs/data-loading])

> Ability to disable WAL (Documentation)
> --
>
> Key: IGNITE-7415
> URL: https://issues.apache.org/jira/browse/IGNITE-7415
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Anton Vinogradov
>Priority: Major
>




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

[jira] [Updated] (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 updated IGNITE-7415:

Description: 
Need to update
[https://apacheignite.readme.io/docs/write-ahead-log#section-wal-modes]
[https://apacheignite.readme.io/docs/data-loading]

> Ability to disable WAL (Documentation)
> --
>
> Key: IGNITE-7415
> URL: https://issues.apache.org/jira/browse/IGNITE-7415
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Anton Vinogradov
>Priority: Major
>
> 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] [Updated] (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 updated IGNITE-7415:

Component/s: documentation

> Ability to disable WAL (Documentation)
> --
>
> Key: IGNITE-7415
> URL: https://issues.apache.org/jira/browse/IGNITE-7415
> Project: Ignite
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Anton Vinogradov
>Priority: Major
>
> 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-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7408:
---

Assignee: Prachi Garg

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Gura
>Assignee: Prachi Garg
>Priority: Major
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Updated] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7408:

Description: 
WAL documentation should be updated accordingly to IGNITE-6339 issue.

The following changes can affect WAL configuration and behavior:
 # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size equals 
WAL segment size if memory mapped file is enabled, and (WAL segment size) / 4 
if memory mapped file is disabled.
 # Memory mapped file is enabled by default and provides better performance. 
Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
{{false}} value should be added to the JVM arguments: 
{{-DIGNITE_WAL_MMAP=false}}.
 # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
modes behave identically and don't have any differences in performance or data 
integrity guarantees.

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
> Environment: WAL documentation should be updated accordingly to 
> IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {\{DataStorageConfiguration.setWalBufferSize}} added instead of 
> \{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. \{{IGNITE_WAL_MMAP}} property 
> with \{{false}} value should be added to the JVM arguments: 
> \{{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then \{{BACKGROUND}} and \{{LOG_ONLY}} 
> WAL modes behave identically and don't have any differences in performance or 
> data integrity guarantees.
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Updated] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7408:

Environment: (was: WAL documentation should be updated accordingly to 
IGNITE-6339 issue.

The following changes can affect WAL configuration and behavior:
 # {\{DataStorageConfiguration.setWalBufferSize}} added instead of 
\{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size equals 
WAL segment size if memory mapped file is enabled, and (WAL segment size) / 4 
if memory mapped file is disabled.
 # Memory mapped file is enabled by default and provides better performance. 
Memory mapped file usage can be turned off. \{{IGNITE_WAL_MMAP}} property with 
\{{false}} value should be added to the JVM arguments: 
\{{-DIGNITE_WAL_MMAP=false}}.
 # If memory mapped file is enabled then \{{BACKGROUND}} and \{{LOG_ONLY}} WAL 
modes behave identically and don't have any differences in performance or data 
integrity guarantees.)

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Updated] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7408:

Component/s: documentation

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
> Environment: WAL documentation should be updated accordingly to 
> IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {\{DataStorageConfiguration.setWalBufferSize}} added instead of 
> \{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. \{{IGNITE_WAL_MMAP}} property 
> with \{{false}} value should be added to the JVM arguments: 
> \{{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then \{{BACKGROUND}} and \{{LOG_ONLY}} 
> WAL modes behave identically and don't have any differences in performance or 
> data integrity guarantees.
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Updated] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7408:

Description: 
WAL documentation should be updated accordingly to IGNITE-6339 issue.

The following changes can affect WAL configuration and behavior:
 # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size equals 
WAL segment size if memory mapped file is enabled, and (WAL segment size) / 4 
if memory mapped file is disabled.
 # Memory mapped file is enabled by default and provides better performance. 
Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
{{false}} value should be added to the JVM arguments: 
{{-DIGNITE_WAL_MMAP=false}}.
 # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
modes behave identically and don't have any differences in performance or data 
integrity guarantees.

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
> Environment: WAL documentation should be updated accordingly to 
> IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {\{DataStorageConfiguration.setWalBufferSize}} added instead of 
> \{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. \{{IGNITE_WAL_MMAP}} property 
> with \{{false}} value should be added to the JVM arguments: 
> \{{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then \{{BACKGROUND}} and \{{LOG_ONLY}} 
> WAL modes behave identically and don't have any differences in performance or 
> data integrity guarantees.
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> WAL documentation should be updated accordingly to IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
> {{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
> {{false}} value should be added to the JVM arguments: 
> {{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
> modes behave identically and don't have any differences in performance or 
> data integrity guarantees.



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

[jira] [Updated] (IGNITE-7408) Document WAL changes

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7408:

Description: (was: WAL documentation should be updated accordingly to 
IGNITE-6339 issue.

The following changes can affect WAL configuration and behavior:
 # {{DataStorageConfiguration.setWalBufferSize}} added instead of 
{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size equals 
WAL segment size if memory mapped file is enabled, and (WAL segment size) / 4 
if memory mapped file is disabled.
 # Memory mapped file is enabled by default and provides better performance. 
Memory mapped file usage can be turned off. {{IGNITE_WAL_MMAP}} property with 
{{false}} value should be added to the JVM arguments: 
{{-DIGNITE_WAL_MMAP=false}}.
 # If memory mapped file is enabled then {{BACKGROUND}} and {{LOG_ONLY}} WAL 
modes behave identically and don't have any differences in performance or data 
integrity guarantees.)

> Document WAL changes
> 
>
> Key: IGNITE-7408
> URL: https://issues.apache.org/jira/browse/IGNITE-7408
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
> Environment: WAL documentation should be updated accordingly to 
> IGNITE-6339 issue.
> The following changes can affect WAL configuration and behavior:
>  # {\{DataStorageConfiguration.setWalBufferSize}} added instead of 
> \{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size 
> equals WAL segment size if memory mapped file is enabled, and (WAL segment 
> size) / 4 if memory mapped file is disabled.
>  # Memory mapped file is enabled by default and provides better performance. 
> Memory mapped file usage can be turned off. \{{IGNITE_WAL_MMAP}} property 
> with \{{false}} value should be added to the JVM arguments: 
> \{{-DIGNITE_WAL_MMAP=false}}.
>  # If memory mapped file is enabled then \{{BACKGROUND}} and \{{LOG_ONLY}} 
> WAL modes behave identically and don't have any differences in performance or 
> data integrity guarantees.
>Reporter: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>




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

[jira] [Commented] (IGNITE-7412) WAL: Written bytes amount can be updated by wrong value and fail with assertion error

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7412:
--

Andrey, thanks, looks good.

> WAL: Written bytes amount can be updated by wrong value and fail with 
> assertion error
> -
>
> Key: IGNITE-7412
> URL: https://issues.apache.org/jira/browse/IGNITE-7412
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> PDS tests with WAL (w.g. 
> \{{IgniteWalRecoveryWithCompactionTest#testWalRolloverMultithreadedDefault}}) 
> can fail with assertion error like this:
>  
> {noformat}
> java.lang.AssertionError: null
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
>     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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
>     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
>     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
>     at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}



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

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

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7419:
---

 Summary: Document swap usage in Ignite 2.x memory architecture
 Key: IGNITE-7419
 URL: https://issues.apache.org/jira/browse/IGNITE-7419
 Project: Ignite
  Issue Type: Task
  Components: documentation
 Environment: Explain how swap is supported and works in Ignite. 
Provide a rationale on Ignite persistence vs swap.

In addition, looks people don't catch what happens when memory region goes 
beyond the maximum size. Revisit the persistence configuration:

http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-3-Swap-Path-configuration-is-causing-issue-td19040.html#a19046
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.4






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

[jira] [Assigned] (IGNITE-5565) Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.

[Sergey Kosarev (JIRA)]

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

Sergey Kosarev reassigned IGNITE-5565:
--

Assignee: Sergey Kosarev

> Replace Cron4J with Quartz or Spring scheduler for ignite-schedule module.
> --
>
> Key: IGNITE-5565
> URL: https://issues.apache.org/jira/browse/IGNITE-5565
> Project: Ignite
>  Issue Type: Task
>  Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Sergey Kosarev
>Priority: Major
>
> 1) Cron4J is very old:
>   Latest Cron4j 2.2.5 released: 28-Dec-2011 
>   Latest Quarz 2.3.0 released: 20-Apr-2017
> 2) Not very friendly license:
>   CronJ4 licensed under GNU LESSER GENERAL PUBLIC LICENSE
>   Quartz is freely usable, licensed under the Apache 2.0 license.
> So, if we replace Cron4J  with Quartz we can move ignite-schedule module
>  from lgpl profile to main distribution.
> Also spring's scheduler could be considered as Cron4J alternative.



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

[jira] [Commented] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1628:


Added Mono tests to .NET Linux project on TeamCity, waiting for full run.

> .NET: Ensure that Ignite works on Mono platform
> ---
>
> Key: IGNITE-1628
> URL: https://issues.apache.org/jira/browse/IGNITE-1628
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
>
> *NOTE*: Targeted for 1.6, but could be moved even further in case of tight 
> release schedule.
> *Goal*
> As Microsoft is moving .Net towards open standards, Mono receives more an 
> more attention. 
> We need to ensure that our product works fine on this platform. This includes 
> both Windows, Linux and (possibly) Mac environments.
> *Tasks*
> - Ensure that Ignite works with Mono on Windows. This is the easiest task 
> because we only need to re-compile .Net part.
> - Ensure that Ignite works with Mono on Linux. This will require alternate 
> build procedure because CPP recompilation will be required as well.
> - Create relevant TC builds.



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

[jira] [Comment Edited] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn edited comment on IGNITE-1628 at 1/15/18 4:28 PM:
-

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1628 .NET: Compile and run on Mono



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1628

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

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


was (Author: githubbot):
GitHub user ptupitsyn opened a pull request:

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

IGNITE-1628 .NET: Compile and run on Mono



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1628

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

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


commit 1778028c1733722d44a48d245fdf895a0642c5cd
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:49:07Z

IGNITE-1628 .NET: Ensure that Ignite works on Mono platform

commit da84f1c2569a9cf1b61b5654e01759fc45cbd6dd
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:49:26Z

fix IO folder casing

commit c1d1292e67f624c733bf945826cad58f4cba7386
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:50:47Z

fix IO folder casing

commit aba97fdf1cd870114309ae303fb4d0d9f6cec85b
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:55:48Z

fix Apache.Ignite.Log4Net path

commit 2bc9cf5d5fab66048a121633d30cdbc304bd4bc3
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:58:48Z

Suppress obsolete compiler warnings

commit 230ed114cd5d3a8ee7b37c26dece5c89b1dce0bc
Author: Pavel Tupitsyn 
Date:   2018-01-12T12:58:34Z

Suppress xmldoc warnings under mono

commit 8728d8012c363c25c48ba720f67d66d9a1821760
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:02:47Z

revert unnecessary changes

commit 60803c633fbd69c1b69fcb8e65f3484039b4e6ac
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:03:51Z

suppressing warnings

commit cc1dedbb244a8f1955bd94a5e161eb69755e2976
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:05:41Z

disable unnecessary documentation

commit 87d6ddbb3d5db2659411be39ab622684802bddbf
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:08:31Z

fix references

commit c83e103d043ec4f39e44468bdc7b7dd0bbfa97c8
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:10:19Z

fix references

commit c3c114d9b3f5e3fde91257a1172ab86bdda83049
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:15:46Z

fix references

commit ca6d973de3c0a9ea8f595c515067d8634c7e226b
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:21:54Z

Remove ambiguous calls from service tests

commit fac892b95d4fbb4c5d9f4247e1e85049caa339a2
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:25:18Z

Change build event to msbuild task

commit 5a32eaf96a262cc48ad80df3f3f07c5a01d429d4
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:27:58Z

Change build event to msbuild task

commit 165a1e6a2b7526de7e852af43e4f488ac6a7181d
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:38:06Z

update devnotes

commit 1b831adb6820087fb2eb830dd749d9dfdc7c749f
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:40:03Z

Add Mono build script

commit 42791b443a310e4d55d993b3b6069a45ff4b2aee
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:46:02Z

Fixing file copy in EF tests

commit 357d7897d91570086deeb4ce46e96285796fecca
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:49:23Z

mono build works!!

commit b2118728f08372f8c34253b99f03871b7e0acd5e
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:50:05Z

suppress another warn

commit 02ab5bf941348ad8d68f9555e5007fbae3a845f4
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:53:05Z

suppress another warn

commit 1743be7df4c6fbc0b03fac9d633d2d69af0c2055
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:56:56Z

Add NuGet to build script and devnotes

commit 48b6b12473e60546761cc3caee4844c24e6dc321
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:59:55Z

suprpessing more warns for Mono

commit 0cd5218588d21a8bc177fe660753a18fcc75b5a0
Author: Pavel Tupitsyn 
Date:   2018-01-12T15:01:31Z

 

[jira] [Commented] (IGNITE-7401) Entry can be expired even if it doesn't define expiry policy in "putWithPolicy-then-put" scenario

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7401:
--

The reason for this is that a cache with no expiry policy treats TTL as 'TTL 
did not change'. I am not sure if we can determine if this behavior is correct 
because JSR107 does not allow to change expiry policy at runtime.

 

A workaround would be to use the following expiry policy:

{code}

public class ClearExpiryPolicy implements ExpiryPolicy, Serializable {

    @Override public Duration getExpiryForCreation() {

        return ETERNAL;

    }

    @Override public Duration getExpiryForAccess() {

        return ETERNAL;

    }

    @Override public Duration getExpiryForUpdate() {

        return ETERNAL;

    }

}

{code}

> Entry can be expired even if it doesn't define expiry policy in 
> "putWithPolicy-then-put" scenario
> -
>
> Key: IGNITE-7401
> URL: https://issues.apache.org/jira/browse/IGNITE-7401
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Priority: Major
>
> Entry can be expired even if it doesn't define expiry policy in 
> "putWithPolicy-then-put" scenario. The following test case demonstrate the 
> problem.
> {code:java}
> public void testPutWithTtlThenPut() throws Exception {
> Ignite ignite = startGrid();
> try {
> IgniteCache cache = ignite.cache("cache");
> CreatedExpiryPolicy expiryPlc = new CreatedExpiryPolicy(new 
> Duration(TimeUnit.MILLISECONDS, 10));
> IgniteCache cacheTtl = 
> cache.withExpiryPolicy(expiryPlc);
> cacheTtl.put("key", "v1");
> cache.put("key", "v2");
> U.sleep(10);
> assertEquals("v2", cache.get("key")); // Will fail (flaky)
> }
> finally {
> stopAllGrids();
> }
> }
> {code}
> The issue also affects Ignite based cluster manager for Vert.x: 
> https://github.com/vert-x3/vertx-ignite/issues/63



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

[jira] [Commented] (IGNITE-6891) Proper behavior on Persistence errors

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6891:
--

IGNITE-6797 and IGNITE-6832 will handle all persistence errors.

We have to make refactoring to use {{IgniteFailureHandler}} once tasks finished.

Please make sure tests from IGNITE-6797 and IGNITE-6832 works after refactoring.

> Proper behavior on Persistence errors 
> --
>
> Key: IGNITE-6891
> URL: https://issues.apache.org/jira/browse/IGNITE-6891
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Dmitriy Sorokin
>Priority: Major
>  Labels: iep-7
> Fix For: 2.4
>
>
> Node should be stopped anyway, what we can provide is user callback, 
> something like beforeNodeStop'.



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

[jira] [Commented] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov commented on IGNITE-6953:
--

Hi, [~dmagda].
I've investigated this issue and figured out scenario, which leads to a hangup: 
# Client node performs some transactions.
# OOME occurs in some system thread, required to perform transactions.
# The thread dies and some memory is released.
# Node continues to perform some operations, including pings.
# Partition map exchange occurs and waits for all transactions completion.
# All transactions on the entire grid are waiting for partition map exchange 
completion.
 
I've attached logs of some scenarios with real OOMEs and simple reproducer in 
the test (just throw OOME in the right place).

I think it's better to avoid such situations instead of throwing errors (as in 
the code below), change some state and try to stop the node. And send node 
state in ping. If ping received has a bad state, then throw the node out of the 
topology.
{code:java}
catch (Throwable e) {
.
.
.
if (e instanceof Error)
throw e;
}
{code}
Any thoughts?

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: OOMETest.java, ignite-0590a557.log, ignite-5df99d7b.log, 
> ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Commented] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-1628:


GitHub user ptupitsyn opened a pull request:

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

IGNITE-1628 .NET: Compile and run on Mono



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1628

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

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


commit 1778028c1733722d44a48d245fdf895a0642c5cd
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:49:07Z

IGNITE-1628 .NET: Ensure that Ignite works on Mono platform

commit da84f1c2569a9cf1b61b5654e01759fc45cbd6dd
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:49:26Z

fix IO folder casing

commit c1d1292e67f624c733bf945826cad58f4cba7386
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:50:47Z

fix IO folder casing

commit aba97fdf1cd870114309ae303fb4d0d9f6cec85b
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:55:48Z

fix Apache.Ignite.Log4Net path

commit 2bc9cf5d5fab66048a121633d30cdbc304bd4bc3
Author: Pavel Tupitsyn 
Date:   2018-01-12T11:58:48Z

Suppress obsolete compiler warnings

commit 230ed114cd5d3a8ee7b37c26dece5c89b1dce0bc
Author: Pavel Tupitsyn 
Date:   2018-01-12T12:58:34Z

Suppress xmldoc warnings under mono

commit 8728d8012c363c25c48ba720f67d66d9a1821760
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:02:47Z

revert unnecessary changes

commit 60803c633fbd69c1b69fcb8e65f3484039b4e6ac
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:03:51Z

suppressing warnings

commit cc1dedbb244a8f1955bd94a5e161eb69755e2976
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:05:41Z

disable unnecessary documentation

commit 87d6ddbb3d5db2659411be39ab622684802bddbf
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:08:31Z

fix references

commit c83e103d043ec4f39e44468bdc7b7dd0bbfa97c8
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:10:19Z

fix references

commit c3c114d9b3f5e3fde91257a1172ab86bdda83049
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:15:46Z

fix references

commit ca6d973de3c0a9ea8f595c515067d8634c7e226b
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:21:54Z

Remove ambiguous calls from service tests

commit fac892b95d4fbb4c5d9f4247e1e85049caa339a2
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:25:18Z

Change build event to msbuild task

commit 5a32eaf96a262cc48ad80df3f3f07c5a01d429d4
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:27:58Z

Change build event to msbuild task

commit 165a1e6a2b7526de7e852af43e4f488ac6a7181d
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:38:06Z

update devnotes

commit 1b831adb6820087fb2eb830dd749d9dfdc7c749f
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:40:03Z

Add Mono build script

commit 42791b443a310e4d55d993b3b6069a45ff4b2aee
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:46:02Z

Fixing file copy in EF tests

commit 357d7897d91570086deeb4ce46e96285796fecca
Author: Pavel Tupitsyn 
Date:   2018-01-12T13:49:23Z

mono build works!!

commit b2118728f08372f8c34253b99f03871b7e0acd5e
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:50:05Z

suppress another warn

commit 02ab5bf941348ad8d68f9555e5007fbae3a845f4
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:53:05Z

suppress another warn

commit 1743be7df4c6fbc0b03fac9d633d2d69af0c2055
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:56:56Z

Add NuGet to build script and devnotes

commit 48b6b12473e60546761cc3caee4844c24e6dc321
Author: Pavel Tupitsyn 
Date:   2018-01-12T14:59:55Z

suprpessing more warns for Mono

commit 0cd5218588d21a8bc177fe660753a18fcc75b5a0
Author: Pavel Tupitsyn 
Date:   2018-01-12T15:01:31Z

fixing warns

commit 247fe6d567f2fe2dd5033590488d89924334864e
Author: Pavel Tupitsyn 
Date:   2018-01-12T15:02:26Z

wip

commit 4216f730fb00b4106d505adf19ad21f68a82245c
Author: Pavel Tupitsyn 
Date:   2018-01-12T15:03:44Z

wip

commit 27568f5e60e661e0e4f5e40c171b3068cc3ab81f
Author: Pavel Tupitsyn 
Date:   2018-01-12T15:04:24Z

wip

commit 450dbfd43d49062bce2e93aeee2836c81ddbf43e
Author: Pavel Tupitsyn 
Date:   2018-01-12T15:05:30Z

wip

commit 6d493d2ad0f3781537f94c2eceec4ed844839dab
Author: Pavel Tupitsyn 
Date:   

[jira] [Created] (IGNITE-7418) Add RMSProp parameter update algorithm/

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-7418:


 Summary: Add RMSProp parameter update algorithm/
 Key: IGNITE-7418
 URL: https://issues.apache.org/jira/browse/IGNITE-7418
 Project: Ignite
  Issue Type: Sub-task
Reporter: Artem Malykh






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

[jira] [Updated] (IGNITE-7417) Add AdaDelta parameter update algorithm

[Artem Malykh (JIRA)]

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

Artem Malykh updated IGNITE-7417:
-
Summary: Add AdaDelta parameter update algorithm  (was: AdaDelta parameter 
update algorithm)

> Add AdaDelta parameter update algorithm
> ---
>
> Key: IGNITE-7417
> URL: https://issues.apache.org/jira/browse/IGNITE-7417
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Artem Malykh
>Priority: Major
>




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

[jira] [Created] (IGNITE-7417) AdaDelta parameter update algorithm

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-7417:


 Summary: AdaDelta parameter update algorithm
 Key: IGNITE-7417
 URL: https://issues.apache.org/jira/browse/IGNITE-7417
 Project: Ignite
  Issue Type: Sub-task
Reporter: Artem Malykh






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

[jira] [Created] (IGNITE-7416) Add more parameter update methods

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-7416:


 Summary: Add more parameter update methods
 Key: IGNITE-7416
 URL: https://issues.apache.org/jira/browse/IGNITE-7416
 Project: Ignite
  Issue Type: Improvement
Reporter: Artem Malykh
Assignee: Artem Malykh






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

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov commented on IGNITE-3935:
--

Fix for {{StreamTransformer.from()}} method is ready: 
https://github.com/apache/ignite/pull/3378
Please review.

> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Mekhanikov
>Priority: Major
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



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

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin updated IGNITE-7411:

Description: 
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}

/** */
private List convert(ResultSet resSet) throws SQLException {
List res = new ArrayList<>();

while (resSet.next())
res.add(new Person(resSet.getBytes(1), resSet.getBytes(2), 
resSet.getBytes(3)));

return res;
}
{code}
 

  was:
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}

/** */
private List convert(ResultSet resSet) throws SQLException {
List res = new ArrayList<>();

while (resSet.next())
res.add(new Person(resSet.getBytes(1), resSet.getBytes(2), 
resSet.getBytes(3)));

return res;
}
{code}
 
The issue was initially discussed on user-list: 
http://apache-ignite-users.70518.x6.nabble.com/Error-of-start-with-multiple-data-regions-td19116.html


> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: 

[jira] [Updated] (IGNITE-7414) Cluster restart may lead to cluster activation error

[Vyacheslav Koptilin (JIRA)]

.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
[2018-01-15 
17:12:52,643][ERROR][exchange-worker-#42%test-grid%][GridCachePartitionExchangeManager]
 Failed to wait for completion of partition map exchange (preloading will not 
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], crd=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
discoEvt=DiscoveryCustomEvent [customMsg=null, 
affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], nodeId=4ba59aa1, 
evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=false, hash=1909804306], init=false, 
lastVer=GridCacheVersion [topVer=0, order=1516025562402, nodeOrder=0], 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[, 
exchActions=null, affChangeMsg=null, initTs=1516025572201, 
centralizedAff=false, changeGlobalStateE=class o.a.i.IgniteCheckedException: 
Failed to find cache group descriptor [grpId=623628935], done=true, state=DONE, 
evtLatch=0, remaining=[], super=GridFutureAdapter [ignoreInterrupts=false, 
state=DONE, res=class o.a.i.IgniteCheckedException: Cluster state change 
failed., hash=940092163]]
class org.apache.ignite.IgniteCheckedException: Cluster state change failed.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2414)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2216)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1039)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}

The issue was initially discussed on user-list: 
http://apache-ignite-users.70518.x6.nabble.com/Error-of-start-with-multiple-data-regions-td19116.html

  was:
Attempt to execute the following reproducer twice result in an error (please 
see attached)
{code}
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start(createIgniteConfiguration());

ignite.active(true);

CacheConfiguration cacheCfg = new CacheConfiguration("test-cac

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin updated IGNITE-7411:

Description: 
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}

/** */
private List convert(ResultSet resSet) throws SQLException {
List res = new ArrayList<>();

while (resSet.next())
res.add(new Person(resSet.getBytes(1), resSet.getBytes(2), 
resSet.getBytes(3)));

return res;
}
{code}
 
The issue was initially discussed on user-list: 
http://apache-ignite-users.70518.x6.nabble.com/Error-of-start-with-multiple-data-regions-td19116.html

  was:
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}

/** */
private List convert(ResultSet resSet) throws SQLException {
List res = new ArrayList<>();

while (resSet.next())
res.add(new Person(resSet.getBytes(1), resSet.getBytes(2), 
resSet.getBytes(3)));

return res;
}
{code}
 


> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: 

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

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-7415:


 Summary: Ability to disable WAL (Documentation)
 Key: IGNITE-7415
 URL: https://issues.apache.org/jira/browse/IGNITE-7415
 Project: Ignite
  Issue Type: Sub-task
 Environment: Need to update
[https://apacheignite.readme.io/docs/write-ahead-log#section-wal-modes]
[https://apacheignite.readme.io/docs/data-loading]
Reporter: Anton Vinogradov






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

[jira] [Updated] (IGNITE-7414) Cluster restart may lead to cluster activation error

[Vyacheslav Koptilin (JIRA)]

.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
[2018-01-15 
17:12:52,643][ERROR][exchange-worker-#42%test-grid%][GridCachePartitionExchangeManager]
 Failed to wait for completion of partition map exchange (preloading will not 
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], crd=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
discoEvt=DiscoveryCustomEvent [customMsg=null, 
affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], nodeId=4ba59aa1, 
evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=false, hash=1909804306], init=false, 
lastVer=GridCacheVersion [topVer=0, order=1516025562402, nodeOrder=0], 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[, 
exchActions=null, affChangeMsg=null, initTs=1516025572201, 
centralizedAff=false, changeGlobalStateE=class o.a.i.IgniteCheckedException: 
Failed to find cache group descriptor [grpId=623628935], done=true, state=DONE, 
evtLatch=0, remaining=[], super=GridFutureAdapter [ignoreInterrupts=false, 
state=DONE, res=class o.a.i.IgniteCheckedException: Cluster state change 
failed., hash=940092163]]
class org.apache.ignite.IgniteCheckedException: Cluster state change failed.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2414)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2216)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1039)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}

  was:
Attempt to execute the following reproducer (please see attached) twice result 
in an error
{code}
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start(createIgniteConfiguration());

ignite.active(true);

CacheConfiguration cacheCfg = new CacheConfiguration("test-cache");
cacheCfg.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cacheCfg.setCacheMode(CacheMode.PARTITIONED);
cacheCfg.setDataRegionName(&qu

[jira] [Updated] (IGNITE-7414) Cluster restart may lead to cluster activation error

[Vyacheslav Koptilin (JIRA)]

.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
[2018-01-15 
17:12:52,643][ERROR][exchange-worker-#42%test-grid%][GridCachePartitionExchangeManager]
 Failed to wait for completion of partition map exchange (preloading will not 
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], crd=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
discoEvt=DiscoveryCustomEvent [customMsg=null, 
affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], nodeId=4ba59aa1, 
evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=false, hash=1909804306], init=false, 
lastVer=GridCacheVersion [topVer=0, order=1516025562402, nodeOrder=0], 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[, 
exchActions=null, affChangeMsg=null, initTs=1516025572201, 
centralizedAff=false, changeGlobalStateE=class o.a.i.IgniteCheckedException: 
Failed to find cache group descriptor [grpId=623628935], done=true, state=DONE, 
evtLatch=0, remaining=[], super=GridFutureAdapter [ignoreInterrupts=false, 
state=DONE, res=class o.a.i.IgniteCheckedException: Cluster state change 
failed., hash=940092163]]
class org.apache.ignite.IgniteCheckedException: Cluster state change failed.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2414)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2216)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1039)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}

  was:
Attempt to execute the following reproducer twice result in an error

{code}
public static void main(String[] args) throws IgniteException {
Ignite ignite = Ignition.start(createIgniteConfiguration());

ignite.active(true);

CacheConfiguration cacheCfg = new CacheConfiguration("test-cache");
cacheCfg.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cacheCfg.setCacheMode(CacheMode.PARTITIONED);
cacheCfg.setDataRegionName("inmemory");
c

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-3935:


GitHub user dmekhanikov opened a pull request:

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

IGNITE-3935: Fix P2P class loading for StreamTransformer.from()



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

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

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

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


commit 44bae8f97be94be40584a7500339663e25133fad
Author: Denis Mekhanikov 
Date:   2018-01-15T10:22:41Z

ignite-3935 fix P2P class loading for StreamTransformer.from()

commit c3d52c511169c3624aaf1ebd39c0e93022f9a242
Author: Denis Mekhanikov 
Date:   2018-01-15T14:14:55Z

ignite-3935 add test for P2P class loading for stream transformer




> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Mekhanikov
>Priority: Major
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



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

[jira] [Commented] (IGNITE-7396) IgniteUtils.offheapSize may throw NullPointerException

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7396:
-

LGTM. Merged to master branch.

> IgniteUtils.offheapSize may throw NullPointerException
> --
>
> Key: IGNITE-7396
> URL: https://issues.apache.org/jira/browse/IGNITE-7396
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.4
>
>
> In case of a newly joined node does not specify 
> {{ATTR_DATA_REGIONS_OFFHEAP_SIZE}} via node attributes, 
> {{IgniteUtils.offheapSize()}} throws {{NullPointerException}}
> {code}
> [2018-01-11 
> 12:57:14,257][ERROR][disco-event-worker-#222%cache%][GridDiscoveryManager] 
> Unexpected exception in discovery worker thread (ignored).
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.util.IgniteUtils.offheapSize(IgniteUtils.java:1250)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.ackTopology(GridDiscoveryManager.java:1485)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.access$9500(GridDiscoveryManager.java:166)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:2644)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:2573)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Updated] (IGNITE-7414) Cluster restart may lead to cluster activation error

[Vyacheslav Koptilin (JIRA)]

che.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreMemory(GridCacheDatabaseSharedManager.java:1544)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readCheckpointAndRestoreMemory(GridCacheDatabaseSharedManager.java:570)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:820)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at java.lang.Thread.run(Thread.java:748)
> [2018-01-15 
> 17:12:52,643][ERROR][exchange-worker-#42%test-grid%][GridCachePartitionExchangeManager]
>  Failed to wait for completion of partition map exchange (preloading will not 
> start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
> [customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
> sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
> /2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
> isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], crd=TcpDiscoveryNode 
> [id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
> sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
> /2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
> isClient=false], exchId=GridDhtPartitionExchangeId 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> discoEvt=DiscoveryCustomEvent [customMsg=null, 
> affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
> [id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
> 172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
> sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
> /2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
> /127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
> lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
> isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
> type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], nodeId=4ba59aa1, 
> evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=false, hash=1909804306], init=false, 
> lastVer=GridCacheVersion [topVer=0, order=1516025562402, nodeOrder=0], 
> partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=1, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
> TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
> futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
> [topVer=1, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
> [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[, 
> exchActions=null, affChangeMsg=null, initTs=1516025572201, 
> centralizedAff=false, changeGlobalStateE=class o.a.i.IgniteCheckedException: 
> Failed to find cache group descriptor [grpId=623628935], done=true, 
> state=DONE, evtLatch=0, remaining=[], super=GridFutureAdapter 
> [ignoreInterrupts=false, state=DONE, res=class o.a.i.IgniteCheckedException: 
> Cluster state change failed., hash=940092163]]
> class org.apache.ignite.IgniteCheckedException: Cluster state change failed.
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2414)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2216)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExch

[jira] [Created] (IGNITE-7414) Cluster restart may lead to cluster activation error

[Vyacheslav Koptilin (JIRA)]

ExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:583)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
[2018-01-15 
17:12:52,643][ERROR][exchange-worker-#42%test-grid%][GridCachePartitionExchangeManager]
 Failed to wait for completion of partition map exchange (preloading will not 
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent 
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], crd=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], exchId=GridDhtPartitionExchangeId 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
discoEvt=DiscoveryCustomEvent [customMsg=null, 
affTopVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
super=DiscoveryEvent [evtNode=TcpDiscoveryNode 
[id=4ba59aa1-cbc5-4d67-8ca5-b6dd1628c5dc, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, 
172.25.4.158, 2001:0:9d38:6abd:188f:1f82:53e6:fb61], 
sockAddrs=[DESKTOP-IMRCA1M/172.25.4.158:47500, 
/2001:0:9d38:6abd:188f:1f82:53e6:fb61:47500, /0:0:0:0:0:0:0:1:47500, 
/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, 
lastExchangeTime=1516025562983, loc=true, ver=2.4.0#20180115-sha1:31c60bd6, 
isClient=false], topVer=1, nodeId8=4ba59aa1, msg=null, 
type=DISCOVERY_CUSTOM_EVT, tstamp=1516025572191]], nodeId=4ba59aa1, 
evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter 
[ignoreInterrupts=false, state=DONE, res=false, hash=1909804306], init=false, 
lastVer=GridCacheVersion [topVer=0, order=1516025562402, nodeOrder=0], 
partReleaseFut=PartitionReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[ExplicitLockReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[]], 
TxReleaseFuture [topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], 
futures=[]], AtomicUpdateReleaseFuture [topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], futures=[]], DataStreamerReleaseFuture 
[topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], futures=[, 
exchActions=null, affChangeMsg=null, initTs=1516025572201, 
centralizedAff=false, changeGlobalStateE=class o.a.i.IgniteCheckedException: 
Failed to find cache group descriptor [grpId=623628935], done=true, state=DONE, 
evtLatch=0, remaining=[], super=GridFutureAdapter [ignoreInterrupts=false, 
state=DONE, res=class o.a.i.IgniteCheckedException: Cluster state change 
failed., hash=940092163]]
class org.apache.ignite.IgniteCheckedException: Cluster state change failed.
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.finishExchangeOnCoordinator(GridDhtPartitionsExchangeFuture.java:2414)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onAllReceived(GridDhtPartitionsExchangeFuture.java:2216)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1039)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:748)
{code}



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

[jira] [Commented] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7386:


GitHub user andrey-kuznetsov opened a pull request:

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

IGNITE-7386: Got rid of ThreadLocalRandom8.

For test purposes.

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

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

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

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


commit bfa217419c72623e3ed4a9f4c0ff2f9bcb7db962
Author: Andrey Kuznetsov 
Date:   2018-01-15T14:16:24Z

IGNITE-7386: Got rid of ThreadLocalRandom8.




> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Since we're dropping java7 support there is no need now to use 
> {{LongAdder8}}, {{ConcurrentHashMap8}}, ...
> We should remove all classes from {{org.jsr166}} namespace and use 
> corresponding classes from jdk8.



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

[jira] [Comment Edited] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh edited comment on IGNITE-7389 at 1/15/18 1:45 PM:
---

Reproducer:
{noformat}
public void testCacheStartAndStreamOpenFromDifferentNodes() throws Exception {
final Ignite ignite0 = startGrids(2);
final Ignite ignite1 = grid(1);

final String cacheName = "testCache";

IgniteCache cache = ignite0.getOrCreateCache(
new CacheConfiguration().setName(cacheName));

try (IgniteDataStreamer ldr = 
ignite1.dataStreamer(cacheName)) {
ldr.addData(0, 0);
}

assertEquals(Integer.valueOf(0), cache.get(0));
}
{noformat}

No exception will be thrown from IgniteDataStreamer methods, the problem will 
be indicated only by missing value in cache.


was (Author: ilantukh):
Reproducer:
{noformat}
public void testCacheStartAndStreamOpenFromDifferentNodes() throws Exception {
final Ignite ignite0 = startGrids(2);
final Ignite ignite1 = grid(1);

final String cacheName = "testCache";

IgniteCache cache = ignite0.getOrCreateCache(
new CacheConfiguration().setName(cacheName));

U.sleep(1000);

try (IgniteDataStreamer ldr = 
ignite1.dataStreamer(cacheName)) {
ldr.addData(0, 0);
}

assertEquals(Integer.valueOf(0), cache.get(0));
}
{noformat}

No exception will be thrown from IgniteDataStreamer methods, the problem will 
be indicated only by missing value in cache.

> DataStreamer hangs if exception was thrown during addData which isn't 
> IgniteException
> -
>
> Key: IGNITE-7389
> URL: https://issues.apache.org/jira/browse/IGNITE-7389
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Major
>
> I have written test which starts cache on one node and right after that 
> starts dataStreamer on another node. Which hangs on close method because 
> {{resFut}} will never be done. 
> {code}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4], 
> history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
>   at 
> org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
>   at 
> org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> The best solution is waiting for topology on which cache should be started.



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

[jira] [Commented] (IGNITE-7389) DataStreamer hangs if exception was thrown during addData which isn't IgniteException

[Ilya Lantukh (JIRA)]

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

Ilya Lantukh commented on IGNITE-7389:
--

Reproducer:
{noformat}
public void testCacheStartAndStreamOpenFromDifferentNodes() throws Exception {
final Ignite ignite0 = startGrids(2);
final Ignite ignite1 = grid(1);

final String cacheName = "testCache";

IgniteCache cache = ignite0.getOrCreateCache(
new CacheConfiguration().setName(cacheName));

U.sleep(1000);

try (IgniteDataStreamer ldr = 
ignite1.dataStreamer(cacheName)) {
ldr.addData(0, 0);
}

assertEquals(Integer.valueOf(0), cache.get(0));
}
{noformat}

No exception will be thrown from IgniteDataStreamer methods, the problem will 
be indicated only by missing value in cache.

> DataStreamer hangs if exception was thrown during addData which isn't 
> IgniteException
> -
>
> Key: IGNITE-7389
> URL: https://issues.apache.org/jira/browse/IGNITE-7389
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Ilya Lantukh
>Priority: Major
>
> I have written test which starts cache on one node and right after that 
> starts dataStreamer on another node. Which hangs on close method because 
> {{resFut}} will never be done. 
> {code}
> java.lang.IllegalStateException: Getting affinity for topology version 
> earlier than affinity is calculated [locNode=TcpDiscoveryNode 
> [id=ad14d7f6-5895-4038-ba5e-cc487ab0, addrs=[127.0.0.1], 
> sockAddrs=[/127.0.0.1:47501], discPort=47501, order=2, intOrder=2, 
> lastExchangeTime=1515672065430, loc=true, ver=2.4.0#19700101-sha1:, 
> isClient=false], grp=PART-G2, topVer=AffinityTopologyVersion [topVer=4, 
> minorTopVer=3], head=AffinityTopologyVersion [topVer=4, minorTopVer=4], 
> history=[AffinityTopologyVersion [topVer=4, minorTopVer=4]]]
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:603)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignment(GridCacheAffinityManager.java:243)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:375)
>   at 
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.partition0(GridAffinityProcessor.java:187)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.partition(IgniteCacheObjectProcessorImpl.java:267)
>   at 
> org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.toCacheKeyObject0(IgniteCacheObjectProcessorImpl.java:135)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheKeyObject(CacheObjectBinaryProcessorImpl.java:805)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:581)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl.addData(DataStreamerImpl.java:555)
>   at 
> org.gridgain.grid.internal.processors.cache.database.AbstractSnapshotTest$2.run(AbstractSnapshotTest.java:404)
>   at 
> org.apache.ignite.testframework.GridTestUtils$6.run(GridTestUtils.java:933)
>   at 
> org.apache.ignite.testframework.GridTestUtils$9.call(GridTestUtils.java:1278)
>   at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> The best solution is waiting for topology on which cache should be started.



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

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin updated IGNITE-7411:

Description: 
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}

/** */
private List convert(ResultSet resSet) throws SQLException {
List res = new ArrayList<>();

while (resSet.next())
res.add(new Person(resSet.getBytes(1), resSet.getBytes(2), 
resSet.getBytes(3)));

return res;
}
{code}
 

  was:
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}
{code}
 


> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: Critical
> Attachments: Reproducer.java
>
>
> I am using SQL to create caches and run queries and DataStreamer to load lots 
> of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
> problem is when I select data loaded with DataStreamer the fields 
> participating in PRIMARY KEY are null.
>  * Note: binary fields not part of primary keys are OK (not null)
>  * Note: if I use JAVA API 

[jira] [Commented] (IGNITE-7412) WAL: Written bytes amount can be updated by wrong value and fail with assertion error

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7412:
-

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

Please review.

> WAL: Written bytes amount can be updated by wrong value and fail with 
> assertion error
> -
>
> Key: IGNITE-7412
> URL: https://issues.apache.org/jira/browse/IGNITE-7412
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> PDS tests with WAL (w.g. 
> \{{IgniteWalRecoveryWithCompactionTest#testWalRolloverMultithreadedDefault}}) 
> can fail with assertion error like this:
>  
> {noformat}
> java.lang.AssertionError: null
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
>     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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
>     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
>     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
>     at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}



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

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Vyacheslav Koptilin (JIRA)]

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

Vyacheslav Koptilin updated IGNITE-7411:

Description: 
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.
{code:java}
@Test
public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = 
DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
) {
conn.prepareStatement(
"CREATE TABLE " + CACHE_NAME + "(" +
"ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY 
KEY(ssn, orgId)" +
") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
).execute();

IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] {1, 2}, new 
byte[] {3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] 
{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from 
" + CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", 
key.key(), entries.get(0).getSsn());
}
}
{code}
 

  was:
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 )

{ conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn BINARY(16), 
orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
).execute(); IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME); AffinityKey key = new 
AffinityKey<>(new byte[] 

{1, 2}

, new byte[] \{3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 


> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: Critical
> Attachments: Reproducer.java
>
>
> I am using SQL to create caches and run queries and DataStreamer to load lots 
> of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
> problem is when I select data loaded with DataStreamer the fields 
> participating in PRIMARY KEY are null.
>  * Note: binary fields not part of primary keys are OK (not null)
>  * Note: if I use JAVA API even the binary primary key fields are OK (not 
> null).
> Reproducer below fails on the last assertion since SSN is NULL.
> See full reproducer code in branch ignite-7411 or use the reproducer attached.
> {code:java}
> @Test
> public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws 
> SQLException {
> try (Ignite srv = Ignition.start(getServerConfig());
>  Ignite cln = Ignition.start(getClientConfig());
>  Connection conn = 
> 

[jira] [Assigned] (IGNITE-7413) .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with standalone nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn reassigned IGNITE-7413:
--

Assignee: Pavel Tupitsyn

> .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run 
> with standalone nodes
> ---
>
> Key: IGNITE-7413
> URL: https://issues.apache.org/jira/browse/IGNITE-7413
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with 
> standalone nodes
>  
> without standalone nodes:
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400 
> >>> 2: Jane Roe, ASF, 5500
>  
> with standalone nodes:
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400
>  >>> 4: Richard Miles, Eclipse, 3000 
> >>> 2: Jane Roe, ASF, 5500



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

[jira] [Updated] (IGNITE-7413) .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with standalone nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7413:
---
Priority: Minor  (was: Major)

> .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run 
> with standalone nodes
> ---
>
> Key: IGNITE-7413
> URL: https://issues.apache.org/jira/browse/IGNITE-7413
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET
> Fix For: 2.4
>
>
> Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with 
> standalone nodes
>  
> without standalone nodes:
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400 
> >>> 2: Jane Roe, ASF, 5500
>  
> with standalone nodes:
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400
>  >>> 4: Richard Miles, Eclipse, 3000 
> >>> 2: Jane Roe, ASF, 5500



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

[jira] [Updated] (IGNITE-7413) .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with standalone nodes

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7413:
---
Fix Version/s: 2.4

> .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run 
> with standalone nodes
> ---
>
> Key: IGNITE-7413
> URL: https://issues.apache.org/jira/browse/IGNITE-7413
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.3
>Reporter: Irina Zaporozhtseva
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with 
> standalone nodes
>  
> without standalone nodes:
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400 
> >>> 2: Jane Roe, ASF, 5500
>  
> with standalone nodes:
> >>> Delete non-ASF employees 
> >>> 1: John Doe, ASF, 4400
>  >>> 4: Richard Miles, Eclipse, 3000 
> >>> 2: Jane Roe, ASF, 5500



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

[jira] [Comment Edited] (IGNITE-7412) WAL: Written bytes amount can be updated by wrong value and fail with assertion error

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-7412 at 1/15/18 1:29 PM:
--

{{written}} field can be updated with wrong value from {{addRecord}} method 
when {{mmap}} is enabled. For example thread T1 reserves buffer segment with 
end position P1 for record R1 with size X1, and then thread T2 reserves buffer 
segment with end position P2 > P1 for record R2 with size X2 < X1. In this case 
record R2 can be serialized into buffer earlier than record R1 and T2 will 
update {{written}} field first, and then T1 will update {{written}} field with 
smaller value.

Solution: Use "setIfGreater" operation because {{written}} value must grow only.


was (Author: agura):
{\{written}} field can be updated with wrong value from \{{addRecord}} method 
when \{{mmap}} is enabled. For example thread T1 reserves buffer segment with 
end position P1 for record R1 with size X1, and then thread T2 reserves buffer 
segment with end position P2 > P1 for record R2 with size X2 < X1. In this case 
record R2 can be serialized into buffer earlier than record R1 and T2 will 
update \{{written}} field first, and then T1 will update \{{written}} field 
with smaller value.

Solution: Use "setIfGreater" operation because written value must grow only.

> WAL: Written bytes amount can be updated by wrong value and fail with 
> assertion error
> -
>
> Key: IGNITE-7412
> URL: https://issues.apache.org/jira/browse/IGNITE-7412
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> PDS tests with WAL (w.g. 
> \{{IgniteWalRecoveryWithCompactionTest#testWalRolloverMultithreadedDefault}}) 
> can fail with assertion error like this:
>  
> {noformat}
> java.lang.AssertionError: null
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
>     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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
>     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
>     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
>     at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}



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

[jira] [Created] (IGNITE-7413) .NET: Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with standalone nodes

[Irina Zaporozhtseva (JIRA)]

Irina Zaporozhtseva created IGNITE-7413:
---

 Summary: .NET: Datagrid.QueryDmlExample: Incorrect result for 
Delete and Update if run with standalone nodes
 Key: IGNITE-7413
 URL: https://issues.apache.org/jira/browse/IGNITE-7413
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 2.3
Reporter: Irina Zaporozhtseva


Datagrid.QueryDmlExample: Incorrect result for Delete and Update if run with 
standalone nodes

 

without standalone nodes:

>>> Delete non-ASF employees 
>>> 1: John Doe, ASF, 4400 
>>> 2: Jane Roe, ASF, 5500

 

with standalone nodes:

>>> Delete non-ASF employees 
>>> 1: John Doe, ASF, 4400
 >>> 4: Richard Miles, Eclipse, 3000 
>>> 2: Jane Roe, ASF, 5500



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

[jira] [Commented] (IGNITE-7412) WAL: Written bytes amount can be updated by wrong value and fail with assertion error

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7412:
-

{\{written}} field can be updated with wrong value from \{{addRecord}} method 
when \{{mmap}} is enabled. For example thread T1 reserves buffer segment with 
end position P1 for record R1 with size X1, and then thread T2 reserves buffer 
segment with end position P2 > P1 for record R2 with size X2 < X1. In this case 
record R2 can be serialized into buffer earlier than record R1 and T2 will 
update \{{written}} field first, and then T1 will update \{{written}} field 
with smaller value.

Solution: Use "setIfGreater" operation because written value must grow only.

> WAL: Written bytes amount can be updated by wrong value and fail with 
> assertion error
> -
>
> Key: IGNITE-7412
> URL: https://issues.apache.org/jira/browse/IGNITE-7412
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> PDS tests with WAL (w.g. 
> \{{IgniteWalRecoveryWithCompactionTest#testWalRolloverMultithreadedDefault}}) 
> can fail with assertion error like this:
>  
> {noformat}
> java.lang.AssertionError: null
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
>     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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
>     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
>     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
>     at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}



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

[jira] [Updated] (IGNITE-7412) WAL: Written bytes amount can be updated by wrong value and fail with assertion error

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-7412:

Summary: WAL: Written bytes amount can be updated by wrong value and fail 
with assertion error  (was: WAL: Last fsync position can be update by wrong 
value)

> WAL: Written bytes amount can be updated by wrong value and fail with 
> assertion error
> -
>
> Key: IGNITE-7412
> URL: https://issues.apache.org/jira/browse/IGNITE-7412
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Gura
>Assignee: Andrey Gura
>Priority: Major
> Fix For: 2.4
>
>
> PDS tests with WAL (w.g. 
> \{{IgniteWalRecoveryWithCompactionTest#testWalRolloverMultithreadedDefault}}) 
> can fail with assertion error like this:
>  
> {noformat}
> java.lang.AssertionError: null
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
>     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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
>     at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
>     at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
>     at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
>     at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
>     at 
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
>     at 
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}



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

[jira] [Updated] (IGNITE-7412) WAL: Last fsync position can be update by wrong value

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-7412:

Description: 
PDS tests with WAL (w.g. 
\{{IgniteWalRecoveryWithCompactionTest#testWalRolloverMultithreadedDefault}}) 
can fail with assertion error like this:

 
{noformat}
java.lang.AssertionError: null
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
    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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
    at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
    at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
    at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
    at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
    at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
    at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
    at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)

{noformat}

  was:
PDS tests with WAL can fail with assertion error like this:

 

{noformat}

java.lang.AssertionError: null
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
    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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
    at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
    at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
    at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
    at 

[jira] [Created] (IGNITE-7412) WAL: Last fsync position can be update by wrong value

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-7412:
---

 Summary: WAL: Last fsync position can be update by wrong value
 Key: IGNITE-7412
 URL: https://issues.apache.org/jira/browse/IGNITE-7412
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura
Assignee: Andrey Gura
 Fix For: 2.4


PDS tests with WAL can fail with assertion error like this:

 

{noformat}

java.lang.AssertionError: null
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.fsync(FileWriteAheadLogManager.java:2445)
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileWriteHandle.access$2200(FileWriteAheadLogManager.java:2206)
    at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.fsync(FileWriteAheadLogManager.java:661)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1771)
    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.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1117)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
    at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2354)
    at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2331)
    at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1005)
    at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:872)
    at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:550)
    at 
org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRecoveryTest$2.call(IgniteWalRecoveryTest.java:545)
    at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)

{noformat}



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

[jira] [Updated] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6953:
-
Attachment: OOMETest.java

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: OOMETest.java, ignite-0590a557.log, ignite-5df99d7b.log, 
> ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Updated] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6953:
-
Attachment: (was: ExcludeList)

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: ignite-0590a557.log, ignite-5df99d7b.log, 
> ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Updated] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6953:
-
Attachment: ExcludeList

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: ignite-0590a557.log, ignite-5df99d7b.log, 
> ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Updated] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6953:
-
Attachment: ignite-5df99d7b.log

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: ignite-0590a557.log, ignite-5df99d7b.log, 
> ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Updated] (IGNITE-6953) OOM on the client node freezes the whole cluster

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov updated IGNITE-6953:
-
Attachment: ignite-0590a557.log
ignite-9b5b6e6e.log

> OOM on the client node freezes the whole cluster
> 
>
> Key: IGNITE-6953
> URL: https://issues.apache.org/jira/browse/IGNITE-6953
> Project: Ignite
>  Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: iep-5
> Fix For: 2.4
>
> Attachments: ignite-0590a557.log, ignite-9b5b6e6e.log
>
>
> It's reported that if an OOM happens on the client side the whole cluster 
> becomes unresponsive:
> http://apache-ignite-users.70518.x6.nabble.com/Out-of-memory-in-client-node-freezes-complete-cluster-td18044.html
> Let's reproduce and prevent this by bringing the client node down 
> automatically.  



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

[jira] [Assigned] (IGNITE-6797) Handle IO errors in LFS files

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-6797:
---

Assignee: Pavel Kovalenko

> Handle IO errors in LFS files
> -
>
> Key: IGNITE-6797
> URL: https://issues.apache.org/jira/browse/IGNITE-6797
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Pavel Kovalenko
>Priority: Minor
> Attachments: IgnitePdsThreadInterruptionTest.java
>
>
> If some thread was interrupted while IO operation with LFS file (for example 
> - read page) then JVM close FileChannel of such file and mark it as closed by 
> interrupt. If next thread try to load any page from closed file it get 
> ClosedChannelException, but PageMemoryImpl first register page in segment 
> FillPageIdTable loadedPages and didn't clear it after IO error, so third 
> thread will find empty page in it and throw Unknown page type: 0 
> IgniteCheckedException.
> To fix it we should try to restore FileChannel after ClosedChannelException 
> (for first time) and stop node if we get any other exception or get some 
> error while reopening by ClosedChannelException in FilePageStore.
> Read from closed channel exception:
> {noformat}
> 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 
> com.google.common.eventbus.EventSubscriber.handleEvent(EventSubscriber.java:74)
> at com.google.common.eventbus.EventBus.dispatch(EventBus.java:322)
> at 
> com.google.common.eventbus.AsyncEventBus.access$001(AsyncEventBus.java:34)
> at 
> com.google.common.eventbus.AsyncEventBus$1.run(AsyncEventBus.java:117)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.ignite.IgniteCheckedException: Runtime failure on 
> lookup row: 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$SearchRow@5678e76a
> at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1070)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:1476)
> at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:1276)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:406)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAllAsync0(GridCacheAdapter.java:1902)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtAllAsync(GridDhtCacheAdapter.java:780)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.getAsync(GridDhtGetSingleFuture.java:360)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map0(GridDhtGetSingleFuture.java:254)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.map(GridDhtGetSingleFuture.java:237)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtGetSingleFuture.init(GridDhtGetSingleFuture.java:161)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.getDhtSingleAsync(GridDhtCacheAdapter.java:878)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetRequest(GridDhtCacheAdapter.java:892)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:131)
> at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$2.apply(GridDhtTransactionalCacheAdapter.java:129)
> 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 
> 

[jira] [Assigned] (IGNITE-6832) handle IO errors while checkpointing

[Pavel Kovalenko (JIRA)]

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

Pavel Kovalenko reassigned IGNITE-6832:
---

Assignee: Pavel Kovalenko

> handle IO errors while checkpointing
> 
>
> Key: IGNITE-6832
> URL: https://issues.apache.org/jira/browse/IGNITE-6832
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Assignee: Pavel Kovalenko
>Priority: Major
>
> If we get some IO error (like "No spece left on device") during checkpointing 
> (GridCacheDatabaseSharedManager$WriteCheckpointPages:2509) node didn't stop 
> as when get same error while writting WAL log and clients will get some "Long 
> running cache futures". We must stop node in this case! Better - add some 
> internal healthcheck and stop node anyway if  it won't pass for few times (do 
> it with different issue).



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

[jira] [Comment Edited] (IGNITE-6861) SQL parser: support CREATE TABLE and DROP TABLE commands

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov edited comment on IGNITE-6861 at 1/15/18 12:52 PM:
---

Fixed code to address reviewers' suggestions. Eager for new ones...


was (Author: kirill.shirokov):
Fixed to address the reviewers' suggestions. Eager for new ones...

> SQL parser: support CREATE TABLE and DROP TABLE commands
> 
>
> Key: IGNITE-6861
> URL: https://issues.apache.org/jira/browse/IGNITE-6861
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Kirill Shirokov
>Priority: Major
> Fix For: 2.5
>
>
> Partial implementation is ready (see PR). Need to make sure that the full 
> syntax is supported.



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

[jira] [Commented] (IGNITE-6832) handle IO errors while checkpointing

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-6832:
--

For starters, we need to have a generic method to check the environment and 
invoke when an unrecoverable exception occurs.

> handle IO errors while checkpointing
> 
>
> Key: IGNITE-6832
> URL: https://issues.apache.org/jira/browse/IGNITE-6832
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Alexander Belyak
>Priority: Major
>
> If we get some IO error (like "No spece left on device") during checkpointing 
> (GridCacheDatabaseSharedManager$WriteCheckpointPages:2509) node didn't stop 
> as when get same error while writting WAL log and clients will get some "Long 
> running cache futures". We must stop node in this case! Better - add some 
> internal healthcheck and stop node anyway if  it won't pass for few times (do 
> it with different issue).



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

[jira] [Commented] (IGNITE-7050) Add support for spring3

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-7050:
--

[~mcherkasov]

LGTM after changes you did. 

> Add support for spring3
> ---
>
> Key: IGNITE-7050
> URL: https://issues.apache.org/jira/browse/IGNITE-7050
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Mikhail Cherkasov
>Priority: Major
> Fix For: 2.4
>
>
> there are still users who use spring3 and hence can't use ignite which 
> depends on spring4. I think we can create separate modules for spring3 
> support, like it was done for hibernate 4/5.



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

[jira] [Assigned] (IGNITE-7313) Recovery process doesn't propagate MVCC version

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov reassigned IGNITE-7313:


Assignee: Igor Seliverstov

> Recovery process doesn't propagate MVCC version
> ---
>
> Key: IGNITE-7313
> URL: https://issues.apache.org/jira/browse/IGNITE-7313
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.5
>
>
> Reproducer: 
> {{IgnitePdsContinuousRestartTest.testRebalancingDuringLoad_8000_8000_8_16}}
> Root cause: MVCC version is not passed during recovery process, as a result 
> we cannot commit transaction properly.
> Stack trace:
> {code}
> [2017-12-26 
> 17:44:03,011][ERROR][sys-stripe-5-#216%persistence.IgnitePdsContinuousRestartTest3%][G]
>  Failed to execute runnable.
> java.lang.AssertionError: Mvcc is not initialized: GridDhtTxRemote 
> [nearNodeId=5213f13a-541e-41e0-ac30-c0cdc9d0, 
> rmtFutId=ea4b6a39061-cf384028-0bcb-46d8-92e1-3c898390d074, 
> nearXidVer=GridCacheVersion [topVer=125779403, order=1514300484265, 
> nodeOrder=1], storeWriteThrough=false, super=GridDistributedTxRemoteAdapter 
> [explicitVers=null, started=true, commitAllowed=1, 
> txState=IgniteTxRemoteStateImpl [readMap={}, writeMap={IgniteTxKey 
> [key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> cacheId=-1368047377]=IgniteTxEntry [key=KeyCacheObjectImpl [part=113, 
> val=2545, hasValBytes=true], cacheId=-1368047377, txKey=IgniteTxKey 
> [key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> cacheId=-1368047377], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=113, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> val=CacheObjectImpl [val=null, hasValBytes=true], startVer=1514300484409, 
> ver=GridCacheVersion [topVer=125779403, order=1514300455870, nodeOrder=2], 
> hash=2545, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null, 
> rmts=[GridCacheMvccCandidate [nodeId=91bcaf65-b816-41e9-a74e-ca58c821, 
> ver=GridCacheVersion [topVer=125779403, order=1514300484266, nodeOrder=2], 
> threadId=285, id=1158826, topVer=AffinityTopologyVersion [topVer=-1, 
> minorTopVer=0], reentry=null, 
> otherNodeId=5213f13a-541e-41e0-ac30-c0cdc9d0, otherVer=null, 
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=KeyCacheObjectImpl [part=113, val=2545, hasValBytes=true], 
> masks=local=0|owner=1|ready=0|reentry=0|used=1|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null, flags=2]]], prepared=1, locked=false, 
> nodeId=null, locMapped=false, expiryPlc=null, transferExpiryPlc=false, 
> flags=0, partUpdateCntr=0, serReadVer=null, xidVer=null], IgniteTxKey 
> [key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> cacheId=-1368047377]=IgniteTxEntry [key=KeyCacheObjectImpl [part=17, 
> val=3089, hasValBytes=true], cacheId=-1368047377, txKey=IgniteTxKey 
> [key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> cacheId=-1368047377], val=[op=CREATE, val=CacheObjectImpl [val=null, 
> hasValBytes=true]], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP, val=null], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
> filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], part=17, 
> super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> val=CacheObjectImpl [val=null, hasValBytes=true], startVer=1514300484410, 
> ver=GridCacheVersion [topVer=125779403, order=1514300459131, nodeOrder=2], 
> hash=3089, extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc [locs=null, 
> rmts=[GridCacheMvccCandidate [nodeId=91bcaf65-b816-41e9-a74e-ca58c821, 
> ver=GridCacheVersion [topVer=125779403, order=1514300484266, nodeOrder=2], 
> threadId=285, id=1158827, topVer=AffinityTopologyVersion [topVer=-1, 
> minorTopVer=0], reentry=null, 
> otherNodeId=5213f13a-541e-41e0-ac30-c0cdc9d0, otherVer=null, 
> mappedDhtNodes=null, mappedNearNodes=null, ownerVer=null, serOrder=null, 
> key=KeyCacheObjectImpl [part=17, val=3089, hasValBytes=true], 
> masks=local=0|owner=1|ready=0|reentry=0|used=1|tx=1|single_implicit=0|dht_local=0|near_local=0|removed=0|read=0,
>  prevVer=null, nextVer=null, flags=2]]], prepared=1, locked=false, 
> nodeId=null, 

[jira] [Assigned] (IGNITE-5935) Integrate mvcc support in tx recovery protocol

[Igor Seliverstov (JIRA)]

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

Igor Seliverstov reassigned IGNITE-5935:


Assignee: Igor Seliverstov  (was: Semen Boikov)

> Integrate mvcc support in tx recovery protocol
> --
>
> Key: IGNITE-5935
> URL: https://issues.apache.org/jira/browse/IGNITE-5935
> Project: Ignite
>  Issue Type: Task
>  Components: cache
>Reporter: Semen Boikov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.5
>
>
> Need make sure tx recovery work properly with mvcc enabled:
> - tx IDs are generated and not lost if transaction is committed by recovery 
> procedure
> - tx should be removed from list of active transactions on coordinator



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

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7411:
-
Description: 
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411 or use the reproducer attached.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 )

{ conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn BINARY(16), 
orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
).execute(); IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME); AffinityKey key = new 
AffinityKey<>(new byte[] 

{1, 2}

, new byte[] \{3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 

  was:
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 )

{ conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn BINARY(16), 
orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
).execute(); IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME); AffinityKey key = new 
AffinityKey<>(new byte[] \\{1, 2}

, new byte[] \{3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 


> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: Critical
> Attachments: Reproducer.java
>
>
> I am using SQL to create caches and run queries and DataStreamer to load lots 
> of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
> problem is when I select data loaded with DataStreamer the fields 
> participating in PRIMARY KEY are null.
>  * Note: binary fields not part of primary keys are OK (not null)
>  * Note: if I use JAVA API even the binary primary key fields are OK (not 
> null).
> Reproducer below fails on the last assertion since SSN is NULL.
> See full reproducer code in branch ignite-7411 or use the reproducer attached.
> @Test
>  public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
>  try (Ignite srv = Ignition.start(getServerConfig());
>  Ignite cln = Ignition.start(getClientConfig());
>  Connection conn = 
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
>  )
> { conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn 
> BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") 
> WITH \"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
> ).execute(); 

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7411:
-
Attachment: Reproducer.java

> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: Critical
> Attachments: Reproducer.java
>
>
> I am using SQL to create caches and run queries and DataStreamer to load lots 
> of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
> problem is when I select data loaded with DataStreamer the fields 
> participating in PRIMARY KEY are null.
>  * Note: binary fields not part of primary keys are OK (not null)
>  * Note: if I use JAVA API even the binary primary key fields are OK (not 
> null).
> Reproducer below fails on the last assertion since SSN is NULL.
> See full reproducer code in branch ignite-7411.
> @Test
>  public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
>  try (Ignite srv = Ignition.start(getServerConfig());
>  Ignite cln = Ignition.start(getClientConfig());
>  Connection conn = 
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
>  )
> { conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn 
> BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") 
> WITH \"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
> ).execute(); IgniteCache, Person> cache = 
> cln.cache("SQL_PUBLIC_" + CACHE_NAME); AffinityKey key = new 
> AffinityKey<>(new byte[] \\{1, 2}
> , new byte[] \{3, 4});
> cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));
> List entries = convert(conn.prepareStatement("SELECT * from " + 
> CACHE_NAME).executeQuery());
> assertEquals("1 person must be in the cache", 1, entries.size());
> assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
> entries.get(0).getSsn());
>  }
>  }
>  



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

[jira] [Updated] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-7411:
-
Description: 
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-7411.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 )

{ conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn BINARY(16), 
orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") WITH 
\"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
).execute(); IgniteCache, Person> cache = 
cln.cache("SQL_PUBLIC_" + CACHE_NAME); AffinityKey key = new 
AffinityKey<>(new byte[] \\{1, 2}

, new byte[] \{3, 4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 

  was:
I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-TBD.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 ) {
 conn.prepareStatement(
 "CREATE TABLE " + CACHE_NAME + "(" +
 "ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" +
 ") WITH \"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
 ).execute();

IgniteCache, Person> cache = cln.cache("SQL_PUBLIC_" + 
CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] \{1, 2}, new byte[] \{3, 
4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 


> JDBC thin client selects NULL cache ID values of entries added with Java API
> 
>
> Key: IGNITE-7411
> URL: https://issues.apache.org/jira/browse/IGNITE-7411
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Affects Versions: 2.3
>Reporter: Alexey Kukushkin
>Priority: Critical
>
> I am using SQL to create caches and run queries and DataStreamer to load lots 
> of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
> problem is when I select data loaded with DataStreamer the fields 
> participating in PRIMARY KEY are null.
>  * Note: binary fields not part of primary keys are OK (not null)
>  * Note: if I use JAVA API even the binary primary key fields are OK (not 
> null).
> Reproducer below fails on the last assertion since SSN is NULL.
> See full reproducer code in branch ignite-7411.
> @Test
>  public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
>  try (Ignite srv = Ignition.start(getServerConfig());
>  Ignite cln = Ignition.start(getClientConfig());
>  Connection conn = 
> DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
>  )
> { conn.prepareStatement( "CREATE TABLE " + CACHE_NAME + "(" + "ssn 
> BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" + ") 
> WITH \"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\"" 
> ).execute(); IgniteCache, Person> cache = 
> cln.cache("SQL_PUBLIC_" + CACHE_NAME); AffinityKey key = 

[jira] [Created] (IGNITE-7411) JDBC thin client selects NULL cache ID values of entries added with Java API

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-7411:


 Summary: JDBC thin client selects NULL cache ID values of entries 
added with Java API
 Key: IGNITE-7411
 URL: https://issues.apache.org/jira/browse/IGNITE-7411
 Project: Ignite
  Issue Type: Bug
  Components: thin client
Affects Versions: 2.3
Reporter: Alexey Kukushkin


I am using SQL to create caches and run queries and DataStreamer to load lots 
of data. I must use MD5 digests as entity IDs (BINARY(16) SQL type). The 
problem is when I select data loaded with DataStreamer the fields participating 
in PRIMARY KEY are null.
 * Note: binary fields not part of primary keys are OK (not null)
 * Note: if I use JAVA API even the binary primary key fields are OK (not null).

Reproducer below fails on the last assertion since SSN is NULL.

See full reproducer code in branch ignite-TBD.

@Test
 public void javaPutIntoSqlCacheWithBinaryAffinityKey() throws SQLException {
 try (Ignite srv = Ignition.start(getServerConfig());
 Ignite cln = Ignition.start(getClientConfig());
 Connection conn = DriverManager.getConnection("jdbc:ignite:thin://127.0.0.1/")
 ) {
 conn.prepareStatement(
 "CREATE TABLE " + CACHE_NAME + "(" +
 "ssn BINARY(16), orgId BINARY(16), name BINARY(16), PRIMARY KEY(ssn, orgId)" +
 ") WITH \"affinitykey=orgId,value_type=org.apache.ignite.Reproducer$Person\""
 ).execute();

IgniteCache, Person> cache = cln.cache("SQL_PUBLIC_" + 
CACHE_NAME);

AffinityKey key = new AffinityKey<>(new byte[] \{1, 2}, new byte[] \{3, 
4});

cache.put(key, new Person(key.key(), key.affinityKey(), new byte[] \{5, 6}));

List entries = convert(conn.prepareStatement("SELECT * from " + 
CACHE_NAME).executeQuery());

assertEquals("1 person must be in the cache", 1, entries.size());

assertArrayEquals("Person SSN must be same as affinity key's key", key.key(), 
entries.get(0).getSsn());
 }
 }

 



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

[jira] [Updated] (IGNITE-7278) Node failed to recover partition from WAL on unstable topology

[Dmitriy Govorukhin (JIRA)]

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

Dmitriy Govorukhin updated IGNITE-7278:
---
Summary: Node failed to recover partition from WAL on unstable topology  
(was: Node failed to recover partition from WAL on unstable topology.)

> Node failed to recover partition from WAL on unstable topology
> --
>
> Key: IGNITE-7278
> URL: https://issues.apache.org/jira/browse/IGNITE-7278
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Andrew Mashenkov
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.4
>
> Attachments: page_corrupted2.tar.gz
>
>
> The use case is:
> -Grid with partitioned cache with 2 backups (or replicated)
> -Node-1 is killed in the middle of checkpoint and started again.
> -Node-1 detects unfinished checkpoint and tries to recover it.
> -At this point Node-2 is killed while node-1 recovering is in progress.
> -Node-1 fails with AssertionError.
> PFA logs, parsed WAL, reproducer.
> Can be reproduced with IgnitePdsContinuousRestartTest with minor changes,
> we have to have 2 nodes flapping and kill nodes ungracefully.



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

[jira] [Comment Edited] (IGNITE-6923) Cache metrics are updated in timeout-worker potentially delaying critical code execution due to current implementation issues.

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov edited comment on IGNITE-6923 at 1/15/18 11:36 AM:


Merged to master branch.

Thanks for contribution.


was (Author: avinogradov):
Merged to master brunch.

Thanks for contribution.

> Cache metrics are updated in timeout-worker potentially delaying critical 
> code execution due to current implementation issues.
> --
>
> Key: IGNITE-6923
> URL: https://issues.apache.org/jira/browse/IGNITE-6923
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Aleksey Plekhanov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.4
>
>
> Some metrics are using cache iteration for calculation. If number of caches 
> rather large this can be slow.
> Similar code is running in discovery thread.
> See stack trace for example.
> {noformat}
> "grid-timeout-worker-#39%DPL_GRID%DplGridNodeName%" #152 prio=5 os_prio=0 
> tid=0x7f1009a03000 nid=0x5caa runnable [0x7f0f059d9000] 
>java.lang.Thread.State: RUNNABLE 
> at java.util.HashMap.containsKey(HashMap.java:595) 
> at java.util.HashSet.contains(HashSet.java:203) 
> at 
> java.util.Collections$UnmodifiableCollection.contains(Collections.java:1032) 
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:339)
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$3.apply(IgniteCacheOffheapManagerImpl.java:337)
> at 
> org.apache.ignite.internal.util.lang.gridfunc.TransformFilteringIterator.hasNext:@TransformFilteringIterator.java:90)
> at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
>  
> at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.cacheEntriesCount(IgniteCacheOffheapManagerImpl.java:293)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsImpl.getOffHeapPrimaryEntriesCount(CacheMetricsImpl.java:240)
> at 
> org.apache.ignite.internal.processors.cache.CacheMetricsSnapshot.(CacheMetricsSnapshot.java:271)
>  
> at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.localMetrics(GridCacheAdapter.java:3217)
>  
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.cacheMetrics(GridDiscoveryManager.java:1151)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.nonHeapMemoryUsed(GridDiscoveryManager.java:1121)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$7.metrics(GridDiscoveryManager.java:1087)
>  
> at 
> org.apache.ignite.spi.discovery.tcp.internal.TcpDiscoveryNode.metrics(TcpDiscoveryNode.java:269)
>  
> at 
> org.apache.ignite.internal.IgniteKernal$3.run(IgniteKernal.java:1175) 
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask.onTimeout(GridTimeoutProcessor.java:256)
> - locked <0x7f115f5bf890> (a 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$CancelableTask)
> at 
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:158)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) 
> at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Commented] (IGNITE-7399) .NET: Thin client: NullRefException on connection to arbitrary server

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7399:


Merged to master: {{66cf82d2e4335d01d71184a60182e3e8ae1f0bb6}}.

> .NET: Thin client: NullRefException on connection to arbitrary server
> -
>
> Key: IGNITE-7399
> URL: https://issues.apache.org/jira/browse/IGNITE-7399
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Reproducer:
> {code}
> var cfg = new IgniteClientConfiguration { Host = "ya.ru", Port=80 };
> var client = Ignition.StartClient(cfg);
> {code}
> Result:
> {code}
> Object reference not set to an instance of an object.
> at Apache.Ignite.Core.Impl.Client.ClientSocket.Dispose()
>at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)
>at 
> Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(ClientProtocolVersion 
> version)
>at 
> Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration 
> clientConfiguration, Nullable`1 version)
>at 
> Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration 
> clientConfiguration)
>at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration 
> clientConfiguration)
> {code}



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

[jira] [Resolved] (IGNITE-7399) .NET: Thin client: NullRefException on connection to arbitrary server

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7399.

Resolution: Fixed

> .NET: Thin client: NullRefException on connection to arbitrary server
> -
>
> Key: IGNITE-7399
> URL: https://issues.apache.org/jira/browse/IGNITE-7399
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Reproducer:
> {code}
> var cfg = new IgniteClientConfiguration { Host = "ya.ru", Port=80 };
> var client = Ignition.StartClient(cfg);
> {code}
> Result:
> {code}
> Object reference not set to an instance of an object.
> at Apache.Ignite.Core.Impl.Client.ClientSocket.Dispose()
>at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)
>at 
> Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(ClientProtocolVersion 
> version)
>at 
> Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration 
> clientConfiguration, Nullable`1 version)
>at 
> Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration 
> clientConfiguration)
>at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration 
> clientConfiguration)
> {code}



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

[jira] [Updated] (IGNITE-7399) .NET: Thin client: NullRefException on connection to arbitrary server

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn updated IGNITE-7399:
---
Summary: .NET: Thin client: NullRefException on connection to arbitrary 
server  (was: .NET: Thin client: NullRefException when connection to arbitrary 
server)

> .NET: Thin client: NullRefException on connection to arbitrary server
> -
>
> Key: IGNITE-7399
> URL: https://issues.apache.org/jira/browse/IGNITE-7399
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms, thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET
> Fix For: 2.4
>
>
> Reproducer:
> {code}
> var cfg = new IgniteClientConfiguration { Host = "ya.ru", Port=80 };
> var client = Ignition.StartClient(cfg);
> {code}
> Result:
> {code}
> Object reference not set to an instance of an object.
> at Apache.Ignite.Core.Impl.Client.ClientSocket.Dispose()
>at Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)
>at 
> Apache.Ignite.Core.Impl.Client.ClientSocket.Handshake(ClientProtocolVersion 
> version)
>at 
> Apache.Ignite.Core.Impl.Client.ClientSocket..ctor(IgniteClientConfiguration 
> clientConfiguration, Nullable`1 version)
>at 
> Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration 
> clientConfiguration)
>at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration 
> clientConfiguration)
> {code}



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

[jira] [Assigned] (IGNITE-7386) Get rid of LongAdder8, ConcurrentHashMap8, etc

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov reassigned IGNITE-7386:


Assignee: Andrey Kuznetsov  (was: Aleksey Plekhanov)

> Get rid of LongAdder8, ConcurrentHashMap8, etc
> --
>
> Key: IGNITE-7386
> URL: https://issues.apache.org/jira/browse/IGNITE-7386
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Since we're dropping java7 support there is no need now to use 
> {{LongAdder8}}, {{ConcurrentHashMap8}}, ...
> We should remove all classes from {{org.jsr166}} namespace and use 
> corresponding classes from jdk8.



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

[jira] [Updated] (IGNITE-5038) BinaryMarshaller might need to use context class loader for deserialization

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov updated IGNITE-5038:

Fix Version/s: 2.5

> BinaryMarshaller might need to use context class loader for deserialization
> ---
>
> Key: IGNITE-5038
> URL: https://issues.apache.org/jira/browse/IGNITE-5038
> Project: Ignite
>  Issue Type: Improvement
>  Components: binary
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Vladimir Ozerov
>Priority: Major
>  Labels: features
> Fix For: 2.5
>
> Attachments: results-compound-20170802.zip, 
> results-compound-20170808.zip
>
>
> There is a special use case discussed on the dev list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-BinaryObjectImpl-deserializeValue-with-specific-ClassLoader-td17126.html#a17224
> According to the use case, BinaryMarshaller might need to try to deserialize 
> an object using a context class loader if it failed to do so with a custom 
> classloader (`IgniteConfiguration.getClassLoader()`) or the system one.



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

[jira] [Commented] (IGNITE-1628) .NET: Ensure that Ignite works on Mono platform

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-1628:


Did not find a way to call {{CLRCreateInstance}} on Mono. Let's skip 
multi-AppDomain support on Mono for now.

> .NET: Ensure that Ignite works on Mono platform
> ---
>
> Key: IGNITE-1628
> URL: https://issues.apache.org/jira/browse/IGNITE-1628
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .net
>
> *NOTE*: Targeted for 1.6, but could be moved even further in case of tight 
> release schedule.
> *Goal*
> As Microsoft is moving .Net towards open standards, Mono receives more an 
> more attention. 
> We need to ensure that our product works fine on this platform. This includes 
> both Windows, Linux and (possibly) Mac environments.
> *Tasks*
> - Ensure that Ignite works with Mono on Windows. This is the easiest task 
> because we only need to re-compile .Net part.
> - Ensure that Ignite works with Mono on Linux. This will require alternate 
> build procedure because CPP recompilation will be required as well.
> - Create relevant TC builds.



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

[jira] [Assigned] (IGNITE-7410) IgniteSparseDistributedMatrixMulBenchmark(Mul2) hangs

[Oleg Ignatenko (JIRA)]

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

Oleg Ignatenko reassigned IGNITE-7410:
--

Assignee: Oleg Ignatenko

> IgniteSparseDistributedMatrixMulBenchmark(Mul2) hangs 
> --
>
> Key: IGNITE-7410
> URL: https://issues.apache.org/jira/browse/IGNITE-7410
> Project: Ignite
>  Issue Type: Bug
>  Components: yardstick
>Affects Versions: 2.4
>Reporter: Ilya Suntsov
>Assignee: Oleg Ignatenko
>Priority: Major
> Attachments: logs_sparse-distributed-matrix-mul.zip
>
>
> I tried to run the benchmarks bellow on 2 servers and 3 clients:
>  * IgniteSparseDistributedMatrixMulBenchmark
>  * IgniteSparseDistributedMatrixMul2Benchmark
> They hang.
> I've attached logs and configs.



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

[jira] [Created] (IGNITE-7410) IgniteSparseDistributedMatrixMulBenchmark(Mul2) hangs

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-7410:


 Summary: IgniteSparseDistributedMatrixMulBenchmark(Mul2) hangs 
 Key: IGNITE-7410
 URL: https://issues.apache.org/jira/browse/IGNITE-7410
 Project: Ignite
  Issue Type: Bug
  Components: yardstick
Affects Versions: 2.4
Reporter: Ilya Suntsov
 Attachments: logs_sparse-distributed-matrix-mul.zip

I tried to run the benchmarks bellow on 2 servers and 3 clients:
 * IgniteSparseDistributedMatrixMulBenchmark

 * IgniteSparseDistributedMatrixMul2Benchmark

They hang.

I've attached logs and configs.



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

[jira] [Created] (IGNITE-7409) Rework exception handling in suspend()\resume() methods

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-7409:


 Summary: Rework exception handling in suspend()\resume() methods
 Key: IGNITE-7409
 URL: https://issues.apache.org/jira/browse/IGNITE-7409
 Project: Ignite
  Issue Type: Bug
 Environment: Rework exception handling logicin suspend()\resume() 
methods.

Currently user may cause assertion error when misusing suspend()\resume() 
methods, needs to move some exception handling logic from asserts into "if-then 
throw" clauses.  
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov






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

[jira] [Commented] (IGNITE-6625) JDBC thin: support SSL connection to Ignite node

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-6625:
--

[~vozerov], 1-5 comments are fixed, please take a look.

> JDBC thin: support SSL connection to Ignite node
> 
>
> Key: IGNITE-6625
> URL: https://issues.apache.org/jira/browse/IGNITE-6625
> Project: Ignite
>  Issue Type: Improvement
>  Components: jdbc
>Affects Versions: 2.2
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> SSL connection must be supported for JDBC thin driver.



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

[jira] [Created] (IGNITE-7408) Document WAL changes

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-7408:
---

 Summary: Document WAL changes
 Key: IGNITE-7408
 URL: https://issues.apache.org/jira/browse/IGNITE-7408
 Project: Ignite
  Issue Type: Task
 Environment: WAL documentation should be updated accordingly to 
IGNITE-6339 issue.

The following changes can affect WAL configuration and behavior:
 # {\{DataStorageConfiguration.setWalBufferSize}} added instead of 
\{{PersistentStoreConfiguration.setTlbSize}}. By default WAL buffer size equals 
WAL segment size if memory mapped file is enabled, and (WAL segment size) / 4 
if memory mapped file is disabled.
 # Memory mapped file is enabled by default and provides better performance. 
Memory mapped file usage can be turned off. \{{IGNITE_WAL_MMAP}} property with 
\{{false}} value should be added to the JVM arguments: 
\{{-DIGNITE_WAL_MMAP=false}}.
 # If memory mapped file is enabled then \{{BACKGROUND}} and \{{LOG_ONLY}} WAL 
modes behave identically and don't have any differences in performance or data 
integrity guarantees.
Reporter: Andrey Gura
 Fix For: 2.4






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

[jira] [Assigned] (IGNITE-7031) Web console: Error on cancellation of comfirm dialog

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-7031:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Added handling expections on canceling clone functions. No console warning. 
Please test.

> Web console: Error on cancellation of comfirm dialog
> 
>
> Key: IGNITE-7031
> URL: https://issues.apache.org/jira/browse/IGNITE-7031
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> On cancellation of confirm dialog error message showed in log of browser.
> F.e. Clone dialog or remove all dialog.



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

[jira] [Updated] (IGNITE-7378) WAL converter: add records statistic to WAL reader dev-util

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-7378:
---
Description: 
In Standalone WAL iterator implemented under 
https://issues.apache.org/jira/browse/IGNITE-5558 and in 
https://issues.apache.org/jira/browse/IGNITE-6277

but this tool just prints record into log.

It is usefull to see at least machine readable statistics of record types, 
caches involved into this log to find out most popular record types.

It is suggested to add statistic to this tool and print this at end of 
execution.

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73638827

  was:
In Standalone WAL iterator implemented under 
https://issues.apache.org/jira/browse/IGNITE-5558 and  in 
https://issues.apache.org/jira/browse/IGNITE-6277

but this tool just prints record into log. 

It is usefull to see at least machine readable statistics of record types, 
caches involved into this log to find out most popular record types.

It is suggested to add statistic to this tool and print this at end of 
execution.
 


> WAL converter: add records statistic to WAL reader dev-util
> ---
>
> Key: IGNITE-7378
> URL: https://issues.apache.org/jira/browse/IGNITE-7378
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>
> In Standalone WAL iterator implemented under 
> https://issues.apache.org/jira/browse/IGNITE-5558 and in 
> https://issues.apache.org/jira/browse/IGNITE-6277
> but this tool just prints record into log.
> It is usefull to see at least machine readable statistics of record types, 
> caches involved into this log to find out most popular record types.
> It is suggested to add statistic to this tool and print this at end of 
> execution.
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73638827



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

[jira] [Created] (IGNITE-7407) Cancelling Query notebook deletion doesn't work

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-7407:
-

 Summary: Cancelling Query notebook deletion doesn't work
 Key: IGNITE-7407
 URL: https://issues.apache.org/jira/browse/IGNITE-7407
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin


Steps to reproduce:

1) Create a query notebook

2) Open this notebook in Queries page

3) Click "delete" (trash bin icon)

4) In confirmation window click "Cancel"

 

Actual:

Notebook is deleted

Expected:

Notebook is not deleted.



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

[jira] [Updated] (IGNITE-7406) Transactions hang forever during load test

[Ksenia Rybakova (JIRA)]

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

Ksenia Rybakova updated IGNITE-7406:

Attachment: run-load.xml
run-load.properties
ignite-base-load-config.xml
IGNITE-7406_hungTx.log

> Transactions hang forever during load test
> --
>
> Key: IGNITE-7406
> URL: https://issues.apache.org/jira/browse/IGNITE-7406
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Ksenia Rybakova
>Priority: Critical
> Attachments: IGNITE-7406_hungTx.log, ignite-base-load-config.xml, 
> run-load.properties, run-load.xml
>
>
> Load test config:
> - CacheRandomOperationBenchmark
> - 13 client nodes (1 per host), 62 server nodes (4 per host)
> - 30 caches with different configs
> - data store config: 6Gb default region, two 100M regions, two 1Gb regions
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL 
> PUT_IF_ABSENT REPLACE
> - preload amount 200K entries, key range 400K
> - Persistent store is disabled
> Preloading phase completed successfully, but during main test transactions 
> completely hang ("long running tx/cache future" logs show duration more than 
> 48h) after some time.
> Yardstick configs are attached, "long running tx/cache future" messages from 
> one of the server are attached.



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

[jira] [Created] (IGNITE-7406) Transactions hang forever during load test

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-7406:
---

 Summary: Transactions hang forever during load test
 Key: IGNITE-7406
 URL: https://issues.apache.org/jira/browse/IGNITE-7406
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Ksenia Rybakova


Load test config:

- CacheRandomOperationBenchmark
- 13 client nodes (1 per host), 62 server nodes (4 per host)
- 30 caches with different configs
- data store config: 6Gb default region, two 100M regions, two 1Gb regions
- operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL 
PUT_IF_ABSENT REPLACE
- preload amount 200K entries, key range 400K
- Persistent store is disabled

Preloading phase completed successfully, but during main test transactions 
completely hang ("long running tx/cache future" logs show duration more than 
48h) after some time.

Yardstick configs are attached, "long running tx/cache future" messages from 
one of the server are attached.



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

[jira] [Commented] (IGNITE-3935) ClassLoaders are not switched during object deserialization

[Denis Mekhanikov (JIRA)]

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

Denis Mekhanikov commented on IGNITE-3935:
--

{{GridPeerDeployAware}} interface solves this problem for internal types, that 
may contain some user classes.

The problem with {{StreamTransformer}} is that the object, returned from 
{{StreamTransformer.from()}} doesn't implement {{GridPeerDeployAware}} 
interface.

> ClassLoaders are not switched during object deserialization
> ---
>
> Key: IGNITE-3935
> URL: https://issues.apache.org/jira/browse/IGNITE-3935
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 1.6
>Reporter: Denis Magda
>Assignee: Denis Mekhanikov
>Priority: Major
>
> If an object is being deserialized with ClassLoader A then this ClassLoader A 
> will be used for the deserialization of the whole object's state, i.e., 
> including all its fields that can be custom objects loaded by ClassLoader B. 
> In a basic scenario we can have an object of some Ignite class that is 
> presented in the classpath. That Ignite class may enclose an object that is 
> loaded by peer-class-loading class loader. The deserialization will fail 
> because Ignite won't switch to the peer-class-loading loader when it's needed.
> To reproduce the issue do the following:
> 1. Start a remote ignite node using {{./ignite.sh 
> ../examples/config/example-ignite.xml}}
> 2. Run the code below
> {code}
> public class StreamingExample {`
> public static class StreamingExampleCacheEntryProcessor implements 
> CacheEntryProcessor {
> @Override
> public Object process(MutableEntry e, Object... arg) throws 
> EntryProcessorException {
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(StreamTransformer.from(new 
> StreamingExampleCacheEntryProcessor()));
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> {code}
> However if to modify this code to the following everything will work fine 
> {code}
> public class StreamingExample {
> public static class StreamingExampleCacheEntryProcessor extends 
> StreamTransformer {
> @Override
> public Object process(MutableEntry e, Object... arg) 
> throws EntryProcessorException {
> System.out.println("Executed!");
> Long val = e.getValue();
> e.setValue(val == null ? 1L : val + 1);
> return null;
> }
> }
> public static void main(String[] args) throws IgniteException, 
> IOException {
> Ignition.setClientMode(true);
> try (Ignite ignite = 
> Ignition.start("examples/config/example-ignite.xml")) {
> IgniteCache stmCache = 
> ignite.getOrCreateCache("mycache");
> try (IgniteDataStreamer stmr = 
> ignite.dataStreamer(stmCache.getName())) {
> stmr.allowOverwrite(true);
> stmr.receiver(new StreamingExampleCacheEntryProcessor());
> stmr.addData("word", 1L);
> System.out.println("Finished");
> }
> }
> }
> }
> {code}



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