[jira] [Commented] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

[Roman Kondakov (JIRA)]

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

Roman Kondakov commented on IGNITE-7044:


[~dmagda], [~pgarg], please review the documentation for the PARALLEL option in 
the CREATE INDEX command: 
https://dash.readme.io/project/apacheignite-sql/v2.3/docs/create-index_24_hidden

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7064) Web console: implement mechanism to manage E2E tests environment

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7064:
-
Summary: Web console: implement mechanism to manage E2E tests environment  
(was: Web console: implement mechanism to)

> Web console: implement mechanism to manage E2E tests environment
> 
>
> Key: IGNITE-7064
> URL: https://issues.apache.org/jira/browse/IGNITE-7064
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexander Kalinin
>Priority: Minor
>
> Most of E2E tests require complex DB/web-agent/Ignite cluster state 
> management. Let's implement tools to help with that, maybe something easy at 
> first, like DB state. Web console backend already has a similar mechanism we 
> can reuse.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7064) Web console: implement mechanism to

[Ilya Borisov (JIRA)]

Ilya Borisov created IGNITE-7064:


 Summary: Web console: implement mechanism to
 Key: IGNITE-7064
 URL: https://issues.apache.org/jira/browse/IGNITE-7064
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Alexander Kalinin
Priority: Minor


Most of E2E tests require complex DB/web-agent/Ignite cluster state management. 
Let's implement tools to help with that, maybe something easy at first, like DB 
state. Web console backend already has a similar mechanism we can reuse.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin commented on IGNITE-4398:
---

[~anovikov] Moved header cache stuff to upper level

> Web console: incorrect authentication under IE 11 (windows 10)
> --
>
> Key: IGNITE-4398
> URL: https://issues.apache.org/jira/browse/IGNITE-4398
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> To reproduce:
> 1) log in as User1
> 2) create some cluster and save
> 3) log out
> 4) log in as User2
> You will see the cluster from User1.
> Note: IE specific only



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7043) Incorrect method name suggested when page eviction starts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7043:


Github user asfgit closed the pull request at:

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


> Incorrect method name suggested when page eviction starts
> -
>
> Key: IGNITE-7043
> URL: https://issues.apache.org/jira/browse/IGNITE-7043
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Trivial
>
> Reported via gitter:
> WARNING: Page evictions started, this will affect storage performance 
> (consider increasing DataStorageConfiguration#setPageCacheSize).
> since there is no such setting (field/property) setPageCacheSize (ver. 
> 2.3.0#20171028-sha1:8add7fd5)
> The actual method is DataRegionConfiguration.setMaxSize.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-4398:
-

Assignee: Andrey Novikov  (was: Alexander Kalinin)

Implemented caching as described here: 
https://stackoverflow.com/questions/5017454/make-ie-to-cache-resources-but-always-revalidate

> Web console: incorrect authentication under IE 11 (windows 10)
> --
>
> Key: IGNITE-4398
> URL: https://issues.apache.org/jira/browse/IGNITE-4398
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> To reproduce:
> 1) log in as User1
> 2) create some cluster and save
> 3) log out
> 4) log in as User2
> You will see the cluster from User1.
> Note: IE specific only



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin edited comment on IGNITE-4398 at 11/29/17 5:42 AM:
-

Implemented caching as described here: 
https://stackoverflow.com/questions/5017454/make-ie-to-cache-resources-but-always-revalidate,
 Please review


was (Author: alexdel):
Implemented caching as described here: 
https://stackoverflow.com/questions/5017454/make-ie-to-cache-resources-but-always-revalidate

> Web console: incorrect authentication under IE 11 (windows 10)
> --
>
> Key: IGNITE-4398
> URL: https://issues.apache.org/jira/browse/IGNITE-4398
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> To reproduce:
> 1) log in as User1
> 2) create some cluster and save
> 3) log out
> 4) log in as User2
> You will see the cluster from User1.
> Note: IE specific only



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4835) Add ability to start rebalancing from management console

[Alexander Kalinin (JIRA)]

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

Alexander Kalinin reassigned IGNITE-4835:
-

Assignee: Pavel Konstantinov  (was: Alexander Kalinin)

Please review once again. Everything should work fine.

> Add ability to start rebalancing from management console
> 
>
> Key: IGNITE-4835
> URL: https://issues.apache.org/jira/browse/IGNITE-4835
> Project: Ignite
>  Issue Type: New Feature
>  Components: wizards
>Affects Versions: 1.9
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
>Priority: Minor
>
> Management console should allow for starting rebalancing manually.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7063) Web console: improve error handling in case of custom SMTP server

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-7063:
--

 Summary: Web console: improve error handling in case of custom 
SMTP server
 Key: IGNITE-7063
 URL: https://issues.apache.org/jira/browse/IGNITE-7063
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov


Add an error message in case if settings.json can't be read (contains error)
Add an error message in case if 'forgot password' message failed to be sent



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)

[Andrey Novikov (JIRA)]

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

Andrey Novikov reassigned IGNITE-4398:
--

Assignee: Alexander Kalinin  (was: Andrey Novikov)

Please, take a look.
https://stackoverflow.com/questions/39404588/prevent-cache-when-serving-a-json-response-in-node-js-api/39407519

> Web console: incorrect authentication under IE 11 (windows 10)
> --
>
> Key: IGNITE-4398
> URL: https://issues.apache.org/jira/browse/IGNITE-4398
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexander Kalinin
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> To reproduce:
> 1) log in as User1
> 2) create some cluster and save
> 3) log out
> 4) log in as User2
> You will see the cluster from User1.
> Note: IE specific only



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

[Sunny Chan (JIRA)]

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

Sunny Chan edited comment on IGNITE-5960 at 11/29/17 1:24 AM:
--

[~akuznetsov] The CacheContinuousQueryConcurrentPartitionUpdateTest is a redux 
of our problem. From our application prospective we did this:

# Setup a cache with a pair of node
# Setup continuous query, and update entries in the cache that would trigger 
the CQ
# Remove one node forcefully (e.g. kill -9). The thread that update entries 
should continue in the background
# Now restart the killed node and you will find the continuous query no longer 
gets any event even the update continuous.


was (Author: sunnychanclsa):
[~akuznetsov] The CacheContinuousQueryConcurrentPartitionUpdateTest is a redux 
of our problem. From our application prospective we did this:

# Setup a cache with a pair of node
# Setup continuous query, and update entries in the cache that would trigger 
the CQ
# Remove one node forcefully (e.g. kill -9). The entries update to cache should 
continue in the background
# Now restart the killed node and you will find the continuous query no longer 
gets any event even the update continuous.

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
> -
>
> Key: IGNITE-5960
> URL: https://issues.apache.org/jira/browse/IGNITE-5960
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4
>
>
> According to [TC 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E]
>  test is flaky.
> It is possible to reproduce it locally, sample run shows 9 failed tests out 
> of 30 overall executed.
> Test fails with jUnit assertion check: 
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :1
> Actual   :0
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

[Sunny Chan (JIRA)]

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

Sunny Chan commented on IGNITE-5960:


[~akuznetsov] The CacheContinuousQueryConcurrentPartitionUpdateTest is a redux 
of our problem. From our application prospective we did this:

# Setup a cache with a pair of node
# Setup continuous query, and update entries in the cache that would trigger 
the CQ
# Remove one node forcefully (e.g. kill -9). The entries update to cache should 
continue in the background
# Now restart the killed node and you will find the continuous query no longer 
gets any event even the update continuous.

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
> -
>
> Key: IGNITE-5960
> URL: https://issues.apache.org/jira/browse/IGNITE-5960
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4
>
>
> According to [TC 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E]
>  test is flaky.
> It is possible to reproduce it locally, sample run shows 9 failed tests out 
> of 30 overall executed.
> Test fails with jUnit assertion check: 
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :1
> Actual   :0
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7062) Ignite page with video resources and recording

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7062:
---

 Summary: Ignite page with video resources and recording
 Key: IGNITE-7062
 URL: https://issues.apache.org/jira/browse/IGNITE-7062
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.4


There is a plenty of recordings of Ignite meetups, webinars and conference 
talks available on the Internet. Some of them introduce basic components and 
capabilities, some share best practices and pitfalls while the other share use 
cases.

Generally, it's beneficial for both Ignite community and users to gather and 
expose the most useful ones under a special video recording section. For 
instance, we might consider these talks to be added right away:
* Ignite use case: https://youtu.be/1D8hyLWMtfM
* Ignite essentials: https://www.youtube.com/watch?v=G22L2KW9gEQ
* Kubernetes: https://www.youtube.com/watch?v=igDB0wyodr8

Instead of creating a new page for this purpose I would rework the screencasts' 
page combining all the media content there: 
https://ignite.apache.org/screencasts.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7061) Rework Features menu and page

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7061:

Description: 
The features menu and the page [1] is overloaded and confusing. As a technical 
guy, I feel lost trying to grasp what’s important and what’s secondary. That 
deters me from digging into the project. 

Rework the menu and page in accordance with this discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html

All the changes are incorporated in this SVN branch:
https://svn.apache.org/repos/asf/ignite/site/branches/ignite-7061

[1] https://ignite.apache.org/features.html

  was:
The features menu and the page [1] is overloaded and confusing. As a technical 
guy, I feel lost trying to grasp what’s important and what’s secondary. That 
deters me from digging into the project. 

Rework the menu and page in accordance with this discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html

[1] https://ignite.apache.org/features.html


> Rework Features menu and page
> -
>
> Key: IGNITE-7061
> URL: https://issues.apache.org/jira/browse/IGNITE-7061
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> The features menu and the page [1] is overloaded and confusing. As a 
> technical guy, I feel lost trying to grasp what’s important and what’s 
> secondary. That deters me from digging into the project. 
> Rework the menu and page in accordance with this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html
> All the changes are incorporated in this SVN branch:
> https://svn.apache.org/repos/asf/ignite/site/branches/ignite-7061
> [1] https://ignite.apache.org/features.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-7061) Rework Features menu and page

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7061:
---

Assignee: Denis Magda

> Rework Features menu and page
> -
>
> Key: IGNITE-7061
> URL: https://issues.apache.org/jira/browse/IGNITE-7061
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> The features menu and the page [1] is overloaded and confusing. As a 
> technical guy, I feel lost trying to grasp what’s important and what’s 
> secondary. That deters me from digging into the project. 
> Rework the menu and page in accordance with this discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html
> [1] https://ignite.apache.org/features.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7061) Rework Features menu and page

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7061:
---

 Summary: Rework Features menu and page
 Key: IGNITE-7061
 URL: https://issues.apache.org/jira/browse/IGNITE-7061
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
 Fix For: 2.4


The features menu and the page [1] is overloaded and confusing. As a technical 
guy, I feel lost trying to grasp what’s important and what’s secondary. That 
deters me from digging into the project. 

Rework the menu and page in accordance with this discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Reworking-Ignite-site-s-quot-Features-quot-menu-td24569.html

[1] https://ignite.apache.org/features.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7060) Prepare Architecture section for the site

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7060:
---

 Summary: Prepare Architecture section for the site
 Key: IGNITE-7060
 URL: https://issues.apache.org/jira/browse/IGNITE-7060
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
 Fix For: 2.4


In addition to the features, it's useful to introduce Ignite architecture right 
in the Features menu covering the following:
* Overview
* Clustering and Deployment
* Distributed Database
* Durable Memory



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7059) Improve Collocated Processing page on the site

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-7059:

Summary: Improve Collocated Processing page on the site  (was: Expand 
Collocated Processing page on the site)

> Improve Collocated Processing page on the site
> --
>
> Key: IGNITE-7059
> URL: https://issues.apache.org/jira/browse/IGNITE-7059
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
> Fix For: 2.4
>
>
> Presently the collocated processing [1] covers general aspects of this 
> paradigm. Elaborate more on the following:
> * How it's related to SQL
> * How it's related to compute grid and ML
> * As for compute grid, mention that it allows broadcast or run computations 
> on concrete nodes as well.
> [1] https://ignite.apache.org/collocatedprocessing.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7059) Expand Collocated Processing page on the site

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7059:
---

 Summary: Expand Collocated Processing page on the site
 Key: IGNITE-7059
 URL: https://issues.apache.org/jira/browse/IGNITE-7059
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
 Fix For: 2.4


Presently the collocated processing [1] covers general aspects of this 
paradigm. Elaborate more on the following:
* How it's related to SQL
* How it's related to compute grid and ML
* As for compute grid, mention that it allows broadcast or run computations on 
concrete nodes as well.

[1] https://ignite.apache.org/collocatedprocessing.html




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7058) Make out a site page for ACID Transactions

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7058:
---

 Summary: Make out a site page for ACID Transactions
 Key: IGNITE-7058
 URL: https://issues.apache.org/jira/browse/IGNITE-7058
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
 Fix For: 2.4


ACID transactions are a major feature of Ignite and have to be exposed under 
the Features menu on the site.

Make out the page covering the following:
* 2Phase Commit Protocol
* Pessimistic and Optimistic Modes
* Deadlock detection



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7057) Create Key-Value Page for the site

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7057:
---

 Summary: Create Key-Value Page for the site
 Key: IGNITE-7057
 URL: https://issues.apache.org/jira/browse/IGNITE-7057
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
 Fix For: 2.4


Prepare a page to describe Ignite key-value APIs. The page will go to the 
Features menu and should cover the following:
* Scope of K/V APIs.
* JCache 
* Benefits of JCache
* How to combine K/V and SQL APIs
* Examples

Rework existing data grid and key-value store pages:
https://ignite.apache.org/features/datagrid.html
https://ignite.apache.org/use-cases/database/key-value-store.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7056) Prepare Multi-Language support page for the site

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7056:
---

 Summary: Prepare Multi-Language support page for the site
 Key: IGNITE-7056
 URL: https://issues.apache.org/jira/browse/IGNITE-7056
 Project: Ignite
  Issue Type: Task
  Components: site
Reporter: Denis Magda
 Fix For: 2.4


Prepare Ignite's multi-language page that will go under the features menu. The 
page should encompass the following:
* Java, .NET and C++ native APIs.
* Supported drivers and protocols that can be used in various languages.
* A couple of examples.

Update the image by combining Java, NET and C++ logos.

Remove the pages below setting up a redirect the multi-languages page:
https://ignite.apache.org/features/java.html
https://ignite.apache.org/features/dotnet.html
https://ignite.apache.org/features/cpp.html
https://ignite.apache.org/features/clientprotos.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-3084:
-

I'm OK with upgrading to 2.2.0.

> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>  Labels: bigdata
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-7056) Prepare Multi-Language support page for the site

[Denis Magda (JIRA)]

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

Denis Magda reassigned IGNITE-7056:
---

Assignee: Denis Magda

> Prepare Multi-Language support page for the site
> 
>
> Key: IGNITE-7056
> URL: https://issues.apache.org/jira/browse/IGNITE-7056
> Project: Ignite
>  Issue Type: Task
>  Components: site
>Reporter: Denis Magda
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> Prepare Ignite's multi-language page that will go under the features menu. 
> The page should encompass the following:
> * Java, .NET and C++ native APIs.
> * Supported drivers and protocols that can be used in various languages.
> * A couple of examples.
> Update the image by combining Java, NET and C++ logos.
> Remove the pages below setting up a redirect the multi-languages page:
> https://ignite.apache.org/features/java.html
> https://ignite.apache.org/features/dotnet.html
> https://ignite.apache.org/features/cpp.html
> https://ignite.apache.org/features/clientprotos.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Valentin Kulichenko (JIRA)]

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

Valentin Kulichenko commented on IGNITE-6846:
-

[~Alexey Kuznetsov], here are my comments.

1. Makes sense.
2. Metrics for total number of invocations should be incremented.
3. Correct.
4. This sounds like a weird case, how do you update multiple entries with one 
entry processor invocation?
5. Correct. And this does not depend on what entry processor returns.
6. How does regular 'remove' metric behaves in this case? I think similar 
'invoke' metric should be consistent with that one.
7. Can you draft the API and present it here?

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7055) Text query for a particular field not working

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7055:
---

 Summary: Text query for a particular field not working
 Key: IGNITE-7055
 URL: https://issues.apache.org/jira/browse/IGNITE-7055
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.3
Reporter: Valentin Kulichenko


Lucene queries allow to specify a specific field name to search in [1], however 
this doesn't seem to work in latest versions of Ignite.

To reproduce, modify {{CacheQueryExample#textQuery}} to use Lucene field 
expression:
{code}
QueryCursor> masters =
cache.query(new TextQuery(Person.class, "resume:Master"));
{code}
This query returns empty result.

[1] 
http://lucene.apache.org/core/5_5_2/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#Fields



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6390) [IGNITE-6390] Web console: Implement component for cluster selection on pages where it make sense

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-6390:


Assignee: Andrey Novikov  (was: Dmitriy Shabalin)

[~alexeinov] fixed issues, pls review it

> [IGNITE-6390] Web console: Implement component for cluster selection on pages 
> where it make sense
> -
>
> Key: IGNITE-6390
> URL: https://issues.apache.org/jira/browse/IGNITE-6390
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Andrey Novikov
> Fix For: 2.4
>
>
> 1. add cluster-selector to pages.
> 2. add update information of cluster data in page after change cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-7040) Web console: Invalid user table height

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-7040:


Assignee: Dmitriy Shabalin  (was: Andrey Novikov)

> Web console: Invalid user table height
> --
>
> Key: IGNITE-7040
> URL: https://issues.apache.org/jira/browse/IGNITE-7040
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Dmitriy Shabalin
>
> # Filter user list (f.e. to 2 rows)
> # Change period of showed activity metrics.
> Height of table changed to maximum available but show only filtered rows.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6390) [IGNITE-6390] Web console: Implement component for cluster selection on pages where it make sense

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-6390:


Assignee: Dmitriy Shabalin  (was: Ilya Borisov)

> [IGNITE-6390] Web console: Implement component for cluster selection on pages 
> where it make sense
> -
>
> Key: IGNITE-6390
> URL: https://issues.apache.org/jira/browse/IGNITE-6390
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Dmitriy Shabalin
>Assignee: Dmitriy Shabalin
> Fix For: 2.4
>
>
> 1. add cluster-selector to pages.
> 2. add update information of cluster data in page after change cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Issue Comment Deleted] (IGNITE-7040) Web console: Invalid user table height

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin updated IGNITE-7040:
-
Comment: was deleted

(was: [~anovikov] fixed issues, pls review it.)

> Web console: Invalid user table height
> --
>
> Key: IGNITE-7040
> URL: https://issues.apache.org/jira/browse/IGNITE-7040
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Dmitriy Shabalin
>
> # Filter user list (f.e. to 2 rows)
> # Change period of showed activity metrics.
> Height of table changed to maximum available but show only filtered rows.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-7040) Web console: Invalid user table height

[Dmitriy Shabalin (JIRA)]

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

Dmitriy Shabalin reassigned IGNITE-7040:


Assignee: Andrey Novikov  (was: Dmitriy Shabalin)

[~anovikov] fixed issues, pls review it.

> Web console: Invalid user table height
> --
>
> Key: IGNITE-7040
> URL: https://issues.apache.org/jira/browse/IGNITE-7040
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vasiliy Sisko
>Assignee: Andrey Novikov
>
> # Filter user list (f.e. to 2 rows)
> # Change period of showed activity metrics.
> Height of table changed to maximum available but show only filtered rows.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-5733) Activate/deactivate cluster through http-rest api

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-5733:

Labels: usability  (was: )

> Activate/deactivate cluster through http-rest api
> -
>
> Key: IGNITE-5733
> URL: https://issues.apache.org/jira/browse/IGNITE-5733
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexander Belyak
>Assignee: Alexander Belyak
>Priority: Critical
>  Labels: usability
> Fix For: 2.4
>
>
> Need to add command to get/set cluster active flag into http rest api.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6994:

Priority: Critical  (was: Major)

> Need to document PartitionLossPolicy
> 
>
> Key: IGNITE-6994
> URL: https://issues.apache.org/jira/browse/IGNITE-6994
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Prachi Garg
>Priority: Critical
>  Labels: documentation
> Fix For: 2.4
>
>
> Since 2.0 we have a feature that makes cache(s) unavailable in case of data 
> loss; exact behavior is controlled by {{PartitionLossPolicy}}: 
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/PartitionLossPolicy.html
> However, there is no mentioning in documentation about this. Need to provide 
> explanation of how and when it should be used and provide configuration 
> examples.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6698) Document CREATE TABLE "DATA_REGION" option

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6698.
---

> Document CREATE TABLE "DATA_REGION" option
> --
>
> Key: IGNITE-6698
> URL: https://issues.apache.org/jira/browse/IGNITE-6698
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Vladimir Ozerov
>Assignee: Denis Magda
>Priority: Critical
> Fix For: 2.4
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (IGNITE-6950) Update documentation for user facing CREATE TABLE params

[Denis Magda (JIRA)]

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

Denis Magda closed IGNITE-6950.
---

> Update documentation for user facing CREATE TABLE params
> 
>
> Key: IGNITE-6950
> URL: https://issues.apache.org/jira/browse/IGNITE-6950
> Project: Ignite
>  Issue Type: Task
>  Components: documentation, sql
>Affects Versions: 2.4
>Reporter: Alexander Paschenko
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> Changes to documentation should be made to reflect additional spelling for 
> some {{CREATE TABLE}} params added in IGNITE-6270.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6948) SQL: Document new INLINE_SIZE option in CREATE INDEX command

[Denis Magda (JIRA)]

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

Denis Magda commented on IGNITE-6948:
-

[~kirill.shirokov], thanks for the documentation! I've tweaked it a little bit.

[~pgarg], please do a final review. Read through {INLINE_SIZE} parameter 
description [1]
and index inlining section [2].

[1] 
https://apacheignite-sql.readme.io/v2.3/docs/create-index_24_hidden#section-parameters
[2] 
https://apacheignite-sql.readme.io/v2.3/docs/create-index_24_hidden#section-index-inlining

> SQL: Document new INLINE_SIZE option in CREATE INDEX command
> 
>
> Key: IGNITE-6948
> URL: https://issues.apache.org/jira/browse/IGNITE-6948
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Kirill Shirokov
>Assignee: Denis Magda
> Fix For: 2.4
>
>
> INLINE_SIZE is optional and accepts positive integer values. To specify the 
> default inline size user should omit the option.
> The corresponding documentation page is at:
> https://apacheignite-sql.readme.io/docs/create-index



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7054) S3 IP finder: support client side encryption

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7054:
---

 Summary: S3 IP finder: support client side encryption
 Key: IGNITE-7054
 URL: https://issues.apache.org/jira/browse/IGNITE-7054
 Project: Ignite
  Issue Type: Improvement
  Components: s3
Affects Versions: 2.3
Reporter: Valentin Kulichenko
 Fix For: 2.4


In case client side encryption [1] is used, it may be required to use 
{{AmazonS3EncryptionClient}} instead of regular {{AmazonS3Client}}. We need to 
add this option to the S3 IP finder, along with any applicable configuration 
parameters.

[1] 
http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7053) S3 IP finder: support server side encryption

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7053:
---

 Summary: S3 IP finder: support server side encryption
 Key: IGNITE-7053
 URL: https://issues.apache.org/jira/browse/IGNITE-7053
 Project: Ignite
  Issue Type: Improvement
  Components: s3
Affects Versions: 2.3
Reporter: Valentin Kulichenko
 Fix For: 2.4


In case server side encryption [1] is used, it may be required to specify the 
algorithm in request headers when saving information in a bucket (can be done 
via {{ObjectMetadata#setSSEAlgorithm}} method). To support this we need to add 
corresponding configuration property to the S3 IP finder.

[1] http://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7052) S3 IP finder: add an ability to provide endpoint address

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-7052:
---

 Summary: S3 IP finder: add an ability to provide endpoint address
 Key: IGNITE-7052
 URL: https://issues.apache.org/jira/browse/IGNITE-7052
 Project: Ignite
  Issue Type: Improvement
  Components: s3
Affects Versions: 2.3
Reporter: Valentin Kulichenko
 Fix For: 2.4


By default S3 client detects region automatically by sending special request to 
{{us-west-1}}. In case environment is restricted to some other region, this 
leads to connection timeout exception.

The issue can be solved by providing a specific region endpoint via 
{{AmazonS3Client#setEndpoint}} method. To support this we need to add 
{{endpoint}} configuration property to the IP finder.

List of S3 region endpoints: 
http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6937) SQL TX: Support SELECT FOR UPDATE

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-6937:

Description: 
Normally in SQL world readers do not block writers. This is how our SELECT 
operations should work by default. But we need to add a support for {{SELECT 
... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 

In this mode we lock entries as usual, but then send data back to the caller. 
First page can be returned directly in our {{LockResponse}}. Next pages should 
be requested in separate requests. With this approach {{SELECT ,,, FOR UPDATE}} 
will require only single round-trip to both lock and read data in case of small 
updates.

Update {{SELECT}} statement syntax once this feature is supported:
https://apacheignite-sql.readme.io/docs/select

  was:
Normally in SQL world readers do not block writers. This is how our SELECT 
operations should work by default. But we need to add a support for {{SELECT 
... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 

In this mode we lock entries as usual, but then send data back to the caller. 
First page can be returned directly in our {{LockResponse}}. Next pages should 
be requested in separate requests. With this approach {{SELECT ,,, FOR UPDATE}} 
will require only single round-trip to both lock and read data in case of small 
updates.


> SQL TX: Support SELECT FOR UPDATE
> -
>
> Key: IGNITE-6937
> URL: https://issues.apache.org/jira/browse/IGNITE-6937
> Project: Ignite
>  Issue Type: Task
>  Components: cache, sql
>Reporter: Vladimir Ozerov
>  Labels: iep-3
> Fix For: 2.4
>
>
> Normally in SQL world readers do not block writers. This is how our SELECT 
> operations should work by default. But we need to add a support for {{SELECT 
> ... FOR UPDATE}} read mode, when reader obtains exclusive lock on read. 
> In this mode we lock entries as usual, but then send data back to the caller. 
> First page can be returned directly in our {{LockResponse}}. Next pages 
> should be requested in separate requests. With this approach {{SELECT ,,, FOR 
> UPDATE}} will require only single round-trip to both lock and read data in 
> case of small updates.
> Update {{SELECT}} statement syntax once this feature is supported:
> https://apacheignite-sql.readme.io/docs/select



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Blackfield (JIRA)]

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

Blackfield commented on IGNITE-7029:


IGNITE-6942 covers the failover feature.

This ticket asks for load balancing feature implemented as well.

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7051) SQL Rename table support

[Blackfield (JIRA)]

Blackfield created IGNITE-7051:
--

 Summary: SQL Rename table support
 Key: IGNITE-7051
 URL: https://issues.apache.org/jira/browse/IGNITE-7051
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.3
Reporter: Blackfield


Use case was discussed at length here: 
http://apache-ignite-users.70518.x6.nabble.com/Continuous-update-Data-Grid-Cache-td2075.html#a17641

Currently, we have to load data to second table, the client then has to 
change their query to query this 
new table. Drop the old table. 

The latest suggestion in the above thread to "load new data set in the same 
cache and remove old entries once preloading is finished" is not feasible 
since for large table and table scan query (thus requires whole dataset to 
be loaded), it will take a while to load everything - thus increasing the 
downtime. 

Table rename support will reduce the downtime greatly. 

Ref: Postgresql and H2 syntax
ALTER TABLE TmpTable RENAME TO Table1; 


Then, one would wrap it within transaction (It appears that this is slated 
for 2.4/2.5?) to drop old table, rename temp table to original table. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-7050:
-

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






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7049) Optimistic transaction is not properly rolled back if timed out before sending prepare response.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-7049:
-

 Summary: Optimistic transaction is not properly rolled back if 
timed out before sending prepare response.
 Key: IGNITE-7049
 URL: https://issues.apache.org/jira/browse/IGNITE-7049
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexei Scherbakov
 Fix For: 2.4


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 org.apache.ignite.Ignite;
import org.apache.ignite.cluster.ClusterNode;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.internal.TestRecordingCommunicationSpi;
import 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareResponse;
import org.apache.ignite.internal.util.typedef.G;
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 static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
import static org.apache.ignite.cache.CacheWriteSynchronizationMode.FULL_SYNC;
import static org.apache.ignite.transactions.TransactionConcurrency.OPTIMISTIC;
import static org.apache.ignite.transactions.TransactionIsolation.SERIALIZABLE;

/**
 * Tests an ability to eagerly rollback timed out optimistic transactions.
 */
public class TxRollbackOnTimeoutOptimisticTest extends GridCommonAbstractTest {
/** */
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;

/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String 
igniteInstanceName) throws Exception {
IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);

((TcpDiscoverySpi)cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);

TestRecordingCommunicationSpi commSpi = new 
TestRecordingCommunicationSpi();

cfg.setCommunicationSpi(commSpi);

boolean client = "client".equals(igniteInstanceName);

cfg.setClientMode(client);

if (!client) {
CacheConfiguration ccfg = new CacheConfiguration(CACHE_NAME);

ccfg.setAtomicityMode(TRANSACTIONAL);
ccfg.setBackups(2);
ccfg.setWriteSynchronizationMode(FULL_SYNC);

cfg.setCacheConfiguration(ccfg);
}

return cfg;
}

/**
 * @return Near cache flag.
 */
protected boolean nearCacheEnabled() {
return false;
}

/** {@inheritDoc} */
@Override protected void beforeTest() throws Exception {
super.beforeTest();

startGridsMultiThreaded(GRID_CNT);
}

/** {@inheritDoc} */
@Override protected void afterTest() throws Exception {
super.afterTest();

stopAllGrids();
}

/** */
public void testOptimisticTimeout() throws Exception {
final Ignite client = startGrid("client");

assertNotNull(client.cache(CACHE_NAME));

final ClusterNode n0 = client.affinity(CACHE_NAME).mapKeyToNode(0);

final Ignite prim = G.ignite(n0.id());

for (Ignite ignite : G.allGrids()) {
if (ignite == prim)
continue;

final TestRecordingCommunicationSpi spi =

(TestRecordingCommunicationSpi)ignite.configuration().getCommunicationSpi();

spi.blockMessages(GridDhtTxPrepareResponse.class, prim.name());
}

final int val = 0;

try {
multithreaded(new Runnable() {
@Override public void run() {
try (Transaction txOpt = 
client.transactions().txStart(OPTIMISTIC, SERIALIZABLE, 300, 1)) {

client.cache(CACHE_NAME).put(val, val);

txOpt.commit();
   

[jira] [Updated] (IGNITE-3478) Multi-version concurrency control

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-3478:

Fix Version/s: 2.5

> Multi-version concurrency control
> -
>
> Key: IGNITE-3478
> URL: https://issues.apache.org/jira/browse/IGNITE-3478
> Project: Ignite
>  Issue Type: New Feature
>  Components: cache
>Reporter: Alexey Goncharuk
>  Labels: important
> Fix For: 2.5
>
>
> Current Ignite SQL does not take into account transaction boundaries. For 
> example, if a transaction atomically changes balance of two accounts, then a 
> concurrent SQL query can see partially committed transaction. This works for 
> data analytics, but does not work for more strict and demanding scenarios.
> It would be perfect if we had a mode which ensures transaction boundaries are 
> taken into account for SQL query.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4191) SQL: support transactions

[Denis Magda (JIRA)]

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

Denis Magda updated IGNITE-4191:

Fix Version/s: 2.5

> SQL: support transactions
> -
>
> Key: IGNITE-4191
> URL: https://issues.apache.org/jira/browse/IGNITE-4191
> Project: Ignite
>  Issue Type: New Feature
>  Components: sql
>Reporter: Denis Magda
>  Labels: iep-3, important
> Fix For: 2.5
>
>
> Presently there is no any way to execute data modification statements and 
> SELECT queries in a transactional fashion using our JDBC/ODBC drivers and DML 
> API.
> This can be fully supported once MVCC is ready and released.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7048) Cache get fails on node not in BaselineTopology.

[Sergey Chugunov (JIRA)]

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

Sergey Chugunov updated IGNITE-7048:

Component/s: persistence

> Cache get fails on node not in BaselineTopology.
> 
>
> Key: IGNITE-7048
> URL: https://issues.apache.org/jira/browse/IGNITE-7048
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Sergey Chugunov
> Fix For: 2.4
>
>
> As an example take a look at 
> IgnitePdsBinaryMetadataOnClusterRestartTest::testMixedMetadataIsRestoredOnRestart.
> When reading data for check from node not in BaselineTopology it fails with 
> the following assertion:
> {noformat}java.lang.AssertionError: result = true, persistenceEnabled = true, 
> partitionState = EVICTED
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheContext.allowFastLocalRead(GridCacheContext.java:2044)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:321)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:211)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:203)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1392)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:131)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:470)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:468)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:757)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:468)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4545)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4526)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1343)
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:828)
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:662)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.examineStaticMetadata(IgnitePdsBinaryMetadataOnClusterRestartTest.java:145)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.testMixedMetadataIsRestoredOnRestart(IgnitePdsBinaryMetadataOnClusterRestartTest.java:334)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The problem with the test is that in method 
> *GridCacheProcessor::prepareCacheStart* flag *affNode* is calculated ignoring 
> information about BaselineTopology distribution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7043) Incorrect method name suggested when page eviction starts

[Ivan Rakov (JIRA)]

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

Ivan Rakov commented on IGNITE-7043:


Looks good, please merge.

> Incorrect method name suggested when page eviction starts
> -
>
> Key: IGNITE-7043
> URL: https://issues.apache.org/jira/browse/IGNITE-7043
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Trivial
>
> Reported via gitter:
> WARNING: Page evictions started, this will affect storage performance 
> (consider increasing DataStorageConfiguration#setPageCacheSize).
> since there is no such setting (field/property) setPageCacheSize (ver. 
> 2.3.0#20171028-sha1:8add7fd5)
> The actual method is DataRegionConfiguration.setMaxSize.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7048) Cache get fails on node not in BaselineTopology.

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-7048:
---

 Summary: Cache get fails on node not in BaselineTopology.
 Key: IGNITE-7048
 URL: https://issues.apache.org/jira/browse/IGNITE-7048
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Chugunov
 Fix For: 2.4


As an example take a look at 
IgnitePdsBinaryMetadataOnClusterRestartTest::testMixedMetadataIsRestoredOnRestart.

When reading data for check from node not in BaselineTopology it fails with the 
following assertion:
{noformat}java.lang.AssertionError: result = true, persistenceEnabled = true, 
partitionState = EVICTED

at 
org.apache.ignite.internal.processors.cache.GridCacheContext.allowFastLocalRead(GridCacheContext.java:2044)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.mapKeyToNode(GridPartitionedSingleGetFuture.java:321)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.map(GridPartitionedSingleGetFuture.java:211)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:203)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1392)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:131)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:470)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:468)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:757)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:468)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get0(GridCacheAdapter.java:4545)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:4526)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1343)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:828)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:662)
at 
org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.examineStaticMetadata(IgnitePdsBinaryMetadataOnClusterRestartTest.java:145)
at 
org.apache.ignite.internal.processors.cache.persistence.IgnitePdsBinaryMetadataOnClusterRestartTest.testMixedMetadataIsRestoredOnRestart(IgnitePdsBinaryMetadataOnClusterRestartTest.java:334)
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:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745)
{noformat}

The problem with the test is that in method 
*GridCacheProcessor::prepareCacheStart* flag *affNode* is calculated ignoring 
information about BaselineTopology distribution.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7013:


Github user asfgit closed the pull request at:

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


> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (IGNITE-7013) .NET: Ignite does not start on macOS

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn resolved IGNITE-7013.

Resolution: Fixed

> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7013) .NET: Ignite does not start on macOS

[Pavel Tupitsyn (JIRA)]

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

Pavel Tupitsyn commented on IGNITE-7013:


TC is fine, merged to master: {{0b849abce4514ffe949915c85b15ad6aae23ee33}}.

> .NET: Ignite does not start on macOS
> 
>
> Key: IGNITE-7013
> URL: https://issues.apache.org/jira/browse/IGNITE-7013
> Project: Ignite
>  Issue Type: Bug
>  Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>  Labels: .NET, xplat
> Fix For: 2.4
>
>
> Looks like dlopen code is incorrect for macOS:
> {code}
> Unhandled Exception: System.DllNotFoundException: Unable to load DLL 
> 'libcoreclr.so': The specified module or one of its dependencies could not be 
> found.
>  (Exception from HRESULT: 0x8007007E)
>at 
> Apache.Ignite.Core.Impl.Unmanaged.DllLoader.NativeMethodsCore.dlopen(String 
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDll(String filePath, String 
> simpleName)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadJvmDll(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Impl.IgniteUtils.LoadDlls(String configJvmDllPath, 
> ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at ignite_nuget_test.Program.Main(String[] args) in 
> /Users/vveider/Development/VCS/Git/ignite-dotnetcore-demo/Program.cs:line 17
> {code}
> Steps to reproduce:
> {code}
> git clone https://github.com/ptupitsyn/ignite-dotnetcore-demo.git
> cd ignite-dotnetcore-demo
> dotnet run
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6919) Web console: incorrect character in tab name under IE11

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6919:


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

Looks good. Merged to master.

> Web console: incorrect character in tab name under IE11
> ---
>
> Key: IGNITE-6919
> URL: https://issues.apache.org/jira/browse/IGNITE-6919
> Project: Ignite
>  Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> !screenshot-1.png!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4398) Web console: incorrect authentication under IE 11 (windows 10)

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4398:


Assignee: Andrey Novikov  (was: Alexey Kuznetsov)

[~anovikov] Please review.

> Web console: incorrect authentication under IE 11 (windows 10)
> --
>
> Key: IGNITE-4398
> URL: https://issues.apache.org/jira/browse/IGNITE-4398
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Andrey Novikov
>  Time Spent: 0.1m
>  Remaining Estimate: 0h
>
> To reproduce:
> 1) log in as User1
> 2) create some cluster and save
> 3) log out
> 4) log in as User2
> You will see the cluster from User1.
> Note: IE specific only



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4452) Web console: add execution time to results panel on Queries screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4452:


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

It seems, that issue was already fixed in IGNITE-4454.

> Web console: add execution time to results panel on Queries screen
> --
>
> Key: IGNITE-4452
> URL: https://issues.apache.org/jira/browse/IGNITE-4452
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Trivial
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> I think it may be useful to know query last execution time, especially if we 
> have a Refresh rate possibility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-4452) Web console: add execution time to results panel on Queries screen

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov updated IGNITE-4452:
-
Fix Version/s: 2.4

> Web console: add execution time to results panel on Queries screen
> --
>
> Key: IGNITE-4452
> URL: https://issues.apache.org/jira/browse/IGNITE-4452
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Alexey Kuznetsov
>Priority: Trivial
> Fix For: 2.4
>
> Attachments: screenshot-1.png
>
>
> I think it may be useful to know query last execution time, especially if we 
> have a Refresh rate possibility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7047) NPE at org.jsr166.ConcurrentLinkedHashMap.replace

[Alexey Popov (JIRA)]

Alexey Popov created IGNITE-7047:


 Summary: NPE at org.jsr166.ConcurrentLinkedHashMap.replace
 Key: IGNITE-7047
 URL: https://issues.apache.org/jira/browse/IGNITE-7047
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.1
Reporter: Alexey Popov
Assignee: Alexey Popov


NPE happens sometimes at heavy load after receiving 
GridDhtTxOnePhaseCommitAckRequest, no more details

ERROR 11/25/17 17:39:28 [::sys-stripe-2-#3%null%] cache.GridCacheIoManager> 
Failed processing message [senderId=0393e394-09a9-4c02-b33e-fb4d99c3539f, 
msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersi
on [topVer=123129570, order=1511649564004, nodeOrder=2]], 
super=GridCacheMessage [msgId=95, depInfo=null, err=null, skipPrepare=false]]]
java.lang.NullPointerException
at 
org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:483)
at java.lang.Thread.run(Thread.java:745)
ERROR 11/25/17 17:39:28 [::sys-stripe-14-#15%null%] cache.GridCacheIoManager> 
Failed processing message [senderId=52c4ced0-49f3-4075-9b2f-7d619adf6d33, 
msg=GridDhtTxOnePhaseCommitAckRequest [vers=[GridCacheVersion 
[topVer=123129570, order=1511649564004, nodeOrder=4]], super=GridCacheMessage 
[msgId=97, depInfo=null, err=null, skipPrepare=false]]]
java.lang.NullPointerException
at 
org.jsr166.ConcurrentLinkedHashMap.replace(ConcurrentLinkedHashMap.java:1517)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.removeTxReturn(IgniteTxManager.java:1043)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxOnePhaseCommitAckRequest(IgniteTxHandler.java:1070)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$700(IgniteTxHandler.java:95)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:183)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$8.apply(IgniteTxHandler.java:181)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1042)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:561)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)

[jira] [Commented] (IGNITE-6945) SQL: optionally do not copy offheap rows for local SqlQuery

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov commented on IGNITE-6945:
-

[~tledkov-gridgain], my comments:
1) BinaryObjectOffheapImpl: I think it is illegal to "copy" object this way. We 
should copy data from offheap to heap and return BinaryObjectImpl.
2) Usage of GridCloseableCursor and/or Closeable is bad idea, because this may 
lead to unexpected calls to "close" in future. Let's define separate interface 
for this.
3) Why do we push flag to CacheOperationContext? Looks wrong to me, as it 
doesn't relate to cache. This is indexing stuff, GridH2QueryContext should be 
enough.
4) H2Tree.compare - why do we cleanup temp row in one place, but do not do this 
after another getRow() call below?
5) Is it possible to remove all current changes from BPlusTree and perform 
close in H2 classes? It looks strange that we call unrelated unlocks in all 
tree types just to support local SQL queries. You can do that as follows: 
define a kind of registry of binary objects to be closed; pass it to BPlusTree 
when cursor is created; use it inside H2LeafIO and H2ExtrasLeadIO classes to 
track pages to be unlocked. Will that work? Ideally, there should be no changes 
to BPlusTree and CacheDataRow.

> SQL: optionally do not copy offheap rows for local SqlQuery
> ---
>
> Key: IGNITE-6945
> URL: https://issues.apache.org/jira/browse/IGNITE-6945
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Fix For: 2.4
>
>
> Currently when iterating over rows we eagerly materialize them [1]. If key or 
> value are large enough, we could loose a lot of time on offheap-heap copying. 
> To partially mitigate this, we can do the following:
> 1) Add new flag {{SqlQuery.localNoCopy}} which is applicable only for local 
> queries.
> 2) When enabled we will not copy final {{_KEY}} and {{_VAL}} columns to heap. 
> but rather wrap them into {{BinaryOffheapObjectImpl}}
> 3) These rows must be released when query iterator switches to the next row.
> [1] {{H2RowFactory.getRow}}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6186:
-
Description: 
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing 
two adjacent non-root listener nodes from list simultaneously by calling 
{{unregisterWaiter()}}. Then data race is possible: one of these listeners can 
survive its removal. If the listener is a thread waiting for completion in 
{{get0()}} then this race leads at worst case to 1 extra call to 
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
arbitrary listener, and its {{apply()}} will be called twice.

To be precise, this Jira issue does not relate to any existing bug, but it 
eliminates fragile construct that can explode on future chages/refactorings.

  was:
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing 
two adjacent non-root listener nodes from list simultaneously by calling 
{{unregisterWaiter()}}. Then data race is possible: one of these listeners can 
survive its removal. If the listener is a thread waiting for completion in 
{{get0()}} then this race leads at worst case to 1 extra call to 
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
arbitrary listener, and its {{apply()}} will be called twice.


> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.
> Let future state is a list of listeners and two concurrent threads are 
> removing two adjacent non-root listener nodes from list simultaneously by 
> calling {{unregisterWaiter()}}. Then data race is possible: one of these 
> listeners can survive its removal. If the listener is a thread waiting for 
> completion in {{get0()}} then this race leads at worst case to 1 extra call 
> to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
> arbitrary listener, and its {{apply()}} will be called twice.
> To be precise, this Jira issue does not relate to any existing bug, but it 
> eliminates fragile construct that can explode on future chages/refactorings.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7046) Client queries should throw a correct exception

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-7046:

Description: 
The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:


{noformat}
/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}
{noformat}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.

  was:
The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:

{{/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}}}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.


> Client queries should throw a correct exception
> ---
>
> Key: IGNITE-7046
> URL: https://issues.apache.org/jira/browse/IGNITE-7046
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>
> The following test being added to 
> org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:
> {noformat}
> /**
>  * Method verifies that in the case of client query index is not used and 
> a correct exception is thrown.
>  *
>  * @throws Exception If failed.
>  */
> public void testClientOnlyNodeIndexException() throws Exception {
> try {
> Ignite g = startGrid("client");
> IgniteCache c = jcache(g, Integer.class, 
> Integer.class);
> try {
> List cres = c.query(new SqlFieldsQuery("select 
> count(*) from Integer")
> .setLocal(true)).getAll();
> } 
> catch (IgniteException e) {
> throw e; // FIXME: put an exception-checking code here 
> instead of throw
> }
> }
> finally {
> stopGrid("client");
> }
> }
> {noformat}
> ...will result in NPE instead of an Ignite exception explaining the 
> appropriate cause.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7046) Client queries should throw a correct exception

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-7046:

Description: 
The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:


{noformat}
/**
 * Verifies that in the case of client query the index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}
{noformat}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.

  was:
The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:


{noformat}
/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}
{noformat}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.


> Client queries should throw a correct exception
> ---
>
> Key: IGNITE-7046
> URL: https://issues.apache.org/jira/browse/IGNITE-7046
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>
> The following test being added to 
> org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:
> {noformat}
> /**
>  * Verifies that in the case of client query the index is not used and a 
> correct exception is thrown.
>  *
>  * @throws Exception If failed.
>  */
> public void testClientOnlyNodeIndexException() throws Exception {
> try {
> Ignite g = startGrid("client");
> IgniteCache c = jcache(g, Integer.class, 
> Integer.class);
> try {
> List cres = c.query(new SqlFieldsQuery("select 
> count(*) from Integer")
> .setLocal(true)).getAll();
> } 
> catch (IgniteException e) {
> throw e; // FIXME: put an exception-checking code here 
> instead of throw
> }
> }
> finally {
> stopGrid("client");
> }
> }
> {noformat}
> ...will result in NPE instead of an Ignite exception explaining the 
> appropriate cause.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7046) Client queries should throw a correct exception

[Kirill Shirokov (JIRA)]

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

Kirill Shirokov updated IGNITE-7046:

Description: 
The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:

{{/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}}}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.

  was:
The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:

/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.


> Client queries should throw a correct exception
> ---
>
> Key: IGNITE-7046
> URL: https://issues.apache.org/jira/browse/IGNITE-7046
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.3
>Reporter: Kirill Shirokov
>
> The following test being added to 
> org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:
> {{/**
>  * Method verifies that in the case of client query index is not used and 
> a correct exception is thrown.
>  *
>  * @throws Exception If failed.
>  */
> public void testClientOnlyNodeIndexException() throws Exception {
> try {
> Ignite g = startGrid("client");
> IgniteCache c = jcache(g, Integer.class, 
> Integer.class);
> try {
> List cres = c.query(new SqlFieldsQuery("select 
> count(*) from Integer")
> .setLocal(true)).getAll();
> } 
> catch (IgniteException e) {
> throw e; // FIXME: put an exception-checking code here 
> instead of throw
> }
> }
> finally {
> stopGrid("client");
> }
> }}}
> ...will result in NPE instead of an Ignite exception explaining the 
> appropriate cause.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7046) Client queries should throw a correct exception

[Kirill Shirokov (JIRA)]

Kirill Shirokov created IGNITE-7046:
---

 Summary: Client queries should throw a correct exception
 Key: IGNITE-7046
 URL: https://issues.apache.org/jira/browse/IGNITE-7046
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Kirill Shirokov


The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:

/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7045) Client queries should throw a correct exception

[Kirill Shirokov (JIRA)]

Kirill Shirokov created IGNITE-7045:
---

 Summary: Client queries should throw a correct exception
 Key: IGNITE-7045
 URL: https://issues.apache.org/jira/browse/IGNITE-7045
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Kirill Shirokov


The following test being added to 
org.apache.ignite.internal.processors.cache.distributed.replicated.IgniteCacheReplicatedQuerySelfTest:

/**
 * Method verifies that in the case of client query index is not used and a 
correct exception is thrown.
 *
 * @throws Exception If failed.
 */
public void testClientOnlyNodeIndexException() throws Exception {
try {
Ignite g = startGrid("client");

IgniteCache c = jcache(g, Integer.class, 
Integer.class);

try {
List cres = c.query(new SqlFieldsQuery("select 
count(*) from Integer")
.setLocal(true)).getAll();
} 
catch (IgniteException e) {
throw e; // FIXME: put an exception-checking code here instead 
of throw
}
}
finally {
stopGrid("client");
}
}

...will result in NPE instead of an Ignite exception explaining the appropriate 
cause.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-602) [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by infinite recursion

[Ryabov Dmitrii (JIRA)]

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

Ryabov Dmitrii commented on IGNITE-602:
---

[~agura], what is current status of tests and ticket?

> [Test] GridToStringBuilder is vulnerable for StackOverflowError caused by 
> infinite recursion
> 
>
> Key: IGNITE-602
> URL: https://issues.apache.org/jira/browse/IGNITE-602
> Project: Ignite
>  Issue Type: Bug
>  Components: general
>Reporter: Artem Shutak
>Assignee: Ryabov Dmitrii
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> See test 
> org.gridgain.grid.util.tostring.GridToStringBuilderSelfTest#_testToStringCheckAdvancedRecursionPrevention
>  and related TODO in same source file.
> Also take a look at 
> http://stackoverflow.com/questions/11300203/most-efficient-way-to-prevent-an-infinite-recursion-in-tostring
> Test should be unmuted on TC after fix.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

[Roman Kondakov (JIRA)]

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

Roman Kondakov updated IGNITE-7044:
---
External issue URL:   (was: 
https://issues.apache.org/jira/browse/IGNITE-6406)

> SQL: Documentation for the PARALLEL statement in the CREATE INDEX command
> -
>
> Key: IGNITE-7044
> URL: https://issues.apache.org/jira/browse/IGNITE-7044
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.1
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> Add a documentation for the PARALLEL option in the CREATE INDEX command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7044) SQL: Documentation for the PARALLEL statement in the CREATE INDEX command

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-7044:
--

 Summary: SQL: Documentation for the PARALLEL statement in the 
CREATE INDEX command
 Key: IGNITE-7044
 URL: https://issues.apache.org/jira/browse/IGNITE-7044
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.1
Reporter: Roman Kondakov
Assignee: Roman Kondakov
 Fix For: 2.4


Add a documentation for the PARALLEL option in the CREATE INDEX command.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6952) Deserialization failures on AIX

[Vladimir Ozerov (JIRA)]

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

Vladimir Ozerov reassigned IGNITE-6952:
---

Assignee: (was: Vladimir Ozerov)

> Deserialization failures on AIX 
> 
>
> Key: IGNITE-6952
> URL: https://issues.apache.org/jira/browse/IGNITE-6952
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Denis Magda
>Priority: Critical
> Fix For: 2.4
>
>
> Ignite fails on AIX with the following stack trace:
> {code}
> GridConnectionBytesVerifyFilter], accepted=true]]]
> java.lang.IllegalArgumentException: null
>   at java.nio.Buffer.position(Buffer.java:255) ~[?:1.8.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readArrayLE(DirectByteBufferStreamImplV2.java:1587)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readArrayLE(DirectByteBufferStreamImplV2.java:1542)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readLongArray(DirectByteBufferStreamImplV2.java:1013)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.DirectMessageReader.readLongArray(DirectMessageReader.java:212)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.GridLongList.readFrom(GridLongList.java:558)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.read(DirectByteBufferStreamImplV2.java:1785)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readCollection(DirectByteBufferStreamImplV2.java:1244)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.DirectMessageReader.readCollection(DirectMessageReader.java:333)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.CacheGroupAffinityMessage.readFrom(CacheGroupAffinityMessage.java:292)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.read(DirectByteBufferStreamImplV2.java:1785)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMap(DirectByteBufferStreamImplV2.java:1294)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.DirectMessageReader.readMap(DirectMessageReader.java:345)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsFullMessage.readFrom(GridDhtPartitionsFullMessage.java:645)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.stream.v2.DirectByteBufferStreamImplV2.readMessage(DirectByteBufferStreamImplV2.java:1165)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.direct.DirectMessageReader.readMessage(DirectMessageReader.java:311)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.managers.communication.GridIoMessage.readFrom(GridIoMessage.java:262)
> ~[ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridDirectParser.decode(GridDirectParser.java:90)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridConnectionBytesVerifyFilter.onMessageReceived(GridConnectionBytesVerifyFilter.java:133)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3388)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1261)
> [ignite-core-2.3.0.jar:2.3.0]
>   at
> 

[jira] [Commented] (IGNITE-6406) SQL: CREATE INDEX should fill index from multiple threads

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-6406:


Github user asfgit closed the pull request at:

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


> SQL: CREATE INDEX should fill index from multiple threads
> -
>
> Key: IGNITE-6406
> URL: https://issues.apache.org/jira/browse/IGNITE-6406
> Project: Ignite
>  Issue Type: Task
>  Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>  Labels: iep-1, performance
> Fix For: 2.4
>
>
> Currently when {{CREATE INDEX}} command is executed, we fill new index from a 
> single thread. Low CPU, long create time. We can trade off CPU vs time by 
> adding more threads. 
> Probably number of threads should be specified in {{CREATE INDEX}} command as 
> a hint.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7043) Incorrect method name suggested when page eviction starts

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on IGNITE-7043:


GitHub user alamar opened a pull request:

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

IGNITE-7043 Fix method name suggested when page eviction starts



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

$ git pull https://github.com/alamar/ignite patch-1

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

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


commit 40700bbba66528e8c42da66f28bcc07f634dbb20
Author: Ilya Kasnacheev 
Date:   2017-11-28T12:49:23Z

IGNITE-7043 Fix method name suggested when page eviction starts




> Incorrect method name suggested when page eviction starts
> -
>
> Key: IGNITE-7043
> URL: https://issues.apache.org/jira/browse/IGNITE-7043
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Trivial
>
> Reported via gitter:
> WARNING: Page evictions started, this will affect storage performance 
> (consider increasing DataStorageConfiguration#setPageCacheSize).
> since there is no such setting (field/property) setPageCacheSize (ver. 
> 2.3.0#20171028-sha1:8add7fd5)
> The actual method is DataRegionConfiguration.setMaxSize.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7043) Incorrect method name suggested when page eviction starts

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7043:
---

 Summary: Incorrect method name suggested when page eviction starts
 Key: IGNITE-7043
 URL: https://issues.apache.org/jira/browse/IGNITE-7043
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev
Priority: Trivial


Reported via gitter:

WARNING: Page evictions started, this will affect storage performance (consider 
increasing DataStorageConfiguration#setPageCacheSize).
since there is no such setting (field/property) setPageCacheSize (ver. 
2.3.0#20171028-sha1:8add7fd5)

The actual method is DataRegionConfiguration.setMaxSize.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/28/17 12:10 PM:
-

While implementing the task i rely on the following 

1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once, local metrics on other nodes 
are zero.
5)Read-only 'invoke' metric is incremented if processor invoke operation is 
called without executing entry.setValue(...) (even calling entry.getValue() can 
be omit), processor can return non-null value.Also, cache might be empty while 
processor invocation.
6)'invoke removal' metric is incremented only if old cache value exists and 
removal succeedes.
If there was no old value, associated with a key, then 'invoke read-only' 
metric is incremented.
7)The following metrics are going to be added : total number of invokes, number 
of invoke updates, number of invoke removals, number of read-only invokes, 
min\max\avg number of invocations(all invocations).

Do you think its correct?


was (Author: alexey kuznetsov):
While implementing the task i rely on the following 

1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once, local metrics on other nodes 
are zero.
5)Read-only 'invoke' metric is incremented if processor invoke operation is 
called without executing entry.setValue(...) (even calling entry.getValue() can 
be omit), processor can return non-null value.Also, cache might be empty while 
processor invocation.
6)'invoke removal' metric is incremented only if old cache value exists and 
removal succeedes.
7)The following metrics are going to be added : total number of invokes, number 
of invoke updates, number of invoke removals, number of read-only invokes, 
min\max\avg number of invocations(all invocations).

Do you think its correct?

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4192) SQL TX: JDBC driver support

[Alexander Paschenko (JIRA)]

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

Alexander Paschenko reassigned IGNITE-4192:
---

Assignee: Alexander Paschenko

> SQL TX: JDBC driver support
> ---
>
> Key: IGNITE-4192
> URL: https://issues.apache.org/jira/browse/IGNITE-4192
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
>  Labels: iep-3
> Fix For: 2.4
>
>
> To support execution of DML and SELECT statements inside of a transaction 
> started from JDBC driver side.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-6186) Remove redundant parameter of GridFutureAdapter::unregisterWaiter()

[Andrey Kuznetsov (JIRA)]

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

Andrey Kuznetsov updated IGNITE-6186:
-
Description: 
The method is not thread-safe unless actual parameter is currentThread.

Let future state is a list of listeners and two concurrent threads are removing 
two adjacent non-root listener nodes from list simultaneously by calling 
{{unregisterWaiter()}}. Then data race is possible: one of these listeners can 
survive its removal. If the listener is a thread waiting for completion in 
{{get0()}} then this race leads at worst case to 1 extra call to 
{{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
arbitrary listener, and its {{apply()}} will be called twice.

  was:The method is not thread-safe unless actual parameter is currentThread.


> Remove redundant parameter of GridFutureAdapter::unregisterWaiter()
> ---
>
> Key: IGNITE-6186
> URL: https://issues.apache.org/jira/browse/IGNITE-6186
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Minor
>
> The method is not thread-safe unless actual parameter is currentThread.
> Let future state is a list of listeners and two concurrent threads are 
> removing two adjacent non-root listener nodes from list simultaneously by 
> calling {{unregisterWaiter()}}. Then data race is possible: one of these 
> listeners can survive its removal. If the listener is a thread waiting for 
> completion in {{get0()}} then this race leads at worst case to 1 extra call 
> to {{LockSupport.park()}}, and it's negligible. Otherwise we deal with an 
> arbitrary listener, and its {{apply()}} will be called twice.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-5960 at 11/28/17 11:16 AM:
-

[~sunnychanclsa] Can you provide reproducer of your problem, so that i can see 
the steps you described above?


was (Author: alexey kuznetsov):
[~sunnychanclsa]Can you provide reproducer of your problem, so that i can see 
the steps you described above?

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
> -
>
> Key: IGNITE-5960
> URL: https://issues.apache.org/jira/browse/IGNITE-5960
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4
>
>
> According to [TC 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E]
>  test is flaky.
> It is possible to reproduce it locally, sample run shows 9 failed tests out 
> of 30 overall executed.
> Test fails with jUnit assertion check: 
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :1
> Actual   :0
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-425:


TC run after merge with latest master - 
https://ci.ignite.apache.org/viewLog.html?buildId=965950=buildResultsDiv=Ignite20Tests_RunAll

> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
>  Issue Type: Sub-task
>  Components: cache
>Affects Versions: 2.2
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
> Fix For: 2.4
>
>
> Currently if updated entry passes the filter, it is sent to node initiated 
> the query entirely. It would be good to provide user with the ability to 
> transform entry and, for example, select only fields that are important. This 
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer 
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} // 
> Probably, we will have to introduce new listener type, since user may want to 
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-5960) Ignite Continuous Query (Queries 3): CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic is flaky

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov commented on IGNITE-5960:
--

[~sunnychanclsa]Can you provide reproducer of your problem, so that i can see 
the steps you described above?

> Ignite Continuous Query (Queries 3): 
> CacheContinuousQueryConcurrentPartitionUpdateTest::testConcurrentUpdatesAndQueryStartAtomic
>  is flaky
> -
>
> Key: IGNITE-5960
> URL: https://issues.apache.org/jira/browse/IGNITE-5960
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Alexey Kuznetsov
>  Labels: MakeTeamcityGreenAgain, test-failure
> Fix For: 2.4
>
>
> According to [TC 
> history|http://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=6546112007182082024=testDetails_Ignite20Tests=%3Cdefault%3E]
>  test is flaky.
> It is possible to reproduce it locally, sample run shows 9 failed tests out 
> of 30 overall executed.
> Test fails with jUnit assertion check: 
> {noformat}
> junit.framework.AssertionFailedError: 
> Expected :1
> Actual   :0
>  
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.Assert.failNotEquals(Assert.java:329)
>   at junit.framework.Assert.assertEquals(Assert.java:78)
>   at junit.framework.Assert.assertEquals(Assert.java:234)
>   at junit.framework.Assert.assertEquals(Assert.java:241)
>   at junit.framework.TestCase.assertEquals(TestCase.java:409)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.concurrentUpdatesAndQueryStart(CacheContinuousQueryConcurrentPartitionUpdateTest.java:385)
>   at 
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryConcurrentPartitionUpdateTest.testConcurrentUpdatesAndQueryStartTx(CacheContinuousQueryConcurrentPartitionUpdateTest.java:245)
>   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:2000)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
>   at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6015) Test fail in Ignite Cache 2: GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform

[Anton Vinogradov (JIRA)]

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

Anton Vinogradov commented on IGNITE-6015:
--

[~andrey-kuznetsov]
That's not acceptable case. 
We need successful run :) 
Master now seems to be green, please try again.

> Test fail in Ignite Cache 2: 
> GridCachePartitionedGetAndTransformStoreSelfTest.testGetAndTransform 
> --
>
> Key: IGNITE-6015
> URL: https://issues.apache.org/jira/browse/IGNITE-6015
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.1
>Reporter: Dmitriy Govorukhin
>Assignee: Andrey Kuznetsov
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> {code}
> java.util.concurrent.TimeoutException: Test has been timed out 
> [test=testGetAndTransform, timeout=30]
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:1949)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at junit.framework.TestSuite.runTest(TestSuite.java:255)
> at junit.framework.TestSuite.run(TestSuite.java:250)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> 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 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208)
> at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:156)
> at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:82)
> at 
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:82)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:951)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 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 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at 

[jira] [Comment Edited] (IGNITE-7041) Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov edited comment on IGNITE-7041 at 11/28/17 10:51 AM:
---

Already has a fix in branch https://issues.apache.org/jira/browse/IGNITE-6995


was (Author: pkonstantinov):
Already fixed in issue https://issues.apache.org/jira/browse/IGNITE-6995

> Web Console: Incorrect code generation in case if cache has eviction policy 
> and near cache with eviction policy
> ---
>
> Key: IGNITE-7041
> URL: https://issues.apache.org/jira/browse/IGNITE-7041
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>
> In case if cache has eviction policy and also near cache configuration with 
> eviction policy then generated code contains an error - the same variable is 
> used to define two different eviction policy types
> {code}
> public static CacheConfiguration cacheDepartmentCache() throws Exception {
> CacheConfiguration ccfg = new CacheConfiguration();
> 
> .
> LruEvictionPolicy evictionPlc = new LruEvictionPolicy();
> evictionPlc.setBatchSize(5);
> evictionPlc.setMaxSize(100);
> ccfg.setEvictionPolicy(evictionPlc);
>
> .
> NearCacheConfiguration nearConfiguration = new 
> NearCacheConfiguration();
> nearConfiguration.setNearStartSize(4545);
> evictionPlc = new SortedEvictionPolicy();-  THIS ROW IS 
> INCORRECT
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7042) Test written in scala doesn't executed on TC

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-7042:
---

 Summary: Test written in scala doesn't executed on TC 
 Key: IGNITE-7042
 URL: https://issues.apache.org/jira/browse/IGNITE-7042
 Project: Ignite
  Issue Type: Bug
  Components: spark
Affects Versions: 2.3
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
Priority: Minor
 Fix For: 2.4


Tests from module `spark` and `spark_2.10` written in scala don't executes on 
TC.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/28/17 10:39 AM:
-

While implementing the task i rely on the following 

1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once, local metrics on other nodes 
are zero.
5)Read-only 'invoke' metric is incremented if processor invoke operation is 
called without executing entry.setValue(...) (even calling entry.getValue() can 
be omit), processor can return non-null value.Also, cache might be empty while 
processor invocation.
6)'invoke removal' metric is incremented only if old cache value exists and 
removal succeedes.
7)The following metrics are going to be added : total number of invokes, number 
of invoke updates, number of invoke removals, number of read-only invokes, 
min\max\avg number of invocations(all invocations).

Do you think its correct?


was (Author: alexey kuznetsov):
While implementing the task i rely on the following 
1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once, local metrics on other nodes 
are zero.
5)Read-only 'invoke' metric is incremented if processor invoke operation is 
called without executing entry.setValue(...) (even calling entry.getValue() can 
be omit), processor can return non-null value.Also, cache might be empty while 
processor invocation.
6)'invoke removal' metric is incremented only if old cache value exists and 
removal succeedes.
7)The following metrics are going to be added : total number of invokes, number 
of invoke updates, number of invoke removals, number of read-only invokes, 
min\max\avg number of invocations(all invocations).

Do you think its correct?

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov edited comment on IGNITE-6846 at 11/28/17 10:39 AM:
-

While implementing the task i rely on the following 
1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once, local metrics on other nodes 
are zero.
5)Read-only 'invoke' metric is incremented if processor invoke operation is 
called without executing entry.setValue(...) (even calling entry.getValue() can 
be omit), processor can return non-null value.Also, cache might be empty while 
processor invocation.
6)'invoke removal' metric is incremented only if old cache value exists and 
removal succeedes.
7)The following metrics are going to be added : total number of invokes, number 
of invoke updates, number of invoke removals, number of read-only invokes, 
min\max\avg number of invocations(all invocations).

Do you think its correct?


was (Author: alexey kuznetsov):
1)When entry is updated, both 'invoke update' and get\put\remove metrics can be 
updated.
2)When entry processor is invoked, but cache entry isn't affected, then invoke 
metric isn't incremented.
3)'invoke update' metrics incremented only when cache entry value is changed(or 
removed) by entry processor(not just when entry processor is invoked).
4)If entry processor process(...) is called once, and multiple entries(perhaps 
on different nodes) are affected, then local invoke metric is incremented only 
once, cluster global metric is incremented once, local metrics on other nodes 
are zero.
5)Read-only 'invoke' metric is incremented if processor invoke operation is 
called without executing entry.setValue(...) (even calling entry.getValue() can 
be omit), processor can return non-null value.Also, cache might be empty while 
processor invocation.
6)'invoke removal' metric is incremented only if old cache value exists and 
removal succeedes.
7)The following metrics are going to be added : total number of invokes, number 
of invoke updates, number of invoke removals, number of read-only invokes, 
min\max\avg number of invocations(all invocations).

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



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-7041) Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy

[Pavel Konstantinov (JIRA)]

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

Pavel Konstantinov commented on IGNITE-7041:


Already fixed in issue https://issues.apache.org/jira/browse/IGNITE-6995

> Web Console: Incorrect code generation in case if cache has eviction policy 
> and near cache with eviction policy
> ---
>
> Key: IGNITE-7041
> URL: https://issues.apache.org/jira/browse/IGNITE-7041
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Pavel Konstantinov
>
> In case if cache has eviction policy and also near cache configuration with 
> eviction policy then generated code contains an error - the same variable is 
> used to define two different eviction policy types
> {code}
> public static CacheConfiguration cacheDepartmentCache() throws Exception {
> CacheConfiguration ccfg = new CacheConfiguration();
> 
> .
> LruEvictionPolicy evictionPlc = new LruEvictionPolicy();
> evictionPlc.setBatchSize(5);
> evictionPlc.setMaxSize(100);
> ccfg.setEvictionPolicy(evictionPlc);
>
> .
> NearCacheConfiguration nearConfiguration = new 
> NearCacheConfiguration();
> nearConfiguration.setNearStartSize(4545);
> evictionPlc = new SortedEvictionPolicy();-  THIS ROW IS 
> INCORRECT
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-7041) Web Console: Incorrect code generation in case if cache has eviction policy and near cache with eviction policy

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-7041:
--

 Summary: Web Console: Incorrect code generation in case if cache 
has eviction policy and near cache with eviction policy
 Key: IGNITE-7041
 URL: https://issues.apache.org/jira/browse/IGNITE-7041
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Pavel Konstantinov


In case if cache has eviction policy and also near cache configuration with 
eviction policy then generated code contains an error - the same variable is 
used to define two different eviction policy types
{code}
public static CacheConfiguration cacheDepartmentCache() throws Exception {
CacheConfiguration ccfg = new CacheConfiguration();

.

LruEvictionPolicy evictionPlc = new LruEvictionPolicy();

evictionPlc.setBatchSize(5);
evictionPlc.setMaxSize(100);

ccfg.setEvictionPolicy(evictionPlc);
   
.

NearCacheConfiguration nearConfiguration = new NearCacheConfiguration();

nearConfiguration.setNearStartSize(4545);

evictionPlc = new SortedEvictionPolicy();-  THIS ROW IS 
INCORRECT
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-3084) Spark Data Frames Support in Apache Ignite

[Nikolay Izhikov (JIRA)]

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

Nikolay Izhikov commented on IGNITE-3084:
-

We can't have IgniteCatalog for 2.1 version of spark.
So I propose to update spark dependencies for module {{spark}} to 2.2.0 in this 
task.

1. To setup IgniteCatalog we need to override `SharedState.externalCatalog` 
val. So spark can lookup Ignite tables.
2. externalCatalog is null while SharedState instance initialized.  
[https://docs.scala-lang.org/tutorials/FAQ/initialization-order.html]
3. externalCatalog is used in internal initializer - 
[SharedState.scala|https://github.com/apache/spark/blob/v2.1.2/sql/core/src/main/scala/org/apache/spark/sql/internal/SharedState.scala#L96]
4. In 2.2.0 version SharedState.scala fixed in the way that allow override of 
externalCatalog - 
[SharedState-2.2.0|https://github.com/apache/spark/blob/v2.2.0/sql/core/src/main/scala/org/apache/spark/sql/internal/SharedState.scala#L93]

{code:scala}
  {
val defaultDbDefinition = CatalogDatabase(
  SessionCatalog.DEFAULT_DATABASE, "default database", warehousePath, Map())
if (!externalCatalog.databaseExists(SessionCatalog.DEFAULT_DATABASE)) { // 
<-- Problem is here! externalCatalog == null if we override it.
  externalCatalog.createDatabase(defaultDbDefinition, ignoreIfExists = true)
}
  }
{code}

> Spark Data Frames Support in Apache Ignite
> --
>
> Key: IGNITE-3084
> URL: https://issues.apache.org/jira/browse/IGNITE-3084
> Project: Ignite
>  Issue Type: Task
>  Components: spark
>Affects Versions: 1.5.0.final
>Reporter: Vladimir Ozerov
>Assignee: Nikolay Izhikov
>  Labels: bigdata
> Fix For: 2.4
>
>
> Apache Spark already benefits from integration with Apache Ignite. The latter 
> provides shared RDDs, an implementation of Spark RDD, that help Spark to 
> share a state between Spark workers and execute SQL queries much faster. The 
> next logical step is to enable support for modern Spark Data Frames API in a 
> similar way.
> As a contributor, you will be fully in charge of the integration of Spark 
> Data Frame API and Apache Ignite.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (IGNITE-6995) Visor CMD: Actualize showed grid/cache configuration.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko commented on IGNITE-6995:
---

Implemented configuration of eviction policy by factory.

> Visor CMD: Actualize showed grid/cache configuration.
> -
>
> Key: IGNITE-6995
> URL: https://issues.apache.org/jira/browse/IGNITE-6995
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>
> Actualise in accordance to IGNITE-6649 changes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6995) Visor CMD: Actualize showed grid/cache configuration.

[Vasiliy Sisko (JIRA)]

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

Vasiliy Sisko reassigned IGNITE-6995:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Visor CMD: Actualize showed grid/cache configuration.
> -
>
> Key: IGNITE-6995
> URL: https://issues.apache.org/jira/browse/IGNITE-6995
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>
> Actualise in accordance to IGNITE-6649 changes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7011) Web console: add more tests

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7011:
-
Description: 
Web console does not have enough test coverage, let's fix that.

Rough plan:
1. Choose E2E testing framework.
2. Investigate/implement mechanism for reproducible test environment (backend 
DB, running web-agent and Ignite clusters).
3. Write some reproducible tests.
4. Setup CI.

  was:Web console does not have enough test coverage, let's fix that.


> Web console: add more tests
> ---
>
> Key: IGNITE-7011
> URL: https://issues.apache.org/jira/browse/IGNITE-7011
> Project: Ignite
>  Issue Type: Improvement
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
>
> Web console does not have enough test coverage, let's fix that.
> Rough plan:
> 1. Choose E2E testing framework.
> 2. Investigate/implement mechanism for reproducible test environment (backend 
> DB, running web-agent and Ignite clusters).
> 3. Write some reproducible tests.
> 4. Setup CI.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7012) Web console: investigate E2E tests

[Ilya Borisov (JIRA)]

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

Ilya Borisov updated IGNITE-7012:
-
Description: 
Investigate what tools we can use to implement E2E tests and try some of them 
out. I think that testcafe will be a good start:
https://github.com/DevExpress/testcafe
https://github.com/DevExpress/testcafe-angular-selectors
http://devexpress.github.io/testcafe/documentation/test-api/authentication/user-roles.html

  was:
Investigate what tools we can use to implement E2E tests and try some of them 
out. I think that testcafe will be a good start:
https://github.com/DevExpress/testcafe
https://github.com/DevExpress/testcafe-angular-selectors


> Web console: investigate E2E tests
> --
>
> Key: IGNITE-7012
> URL: https://issues.apache.org/jira/browse/IGNITE-7012
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Ilya Borisov
>Assignee: Alexander Kalinin
>Priority: Minor
>
> Investigate what tools we can use to implement E2E tests and try some of them 
> out. I think that testcafe will be a good start:
> https://github.com/DevExpress/testcafe
> https://github.com/DevExpress/testcafe-angular-selectors
> http://devexpress.github.io/testcafe/documentation/test-api/authentication/user-roles.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-4454) Web console: add information on query panel UI about node query was executed on

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-4454:


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

Looks good. Merged to master.

> Web console: add information on query panel  UI about node query was executed 
> on
> 
>
> Key: IGNITE-4454
> URL: https://issues.apache.org/jira/browse/IGNITE-4454
> Project: Ignite
>  Issue Type: Task
>  Components: wizards
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.4
>
>
> Currently we show only query text  and do not show node in case of 'Execute 
> on selected node'



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[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=16268459#comment-16268459
 ] 

Michael Griggs commented on IGNITE-6069:


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
>
> 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
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6987) Visor CMD: Config command should show client connector pool size.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6987:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good. Please test in branch ignite-6987.

> Visor CMD: Config command should show client connector pool size.
> -
>
> Key: IGNITE-6987
> URL: https://issues.apache.org/jira/browse/IGNITE-6987
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Now show size for deprecated SqlConnectorConfiguration.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (IGNITE-6999) Add a flag for Visor batch mode to output only command results without additional info.

[Alexey Kuznetsov (JIRA)]

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

Alexey Kuznetsov reassigned IGNITE-6999:


Assignee: Pavel Konstantinov  (was: Alexey Kuznetsov)

Looks good for me. Please test.

> Add a flag for Visor batch mode to output only command results without 
> additional info.
> ---
>
> Key: IGNITE-6999
> URL: https://issues.apache.org/jira/browse/IGNITE-6999
> Project: Ignite
>  Issue Type: New Feature
>  Components: visor
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Pavel Konstantinov
> Fix For: 2.4
>
>
> Currently, in batch mode, Visor Command Line simply run supplied commands one 
> by one as if they were entered from the keyboard which results in a quite 
> verbose output.
> A new flag should be introduced like {{--silent}} to suppress additional info 
> output and left only output related directly to the executed commands.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7024) Introduce some kind of network compression

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-7024:
---
Fix Version/s: 2.4

> Introduce some kind of network compression
> --
>
> Key: IGNITE-7024
> URL: https://issues.apache.org/jira/browse/IGNITE-7024
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
> Fix For: 2.4
>
>
> Introduce some kind of pluggable compression at network level
> The main idea is using in-line compression and writes encoded bytes in
> network channel by bytes array buffer. It allows us avoiding expensive
> memory allocation.
> A solution may be implemented at TcpCommunicationSpi level.
> For example, introduce Compressor interface which will allow us to describe 
> our compression strategy, for example, exclude some small messages, choose 
> compression algorithm and other…



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (IGNITE-7024) Introduce some kind of network compression

[Vyacheslav Daradur (JIRA)]

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

Vyacheslav Daradur updated IGNITE-7024:
---
Affects Version/s: 2.3

> Introduce some kind of network compression
> --
>
> Key: IGNITE-7024
> URL: https://issues.apache.org/jira/browse/IGNITE-7024
> Project: Ignite
>  Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
> Fix For: 2.4
>
>
> Introduce some kind of pluggable compression at network level
> The main idea is using in-line compression and writes encoded bytes in
> network channel by bytes array buffer. It allows us avoiding expensive
> memory allocation.
> A solution may be implemented at TcpCommunicationSpi level.
> For example, introduce Compressor interface which will allow us to describe 
> our compression strategy, for example, exclude some small messages, choose 
> compression algorithm and other…



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)