[jira] [Commented] (IGNITE-3999) Support case insensitive search in SQL

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-3999:
-

Hello, [~aakhmedov].

As far as I can see there are some unfixed comments in Upsource from Alexander 
Paschenko.
I'm also done a preliminary review and leave some comments in Upsource.

Please, see all the comments and fix it. 

> Support case insensitive search in SQL
> --
>
> Key: IGNITE-3999
> URL: https://issues.apache.org/jira/browse/IGNITE-3999
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 1.7
>Reporter: Valentin Kulichenko
>Assignee: Amir Akhmedov
>Priority: Critical
>  Labels: sql-engine
> Fix For: 2.5
>
>
> Currently case insensitive search is possible only with the help of 
> {{lower()}} function:
> {code}
> select name from MyValue where lower(name) = 'abc_5'
> {code}
> But this will always be a full scan, even if {{name}} field is indexed.
> We need to correctly support {{VARCHAR_IGNORECASE}} H2 type in Ignite and add 
> a respective property to {{@QuerySqlField}} annotation.



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

[jira] [Assigned] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8132:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Merged to master.

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

[jira] [Assigned] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-8126:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Web console: the method 'LoadCaches' should not be generated if cache doesn't 
> contain cache store configuration
> ---
>
> Key: IGNITE-8126
> URL: https://issues.apache.org/jira/browse/IGNITE-8126
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
>
> # create cluster, save
> # create cache, save
> # see project structure



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

[jira] [Commented] (IGNITE-8126) Web console: the method 'LoadCaches' should not be generated if cache doesn't contain cache store configuration

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-8126:
---

Fixed cache load geneartion.

> Web console: the method 'LoadCaches' should not be generated if cache doesn't 
> contain cache store configuration
> ---
>
> Key: IGNITE-8126
> URL: https://issues.apache.org/jira/browse/IGNITE-8126
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> # create cluster, save
> # create cache, save
> # see project structure



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

[jira] [Updated] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-8132:
-
Component/s: wizards

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Alexey Kuznetsov (JIRA)]

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

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

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov closed IGNITE-5466.


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




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

[jira] [Updated] (IGNITE-6816) Webconsole: Upgrade to Webpack 4

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-6816:
-
External issue URL:   (was: 
https://github.com/asfktz/autodll-webpack-plugin/issues/9)

> Webconsole: Upgrade to Webpack 4
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.5
>
>
> 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] [Updated] (IGNITE-6816) Webconsole: Upgrade to Webpack 4

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-6816:
-
Summary: Webconsole: Upgrade to Webpack 4  (was: Webconsole: 
investigate/integrate Webpack dll-plugin)

> Webconsole: Upgrade to Webpack 4
> 
>
> Key: IGNITE-6816
> URL: https://issues.apache.org/jira/browse/IGNITE-6816
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.5
>
>
> 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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6816:


Resolution: Fixed
  Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master.

Please do a smoke test of Web Console.

> 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: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.5
>
>
> 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] [Commented] (IGNITE-7940) Visor CMD: Support cache.lostPartitions() and ignite.resetLostPartitions().

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-7940:
---

# Refactored to List.
# Fixed wrong import.

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



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

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

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-7940:
-

Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

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



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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-5466:
--

Assignee: Alexey Kuznetsov  (was: Pavel Konstantinov)

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




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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-5466 at 4/5/18 3:50 AM:


Tested. Created a few new issues for found errors.


was (Author: pkonstantinov):
Tested

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




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

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

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-5466:


Tested

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




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

[jira] [Assigned] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Ilya Borisov (JIRA)]

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

Ilya Borisov reassigned IGNITE-8132:


Assignee: Alexey Kuznetsov  (was: Ilya Borisov)

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8001) Web console: show more user-friendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov updated IGNITE-8001:
---
Fix Version/s: 2.6

> Web console: show more user-friendly error instead of 'Internal error'
> --
>
> Key: IGNITE-8001
> URL: https://issues.apache.org/jira/browse/IGNITE-8001
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> In case if the backend is down we display the 'Internal error' message.
> I suggest displaying some other more user-friendly text.
>  !screenshot-1.png! 



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

[jira] [Commented] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-8132:
--

[~kuaw26] please review and merge.

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

[jira] [Assigned] (IGNITE-8001) Web console: show more user-friendly error instead of 'Internal error'

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-8001:
--

Assignee: Alexey Kuznetsov

> Web console: show more user-friendly error instead of 'Internal error'
> --
>
> Key: IGNITE-8001
> URL: https://issues.apache.org/jira/browse/IGNITE-8001
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.6
>
> Attachments: screenshot-1.png
>
>
> In case if the backend is down we display the 'Internal error' message.
> I suggest displaying some other more user-friendly text.
>  !screenshot-1.png! 



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

[jira] [Updated] (IGNITE-8015) NPE on adding node to baseline

[Pavel Konstantinov (JIRA)]

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

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

> NPE on adding node to baseline
> --
>
> Key: IGNITE-8015
> URL: https://issues.apache.org/jira/browse/IGNITE-8015
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
>
> # start ignite.sh
> # execute .\control.sh --baseline add 111
> {code}
> [17:05:37,396][SEVERE][rest-#68][GridRestProcessor] Failed to handle request: 
> EXE
> class org.apache.ignite.IgniteCheckedException: null
> at 
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7273)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:171)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at 
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:263)
> at 
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler$2.apply(GridTaskCommandHandler.java:257)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:353)
> at 
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:257)
> at 
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsync(GridTaskCommandHandler.java:163)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:266)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:89)
> at 
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:155)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> 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: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.currentBaseLine(VisorBaselineTask.java:100)
> at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.add(VisorBaselineTask.java:148)
> at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:203)
> at 
> org.apache.ignite.internal.visor.baseline.VisorBaselineTask$VisorBaselineJob.run(VisorBaselineTask.java:52)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
> at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6652)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
> at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1407)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:660)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:532)
> at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:760)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:509)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:489)
> at 
> org.apache.ignite.internal.processors.rest.handlers.task.GridTaskCommandHandler.handleAsyncUnsafe(GridTaskCommandHandler.java:227)
> ... 8 more
> {code}



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

[jira] [Updated] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-8132:
-
Attachment: screenshot-2.png

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

[jira] [Commented] (IGNITE-8132) Web console: A little re-design of Checkpointing section

[Ilya Borisov (JIRA)]

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

Ilya Borisov commented on IGNITE-8132:
--

Done:
 !screenshot-2.png! 

> Web console: A little re-design of Checkpointing section 
> -
>
> Key: IGNITE-8132
> URL: https://issues.apache.org/jira/browse/IGNITE-8132
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Konstantinov
>Assignee: Ilya Borisov
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
>  !screenshot-1.png! 



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

[jira] [Assigned] (IGNITE-8099) Web console: wrong editing behavior in case of incorrect field value

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov reassigned IGNITE-8099:
--

Assignee: Alexey Kuznetsov

> Web console: wrong editing behavior in case of incorrect field value
> 
>
> Key: IGNITE-8099
> URL: https://issues.apache.org/jira/browse/IGNITE-8099
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.5
>
>
> For reproduce just try to edit 'Key Type' field of Model



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

[jira] [Commented] (IGNITE-8141) Improve OS config suggestions: SWAPPINESS

[Reed Sandberg (JIRA)]

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

Reed Sandberg commented on IGNITE-8141:
---

[~dpavlov], per your suggestion I referenced a pull request for documentation 
improvement here.

> Improve OS config suggestions: SWAPPINESS
> -
>
> Key: IGNITE-8141
> URL: https://issues.apache.org/jira/browse/IGNITE-8141
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Reed Sandberg
>Assignee: Reed Sandberg
>Priority: Minor
>  Labels: pull-request-available
>
> Acknowledge suggested SWAPPINESS OS param adjustment using a range (<= 10).



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

[jira] [Created] (IGNITE-8141) Improve OS config suggestions: SWAPPINESS

[Reed Sandberg (JIRA)]

Reed Sandberg created IGNITE-8141:
-

 Summary: Improve OS config suggestions: SWAPPINESS
 Key: IGNITE-8141
 URL: https://issues.apache.org/jira/browse/IGNITE-8141
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 2.4
Reporter: Reed Sandberg
Assignee: Reed Sandberg


Acknowledge suggested SWAPPINESS OS param adjustment using a range (<= 10).



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

[jira] [Assigned] (IGNITE-6815) "Unexpected exception during cache update" via NullPointerException thrown using TouchedExpiryPolicy

[Reed Sandberg (JIRA)]

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

Reed Sandberg reassigned IGNITE-6815:
-

Assignee: Reed Sandberg

> "Unexpected exception during cache update" via NullPointerException thrown 
> using TouchedExpiryPolicy
> 
>
> Key: IGNITE-6815
> URL: https://issues.apache.org/jira/browse/IGNITE-6815
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, streaming
>Affects Versions: 2.2, 2.3, 2.4
> Environment: 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11 
> 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Distributor ID:   LinuxMint
> Description:  Linux Mint 18.2 Sonya
> Release:  18.2
> Codename: sonya
>Reporter: Reed Sandberg
>Assignee: Reed Sandberg
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.5
>
>
> This is triggered when I apply an expiry on the cache during an import with 
> StreamLoader, with no expiry on the cache, the import runs fine.
> Somehow the following line of code is hit with val == null:
> org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:1253
> Stack trace (version 2.3.0 release package from maven public repo):
> {noformat}
> 16:04:25.259 ERROR o.a.i.i.p.c.d.d.a.GridDhtAtomicCache -  
> Unexpected exception during cache update
> org.apache.ignite.IgniteException: Runtime failure on search row: 
> org.apache.ignite.internal.processors.cache.tree.SearchRow@68a4e885
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1632)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1201)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:343)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2419)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1882)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1735)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1627)
>   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:1116)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:825)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:783)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1338)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1320)
>   at 
> org.apache.ignite.stream.StreamTransformer.receive(StreamTransformer.java:45)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:137)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6631)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException: null
>   at 
> 

[jira] [Created] (IGNITE-8140) Web console: "integer number too large" in generated project

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8140:
--

 Summary: Web console: "integer number too large" in generated 
project
 Key: IGNITE-8140
 URL: https://issues.apache.org/jira/browse/IGNITE-8140
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Vasiliy Sisko


Some methods expected Long type but we set Integer, please fix
{code}
dataStorageCfg.setSystemRegionMaxSize(2147483648);
eventStorage.setExpireAgeMs(2323232323232323);
cfg.setMetricsExpireTime(2323232323);
{code}



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

[jira] [Updated] (IGNITE-8140) Web console: "integer number too large" in generated project

[Pavel Konstantinov (JIRA)]

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

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

> Web console: "integer number too large" in generated project
> 
>
> Key: IGNITE-8140
> URL: https://issues.apache.org/jira/browse/IGNITE-8140
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
> Fix For: 2.5
>
>
> Some methods expected Long type but we set Integer, please fix
> {code}
> dataStorageCfg.setSystemRegionMaxSize(2147483648);
> eventStorage.setExpireAgeMs(2323232323232323);
> cfg.setMetricsExpireTime(2323232323);
> {code}



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

[jira] [Created] (IGNITE-8139) Need to have better control on the size of SQL on heap cache

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-8139:
---

 Summary: Need to have better control on the size of SQL on heap 
cache
 Key: IGNITE-8139
 URL: https://issues.apache.org/jira/browse/IGNITE-8139
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.4
Reporter: Valentin Kulichenko
Assignee: Vladimir Ozerov
 Fix For: 2.5


Currently, if SQL on heap cache is enabled, there is no clear way to control 
the size of this cache. Looks like its evictions basically depend on evictions 
in off-heap, so it's really to get OOME. Not very usable.

The easiest improvement would be to have a knob (configuration parameter or 
system property) that would control the size of underlying concurrent map that 
stores cached rows.



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

[jira] [Created] (IGNITE-8138) Incorrect uptime in GG metrics for long running server node (1+ days)

[Max Shonichev (JIRA)]

Max Shonichev created IGNITE-8138:
-

 Summary: Incorrect uptime in GG metrics for long running server 
node (1+ days)
 Key: IGNITE-8138
 URL: https://issues.apache.org/jira/browse/IGNITE-8138
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4, 2.1
Reporter: Max Shonichev
 Fix For: 2.5


Ignite prints a metrics to the log with uptime, formatted as 'XX:YY:ZZ:TTT'.
It looks, like XX corresponds to hours, YY to minutes, ZZ to seconds, however 
if we filter uptime metric from a long running server (few days), we would see 
that :

{noformat}
 ^-- Node [id=684d2761, name=null, uptime=00:01:00:009]
 ^-- Node [id=684d2761, name=null, uptime=00:02:00:009]
 ^-- Node [id=684d2761, name=null, uptime=00:03:00:009]
 ^-- Node [id=684d2761, name=null, uptime=00:04:00:021]
...
 ^-- Node [id=684d2761, name=null, uptime=23:58:08:391]
 ^-- Node [id=684d2761, name=null, uptime=23:59:08:393]
 ^-- Node [id=684d2761, name=null, uptime=24:00:08:395]
 ^-- Node [id=684d2761, name=null, uptime=24:01:08:406]
...
 ^-- Node [id=684d2761, name=null, uptime=59:59:23:542]
 ^-- Node [id=684d2761, name=null, uptime=00:00:23:554]
...
{noformat}

BUG:
1. hours do not rollover at 23:59:59
2. there's no simple means for user to get uptime days, because hours do 
actually rollover after 59:59:59

what is expected: 
 1. add a day counter, init with 0
 2. make hours correctly rollover after full day (24hrs) run
{noformat}
 ^-- Node [id=684d2761, name=null, uptime=0:00:01:00:009]
...
 ^-- Node [id=684d2761, name=null, uptime=0:23:59:00:009]
 ^-- Node [id=684d2761, name=null, uptime=1:00:00:00:009]
...
{noformat}



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

[jira] [Comment Edited] (IGNITE-6069) Service versioning

[Michael Griggs (JIRA)]

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

Michael Griggs edited comment on IGNITE-6069 at 4/4/18 7:38 PM:


It is essential that server nodes *not* need to be stopped in order to deploy a 
new service. This implies that we have peer-class loading for Service 
interfaces and implementations.


was (Author: endian675):
It is essential that server nodes must need to be stopped in order to deploy a 
new service.  This implies that we have peer-class loading for Service 
interfaces and implementations.

> Service versioning
> --
>
> Key: IGNITE-6069
> URL: https://issues.apache.org/jira/browse/IGNITE-6069
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Make services upgradable -again-. 
> Main points:
> - compute binary type ID by (classname + version)
> - use serialVersionUuid as version ( ?)
> - all service instances with the same name must have the same version
> - make ServiceProxy aware of versions and upgrade process, pause requests 
> while service is being upgraded
> - extend Service interface (UpgradableService?) - add ability to collect 
> state of previous version before start.
> Once the feature is implemented, it has to be documented extensively. The 
> ticket must not be closed until this happens.



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

[jira] [Commented] (IGNITE-6069) Service versioning

[Michael Griggs (JIRA)]

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

Michael Griggs commented on IGNITE-6069:


The use-case for multiple versions of service active at one time is as follows:
 # Central Team creates a service that provides functionality
 # Application Team 1 accesses that service to use functionality
 # Application Team 2 accesses that service to use functionality
 # Central team needs to modify the service to improve functionality
 # Application Team 1 updates its code to use improved functionality, but 
Application Team 2 does not have time do so. If multiple active Service 
versions are not available, the Central Team can only evolve the functionality 
at the pace of the slowest Application Team. Multiple active service versions 
removes that limitation.

> Service versioning
> --
>
> Key: IGNITE-6069
> URL: https://issues.apache.org/jira/browse/IGNITE-6069
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Make services upgradable -again-. 
> Main points:
> - compute binary type ID by (classname + version)
> - use serialVersionUuid as version ( ?)
> - all service instances with the same name must have the same version
> - make ServiceProxy aware of versions and upgrade process, pause requests 
> while service is being upgraded
> - extend Service interface (UpgradableService?) - add ability to collect 
> state of previous version before start.
> Once the feature is implemented, it has to be documented extensively. The 
> ticket must not be closed until this happens.



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

[jira] [Commented] (IGNITE-975) Peer deployment does not work for distributed services

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-975:
--

While a bug in the utility cache should probably still be fixed, I do not think 
it makes sense to support peer-deployment for services for the same reason we 
do not support it for caches.

> Peer deployment does not work for distributed services
> --
>
> Key: IGNITE-975
> URL: https://issues.apache.org/jira/browse/IGNITE-975
> Project: Ignite
>  Issue Type: Bug
>Reporter: Yakov Zhdanov
>Assignee: Gianfranco Murador
>Priority: Major
>
> it seems that peer-deployment meta is not properly sent for utility cache.
> To reproduce start node with {{main(String[])}} method from module others 
> than {{examples}} and run {{ServicesExample}}.
> Node output:
> {noformat}
> [13:43:41]__   
> [13:43:41]   /  _/ ___/ |/ /  _/_  __/ __/ 
> [13:43:41]  _/ // (7 7// /  / / / _/   
> [13:43:41] /___/\___/_/|_/___/ /_/ /___/  
> [13:43:41]  
> [13:43:41] ver. 1.0.7-SNAPSHOT#19700101-sha1:DEV
> [13:43:41] 2015 Copyright(C) Apache Software Foundation
> [13:43:41] 
> [13:43:41] Quiet mode.
> [13:43:41]   ^-- Logging to file 
> '/Users/yzhdanov/projects/incubator-ignite/work/log/ignite-cb8d4626.0.log'
> [13:43:41]   ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or 
> "-v" to ignite.{sh|bat}
> [13:43:41] 
> [13:43:41] Initial heap size is 256MB (should be no less than 512MB, use 
> -Xms512m -Xmx512m).
> [13:43:41] Configured plugins:
> [13:43:41]   ^-- None
> [13:43:41] 
> [13:43:43] Performance suggestions for grid  (fix if possible)
> [13:43:43] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [13:43:43]   ^-- Disable peer class loading (set 'peerClassLoadingEnabled' to 
> false)
> [13:43:43] 
> [13:43:43] To start Console Management & Monitoring run 
> ignitevisorcmd.{sh|bat}
> [13:43:43] 
> [13:43:43] Ignite node started OK (id=cb8d4626)
> [13:43:43] Topology snapshot [ver=1, nodes=1, CPUs=8, heap=3.6GB]
> [13:43:51] New version is available at ignite.incubator.apache.org: 1.1.0
> [13:44:02] Topology snapshot [ver=2, nodes=2, CPUs=8, heap=7.1GB]
> [13:44:03,512][SEVERE][ignite-#73%utility-null%][GridDhtTxLocal] Heuristic 
> transaction failure.
> class 
> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: 
> Failed to locally write to cache (all transaction entries will be 
> invalidated, however there was a window when entries for this transaction 
> were visible to others): GridNearTxLocal [nearLocallyMapped=false, 
> colocatedLocallyMapped=true, mappings=[cb8d4626-14c8-4b01-af80-861e45c824f3], 
> super=GridDhtTxLocalAdapter [mapped=true, dhtThreadId=95, 
> needsCompletedVers=true, nearNodes=[], 
> dhtNodes=[afd28cea-8fed-4b90-8b81-cfad048c502a], explicitLock=false, 
> super=IgniteTxLocalAdapter [txMap={IgniteTxKey [key=KeyCacheObjectImpl 
> [val=GridServiceAssignmentsKey [name=myClusterSingletonService], 
> hasValBytes=true], cacheId=-2100569601]=IgniteTxEntry [key=KeyCacheObjectImpl 
> [val=GridServiceAssignmentsKey [name=myClusterSingletonService], 
> hasValBytes=true], cacheId=-2100569601, txKey=IgniteTxKey 
> [key=KeyCacheObjectImpl [val=GridServiceAssignmentsKey 
> [name=myClusterSingletonService], hasValBytes=true], cacheId=-2100569601], 
> val=[op=CREATE, val=UserCacheObjectImpl [val=GridServiceAssignments 
> [nodeId=afd28cea-8fed-4b90-8b81-cfad048c502a, topVer=2, 
> cfg=ServiceConfiguration [name=myClusterSingletonService, totalCnt=1, 
> maxPerNodeCnt=1, cacheName=null, svcCls=SimpleMapServiceImpl, 
> nodeFilterCls=AttributeFilter], 
> assigns={cb8d4626-14c8-4b01-af80-861e45c824f3=1}], hasValBytes=true]], 
> prevVal=[op=CREATE, val=UserCacheObjectImpl [val=GridServiceAssignments 
> [nodeId=afd28cea-8fed-4b90-8b81-cfad048c502a, topVer=2, 
> cfg=ServiceConfiguration [name=myClusterSingletonService, totalCnt=1, 
> maxPerNodeCnt=1, cacheName=null, svcCls=SimpleMapServiceImpl, 
> nodeFilterCls=AttributeFilter], 
> assigns={cb8d4626-14c8-4b01-af80-861e45c824f3=1}], hasValBytes=true]], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=GridCacheVersion [topVer=44718225, nodeOrderDrId=1, 
> globalTime=1433238243492, order=1433238242461], filters=[], 
> filtersPassed=false, filtersSet=true, entry=GridDhtColocatedCacheEntry 
> [super=GridDhtCacheEntry [rdrs=[], locPart=GridDhtLocalPartition [id=28, 
> mapPubSize=0, rmvQueue=GridCircularBuffer [sizeMask=127, idxGen=0], 
> state=OWNING, reservations=0, empty=false, createTime=06/02/2015 13:43:43, 
> mapPubSize=0], super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=KeyCacheObjectImpl [val=GridServiceAssignmentsKey 
> 

[jira] [Comment Edited] (IGNITE-6069) Service versioning

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan edited comment on IGNITE-6069 at 4/4/18 7:16 PM:
---

I do not think it makes sense to have multiple versions of service co-exist in 
the same cluster. The right approach is to send all new requests to the new 
instance and undeploy the old service instance when it finished serving all 
existing requests.

This will create a small temporary window when the new and the old service 
instances are both active, but I think it is a correct approach from the user 
standpoint.

Also, it seems that services will have to be deployed within their own 
class-loader, to avoid class conflicts. We use a similar approach for the 
compute tasks.


was (Author: dsetrakyan):
I do not think it makes sense to have multiple versions of service operate at 
the same time. The right approach is to send all new requests to the new 
instance and undeploy the old service instance when it finished serving all 
existing requests.

This will create a small temporary window when the new and the old versions are 
both active, but I think it is a correct approach from the user standpoint.

Also, it seems that services will have to be deployed within their own 
class-loader, to avoid class conflicts. We use a similar approach for the 
compute tasks.

> Service versioning
> --
>
> Key: IGNITE-6069
> URL: https://issues.apache.org/jira/browse/IGNITE-6069
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Make services upgradable -again-. 
> Main points:
> - compute binary type ID by (classname + version)
> - use serialVersionUuid as version ( ?)
> - all service instances with the same name must have the same version
> - make ServiceProxy aware of versions and upgrade process, pause requests 
> while service is being upgraded
> - extend Service interface (UpgradableService?) - add ability to collect 
> state of previous version before start.
> Once the feature is implemented, it has to be documented extensively. The 
> ticket must not be closed until this happens.



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

[jira] [Comment Edited] (IGNITE-6069) Service versioning

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan edited comment on IGNITE-6069 at 4/4/18 7:16 PM:
---

I do not think it makes sense to have multiple versions of service co-exist in 
the same cluster. The right approach is to send all new requests to the new 
instance and undeploy the old service instance when it finished serving all 
existing requests.

This will create a small temporary window when the new and the old service 
instances are both active, but I think it is a correct approach from the user 
standpoint.

Also, it seems that services will have to be deployed within their own 
class-loader, to avoid class conflicts. We use a similar approach for the 
compute tasks, so we should just borrow from that implementation.


was (Author: dsetrakyan):
I do not think it makes sense to have multiple versions of service co-exist in 
the same cluster. The right approach is to send all new requests to the new 
instance and undeploy the old service instance when it finished serving all 
existing requests.

This will create a small temporary window when the new and the old service 
instances are both active, but I think it is a correct approach from the user 
standpoint.

Also, it seems that services will have to be deployed within their own 
class-loader, to avoid class conflicts. We use a similar approach for the 
compute tasks.

> Service versioning
> --
>
> Key: IGNITE-6069
> URL: https://issues.apache.org/jira/browse/IGNITE-6069
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Make services upgradable -again-. 
> Main points:
> - compute binary type ID by (classname + version)
> - use serialVersionUuid as version ( ?)
> - all service instances with the same name must have the same version
> - make ServiceProxy aware of versions and upgrade process, pause requests 
> while service is being upgraded
> - extend Service interface (UpgradableService?) - add ability to collect 
> state of previous version before start.
> Once the feature is implemented, it has to be documented extensively. The 
> ticket must not be closed until this happens.



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

[jira] [Commented] (IGNITE-6069) Service versioning

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-6069:
---

I do not think it makes sense to have multiple versions of service operate at 
the same time. The right approach is to send all new requests to the new 
instance and undeploy the old service instance when it finished serving all 
existing requests.

This will create a small temporary window when the new and the old versions are 
both active, but I think it is a correct approach from the user standpoint.

Also, it seems that services will have to be deployed within their own 
class-loader, to avoid class conflicts. We use a similar approach for the 
compute tasks.

> Service versioning
> --
>
> Key: IGNITE-6069
> URL: https://issues.apache.org/jira/browse/IGNITE-6069
> Project: Ignite
>  Issue Type: New Feature
>  Components: general
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Ilya Lantukh
>Priority: Major
>
> Make services upgradable -again-. 
> Main points:
> - compute binary type ID by (classname + version)
> - use serialVersionUuid as version ( ?)
> - all service instances with the same name must have the same version
> - make ServiceProxy aware of versions and upgrade process, pause requests 
> while service is being upgraded
> - extend Service interface (UpgradableService?) - add ability to collect 
> state of previous version before start.
> Once the feature is implemented, it has to be documented extensively. The 
> ticket must not be closed until this happens.



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

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

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-6405:

Fix Version/s: (was: 2.5)
   2.6

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

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

[Andrey Gura (JIRA)]

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

Andrey Gura updated IGNITE-7820:

Fix Version/s: (was: 2.5)
   2.6

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



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

[jira] [Commented] (IGNITE-7680) Ignite PDS 1 (Direct IO): failed test IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7680:


[~ivan.glukos], could you please review my changes? it is 1 loc of test fix & 
javadoc

> Ignite PDS 1 (Direct IO): failed test 
> IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()
> -
>
> Key: IGNITE-7680
> URL: https://issues.apache.org/jira/browse/IGNITE-7680
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
>  Ignite PDS 1 (Direct IO) [ tests failed ]   
>   org.apache.ignite.testsuites.IgnitePdsNativeIoTestSuite: 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag
>  (fail rate 100%) 
> {noformat}
> class org.apache.ignite.IgniteException: Failed to begin checkpoint (it is 
> already in progress).
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.beginCheckpoint(PageMemoryImpl.java:961)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag(IgnitePdsCheckpointSimulationWithRealCpDisabledTest.java:564)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Commented] (IGNITE-7680) Ignite PDS 1 (Direct IO): failed test IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7680:


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

> Ignite PDS 1 (Direct IO): failed test 
> IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag()
> -
>
> Key: IGNITE-7680
> URL: https://issues.apache.org/jira/browse/IGNITE-7680
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
>  Ignite PDS 1 (Direct IO) [ tests failed ]   
>   org.apache.ignite.testsuites.IgnitePdsNativeIoTestSuite: 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag
>  (fail rate 100%) 
> {noformat}
> class org.apache.ignite.IgniteException: Failed to begin checkpoint (it is 
> already in progress).
>   at 
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.beginCheckpoint(PageMemoryImpl.java:961)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.db.file.IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testDirtyFlag(IgnitePdsCheckpointSimulationWithRealCpDisabledTest.java:564)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}



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

[jira] [Created] (IGNITE-8137) Explain how to see SQL schema and table structure in Ignite

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8137:
---

 Summary: Explain how to see SQL schema and table structure in 
Ignite
 Key: IGNITE-8137
 URL: https://issues.apache.org/jira/browse/IGNITE-8137
 Project: Ignite
  Issue Type: New Feature
  Components: documentation
Reporter: Denis Magda
 Fix For: 2.6


Presently, Ignite doesn't ship {{SHOW TABLE}} command. Thus, it's not clear how 
to get tables and schema structures in Ignite. 

Until this command is not supported we have to explain that:
* Many tools use JDBC and ODBC metadata related parameters can pull that 
information out of there and present it to an end user. For instance, SQLline 
utilizes {{!table}} command that gets data from JDBC metadata methods. DBeaver 
utilizes the same approach.
* Let's create {{Database Administration}} section under SQL reference 
(https://apacheignite-sql.readme.io/docs/sql-reference-overview) and presently 
list approaches supported by various tools (sqlline, dbeaver, etc) and how to 
get the same information from the drivers.



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

[jira] [Commented] (IGNITE-8114) Add fail recovery mechanism to tracking pages

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8114:


[~EdShangGG], I left several proposals in PR. Please fix code if you're agree.

> Add fail recovery mechanism to tracking pages
> -
>
> Key: IGNITE-8114
> URL: https://issues.apache.org/jira/browse/IGNITE-8114
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
> Fix For: 2.5
>
>
> Now we just assert that last saved tag in tracking page should be not greater 
> than passed one.
> But because of different issues which we don't understand yet, it could 
> happen.
> So, I suggest to handle it by adding new "corruption" state to tracking 
> state. 
> If tracking page is in a corrupted state than we would throw an exception on 
> any querying of the tracking page. Caller will have opportunity to catch the 
> exception and recover page state.



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

[jira] [Updated] (IGNITE-8136) Discovery service wrong works if node stopping by segmentation and hangs

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8136:
--
Description: 
Node stopping in long GC pause, after that it will be segmented, but if it not 
stopped, like this:
{noformat}
"Thread-76137" #4835330 daemon prio=5 os_prio=0 tid=0x7ef23c042800 
nid=0x27992c in Object.wait() [0x7e57a000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at 
org.apache.ignite.internal.util.worker.GridWorker.join(GridWorker.java:233)
- locked <0x7ef8babdb0f8> (a java.lang.Object)
at 
org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4655)
at 
org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4681)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.onKernalStop(GridJobProcessor.java:311)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2039)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1987)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2512)
- locked <0x7ef7a166eb70> (a 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2475)
at org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:362)
at org.apache.ignite.Ignition.stop(Ignition.java:224)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$10.run(GridDiscoveryManager.java:2373)
at java.lang.Thread.run(Thread.java:745)

"pub-#1032155%DPL_GRID%DplGridNodeName%" #4832845 prio=5 os_prio=0 
tid=0x7ef2ec10c000 nid=0x277864 waiting on condition [0x7e57b652e000]
   java.lang.Thread.State: RUNNABLE
at 
org.apache.ignite.internal.binary.streams.BinaryMemoryAllocatorChunk.reallocate(BinaryMemoryAllocatorChunk.java:69)
at 
org.apache.ignite.internal.binary.streams.BinaryHeapOutputStream.ensureCapacity(BinaryHeapOutputStream.java:65)
at 
org.apache.ignite.internal.binary.streams.BinaryAbstractOutputStream.writeByte(BinaryAbstractOutputStream.java:34)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteString(BinaryWriterExImpl.java:413)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.writeStringField(BinaryWriterExImpl.java:1124)
at 
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.write(BinaryFieldAccessor.java:531)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:794)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteObject(BinaryWriterExImpl.java:496)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.doWriteCollection(BinaryWriterExImpl.java:764)
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:694)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:206)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:147)
at 
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:134)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
at 
org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:9971)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:832)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.finishJob(GridJobWorker.java:773)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:625)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1189)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
at 

[jira] [Commented] (IGNITE-6815) "Unexpected exception during cache update" via NullPointerException thrown using TouchedExpiryPolicy

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6815:


Github user asfgit closed the pull request at:

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


> "Unexpected exception during cache update" via NullPointerException thrown 
> using TouchedExpiryPolicy
> 
>
> Key: IGNITE-6815
> URL: https://issues.apache.org/jira/browse/IGNITE-6815
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, streaming
>Affects Versions: 2.2, 2.3, 2.4
> Environment: 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11 
> 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Distributor ID:   LinuxMint
> Description:  Linux Mint 18.2 Sonya
> Release:  18.2
> Codename: sonya
>Reporter: Reed Sandberg
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.5
>
>
> This is triggered when I apply an expiry on the cache during an import with 
> StreamLoader, with no expiry on the cache, the import runs fine.
> Somehow the following line of code is hit with val == null:
> org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:1253
> Stack trace (version 2.3.0 release package from maven public repo):
> {noformat}
> 16:04:25.259 ERROR o.a.i.i.p.c.d.d.a.GridDhtAtomicCache -  
> Unexpected exception during cache update
> org.apache.ignite.IgniteException: Runtime failure on search row: 
> org.apache.ignite.internal.processors.cache.tree.SearchRow@68a4e885
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1632)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1201)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:343)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2419)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1882)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1735)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1627)
>   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:1116)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:825)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:783)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1338)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1320)
>   at 
> org.apache.ignite.stream.StreamTransformer.receive(StreamTransformer.java:45)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:137)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6631)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException: null
>   at 
> 

[jira] [Updated] (IGNITE-8136) Discovery service wrong works if node stopping by segmentation and hangs

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8136:
--
Description: 
Node stopping in long GC pause, after that it will be segmented, but if it not 
stopped, like this:
{noformat}
Ignition.stop()

{noformat}
Half of cluster nodes will detect, which the node was failed (with less order).

In the result we got different topology on various nodes.

  was:
Node stopping in long GC pause, after that it will be segmented, but if it not 
stopped, like this:

{noformat}

Ignition.stop()

{noformat}

Half of cluster nodes will detect, which the node was failed (with less order).


> Discovery service wrong works if node stopping by segmentation and hangs
> 
>
> Key: IGNITE-8136
> URL: https://issues.apache.org/jira/browse/IGNITE-8136
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> Node stopping in long GC pause, after that it will be segmented, but if it 
> not stopped, like this:
> {noformat}
> Ignition.stop()
> {noformat}
> Half of cluster nodes will detect, which the node was failed (with less 
> order).
> In the result we got different topology on various nodes.



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

[jira] [Updated] (IGNITE-8136) Discovery service wrong works if node stopping by segmentation and hangs

[Vladislav Pyatkov (JIRA)]

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

Vladislav Pyatkov updated IGNITE-8136:
--
Description: 
Node stopping in long GC pause, after that it will be segmented, but if it not 
stopped, like this:

{noformat}

Ignition.stop()

{noformat}

Half of cluster nodes will detect, which the node was failed (with less order).

> Discovery service wrong works if node stopping by segmentation and hangs
> 
>
> Key: IGNITE-8136
> URL: https://issues.apache.org/jira/browse/IGNITE-8136
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> Node stopping in long GC pause, after that it will be segmented, but if it 
> not stopped, like this:
> {noformat}
> Ignition.stop()
> {noformat}
> Half of cluster nodes will detect, which the node was failed (with less 
> order).



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

[jira] [Updated] (IGNITE-6815) "Unexpected exception during cache update" via NullPointerException thrown using TouchedExpiryPolicy

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov updated IGNITE-6815:
---
Fix Version/s: (was: 2.4)
   (was: 2.3)
   (was: 2.2)
   2.5

> "Unexpected exception during cache update" via NullPointerException thrown 
> using TouchedExpiryPolicy
> 
>
> Key: IGNITE-6815
> URL: https://issues.apache.org/jira/browse/IGNITE-6815
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, streaming
>Affects Versions: 2.2, 2.3, 2.4
> Environment: 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11 
> 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Distributor ID:   LinuxMint
> Description:  Linux Mint 18.2 Sonya
> Release:  18.2
> Codename: sonya
>Reporter: Reed Sandberg
>Priority: Major
>  Labels: pull-request-available
> Fix For: 2.5
>
>
> This is triggered when I apply an expiry on the cache during an import with 
> StreamLoader, with no expiry on the cache, the import runs fine.
> Somehow the following line of code is hit with val == null:
> org/apache/ignite/internal/processors/cache/IgniteCacheOffheapManagerImpl.java:1253
> Stack trace (version 2.3.0 release package from maven public repo):
> {noformat}
> 16:04:25.259 ERROR o.a.i.i.p.c.d.d.a.GridDhtAtomicCache -  
> Unexpected exception during cache update
> org.apache.ignite.IgniteException: Runtime failure on search row: 
> org.apache.ignite.internal.processors.cache.tree.SearchRow@68a4e885
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1632)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1201)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:343)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2419)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1882)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1735)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1627)
>   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:1116)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:825)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:783)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1338)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1320)
>   at 
> org.apache.ignite.stream.StreamTransformer.receive(StreamTransformer.java:45)
>   at 
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:137)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6631)
>   at 
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
>   at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:505)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException: null
>   at 
> 

[jira] [Comment Edited] (IGNITE-5978) [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1

[Vitaliy Biryukov (JIRA)]

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

Vitaliy Biryukov edited comment on IGNITE-5978 at 4/4/18 4:33 PM:
--

[~NIzhikov] please take a look.

Latch creates with "autoDel=true", and there was a race between last 

"latch.countDown()" and resiving latch in threads.


was (Author: vitaliyb):
[~NIzhikov] please take a look.

> [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1
> -
>
> Key: IGNITE-5978
> URL: https://issues.apache.org/jira/browse/IGNITE-5978
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=759891=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId677264269171099154.



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

[jira] [Updated] (IGNITE-8133) Baseline topology documentation improvement

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-8133:

Fix Version/s: 2.5

> Baseline topology documentation improvement
> ---
>
> Key: IGNITE-8133
> URL: https://issues.apache.org/jira/browse/IGNITE-8133
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
> Ignite cluster behavior when persistence is enabled (first of all, activation 
> and rebalancing timings).
> It seems that the current documentation may be confusing.
> For example, the sentence
> {quote}Note that the baseline topology is not set when the cluster is started 
> for the first time; that's the only time when a manual intervention is 
> needed.{quote}
> may lead one to thinking that baseline topology is not used by default and 
> needs to be enabled only if one wants to use it.
> Also, the documentation describes the tools and commands that are used to 
> manage the baseline topology and activation, but doesn't give guidelines on 
> which nodes should be in the topology, when should it be changed, etc.
> The documentation should be enhanced to
> - give clear understanding that baseline topology always needs to be 
> considered as a part of the cluster architecture when persistence is enabled;
> - provide overview of the behavioral changes compared to AI 2.3 (use a 
> note/warning block for that to separate it from the main text?);
> - provide basic guidelines and suggestions of how one can start a new cluster 
> and manage it (when to activate/deactivate, when to change baseline topology, 
> what happens and what needs to be done when a node fails or joins, how to use 
> consistentId)



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

[jira] [Updated] (IGNITE-8133) Baseline topology documentation improvement

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-8133:

Priority: Critical  (was: Major)

> Baseline topology documentation improvement
> ---
>
> Key: IGNITE-8133
> URL: https://issues.apache.org/jira/browse/IGNITE-8133
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Critical
> Fix For: 2.5
>
>
> Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
> Ignite cluster behavior when persistence is enabled (first of all, activation 
> and rebalancing timings).
> It seems that the current documentation may be confusing.
> For example, the sentence
> {quote}Note that the baseline topology is not set when the cluster is started 
> for the first time; that's the only time when a manual intervention is 
> needed.{quote}
> may lead one to thinking that baseline topology is not used by default and 
> needs to be enabled only if one wants to use it.
> Also, the documentation describes the tools and commands that are used to 
> manage the baseline topology and activation, but doesn't give guidelines on 
> which nodes should be in the topology, when should it be changed, etc.
> The documentation should be enhanced to
> - give clear understanding that baseline topology always needs to be 
> considered as a part of the cluster architecture when persistence is enabled;
> - provide overview of the behavioral changes compared to AI 2.3 (use a 
> note/warning block for that to separate it from the main text?);
> - provide basic guidelines and suggestions of how one can start a new cluster 
> and manage it (when to activate/deactivate, when to change baseline topology, 
> what happens and what needs to be done when a node fails or joins, how to use 
> consistentId)



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

[jira] [Updated] (IGNITE-8133) Baseline topology documentation improvement

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-8133:

Issue Type: Improvement  (was: Bug)

> Baseline topology documentation improvement
> ---
>
> Key: IGNITE-8133
> URL: https://issues.apache.org/jira/browse/IGNITE-8133
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
> Ignite cluster behavior when persistence is enabled (first of all, activation 
> and rebalancing timings).
> It seems that the current documentation may be confusing.
> For example, the sentence
> {quote}Note that the baseline topology is not set when the cluster is started 
> for the first time; that's the only time when a manual intervention is 
> needed.{quote}
> may lead one to thinking that baseline topology is not used by default and 
> needs to be enabled only if one wants to use it.
> Also, the documentation describes the tools and commands that are used to 
> manage the baseline topology and activation, but doesn't give guidelines on 
> which nodes should be in the topology, when should it be changed, etc.
> The documentation should be enhanced to
> - give clear understanding that baseline topology always needs to be 
> considered as a part of the cluster architecture when persistence is enabled;
> - provide overview of the behavioral changes compared to AI 2.3 (use a 
> note/warning block for that to separate it from the main text?);
> - provide basic guidelines and suggestions of how one can start a new cluster 
> and manage it (when to activate/deactivate, when to change baseline topology, 
> what happens and what needs to be done when a node fails or joins, how to use 
> consistentId)



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

[jira] [Created] (IGNITE-8136) Discovery service wrong works if node stopping by segmentation and hangs

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-8136:
-

 Summary: Discovery service wrong works if node stopping by 
segmentation and hangs
 Key: IGNITE-8136
 URL: https://issues.apache.org/jira/browse/IGNITE-8136
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov






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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-7940 at 4/4/18 4:21 PM:
--

Lets refactor Collection to List in task arg and result.

Also, what a strange import "import static 
com.sun.corba.se.impl.util.RepositoryId.cache;" in 

VisorCacheLostPartitionsTask?


was (Author: kuaw26):
Lets refactor Collection to List in task arg and result.

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



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

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-7940:


Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

Lets refactor Collection to List in task arg and result.

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



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

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

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-7691:
-

Run All - 
https://ci.ignite.apache.org/viewQueued.html?itemId=1179009=queuedBuildOverviewTab

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



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

[jira] [Commented] (IGNITE-6892) OOM should be covered by failure handling

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6892:


GitHub user alex-plekhanov opened a pull request:

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

IGNITE-6892 OOM should be covered by failure handler



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

$ git pull https://github.com/alex-plekhanov/ignite ignite-6892

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

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


commit e48e8978298995821aa19f8229692ba398ff4bde
Author: Aleksey Plekhanov 
Date:   2018-04-04T13:45:32Z

IGNITE-6892 OOM should be covered by failure handling

commit 2d60b0a760ff88589fe373eba7ebf03ffaeefe1e
Author: Aleksey Plekhanov 
Date:   2018-04-04T15:56:08Z

IGNITE-6892 OOM should be covered by failure handling (unit test)

commit f9af47c175aa78ca6f48b652fe1d76a94d019cb6
Author: Aleksey Plekhanov 
Date:   2018-04-04T16:12:10Z

IGNITE-6892 OOM should be covered by failure handling (typo)




> OOM should be covered by failure handling
> -
>
> Key: IGNITE-6892
> URL: https://issues.apache.org/jira/browse/IGNITE-6892
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> {{java.lang.OutOfMemoryError}} should be handled accordingly to provided 
> failure handle. 
> There are at least 3 types of places where OOM can be catched:
> 1. Crtitical workers that listed in IEP-14. In this case we just handle 
> failures as {{CRITICAL _WORKER_TERMINATED}}.
> 2. We should consider uncaught or default exception handlers for other 
> treads: threads of system, public, etc. thread pools, all threads that are 
> instances of {{IgniteThread}}. 
> Some memory should be reserved at node start to increase chances of OOM 
> handling.



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

[jira] [Assigned] (IGNITE-8008) Web console: Add a link to the SQL documentation in Notebook title

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-8008:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Merged to master.

> Web console: Add a link to the SQL documentation in Notebook title
> --
>
> Key: IGNITE-8008
> URL: https://issues.apache.org/jira/browse/IGNITE-8008
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
> Fix For: 2.5
>
> Attachments: screenshot-1.png
>
>
> Add a link to the documentation in Notebook title
> https://apacheignite-sql.readme.io/docs/sql-reference-overview
>  !screenshot-1.png! 



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7691:


[~tledkov-gridgain], could you please review SQL part?

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



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

[jira] [Comment Edited] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange

[Andrey Gura (JIRA)]

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

Andrey Gura edited comment on IGNITE-6827 at 4/4/18 3:46 PM:
-

This question is discussing on dev list. At least one more reviewer has the 
same question. Please join to discussion on dev list.

Once again, transactions don't make any decisions on this timeout, only PME 
takes this timeout into account. So it isn't transaction configuration.


was (Author: agura):
This question is discussing on dev list. At least one more reviewer has the 
same question. Please join to discussion on dev list.

> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.5
>
>
> Currently long running / buggy user transactions force partition exchange 
> block on waiting for 
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext#partitionReleaseFuture,
>  preventing all grid progress.
> I suggest introducing new global flag in TransactionConfiguration, like 
> {{txRollbackTimeoutOnTopologyChange}}
> which will rollback exchange blocking transaction after the timeout.
> Still need to think what to do with other topology locking activities.



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

[jira] [Commented] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-6827:
-

This question is discussing on dev list. At least one more reviewer has the 
same question. Please join to discussion on dev list.

> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.5
>
>
> Currently long running / buggy user transactions force partition exchange 
> block on waiting for 
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext#partitionReleaseFuture,
>  preventing all grid progress.
> I suggest introducing new global flag in TransactionConfiguration, like 
> {{txRollbackTimeoutOnTopologyChange}}
> which will rollback exchange blocking transaction after the timeout.
> Still need to think what to do with other topology locking activities.



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

[jira] [Assigned] (IGNITE-7441) Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita reassigned IGNITE-7441:
---

Assignee: Amelchev Nikita

> Drop IGNITE_SERVICES_COMPATIBILITY_MODE system property
> ---
>
> Key: IGNITE-7441
> URL: https://issues.apache.org/jira/browse/IGNITE-7441
> Project: Ignite
>  Issue Type: Task
>Reporter: Denis Mekhanikov
>Assignee: Amelchev Nikita
>Priority: Minor
>
> IGNITE_SERVICES_COMPATIBILITY_MODE system property was introduced to 
> configure backward compatibility mode for service configuration classes. But 
> since it was done in 1.9 and current version is completely incompatible with 
> it, there is no point in keeping this property. 
> Moreover, it is ignored after IGNITE-5145.



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

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

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-7691:


I've checked the tests, most of failures are common with master, but there is  
3 suspicious:

   ClientTestSuite: FunctionalTest.testCacheConfiguration (master fail rate 
0,0%) 
   ClientTestSuite: IgniteBinaryQueryTest.testBinaryQueries (master fail rate 
0,0%) 
   ClientTestSuite: ReliabilityTest.testFailover (master fail rate 0,0%)  

[~NIzhikov], could you please check? Simplest workaround is merge master into 
branch and re-run, probably these tests were already fixed.

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



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

[jira] [Commented] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5823:


Triggered CI https://ci.ignite.apache.org/viewQueued.html?itemId=1178819


> Need to remove CacheAtomicUpdateTimeoutException
> 
>
> Key: IGNITE-5823
> URL: https://issues.apache.org/jira/browse/IGNITE-5823
> Project: Ignite
>  Issue Type: Task
>Reporter: Yakov Zhdanov
>Assignee: Sergey Dorozhkin
>Priority: Minor
>  Labels: newbie
>
> And releated - CacheAtomicUpdateTimeoutCheckedException
> These exceptions are not used any more and can be removed.



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

[jira] [Commented] (IGNITE-5046) TcpDiscoverySpi.toString() method miss some fields.

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-5046:


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

> TcpDiscoverySpi.toString() method miss some fields.
> ---
>
> Key: IGNITE-5046
> URL: https://issues.apache.org/jira/browse/IGNITE-5046
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Affects Versions: 1.9
>Reporter: Andrew Mashenkov
>Assignee: neeraj
>Priority: Minor
>  Labels: newbie
>
> We have a number of protected fields that is missed by toString method.
> Looks like we should annotate these fields with @GridToStringInclude.
> locAddr, locPort, locPortRange, netTimeout and others.



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7796:


Github user zaleslaw closed the pull request at:

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


> Adopt kNN classification example to the new datasets
> 
>
> Key: IGNITE-7796
> URL: https://issues.apache.org/jira/browse/IGNITE-7796
> Project: Ignite
>  Issue Type: Sub-task
>  Components: ml
>Reporter: Aleksey Zinoviev
>Assignee: Aleksey Zinoviev
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-8054) Let serialize only valuable part of GridLongList

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-8054:


GitHub user SharplEr opened a pull request:

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

serialize only valuable part of GridLongList

For https://issues.apache.org/jira/browse/IGNITE-8054

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

$ git pull https://github.com/SharplEr/ignite ignite-8054

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

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


commit 0f98ce3336aae2380826b4bbaa8c11aaf4fecd30
Author: Alexander Menshikov 
Date:   2018-04-04T15:09:20Z

serialize only valuable part of GridLongList




> Let serialize only valuable part of GridLongList
> 
>
> Key: IGNITE-8054
> URL: https://issues.apache.org/jira/browse/IGNITE-8054
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 2.4
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
> Fix For: 2.5
>
>
> Here in GridLongList we serialize all elements and don't take into account 
> `idx` value:
> {code:java}
> @Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 
>     writer.setBuffer(buf); 
>   
>     if (!writer.isHeaderWritten()) { 
>     if (!writer.writeHeader(directType(), fieldsCount())) 
>     return false; 
>   
>     writer.onHeaderWritten(); 
>     } 
>   
>     switch (writer.state()) { 
>     case 0: 
>     if (!writer.writeLongArray("arr", arr)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     case 1: 
>     if (!writer.writeInt("idx", idx)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     } 
>   
>     return true; 
>     } {code}
> Which is not happening in another serialization method in the same class:
> {code:java}
> public static void writeTo(DataOutput out, @Nullable GridLongList list) 
> throws IOException { 
>     out.writeInt(list != null ? list.idx : -1); 
>   
>     if (list != null) { 
>     for (int i = 0; i < list.idx; i++) 
>     out.writeLong(list.arr[i]); 
>     } 
> } {code}
> So, we can simply reduce messages size by sending only a valuable part of the 
> array.
> I created this issue according to a discussion on the mailing list:
> [http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html]



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

[jira] [Updated] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Stanislav Lukyanov (JIRA)]

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

Stanislav Lukyanov updated IGNITE-8134:
---
Description: 
If a node is not a part of the baseline topology, the services will never be 
deployed on it. In particular, if that node calls a synchronous deploy* method, 
the method will hang.
 After the node is added to the baseline, all previously initiated deployments 
succeed (and deploy* methods return).

It seems that the issue is with the continuous query started by the 
GridServiceProcessor on the ignite-sys-cache.

Example:
 =
{code}
public class BltServicesBug {
public static void main(String[] args) {
// start one node
IgniteConfiguration cfg1 = new IgniteConfiguration()
.setIgniteInstanceName("node1")
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)
)
);
try (Ignite ignite1 = Ignition.start(cfg1)) {
// activate and set baseline topology
ignite1.cluster().active(true);

// start another node
IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
.setIgniteInstanceName("node2");
try (Ignite ignite2 = Ignition.start(cfg2)) { 
// try to deploy a service; 
// this call hangs until the second node is added to the BLT 
(e.g. externally via control.sh) 
ignite2.services().deployNodeSingleton("myService", new 
MyServiceImpl()); System.out.println("> Deployed"); }

}

}

private static class MyServiceImpl implements Service {
@Override public void cancel(ServiceContext ctx) { }
@Override public void init(ServiceContext ctx) { }
@Override public void execute(ServiceContext ctx) { }
}
}
}
{code}
 =

  was:
If a node is not a part of the baseline topology, the services will never be 
deployed on it. In particular, if that node calls a synchronous deploy* method, 
the method will hang.
 After the node is added to the baseline, all previously initiated deployments 
succeed (and deploy* methods return).

It seems that the issue is with the continuous query started by the 
GridServiceProcessor on the ignite-sys-cache.

Example:
 =
{code:java}
public class BltServicesBug {
public static void main(String[] args) {
// start one node
IgniteConfiguration cfg1 = new IgniteConfiguration()
.setIgniteInstanceName("node1")
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)
)
);
try (Ignite ignite1 = Ignition.start(cfg1)) {
// activate and set baseline topology
ignite1.cluster().active(true);
// start another node
IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
.setIgniteInstanceName("node2");
try (Ignite ignite2 = Ignition.start(cfg2))
{ // try to deploy a service; // this call hangs until the second node is added 
to the BLT (e.g. externally via control.sh) 
ignite2.services().deployNodeSingleton("myService", new MyServiceImpl()); 
System.out.println("> Deployed"); }
}
}
private static class MyServiceImpl implements Service {
@Override public void cancel(ServiceContext ctx) { }
@Override public void init(ServiceContext ctx) { }
@Override public void execute(ServiceContext ctx) { }
}
}{code}




=


> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services, persistence
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> If a node is not a part of the baseline topology, the services will never be 
> deployed on it. In particular, if that node calls a synchronous deploy* 
> method, the method will hang.
>  After the node is added to the baseline, all previously initiated 
> deployments succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the 
> GridServiceProcessor on the ignite-sys-cache.
> Example:
>  =
> {code}
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new 

[jira] [Assigned] (IGNITE-8054) Let serialize only valuable part of GridLongList

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-8054:
---

Assignee: Alexander Menshikov

> Let serialize only valuable part of GridLongList
> 
>
> Key: IGNITE-8054
> URL: https://issues.apache.org/jira/browse/IGNITE-8054
> Project: Ignite
>  Issue Type: Improvement
>  Components: messaging
>Affects Versions: 2.4
>Reporter: Alexander Menshikov
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
> Fix For: 2.5
>
>
> Here in GridLongList we serialize all elements and don't take into account 
> `idx` value:
> {code:java}
> @Override public boolean writeTo(ByteBuffer buf, MessageWriter writer) { 
>     writer.setBuffer(buf); 
>   
>     if (!writer.isHeaderWritten()) { 
>     if (!writer.writeHeader(directType(), fieldsCount())) 
>     return false; 
>   
>     writer.onHeaderWritten(); 
>     } 
>   
>     switch (writer.state()) { 
>     case 0: 
>     if (!writer.writeLongArray("arr", arr)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     case 1: 
>     if (!writer.writeInt("idx", idx)) 
>     return false; 
>   
>     writer.incrementState(); 
>   
>     } 
>   
>     return true; 
>     } {code}
> Which is not happening in another serialization method in the same class:
> {code:java}
> public static void writeTo(DataOutput out, @Nullable GridLongList list) 
> throws IOException { 
>     out.writeInt(list != null ? list.idx : -1); 
>   
>     if (list != null) { 
>     for (int i = 0; i < list.idx; i++) 
>     out.writeLong(list.arr[i]); 
>     } 
> } {code}
> So, we can simply reduce messages size by sending only a valuable part of the 
> array.
> I created this issue according to a discussion on the mailing list:
> [http://apache-ignite-developers.2346864.n4.nabble.com/Optimize-GridLongList-serialization-td28571.html]



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

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

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov commented on IGNITE-7772:
--

The way of critical failures handling I proposed is not perfect. Reworking now.

> All critical system workers health should be covered by IgniteFailureProcessor
> --
>
> Key: IGNITE-7772
> URL: https://issues.apache.org/jira/browse/IGNITE-7772
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Andrey Kuznetsov
>Priority: Major
>  Labels: iep-14
> Fix For: 2.5
>
>
> All critical workers listed in "IEP-14: Ignite failures handling" 
> (https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling).



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

[jira] [Updated] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-8134:
--
Description: 
If a node is not a part of the baseline topology, the services will never be 
deployed on it. In particular, if that node calls a synchronous deploy* method, 
the method will hang.
 After the node is added to the baseline, all previously initiated deployments 
succeed (and deploy* methods return).

It seems that the issue is with the continuous query started by the 
GridServiceProcessor on the ignite-sys-cache.

Example:
 =
{code:java}
public class BltServicesBug {
public static void main(String[] args) {
// start one node
IgniteConfiguration cfg1 = new IgniteConfiguration()
.setIgniteInstanceName("node1")
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)
)
);
try (Ignite ignite1 = Ignition.start(cfg1)) {
// activate and set baseline topology
ignite1.cluster().active(true);
// start another node
IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
.setIgniteInstanceName("node2");
try (Ignite ignite2 = Ignition.start(cfg2))
{ // try to deploy a service; // this call hangs until the second node is added 
to the BLT (e.g. externally via control.sh) 
ignite2.services().deployNodeSingleton("myService", new MyServiceImpl()); 
System.out.println("> Deployed"); }
}
}
private static class MyServiceImpl implements Service {
@Override public void cancel(ServiceContext ctx) { }
@Override public void init(ServiceContext ctx) { }
@Override public void execute(ServiceContext ctx) { }
}
}{code}




=

  was:
If a node is not a part of the baseline topology, the services will never be 
deployed on it. In particular, if that node calls a synchronous deploy* method, 
the method will hang.
After the node is added to the baseline, all previously initiated deployments 
succeed (and deploy* methods return).

It seems that the issue is with the continuous query started by the 
GridServiceProcessor on the ignite-sys-cache.

Example:
=
public class BltServicesBug {
public static void main(String[] args) {
// start one node
IgniteConfiguration cfg1 = new IgniteConfiguration()
.setIgniteInstanceName("node1")
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)
)
);
try (Ignite ignite1 = Ignition.start(cfg1)) {

// activate and set baseline topology
ignite1.cluster().active(true);

// start another node
IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
.setIgniteInstanceName("node2");
try (Ignite ignite2 = Ignition.start(cfg2)) {
// try to deploy a service;
// this call hangs until the second node is added to the BLT 
(e.g. externally via control.sh)
ignite2.services().deployNodeSingleton("myService", new 
MyServiceImpl());

System.out.println("> Deployed");
}
}

}

private static class MyServiceImpl implements Service {
@Override public void cancel(ServiceContext ctx) { }
@Override public void init(ServiceContext ctx) { }
@Override public void execute(ServiceContext ctx) { }
}
}
=


> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services, persistence
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> If a node is not a part of the baseline topology, the services will never be 
> deployed on it. In particular, if that node calls a synchronous deploy* 
> method, the method will hang.
>  After the node is added to the baseline, all previously initiated 
> deployments succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the 
> GridServiceProcessor on the ignite-sys-cache.
> Example:
>  =
> {code:java}
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new 

[jira] [Updated] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan updated IGNITE-8134:
--
Fix Version/s: 2.5

> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services, persistence
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> If a node is not a part of the baseline topology, the services will never be 
> deployed on it. In particular, if that node calls a synchronous deploy* 
> method, the method will hang.
> After the node is added to the baseline, all previously initiated deployments 
> succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the 
> GridServiceProcessor on the ignite-sys-cache.
> Example:
> =
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)
> )
> );
> try (Ignite ignite1 = Ignition.start(cfg1)) {
> // activate and set baseline topology
> ignite1.cluster().active(true);
> // start another node
> IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
> .setIgniteInstanceName("node2");
> try (Ignite ignite2 = Ignition.start(cfg2)) {
> // try to deploy a service;
> // this call hangs until the second node is added to the BLT 
> (e.g. externally via control.sh)
> ignite2.services().deployNodeSingleton("myService", new 
> MyServiceImpl());
> System.out.println("> Deployed");
> }
> }
> }
> private static class MyServiceImpl implements Service {
> @Override public void cancel(ServiceContext ctx) { }
> @Override public void init(ServiceContext ctx) { }
> @Override public void execute(ServiceContext ctx) { }
> }
> }
> =



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

[jira] [Commented] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Dmitriy Setrakyan (JIRA)]

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

Dmitriy Setrakyan commented on IGNITE-8134:
---

Service deployment should not depend on baseline at all and services should be 
deployed once the cluster is activated.

> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
>  Issue Type: Bug
>  Components: managed services, persistence
>Reporter: Stanislav Lukyanov
>Assignee: Stanislav Lukyanov
>Priority: Major
> Fix For: 2.5
>
>
> If a node is not a part of the baseline topology, the services will never be 
> deployed on it. In particular, if that node calls a synchronous deploy* 
> method, the method will hang.
> After the node is added to the baseline, all previously initiated deployments 
> succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the 
> GridServiceProcessor on the ignite-sys-cache.
> Example:
> =
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)
> )
> );
> try (Ignite ignite1 = Ignition.start(cfg1)) {
> // activate and set baseline topology
> ignite1.cluster().active(true);
> // start another node
> IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
> .setIgniteInstanceName("node2");
> try (Ignite ignite2 = Ignition.start(cfg2)) {
> // try to deploy a service;
> // this call hangs until the second node is added to the BLT 
> (e.g. externally via control.sh)
> ignite2.services().deployNodeSingleton("myService", new 
> MyServiceImpl());
> System.out.println("> Deployed");
> }
> }
> }
> private static class MyServiceImpl implements Service {
> @Override public void cancel(ServiceContext ctx) { }
> @Override public void init(ServiceContext ctx) { }
> @Override public void execute(ServiceContext ctx) { }
> }
> }
> =



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

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

[Andrey Gura (JIRA)]

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

Andrey Gura commented on IGNITE-7912:
-

[~ivandasch] Please, take a look at review in Upsource. Could you please also 
check all your change for code style, empty/redundant lines and spaces, 
javadocs, etc.

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



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

[jira] [Assigned] (IGNITE-7692) affinityCall and affinityRun may execute code on backup partitions

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov reassigned IGNITE-7692:
---

Assignee: Sergey Chugunov

> affinityCall and affinityRun may execute code on backup partitions
> --
>
> Key: IGNITE-7692
> URL: https://issues.apache.org/jira/browse/IGNITE-7692
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.1
>Reporter: Alexey Goncharuk
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, usability
> Fix For: 2.5
>
>
> Apparently, the affinityCall and affinityRun methods reserve partitions and 
> check their state to be OWNING, however, if topology changes and partition 
> role is changed to backup from primary, the code is still executed.
> This can be an issue if a user executes a local SQL query inside the 
> affinityCall runnable. In this case, the query result may return null.
> This can be observed in the 
> IgniteCacheLockPartitionOnAffinityRunTest#getPersonsCountSingleCache - note 
> an additional check I've added to make the test pass.
> I think it is ok to have an old semantics for the API, because in some cases 
> (scan query, local gets) a backup OWNER is enough. However, it looks like we 
> need to add another API method to enforce that affinity run be executed on 
> primary nodes and forbid primary role change.
> Another option is to detect a topology version of the affinity run and use 
> that version for local SQL queries.



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

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-7743:
-

I thing left to do is set correct jdbc fail code in thin driver

> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Commented] (IGNITE-5504) Failures in GridTcpCommunicationSpiRecoverySelfTest

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-5504:


Github user asfgit closed the pull request at:

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


> Failures in GridTcpCommunicationSpiRecoverySelfTest
> ---
>
> Key: IGNITE-5504
> URL: https://issues.apache.org/jira/browse/IGNITE-5504
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vladimir Ozerov
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test, test-fail
> Fix For: 2.5
>
>
> Reproducible only on TeamCity.
> Affected tests:
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1}}
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead2}}
> {{GridTcpCommunicationSpiRecoverySelfTest.testBlockRead3}}
> Root cause:
> {code}
> [2017-06-14 18:16:30,016][ERROR][main][root] Test failed.
> junit.framework.AssertionFailedError: Failed to wait for session close
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.communication.tcp.GridTcpCommunicationSpiRecoverySelfTest.testBlockRead1(GridTcpCommunicationSpiRecoverySelfTest.java:333)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1992)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:131)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1907)
> at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Commented] (IGNITE-7743) JDBC driver allows to connect to non existent schema

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-7743:
-

2 updated javadoc
3 moved copy-paste to separated method
4 added javadoc where it make sense
5 if we are able to push changes to 2.5.0 I'll use it.


> JDBC driver allows to connect to non existent schema
> 
>
> Key: IGNITE-7743
> URL: https://issues.apache.org/jira/browse/IGNITE-7743
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Pavel Kuznetsov
>Priority: Major
>  Labels: usability
> Fix For: 2.5
>
>
> Currently, if one creates a cache without DDL (via {{QueryEntity}} or 
> {{indexedTypes}}), separate schema for this cache is created. Schema name is 
> case sensitive, so to connect to it with JDBC driver, it's required to 
> provide the name in quotes. Here is how it looks like in SqlLine:
> {noformat}
> ./bin/sqlline.sh -u jdbc:ignite:thin://127.0.0.1/\"CacheQueryExamplePersons\"
> {noformat}
> However, if name is provided without quotes, driver still connects, but then 
> fails with a very unclear exception when a query is executed:
> {noformat}
> ./bin/sqlline.sh -u 
> jdbc:ignite:thin://127.0.0.1/CacheQueryExamplePersons{noformat}
> This is a huge usability issue. We should disallow connections to schema that 
> does not exist, throw exception in this case. Exception should provide proper 
> explanation how to connect properly.



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

[jira] [Commented] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange

[Alexei Scherbakov (JIRA)]

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

Alexei Scherbakov commented on IGNITE-6827:
---

[~agura],

I don't agree what rollbackOnTopologyChangeTimeout  is not a part of 
transactional configuration.

This property is clearly part of transaction configuration, because it defines 
when a rollback happens.

Moreover, ordinary user doesn't know what is "exchange" at all.

Nevertheless, it's clear for me what I have to add better description to this 
parameter.

> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.5
>
>
> Currently long running / buggy user transactions force partition exchange 
> block on waiting for 
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext#partitionReleaseFuture,
>  preventing all grid progress.
> I suggest introducing new global flag in TransactionConfiguration, like 
> {{txRollbackTimeoutOnTopologyChange}}
> which will rollback exchange blocking transaction after the timeout.
> Still need to think what to do with other topology locking activities.



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

[jira] [Updated] (IGNITE-1776) [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails sometimes

[Dmitriy Pavlov (JIRA)]

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

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

> [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails 
> sometimes
> ---
>
> Key: IGNITE-1776
> URL: https://issues.apache.org/jira/browse/IGNITE-1776
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.5
>
>
> TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails on TC 
> sometimes.
> Looks like a test bug, need just increase awaitTime(). I see Node FAILED 
> message exactly after 10 seconds. But it's strange that it's require too long 
> time. May be something wrong on agent.
> Logs:
> {noformat}
> junit.framework.AssertionFailedError: Latch count: 1
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.await(TcpClientDiscoverySpiSelfTest.java:2030)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer(TcpClientDiscoverySpiSelfTest.java:811)
> --- Stdout: ---
> [03:18:46,228][INFO ][main][root] >>> Starting test: 
> testClientNodeFailOneServer <<<
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> >>>__    
> >>>   /  _/ ___/ |/ /  _/_  __/ __/  
> >>>  _/ // (7 7// /  / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/   
> >>> 
> >>> ver. 1.5.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2015 Copyright(C) Apache Software Foundation
> >>> 
> >>> Ignite documentation: http://ignite.apache.org
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Config URL: n/a
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Daemon mode: off
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS: Mac OS X 10.7.5 
> x86_64
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS user: teamcity
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Language runtime: 
> Java Platform API Specification ver. 1.7
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM information: 
> Java(TM) SE Runtime Environment 1.7.0_67-b01 Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 24.65-b04
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM total memory: 
> 2.7GB
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Remote Management 
> [restart: off, REST: off, JMX (remote: off)]
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> IGNITE_HOME=/Users/teamcity/buildAgent/work/871ff4a46e450b13
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM arguments: 
> [-DJAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home, 
> -DMCAST_GRP=229.116.1.2, -Dagent.home.dir=/Users/teamcity/buildAgent, 
> -Dagent.name=ip_192.168.1.116, -Dagent.ownPort=9090, 
> -Dagent.work.dir=/Users/teamcity/buildAgent/work, -Dbuild.number=3345, 
> -Dbuild.vcs.number=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> -Dbuild.vcs.number.1=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> -Dbuild.vcs.number.ApacheIgniteMirrorOnGitHub=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb,
>  
> -Dclassworlds.conf=/Users/teamcity/buildAgent/temp/buildTmp/teamcity.m2.conf, 
> -Dcom.jetbrains.maven.watcher.report.file=/Users/teamcity/buildAgent/temp/buildTmp/maven-build-info.xml,
>  -Djava.io.tmpdir=/Users/teamcity/buildAgent/temp/buildTmp, 
> -Dmaven.home=/Users/teamcity/buildAgent/tools/maven3, 
> -Dmaven.repo.local=/Users/teamcity/.m2/repository, 
> -Dteamcity.agent.cpuBenchmark=605, 
> -Dteamcity.agent.dotnet.agent_url=http://localhost:9090/RPC2, 
> -Dteamcity.agent.dotnet.build_id=555612, 
> -Dteamcity.auth.password=j1gKlVPBOa3H6Wnrjp3Q3sK7ZqR4biuf, 
> -Dteamcity.auth.userId=TeamCityBuildId=555612, 
> -Dteamcity.build.changedFiles.file=/Users/teamcity/buildAgent/temp/buildTmp/changedFiles5940678572218707636.txt,
>  
> -Dteamcity.build.checkoutDir=/Users/teamcity/buildAgent/work/871ff4a46e450b13,
>  -Dteamcity.build.id=555612, 
> -Dteamcity.build.properties.file=/Users/teamcity/buildAgent/temp/buildTmp/teamcity.build3844607694634646095.properties,
>  -Dteamcity.build.tempDir=/Users/teamcity/buildAgent/temp/buildTmp, 
> -Dteamcity.build.workingDir=/Users/teamcity/buildAgent/work/871ff4a46e450b13, 
> -Dteamcity.buildConfName=Ignite SPI, -Dteamcity.buildType.id=Ignite_Spi, 
> -Dteamcity.configuration.properties.file=/Users/teamcity/buildAgent/temp/buildTmp/teamcity.config8915518964213838573.properties,
>  

[jira] [Commented] (IGNITE-5978) [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-5978:


Looks good.

> [Test Failed] IgnitePartitionedCountDownLatchSelfTest.testLatchMultinode1
> -
>
> Key: IGNITE-5978
> URL: https://issues.apache.org/jira/browse/IGNITE-5978
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Vitaliy Biryukov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Fails locally.
> Example of failing - 
> http://ci.ignite.apache.org/viewLog.html?buildId=759891=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId677264269171099154.



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

[jira] [Updated] (IGNITE-8135) Missing SQL-DDL Authorization

[Alexey Kukushkin (JIRA)]

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

Alexey Kukushkin updated IGNITE-8135:
-
Description: 
Ignite has infrastructure to support 3-rd party security plugins. To support 
authorization, Ignite has security checks spread all over the code delegating 
actual authorization to a 3rd party security plugins if configured.

In addition to existing checks, Ignite 2.5 will authorise "create" and 
"destroy" cache operations.

The problem is authorization is not implemented for SQL at all - even if 
authorization is enabled, it is currently possible to run any SQL to 
create/drop/alter caches and read/modify/remove the cache data thus bypassing 
security. The problem exists for both DDL (create/drop/alter table) and DML 
(select/merge/insert/delete).

This ticket addresses DDL only: DML will be addressed by a different ticket.

The problem must be fixed for all clients: Ignite client and server nodes, Java 
and .NET thin clients, ODBC and JDBC, REST.

  was:
Ignite has infrastructure to support 3-rd party security plugins. To support 
authorization, Ignite has security checks spread all over the code delegating 
actual authorization to a 3rd party security plugins if configured.

In addition to existing checks, Ignite 2.5 will authorise "create" and 
"destroy" cache operations.

The problem is authorization is not implemented for SQL at all - even if 
authorization is enabled, it is currently possible to run any SQL to 
create/drop/alter caches and read/modify/remove the cache data thus bypassing 
security. The problem exists for both DDL (create/drop/alter table) and DML 
(select/merge/insert/delete).

This ticket addresses DDL only: DML will be addressed by a different ticket.

 


> Missing SQL-DDL Authorization
> -
>
> Key: IGNITE-8135
> URL: https://issues.apache.org/jira/browse/IGNITE-8135
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.5
>Reporter: Alexey Kukushkin
>Priority: Major
>
> Ignite has infrastructure to support 3-rd party security plugins. To support 
> authorization, Ignite has security checks spread all over the code delegating 
> actual authorization to a 3rd party security plugins if configured.
> In addition to existing checks, Ignite 2.5 will authorise "create" and 
> "destroy" cache operations.
> The problem is authorization is not implemented for SQL at all - even if 
> authorization is enabled, it is currently possible to run any SQL to 
> create/drop/alter caches and read/modify/remove the cache data thus bypassing 
> security. The problem exists for both DDL (create/drop/alter table) and DML 
> (select/merge/insert/delete).
> This ticket addresses DDL only: DML will be addressed by a different ticket.
> The problem must be fixed for all clients: Ignite client and server nodes, 
> Java and .NET thin clients, ODBC and JDBC, REST.



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

[jira] [Created] (IGNITE-8135) Missing SQL-DDL Authorization

[Alexey Kukushkin (JIRA)]

Alexey Kukushkin created IGNITE-8135:


 Summary: Missing SQL-DDL Authorization
 Key: IGNITE-8135
 URL: https://issues.apache.org/jira/browse/IGNITE-8135
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.5
Reporter: Alexey Kukushkin


Ignite has infrastructure to support 3-rd party security plugins. To support 
authorization, Ignite has security checks spread all over the code delegating 
actual authorization to a 3rd party security plugins if configured.

In addition to existing checks, Ignite 2.5 will authorise "create" and 
"destroy" cache operations.

The problem is authorization is not implemented for SQL at all - even if 
authorization is enabled, it is currently possible to run any SQL to 
create/drop/alter caches and read/modify/remove the cache data thus bypassing 
security. The problem exists for both DDL (create/drop/alter table) and DML 
(select/merge/insert/delete).

This ticket addresses DDL only: DML will be addressed by a different ticket.

 



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

[jira] [Assigned] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov reassigned IGNITE-7640:
---

Assignee: (was: Alexander Menshikov)

> Refactor DiscoveryDataClusterState to be immutable
> --
>
> Key: IGNITE-7640
> URL: https://issues.apache.org/jira/browse/IGNITE-7640
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7640:


Github user SharplEr closed the pull request at:

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


> Refactor DiscoveryDataClusterState to be immutable
> --
>
> Key: IGNITE-7640
> URL: https://issues.apache.org/jira/browse/IGNITE-7640
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexander Menshikov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7640) Refactor DiscoveryDataClusterState to be immutable

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-7640:
-

I'm sorry but I can't do this issue. After strict investigation of tests 
results, I still see failed tests with my PR. And I truly don't understand a 
reason.
I found two type of unclear using of DiscoveryDataClusterState.

*1. Concurrency using*
DiscoveryDataClusterState.transitionRes + 
GridClusterStateProcessor.transitionFuts are working together like a future: 
DiscoveryDataClusterState.transitionRes used for value passing and 
GridClusterStateProcessor.transitionFuts used as a latch.

*2. Serialization*
There is logic based on the fact some fields are `transient` and some other is 
not. It breaks some invariants which I think I see in code (object become 
partly initialized).


But some bugs still here, so maybe there is something else.

I think we should make clear using of DiscoveryDataClusterState before this 
issue became resolvable.

Or maybe someone else will be lucky.

> Refactor DiscoveryDataClusterState to be immutable
> --
>
> Key: IGNITE-7640
> URL: https://issues.apache.org/jira/browse/IGNITE-7640
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Alexander Menshikov
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Commented] (IGNITE-7999) Enhance performance of the thin JDBC streaming mode

[Taras Ledkov (JIRA)]

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

Taras Ledkov commented on IGNITE-7999:
--

Attached flame graph is gathered for streaming prototype without response (only 
one response is sent on the streaming mode off) and server threadpool size = 1. 

> Enhance performance of the thin JDBC streaming mode 
> 
>
> Key: IGNITE-7999
> URL: https://issues.apache.org/jira/browse/IGNITE-7999
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
> Attachments: flamegraph-30.svg
>
>
> Try to enhance thin JDBC performance for streaming mode.
> Waiting for server response takes a lot of time on streaming INSERT.
> Try to skip server response in special mode.



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

[jira] [Updated] (IGNITE-7999) Enhance performance of the thin JDBC streaming mode

[Taras Ledkov (JIRA)]

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

Taras Ledkov updated IGNITE-7999:
-
Attachment: flamegraph-30.svg

> Enhance performance of the thin JDBC streaming mode 
> 
>
> Key: IGNITE-7999
> URL: https://issues.apache.org/jira/browse/IGNITE-7999
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
> Attachments: flamegraph-30.svg
>
>
> Try to enhance thin JDBC performance for streaming mode.
> Waiting for server response takes a lot of time on streaming INSERT.
> Try to skip server response in special mode.



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

[jira] [Created] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8134:
--

 Summary: Services can't be deployed on servers outside of baseline 
topology
 Key: IGNITE-8134
 URL: https://issues.apache.org/jira/browse/IGNITE-8134
 Project: Ignite
  Issue Type: Bug
  Components: managed services, persistence
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


If a node is not a part of the baseline topology, the services will never be 
deployed on it. In particular, if that node calls a synchronous deploy* method, 
the method will hang.
After the node is added to the baseline, all previously initiated deployments 
succeed (and deploy* methods return).

It seems that the issue is with the continuous query started by the 
GridServiceProcessor on the ignite-sys-cache.

Example:
=
public class BltServicesBug {
public static void main(String[] args) {
// start one node
IgniteConfiguration cfg1 = new IgniteConfiguration()
.setIgniteInstanceName("node1")
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setDefaultDataRegionConfiguration(
new DataRegionConfiguration()
.setPersistenceEnabled(true)
)
);
try (Ignite ignite1 = Ignition.start(cfg1)) {

// activate and set baseline topology
ignite1.cluster().active(true);

// start another node
IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
.setIgniteInstanceName("node2");
try (Ignite ignite2 = Ignition.start(cfg2)) {
// try to deploy a service;
// this call hangs until the second node is added to the BLT 
(e.g. externally via control.sh)
ignite2.services().deployNodeSingleton("myService", new 
MyServiceImpl());

System.out.println("> Deployed");
}
}

}

private static class MyServiceImpl implements Service {
@Override public void cancel(ServiceContext ctx) { }
@Override public void init(ServiceContext ctx) { }
@Override public void execute(ServiceContext ctx) { }
}
}
=



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

[jira] [Commented] (IGNITE-6842) Stop all nodes after test by default.

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-6842:
-

[~Mmuzaf] Current changes looks good to me.

Let's make "Run all" one more time to be on a safe side and I will merge this 
PR to master.

> Stop all nodes after test by default.
> -
>
> Key: IGNITE-6842
> URL: https://issues.apache.org/jira/browse/IGNITE-6842
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Maxim Muzafarov
>Priority: Major
>  Labels: newbie
> Fix For: 2.5
>
> Attachments: IgniteStopGridsTestSuite.java, 
> StopGridsStateFirstTest.java, StopGridsStateSecondTest.java
>
>
> Currently it's required to manually call stopAllGrids() after test completion.
> This leads to errors in subsequent tests if someone forgets to call it and to 
> additional boilerplate code in tests.
> Right choice is to make this default behavior.



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

[jira] [Commented] (IGNITE-1776) [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails sometimes

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-1776:


Test is already unmuted, and probably we eventually need to remove 
inverstigation from TC.

> [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails 
> sometimes
> ---
>
> Key: IGNITE-1776
> URL: https://issues.apache.org/jira/browse/IGNITE-1776
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails on TC 
> sometimes.
> Looks like a test bug, need just increase awaitTime(). I see Node FAILED 
> message exactly after 10 seconds. But it's strange that it's require too long 
> time. May be something wrong on agent.
> Logs:
> {noformat}
> junit.framework.AssertionFailedError: Latch count: 1
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.await(TcpClientDiscoverySpiSelfTest.java:2030)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer(TcpClientDiscoverySpiSelfTest.java:811)
> --- Stdout: ---
> [03:18:46,228][INFO ][main][root] >>> Starting test: 
> testClientNodeFailOneServer <<<
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> >>>__    
> >>>   /  _/ ___/ |/ /  _/_  __/ __/  
> >>>  _/ // (7 7// /  / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/   
> >>> 
> >>> ver. 1.5.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2015 Copyright(C) Apache Software Foundation
> >>> 
> >>> Ignite documentation: http://ignite.apache.org
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Config URL: n/a
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Daemon mode: off
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS: Mac OS X 10.7.5 
> x86_64
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS user: teamcity
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Language runtime: 
> Java Platform API Specification ver. 1.7
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM information: 
> Java(TM) SE Runtime Environment 1.7.0_67-b01 Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 24.65-b04
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM total memory: 
> 2.7GB
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Remote Management 
> [restart: off, REST: off, JMX (remote: off)]
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> IGNITE_HOME=/Users/teamcity/buildAgent/work/871ff4a46e450b13
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM arguments: 
> [-DJAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home, 
> -DMCAST_GRP=229.116.1.2, -Dagent.home.dir=/Users/teamcity/buildAgent, 
> -Dagent.name=ip_192.168.1.116, -Dagent.ownPort=9090, 
> -Dagent.work.dir=/Users/teamcity/buildAgent/work, -Dbuild.number=3345, 
> -Dbuild.vcs.number=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> -Dbuild.vcs.number.1=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> -Dbuild.vcs.number.ApacheIgniteMirrorOnGitHub=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb,
>  
> -Dclassworlds.conf=/Users/teamcity/buildAgent/temp/buildTmp/teamcity.m2.conf, 
> -Dcom.jetbrains.maven.watcher.report.file=/Users/teamcity/buildAgent/temp/buildTmp/maven-build-info.xml,
>  -Djava.io.tmpdir=/Users/teamcity/buildAgent/temp/buildTmp, 
> -Dmaven.home=/Users/teamcity/buildAgent/tools/maven3, 
> -Dmaven.repo.local=/Users/teamcity/.m2/repository, 
> -Dteamcity.agent.cpuBenchmark=605, 
> -Dteamcity.agent.dotnet.agent_url=http://localhost:9090/RPC2, 
> -Dteamcity.agent.dotnet.build_id=555612, 
> -Dteamcity.auth.password=j1gKlVPBOa3H6Wnrjp3Q3sK7ZqR4biuf, 
> -Dteamcity.auth.userId=TeamCityBuildId=555612, 
> -Dteamcity.build.changedFiles.file=/Users/teamcity/buildAgent/temp/buildTmp/changedFiles5940678572218707636.txt,
>  
> -Dteamcity.build.checkoutDir=/Users/teamcity/buildAgent/work/871ff4a46e450b13,
>  -Dteamcity.build.id=555612, 
> -Dteamcity.build.properties.file=/Users/teamcity/buildAgent/temp/buildTmp/teamcity.build3844607694634646095.properties,
>  -Dteamcity.build.tempDir=/Users/teamcity/buildAgent/temp/buildTmp, 
> -Dteamcity.build.workingDir=/Users/teamcity/buildAgent/work/871ff4a46e450b13, 
> -Dteamcity.buildConfName=Ignite SPI, -Dteamcity.buildType.id=Ignite_Spi, 
> 

[jira] [Commented] (IGNITE-6565) Use long type for size and keySize in cache metrics

[Alexander Menshikov (JIRA)]

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

Alexander Menshikov commented on IGNITE-6565:
-

A lot of time has been passed after I created PR for the issue. The master 
dispersed with PR and start to use CacheMetricsImpl.EntriesStatMetrics class 
for storing size metrics. So I have to sync my PR with current master. Also, I  
decided don't implement `long` to `int` safe cast, because it's not what this 
issue about.

After I resolve all conflict and fix to fail tests, I will update issue status 
and link to CI.

> Use long type for size and keySize in cache metrics
> ---
>
> Key: IGNITE-6565
> URL: https://issues.apache.org/jira/browse/IGNITE-6565
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.2
>Reporter: Ilya Kasnacheev
>Assignee: Alexander Menshikov
>Priority: Major
>  Labels: easyfix
>
> Currently it's int so for large caches there's no way to convey correct value.
> Should introduce getSizeLong() and getKeySizeLong()
> Also introduce the same in .Net and make sure that compatibility not broken 
> when passing OP_LOCAL_METRICS and OP_GLOBAL_METRICS.
> BTW do we need keySize at all? What's it for?



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

[jira] [Commented] (IGNITE-1776) [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails sometimes

[Amelchev Nikita (JIRA)]

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

Amelchev Nikita commented on IGNITE-1776:
-

This bug is not reproduced, I propose to unmute this test.

awaitTime for discovery spi test was increased by Govorukhin in 
0e9fcb717584a76c45707d3b96afcd56b2a9fddc from 10_000 ms to 20_000 ms. In 
addition, average event waiting time was 9000 ms when the issue was created. 
1700 ms at now.

I tested locally over 3000 times, and on TC 500 times, [all runs are 
OK|https://ci.ignite.apache.org/viewLog.html?buildId=1175498=IgniteTests24Java8_IgniteSpi=testsInfo].

> [Test Failed] TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails 
> sometimes
> ---
>
> Key: IGNITE-1776
> URL: https://issues.apache.org/jira/browse/IGNITE-1776
> Project: Ignite
>  Issue Type: Test
>Reporter: Artem Shutak
>Assignee: Amelchev Nikita
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
>
> TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer fails on TC 
> sometimes.
> Looks like a test bug, need just increase awaitTime(). I see Node FAILED 
> message exactly after 10 seconds. But it's strange that it's require too long 
> time. May be something wrong on agent.
> Logs:
> {noformat}
> junit.framework.AssertionFailedError: Latch count: 1
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.await(TcpClientDiscoverySpiSelfTest.java:2030)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpClientDiscoverySpiSelfTest.testClientNodeFailOneServer(TcpClientDiscoverySpiSelfTest.java:811)
> --- Stdout: ---
> [03:18:46,228][INFO ][main][root] >>> Starting test: 
> testClientNodeFailOneServer <<<
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> >>>__    
> >>>   /  _/ ___/ |/ /  _/_  __/ __/  
> >>>  _/ // (7 7// /  / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/   
> >>> 
> >>> ver. 1.5.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2015 Copyright(C) Apache Software Foundation
> >>> 
> >>> Ignite documentation: http://ignite.apache.org
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Config URL: n/a
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Daemon mode: off
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS: Mac OS X 10.7.5 
> x86_64
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] OS user: teamcity
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Language runtime: 
> Java Platform API Specification ver. 1.7
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM information: 
> Java(TM) SE Runtime Environment 1.7.0_67-b01 Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 24.65-b04
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM total memory: 
> 2.7GB
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] Remote Management 
> [restart: off, REST: off, JMX (remote: off)]
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] 
> IGNITE_HOME=/Users/teamcity/buildAgent/work/871ff4a46e450b13
> [03:18:46,233][INFO ][test-runner][IgniteKernal%server-0] VM arguments: 
> [-DJAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home, 
> -DMCAST_GRP=229.116.1.2, -Dagent.home.dir=/Users/teamcity/buildAgent, 
> -Dagent.name=ip_192.168.1.116, -Dagent.ownPort=9090, 
> -Dagent.work.dir=/Users/teamcity/buildAgent/work, -Dbuild.number=3345, 
> -Dbuild.vcs.number=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> -Dbuild.vcs.number.1=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb, 
> -Dbuild.vcs.number.ApacheIgniteMirrorOnGitHub=91e31e99c2574f7cede8d80ec9b8d981ccc34bcb,
>  
> -Dclassworlds.conf=/Users/teamcity/buildAgent/temp/buildTmp/teamcity.m2.conf, 
> -Dcom.jetbrains.maven.watcher.report.file=/Users/teamcity/buildAgent/temp/buildTmp/maven-build-info.xml,
>  -Djava.io.tmpdir=/Users/teamcity/buildAgent/temp/buildTmp, 
> -Dmaven.home=/Users/teamcity/buildAgent/tools/maven3, 
> -Dmaven.repo.local=/Users/teamcity/.m2/repository, 
> -Dteamcity.agent.cpuBenchmark=605, 
> -Dteamcity.agent.dotnet.agent_url=http://localhost:9090/RPC2, 
> -Dteamcity.agent.dotnet.build_id=555612, 
> -Dteamcity.auth.password=j1gKlVPBOa3H6Wnrjp3Q3sK7ZqR4biuf, 
> -Dteamcity.auth.userId=TeamCityBuildId=555612, 
> -Dteamcity.build.changedFiles.file=/Users/teamcity/buildAgent/temp/buildTmp/changedFiles5940678572218707636.txt,
>  
> -Dteamcity.build.checkoutDir=/Users/teamcity/buildAgent/work/871ff4a46e450b13,
>  -Dteamcity.build.id=555612, 
> 

[jira] [Created] (IGNITE-8133) Baseline topology documentation improvement

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8133:
--

 Summary: Baseline topology documentation improvement
 Key: IGNITE-8133
 URL: https://issues.apache.org/jira/browse/IGNITE-8133
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.4
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


Baseline topology concept was added to Ignite in 2.4 by IEP-4. This changed 
Ignite cluster behavior when persistence is enabled (first of all, activation 
and rebalancing timings).
It seems that the current documentation may be confusing.

For example, the sentence
{quote}Note that the baseline topology is not set when the cluster is started 
for the first time; that's the only time when a manual intervention is 
needed.{quote}
may lead one to thinking that baseline topology is not used by default and 
needs to be enabled only if one wants to use it.

Also, the documentation describes the tools and commands that are used to 
manage the baseline topology and activation, but doesn't give guidelines on 
which nodes should be in the topology, when should it be changed, etc.

The documentation should be enhanced to
- give clear understanding that baseline topology always needs to be considered 
as a part of the cluster architecture when persistence is enabled;
- provide overview of the behavioral changes compared to AI 2.3 (use a 
note/warning block for that to separate it from the main text?);
- provide basic guidelines and suggestions of how one can start a new cluster 
and manage it (when to activate/deactivate, when to change baseline topology, 
what happens and what needs to be done when a node fails or joins, how to use 
consistentId)



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

[jira] [Updated] (IGNITE-7855) ODBC: Support streaming mode

[Igor Sapego (JIRA)]

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

Igor Sapego updated IGNITE-7855:

Summary: ODBC: Support streaming mode  (was: ODBC: Supoprt streaming mode)

> ODBC: Support streaming mode
> 
>
> Key: IGNITE-7855
> URL: https://issues.apache.org/jira/browse/IGNITE-7855
> Project: Ignite
>  Issue Type: Task
>  Components: odbc
>Reporter: Vladimir Ozerov
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.5
>
>
> We need to support streaming mode in the same way it is done for JDBC.



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

[jira] [Commented] (IGNITE-7809) Ignite PDS 2 & PDS 2 Direct IO: stable failures of IgniteWalFlushDefaultSelfTest

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-7809:
--

Ilya,

Can we finalize the patch that fixes the 4 original tests and create a separate 
ticket for Windows failures?

> Ignite PDS 2 & PDS 2 Direct IO: stable failures of 
> IgniteWalFlushDefaultSelfTest
> 
>
> Key: IGNITE-7809
> URL: https://issues.apache.org/jira/browse/IGNITE-7809
> Project: Ignite
>  Issue Type: Task
>  Components: persistence
>Affects Versions: 2.4
>Reporter: Dmitriy Pavlov
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> Probably after last WAL default changes 'IGNITE-7594 Fixed performance drop 
> after WAL optimization for FSYNC' 2 tests in 2 build configs began to fail
>Ignite PDS 2 (Direct IO) [ tests 2 ]  
>  IgnitePdsNativeIoTestSuite2: 
> IgniteWalFlushDefaultSelfTest.testFailAfterStart (fail rate 13,0%) 
>  IgnitePdsNativeIoTestSuite2: 
> IgniteWalFlushDefaultSelfTest.testFailWhileStart (fail rate 13,0%) 
>Ignite PDS 2 [ tests 2 ]  
>  IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailAfterStart 
> (fail rate 8,4%) 
>  IgnitePdsTestSuite2: IgniteWalFlushDefaultSelfTest.testFailWhileStart 
> (fail rate 8,4%) 



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

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

[Pavel Kuznetsov (JIRA)]

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

Pavel Kuznetsov commented on IGNITE-6807:
-

[~vozerov] , Could you please take a look at the patch and merge if it is ok?

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



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

[jira] [Commented] (IGNITE-8112) DirectIO artifact is not published in the maven repository

[Dmitriy Pavlov (JIRA)]

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

Dmitriy Pavlov commented on IGNITE-8112:


Merged to master

> DirectIO artifact is not published in the maven repository
> --
>
> Key: IGNITE-8112
> URL: https://issues.apache.org/jira/browse/IGNITE-8112
> Project: Ignite
>  Issue Type: Bug
>  Components: build
>Affects Versions: 2.4
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.5
>
>




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

[jira] [Updated] (IGNITE-8130) WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails sporadically in master

[Alexey Goncharuk (JIRA)]

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

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

> WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails 
> sporadically in master
> ---
>
> Key: IGNITE-8130
> URL: https://issues.apache.org/jira/browse/IGNITE-8130
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> The reason for random failures is a loop in finally block of forAllNodes() 
> which destroys caches. This leads to a race when cache destroy request is 
> asynchronously sent to other nodes and the cache created in test is destroyed 
> by the finally block.



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

[jira] [Resolved] (IGNITE-8130) WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails sporadically in master

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk resolved IGNITE-8130.
--
Resolution: Fixed

> WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails 
> sporadically in master
> ---
>
> Key: IGNITE-8130
> URL: https://issues.apache.org/jira/browse/IGNITE-8130
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> The reason for random failures is a loop in finally block of forAllNodes() 
> which destroys caches. This leads to a race when cache destroy request is 
> asynchronously sent to other nodes and the cache created in test is destroyed 
> by the finally block.



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

[jira] [Commented] (IGNITE-8130) WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails sporadically in master

[Alexey Goncharuk (JIRA)]

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

Alexey Goncharuk commented on IGNITE-8130:
--

Actually, destroy cache completes when local node finishes exchange. However, 
when we call getOrCreateCache on another node, the node may not have completed 
it's exchange yet, so getOrCreateCache is executed as if the cache is not 
destroyed yet, and results in a no-op.

Fixing this for now in the test.

> WalModeChangeCoordinatorNotAffinityNodeSelfTest#testLocalCache fails 
> sporadically in master
> ---
>
> Key: IGNITE-8130
> URL: https://issues.apache.org/jira/browse/IGNITE-8130
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
>
> The reason for random failures is a loop in finally block of forAllNodes() 
> which destroys caches. This leads to a race when cache destroy request is 
> asynchronously sent to other nodes and the cache created in test is destroyed 
> by the finally block.



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