[jira] [Created] (IGNITE-9305) Wrong off-heap size is reported for a node
Denis Magda created IGNITE-9305:
---
Summary: Wrong off-heap size is reported for a node
Key: IGNITE-9305
URL: https://issues.apache.org/jira/browse/IGNITE-9305
Project: Ignite
Issue Type: Task
Affects Versions: 2.6
Reporter: Denis Magda
Fix For: 2.7
Was troubleshooting an Ignite deployment today and couldn't find out from the
logs what was the actual off-heap space used.
Those were the given memory resoures (Ignite 2.6):
{code}
[2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology snapshot
[ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
{code}
And that weird stuff was reported by the node (pay attention to the last line):
{code}
[2018-08-16 15:45:50,211][INFO
][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
^-- H/N/C [hosts=1, nodes=1, CPUs=64]
^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
^-- PageMemory [pages=6997377]
^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
same!
{code}
Had to change the code by using {code}dataRegion.getPhysicalMemoryPages(){code}
to find out that actual off-heap usage size was
{code}
>>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
{code}
The logs have to report the following instead:
{code}
^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
free=X%, comm=dataRegion1.maxSize()]
^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
free=X%, comm=dataRegion2.maxSize()]
{code}
If Ignite persistence is enabled then the following extra lines have to be
added to see the disk used space:
{code}
^-- Off-heap {Data Region 1}: used={dataRegion1.getTotalAllocatedSize() -
dataRegion1.getPhysicalMemorySize()}
^-- Off-heap {Data Region 2} [used={dataRegion2.getTotalAllocatedSize() -
dataRegion2.getPhysicalMemorySize()}]
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9305) Wrong off-heap size is reported for a node
[
https://issues.apache.org/jira/browse/IGNITE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-9305:
Description:
Was troubleshooting an Ignite deployment today and couldn't find out from the
logs what was the actual off-heap space used.
Those were the given memory resoures (Ignite 2.6):
{code}
[2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology snapshot
[ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
{code}
And that weird stuff was reported by the node (pay attention to the last line):
{code}
[2018-08-16 15:45:50,211][INFO
][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
^-- H/N/C [hosts=1, nodes=1, CPUs=64]
^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
^-- PageMemory [pages=6997377]
^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
same!
{code}
Had to change the code by using {code}dataRegion.getPhysicalMemoryPages(){code}
to find out that actual off-heap usage size was
{code}
>>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
{code}
The logs have to report the following instead:
{code}
^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
free=X%, comm=dataRegion1.maxSize()]
^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
free=X%, comm=dataRegion2.maxSize()]
{code}
If Ignite persistence is enabled then the following extra lines have to be
added to see the disk used space:
{code}
^-- Ignite persistence {Data Region 1}:
used={dataRegion1.getTotalAllocatedSize() - dataRegion1.getPhysicalMemorySize()}
^-- Ignite persistence {Data Region 2}
[used={dataRegion2.getTotalAllocatedSize() -
dataRegion2.getPhysicalMemorySize()}]
{code}
was:
Was troubleshooting an Ignite deployment today and couldn't find out from the
logs what was the actual off-heap space used.
Those were the given memory resoures (Ignite 2.6):
{code}
[2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology snapshot
[ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
{code}
And that weird stuff was reported by the node (pay attention to the last line):
{code}
[2018-08-16 15:45:50,211][INFO
][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
^-- H/N/C [hosts=1, nodes=1, CPUs=64]
^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
^-- PageMemory [pages=6997377]
^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
same!
{code}
Had to change the code by using {code}dataRegion.getPhysicalMemoryPages(){code}
to find out that actual off-heap usage size was
{code}
>>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
{code}
The logs have to report the following instead:
{code}
^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
free=X%, comm=dataRegion1.maxSize()]
^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
free=X%, comm=dataRegion2.maxSize()]
{code}
If Ignite persistence is enabled then the following extra lines have to be
added to see the disk used space:
{code}
^-- Off-heap {Data Region 1}: used={dataRegion1.getTotalAllocatedSize() -
dataRegion1.getPhysicalMemorySize()}
^-- Off-heap {Data Region 2} [used={dataRegion2.getTotalAllocatedSize() -
dataRegion2.getPhysicalMemorySize()}]
{code}
> Wrong off-heap size is reported for a node
> --
>
> Key: IGNITE-9305
> URL: https://issues.apache.org/jira/browse/IGNITE-9305
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Denis Magda
>Priority: Blocker
> Fix For: 2.7
>
>
> Was troubleshooting an Ignite deployment today and couldn't find out from the
> logs what was the actual off-heap space used.
> Those were the given memory resoures (Ignite 2.6):
> {code}
> [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology
> snapshot [ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
> {code}
> And that weird stuff was reported by the node (pay attention to the last
> line):
> {code}
> [2018-08-16 15:45:50,211][INFO
> ][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=64]
> ^-- CPU
[jira] [Commented] (IGNITE-9031) SpringCacheManager throws AssertionError during Spring initialization
[ https://issues.apache.org/jira/browse/IGNITE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583218#comment-16583218 ] ASF GitHub Bot commented on IGNITE-9031: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4511 > SpringCacheManager throws AssertionError during Spring initialization > - > > Key: IGNITE-9031 > URL: https://issues.apache.org/jira/browse/IGNITE-9031 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Joel Lang >Assignee: Amir Akhmedov >Priority: Major > Fix For: 2.7 > > > When initializing Ignite using an IgniteSpringBean and also having a > SpringCacheManager defined, the SpringCacheManager throws an AssertionError > in the onApplicationEvent() method due to it being called more than once. > There is an "assert ignite == null" that fails after the first call. > This is related to the changes in IGNITE-8740. This happened immediately when > I first tried to start Ignite after upgrading from 2.5 to 2.6. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9031) SpringCacheManager throws AssertionError during Spring initialization
[ https://issues.apache.org/jira/browse/IGNITE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-9031. --- > SpringCacheManager throws AssertionError during Spring initialization > - > > Key: IGNITE-9031 > URL: https://issues.apache.org/jira/browse/IGNITE-9031 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Joel Lang >Assignee: Amir Akhmedov >Priority: Major > Fix For: 2.7 > > > When initializing Ignite using an IgniteSpringBean and also having a > SpringCacheManager defined, the SpringCacheManager throws an AssertionError > in the onApplicationEvent() method due to it being called more than once. > There is an "assert ignite == null" that fails after the first call. > This is related to the changes in IGNITE-8740. This happened immediately when > I first tried to start Ignite after upgrading from 2.5 to 2.6. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9031) SpringCacheManager throws AssertionError during Spring initialization
[ https://issues.apache.org/jira/browse/IGNITE-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-9031: Fix Version/s: 2.7 > SpringCacheManager throws AssertionError during Spring initialization > - > > Key: IGNITE-9031 > URL: https://issues.apache.org/jira/browse/IGNITE-9031 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.6 >Reporter: Joel Lang >Assignee: Amir Akhmedov >Priority: Major > Fix For: 2.7 > > > When initializing Ignite using an IgniteSpringBean and also having a > SpringCacheManager defined, the SpringCacheManager throws an AssertionError > in the onApplicationEvent() method due to it being called more than once. > There is an "assert ignite == null" that fails after the first call. > This is related to the changes in IGNITE-8740. This happened immediately when > I first tried to start Ignite after upgrading from 2.5 to 2.6. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9295) Add Warning message for multiple data streamers
[
https://issues.apache.org/jira/browse/IGNITE-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9295:
--
Description:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of IgniteDataStreamer.
For best performance use a single instance and share it between threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method (we should update the Javadoc as well):
{quote}You are using IgniteDataStreamer.addData(key, value) method.
For best performance use addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
was:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of IgniteDataStreamer.
For best performance use a single instance and share it between threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method:
{quote}You are using IgniteDataStreamer.addData(key, value) method.
For best performance use addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
> Add Warning message for multiple data streamers
> ---
>
> Key: IGNITE-9295
> URL: https://issues.apache.org/jira/browse/IGNITE-9295
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Gerus
>Priority: Major
> Fix For: 2.7
>
>
> DataStreamer is design to allocate as much resources as available. In case if
> user is starting more then one instance per cache, it can cause significant
> slowdown for the streaming due to significant consumption of resources
> The proposal is to add warning message to the application log in case if two
> or more data streamers per cache:
> {quote}You are running multiple instances of IgniteDataStreamer.
> For best performance use a single instance and share it between threads.
> {quote}
> Also, if user is using addData(key, value) method, we should print a warning
> suggesting to use addData(Map) method (we should update the Javadoc as well):
> {quote}You are using IgniteDataStreamer.addData(key, value) method.
> For best performance use addData(Map) method.
> {quote}
> Each of these warnings should be printed only once, the 1st time such a case
> was detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9294) StandaloneWalRecordsIterator: support iteration from custom pointer
[ https://issues.apache.org/jira/browse/IGNITE-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583051#comment-16583051 ] ASF GitHub Bot commented on IGNITE-9294: GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/4563 IGNITE-9294 Implement bounds for StandAloneWALIterator You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9294 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4563.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 #4563 commit 6c8e731ca75b2c628a3fc40c60501d374145db13 Author: Dmitriy Govorukhin Date: 2018-08-16T20:51:13Z IGNITE-9294 Implement bound for StandAloneIterator. Replay WAL form/to/between. + test > StandaloneWalRecordsIterator: support iteration from custom pointer > --- > > Key: IGNITE-9294 > URL: https://issues.apache.org/jira/browse/IGNITE-9294 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ivan Rakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > StandaloneWalRecordsIterator can be constructed from set of files and dirs, > but there's no option to pass WAL pointer to the iterator factory class to > start iteration with. It can be worked around (by filtering all records prior > to needed pointer), but also it would be handy to add such option to > IgniteWalIteratorFactory API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9294) StandaloneWalRecordsIterator: support iteration from custom pointer
[ https://issues.apache.org/jira/browse/IGNITE-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-9294: -- Assignee: Dmitriy Govorukhin > StandaloneWalRecordsIterator: support iteration from custom pointer > --- > > Key: IGNITE-9294 > URL: https://issues.apache.org/jira/browse/IGNITE-9294 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ivan Rakov >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.7 > > > StandaloneWalRecordsIterator can be constructed from set of files and dirs, > but there's no option to pass WAL pointer to the iterator factory class to > start iteration with. It can be worked around (by filtering all records prior > to needed pointer), but also it would be handy to add such option to > IgniteWalIteratorFactory API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9294) StandaloneWalRecordsIterator: support iteration from custom pointer
[ https://issues.apache.org/jira/browse/IGNITE-9294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9294: --- Fix Version/s: 2.7 > StandaloneWalRecordsIterator: support iteration from custom pointer > --- > > Key: IGNITE-9294 > URL: https://issues.apache.org/jira/browse/IGNITE-9294 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Ivan Rakov >Priority: Major > Fix For: 2.7 > > > StandaloneWalRecordsIterator can be constructed from set of files and dirs, > but there's no option to pass WAL pointer to the iterator factory class to > start iteration with. It can be worked around (by filtering all records prior > to needed pointer), but also it would be handy to add such option to > IgniteWalIteratorFactory API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9295) Add Warning message for multiple data streamers
[
https://issues.apache.org/jira/browse/IGNITE-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9295:
--
Description:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of IgniteDataStreamer.
For best performance use a single instance and share it between threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method:
{quote}You are using IgniteDataStreamer.addData(key, value) method.
For best performance use addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
was:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of DataStreamer.
For best performance use a single instance and share it between multiple
threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method:
{quote}You are using DataStreamer.addData(key, value) method.
For best performance use DataStreamer.addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
> Add Warning message for multiple data streamers
> ---
>
> Key: IGNITE-9295
> URL: https://issues.apache.org/jira/browse/IGNITE-9295
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Gerus
>Priority: Major
> Fix For: 2.7
>
>
> DataStreamer is design to allocate as much resources as available. In case if
> user is starting more then one instance per cache, it can cause significant
> slowdown for the streaming due to significant consumption of resources
> The proposal is to add warning message to the application log in case if two
> or more data streamers per cache:
> {quote}You are running multiple instances of IgniteDataStreamer.
> For best performance use a single instance and share it between threads.
> {quote}
> Also, if user is using addData(key, value) method, we should print a warning
> suggesting to use addData(Map) method:
> {quote}You are using IgniteDataStreamer.addData(key, value) method.
> For best performance use addData(Map) method.
> {quote}
> Each of these warnings should be printed only once, the 1st time such a case
> was detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9295) Add Warning message for multiple data streamers
[
https://issues.apache.org/jira/browse/IGNITE-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9295:
--
Description:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of DataStreamer.
For best performance use a single instance and share it between multiple
threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method:
{quote}You are using DataStreamer.addData(key, value) method.
For best performance use DataStreamer.addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
was:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of the DataStreamer.
For best performance use a single instance and share it between multiple
threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method:
{quote}You are using DataStreamer.addData(key, value) method.
For best performance use DataStreamer.addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
> Add Warning message for multiple data streamers
> ---
>
> Key: IGNITE-9295
> URL: https://issues.apache.org/jira/browse/IGNITE-9295
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Gerus
>Priority: Major
> Fix For: 2.7
>
>
> DataStreamer is design to allocate as much resources as available. In case if
> user is starting more then one instance per cache, it can cause significant
> slowdown for the streaming due to significant consumption of resources
> The proposal is to add warning message to the application log in case if two
> or more data streamers per cache:
> {quote}You are running multiple instances of DataStreamer.
> For best performance use a single instance and share it between multiple
> threads.
> {quote}
> Also, if user is using addData(key, value) method, we should print a warning
> suggesting to use addData(Map) method:
> {quote}You are using DataStreamer.addData(key, value) method.
> For best performance use DataStreamer.addData(Map) method.
> {quote}
> Each of these warnings should be printed only once, the 1st time such a case
> was detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9295) Add Warning message for multiple data streamers
[
https://issues.apache.org/jira/browse/IGNITE-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-9295:
--
Description:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
{quote}You are running multiple instances of the DataStreamer.
For best performance use a single instance and share it between multiple
threads.
{quote}
Also, if user is using addData(key, value) method, we should print a warning
suggesting to use addData(Map) method:
{quote}You are using DataStreamer.addData(key, value) method.
For best performance use DataStreamer.addData(Map) method.
{quote}
Each of these warnings should be printed only once, the 1st time such a case
was detected.
was:
DataStreamer is design to allocate as much resources as available. In case if
user is starting more then one instance per cache, it can cause significant
slowdown for the streaming due to significant consumption of resources
The proposal is to add warning message to the application log in case if two or
more data streamers per cache:
Warning Text: “DataStreamer is already running. For best performance please use
single instance”
The warning should be printed only once when the case is detected
> Add Warning message for multiple data streamers
> ---
>
> Key: IGNITE-9295
> URL: https://issues.apache.org/jira/browse/IGNITE-9295
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Gerus
>Priority: Major
> Fix For: 2.7
>
>
> DataStreamer is design to allocate as much resources as available. In case if
> user is starting more then one instance per cache, it can cause significant
> slowdown for the streaming due to significant consumption of resources
> The proposal is to add warning message to the application log in case if two
> or more data streamers per cache:
> {quote}You are running multiple instances of the DataStreamer.
> For best performance use a single instance and share it between multiple
> threads.
> {quote}
> Also, if user is using addData(key, value) method, we should print a warning
> suggesting to use addData(Map) method:
> {quote}You are using DataStreamer.addData(key, value) method.
> For best performance use DataStreamer.addData(Map) method.
> {quote}
> Each of these warnings should be printed only once, the 1st time such a case
> was detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9169) Cache (Deadlock Detection) suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-9169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582976#comment-16582976
]
Eduard Shangareev commented on IGNITE-9169:
---
Ok, I see.
Looks good, should fix the issue.
Thank you, Vitaliy.
[~dpavlov], [~agoncharuk], please, help with merge.
> Cache (Deadlock Detection) suite hangs
> --
>
> Key: IGNITE-9169
> URL: https://issues.apache.org/jira/browse/IGNITE-9169
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: threads_report.txt
>
>
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7f289800e000 nid=0x67bb in Object.wait()
> [0x7f289f9dc000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1252)
> - locked <0x849c82b0> (a
> org.apache.ignite.testframework.GridTestSafeThreadFactory$1)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4621)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4606)
> at
> org.apache.ignite.internal.util.IgniteUtils.joinThreads(IgniteUtils.java:4650)
> at
> org.apache.ignite.testframework.GridTestSafeThreadFactory.stopAllThreads(GridTestSafeThreadFactory.java:206)
> at
> org.apache.ignite.testframework.GridTestUtils.stopThreads(GridTestUtils.java:985)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1705)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> 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:369)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
> 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
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
> at
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:84)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1107)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
>
[jira] [Commented] (IGNITE-9169) Cache (Deadlock Detection) suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-9169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582934#comment-16582934
]
Vitaliy Biryukov commented on IGNITE-9169:
--
[~EdShangGG] , *TxOptimisticDeadlockDetectionTest* and
*TxPessimisticDeadlockDetectionTest* start transactions and generate deadlock
between them. Sometimes these tests hang because of unexpected PME during
transactions. This PME caused by late affinity assignment after cache start.
I've added waiting for assignment right after cache start to prevent this
unexpected PME.
> Cache (Deadlock Detection) suite hangs
> --
>
> Key: IGNITE-9169
> URL: https://issues.apache.org/jira/browse/IGNITE-9169
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: threads_report.txt
>
>
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7f289800e000 nid=0x67bb in Object.wait()
> [0x7f289f9dc000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1252)
> - locked <0x849c82b0> (a
> org.apache.ignite.testframework.GridTestSafeThreadFactory$1)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4621)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4606)
> at
> org.apache.ignite.internal.util.IgniteUtils.joinThreads(IgniteUtils.java:4650)
> at
> org.apache.ignite.testframework.GridTestSafeThreadFactory.stopAllThreads(GridTestSafeThreadFactory.java:206)
> at
> org.apache.ignite.testframework.GridTestUtils.stopThreads(GridTestUtils.java:985)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1705)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> 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:369)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
> 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
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
> at
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:84)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1107)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
>
[jira] [Assigned] (IGNITE-9304) AssertionError while updating ATOMIC cache while topology changes
[
https://issues.apache.org/jira/browse/IGNITE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev reassigned IGNITE-9304:
-
Assignee: Eduard Shangareev
> AssertionError while updating ATOMIC cache while topology changes
> -
>
> Key: IGNITE-9304
> URL: https://issues.apache.org/jira/browse/IGNITE-9304
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> I have reproduced it with
> CacheContinuousQueryFailoverAbstractSelfTest#testMultiThreadedFailover.
> {code}
> java.lang.AssertionError: Assertion error on search row:
> org.apache.ignite.internal.processors.cache.tree.SearchRow@257eba3
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1655)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1306)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:381)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1789)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2471)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1930)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1772)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1662)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3111)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:133)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:269)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:264)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:275)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AssertionError: Invalid version for inner update
> [isNew=false, entry=GridDhtCacheEntry [rdrs=ReaderId[] [], part=2,
> super=GridDistributedCacheEntry [super=CacheObjectImpl [val=null,
> hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true],
> ver=GridCacheVersion [topVer=145812931, order=1534332978541, nodeOrder=37],
> hash=2, extras=null, flags=0]]], newVer=GridCacheVersion [topVer=145812931,
> order=1534332978538, nodeOrder=43]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.versionCheck(GridCacheMapEntry.java:5397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4778)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4562)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3104)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2998)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1744)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1622)
> ... 20 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9304) AssertionError while updating ATOMIC cache while topology changes
Eduard Shangareev created IGNITE-9304:
-
Summary: AssertionError while updating ATOMIC cache while topology
changes
Key: IGNITE-9304
URL: https://issues.apache.org/jira/browse/IGNITE-9304
Project: Ignite
Issue Type: Bug
Reporter: Eduard Shangareev
I have reproduced it with
CacheContinuousQueryFailoverAbstractSelfTest#testMultiThreadedFailover.
{code}
java.lang.AssertionError: Assertion error on search row:
org.apache.ignite.internal.processors.cache.tree.SearchRow@257eba3
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1655)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1306)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:381)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1789)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2471)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:1930)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1772)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1662)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3111)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:133)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:269)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:264)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:275)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.AssertionError: Invalid version for inner update
[isNew=false, entry=GridDhtCacheEntry [rdrs=ReaderId[] [], part=2,
super=GridDistributedCacheEntry [super=CacheObjectImpl [val=null,
hasValBytes=true]CacheObjectImpl [val=null, hasValBytes=true],
ver=GridCacheVersion [topVer=145812931, order=1534332978541, nodeOrder=37],
hash=2, extras=null, flags=0]]], newVer=GridCacheVersion [topVer=145812931,
order=1534332978538, nodeOrder=43]]
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.versionCheck(GridCacheMapEntry.java:5397)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4778)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:4562)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3104)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$6200(BPlusTree.java:2998)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:1744)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1622)
... 20 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
Aleksey Plekhanov created IGNITE-9303:
-
Summary: PageSnapshot can contain wrong pageId tag when not dirty
page is recycling
Key: IGNITE-9303
URL: https://issues.apache.org/jira/browse/IGNITE-9303
Project: Ignite
Issue Type: Bug
Affects Versions: 2.6
Reporter: Aleksey Plekhanov
When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
/** {@inheritDoc} */
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
/**
*
*/
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9303) PageSnapshot can contain wrong pageId tag when not dirty page is recycling
[
https://issues.apache.org/jira/browse/IGNITE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9303:
--
Description:
When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
was:
When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
{{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
{{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}} is
stored to PageSnapshot WAL record.
This bug may lead to errors in WAL applying during crash recovery.
Reproducer (ignite-indexing module must be in classpath):
{code:java}
public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
/** {@inheritDoc} */
@Override protected boolean checkPagesOnCheckpoint() {
return true;
}
/**
*
*/
public final void testPutRemoveCacheDestroy() throws Exception {
CacheConfiguration ccfg = new
CacheConfiguration<>("cache0");
ccfg.setIndexedTypes(Integer.class, Integer.class);
IgniteEx ignite = startGrid(0);
ignite.cluster().active(true);
IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
for (int i = 0; i < 5_000; i++)
cache0.put(i, i);
forceCheckpoint();
for (int i = 1_000; i < 4_000; i++)
cache0.remove(i);
forceCheckpoint();
stopAllGrids();
}
}
{code}
> PageSnapshot can contain wrong pageId tag when not dirty page is recycling
> --
>
> Key: IGNITE-9303
> URL: https://issues.apache.org/jira/browse/IGNITE-9303
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> When page is recycling (for example in {{BPlusTree.Remove#freePage()}} ->
> {{DataStructure#recyclePage()}}) tag of {{pageId}} is modified, but original
> {{pageId}} is passed to {{writeUnlock()}} method and this passed {{pageId}}
> is stored to PageSnapshot WAL record.
> This bug may lead to errors in WAL applying during crash recovery.
> Reproducer (ignite-indexing module must be in classpath):
> {code:java}
> public class WalFailReproducer extends AbstractWalDeltaConsistencyTest {
> @Override protected boolean checkPagesOnCheckpoint() {
> return true;
> }
> public final void testPutRemoveCacheDestroy() throws Exception {
> CacheConfiguration ccfg = new
> CacheConfiguration<>("cache0");
> ccfg.setIndexedTypes(Integer.class, Integer.class);
> IgniteEx ignite = startGrid(0);
> ignite.cluster().active(true);
> IgniteCache cache0 = ignite.getOrCreateCache(ccfg);
> for (int i = 0; i < 5_000; i++)
> cache0.put(i, i);
> forceCheckpoint();
> for (int i = 1_000; i < 4_000; i++)
> cache0.remove(i);
> forceCheckpoint();
> stopAllGrids();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9266) Cache 2 TC configuration timeouts because of hangs on latch
[
https://issues.apache.org/jira/browse/IGNITE-9266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582842#comment-16582842
]
Eduard Shangareev commented on IGNITE-9266:
---
[~agoncharuk], [~dpavlov], please help with merge.
> Cache 2 TC configuration timeouts because of hangs on latch
> ---
>
> Key: IGNITE-9266
> URL: https://issues.apache.org/jira/browse/IGNITE-9266
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> Two threads hanged on waiting latch because of it
> GridCacheLocalMultithreadedSelfTest couldn't stop.
> https://ci.ignite.apache.org/viewLog.html?buildId=1645216=buildResultsDiv=IgniteTests24Java8_Cache2
> {code}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode):
> "Attach Listener" #2048 daemon prio=9 os_prio=0 tid=0x7f09cc001000
> nid=0x6237 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "sys-#1820%local.GridCacheLocalMultithreadedSelfTest%" #2047 prio=5 os_prio=0
> tid=0x7f089401a000 nid=0x6207 waiting on condition [0x7f09e69ee000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "sys-#1819%local.GridCacheLocalMultithreadedSelfTest%" #2046 prio=5 os_prio=0
> tid=0x7f0894019000 nid=0x6206 waiting on condition [0x7f09e6aef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "sys-#1818%local.GridCacheLocalMultithreadedSelfTest%" #2045 prio=5 os_prio=0
> tid=0x7f0894018000 nid=0x6205 waiting on condition [0x7f09e6bf]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "sys-#1817%local.GridCacheLocalMultithreadedSelfTest%" #2044 prio=5 os_prio=0
> tid=0x7f0894017000 nid=0x6204 waiting on condition [0x7f09e7ffe000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
>
[jira] [Commented] (IGNITE-9266) Cache 2 TC configuration timeouts because of hangs on latch
[
https://issues.apache.org/jira/browse/IGNITE-9266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582823#comment-16582823
]
Anton Kalashnikov commented on IGNITE-9266:
---
Looks good for me. It can be merged to master.
> Cache 2 TC configuration timeouts because of hangs on latch
> ---
>
> Key: IGNITE-9266
> URL: https://issues.apache.org/jira/browse/IGNITE-9266
> Project: Ignite
> Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>
> Two threads hanged on waiting latch because of it
> GridCacheLocalMultithreadedSelfTest couldn't stop.
> https://ci.ignite.apache.org/viewLog.html?buildId=1645216=buildResultsDiv=IgniteTests24Java8_Cache2
> {code}
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode):
> "Attach Listener" #2048 daemon prio=9 os_prio=0 tid=0x7f09cc001000
> nid=0x6237 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "sys-#1820%local.GridCacheLocalMultithreadedSelfTest%" #2047 prio=5 os_prio=0
> tid=0x7f089401a000 nid=0x6207 waiting on condition [0x7f09e69ee000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "sys-#1819%local.GridCacheLocalMultithreadedSelfTest%" #2046 prio=5 os_prio=0
> tid=0x7f0894019000 nid=0x6206 waiting on condition [0x7f09e6aef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "sys-#1818%local.GridCacheLocalMultithreadedSelfTest%" #2045 prio=5 os_prio=0
> tid=0x7f0894018000 nid=0x6205 waiting on condition [0x7f09e6bf]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1073)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> "sys-#1817%local.GridCacheLocalMultithreadedSelfTest%" #2044 prio=5 os_prio=0
> tid=0x7f0894017000 nid=0x6204 waiting on condition [0x7f09e7ffe000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xfad87890> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
> at
>
[jira] [Commented] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
[ https://issues.apache.org/jira/browse/IGNITE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582819#comment-16582819 ] ASF GitHub Bot commented on IGNITE-9302: GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/4562 IGNITE-9302 Java Thin Clients TC configuration hangs because of no ti… …meout on tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9302 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4562.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 #4562 commit 0bcd88ba6f75f52d63f11b2b0a38fb103713b823 Author: EdShangGG Date: 2018-08-16T16:46:15Z IGNITE-9302 Java Thin Clients TC configuration hangs because of no timeout on tests > Java Thin Clients TC configuration hangs because of no timeout on tests > --- > > Key: IGNITE-9302 > URL: https://issues.apache.org/jira/browse/IGNITE-9302 > Project: Ignite > Issue Type: Bug >Reporter: Eduard Shangareev >Assignee: Eduard Shangareev >Priority: Major > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9301) Support method compute withNoResultCache in .Net
[ https://issues.apache.org/jira/browse/IGNITE-9301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-9301: --- Description: During https://issues.apache.org/jira/browse/IGNITE-6284 implementation new method was added - org.apache.ignite.IgniteCompute#withNoResultCache but this method was not supported in .NET API version. It is required to add correct support to .NET. Please remove method name from UnneededMethods in modules/platforms/dotnet/Apache.Ignite.Core.Tests/ApiParity/ComputeParityTest.cs once issue is done was: During https://issues.apache.org/jira/browse/IGNITE-6284 implementation new method was added - org.apache.ignite.IgniteCompute#withNoResultCache but this method was not supported in .NET API version. It is required to add correct support to .NET > Support method compute withNoResultCache in .Net > > > Key: IGNITE-9301 > URL: https://issues.apache.org/jira/browse/IGNITE-9301 > Project: Ignite > Issue Type: Task > Components: platforms >Reporter: Dmitriy Pavlov >Priority: Major > > During https://issues.apache.org/jira/browse/IGNITE-6284 implementation new > method was added - > org.apache.ignite.IgniteCompute#withNoResultCache > but this method was not supported in .NET API version. > It is required to add correct support to .NET. > Please remove method name from UnneededMethods in > modules/platforms/dotnet/Apache.Ignite.Core.Tests/ApiParity/ComputeParityTest.cs > once issue is done -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9053) testReentrantLockConstantTopologyChangeNonFailoverSafe can hang in case of broken tx
[
https://issues.apache.org/jira/browse/IGNITE-9053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582814#comment-16582814
]
Eduard Shangareev commented on IGNITE-9053:
---
Looks good.
> testReentrantLockConstantTopologyChangeNonFailoverSafe can hang in case of
> broken tx
>
>
> Key: IGNITE-9053
> URL: https://issues.apache.org/jira/browse/IGNITE-9053
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Affects Versions: 2.5
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> -GridCachePartitionedDataStructuresFailoverSelfTest#testReentrantLockConstantTopologyChangeNonFailoverSafe
> -GridCachePartitionedDataStructuresFailoverSelfTest#testCountDownLatchConstantTopologyChange
>
> can hang in case of broken tx
> {noformat}
> Pending transactions:
> [2018-07-15 14:13:41,210][WARN
> ][exchange-worker-#1596354%partitioned.GridCachePartitionedDataStructuresFailoverSelfTest1%][diagnostic]
> >>> [txVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], exchWait=true,
> tx=GridDhtTxLocal [nearNodeId=1392b1bd-c807-4479-9bfe-fc9f7050,
> nearFutId=14ffca0a461-999e75d0-a333-4bd6-a2a2-7f143d0af773, nearMiniId=1,
> nearFinFutId=null, nearFinMiniId=0, nearXidVer=GridCacheVersion
> [topVer=143133203, order=1531653200153, nodeOrder=1],
> super=GridDhtTxLocalAdapter [nearOnOriginatingNode=false, nearNodes=[],
> dhtNodes=[], explicitLock=false, super=IgniteTxLocalAdapter
> [completedBase=null, sndTransformedVals=false, depEnabled=false,
> txState=IgniteTxStateImpl [activeCacheIds=[1968300681], recovery=false,
> txMap=[IgniteTxEntry [key=KeyCacheObjectImpl [part=494,
> val=GridCacheInternalKeyImpl [name=structure,
> grpName=default-volatile-ds-group], hasValBytes=true], cacheId=1968300681,
> txKey=IgniteTxKey [key=KeyCacheObjectImpl [part=494,
> val=GridCacheInternalKeyImpl [name=structure,
> grpName=default-volatile-ds-group], hasValBytes=true], cacheId=1968300681],
> val=[op=NOOP, val=null], prevVal=[op=NOOP, val=null], oldVal=[op=NOOP,
> val=null], entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1,
> conflictVer=null, explicitVer=null, dhtVer=null, filters=[],
> filtersPassed=false, filtersSet=false, entry=GridDhtCacheEntry [rdrs=[],
> part=494, super=GridDistributedCacheEntry [super=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=494, val=GridCacheInternalKeyImpl
> [name=structure, grpName=default-volatile-ds-group], hasValBytes=true],
> val=CacheObjectImpl [val=null, hasValBytes=true], ver=GridCacheVersion
> [topVer=143133201, order=1531653200154, nodeOrder=2], hash=2095426867,
> extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc
> [locs=[GridCacheMvccCandidate [nodeId=1bf28b00-feed-412b-a20b-ca9fc111,
> ver=GridCacheVersion [topVer=143133203, order=1531653200157, nodeOrder=2],
> threadId=1947290, id=31143709, topVer=AffinityTopologyVersion [topVer=7,
> minorTopVer=0], reentry=null,
> otherNodeId=1392b1bd-c807-4479-9bfe-fc9f7050, otherVer=GridCacheVersion
> [topVer=143133203, order=1531653200153, nodeOrder=1], mappedDhtNodes=null,
> mappedNearNodes=null, ownerVer=null, serOrder=null, key=KeyCacheObjectImpl
> [part=494, val=GridCacheInternalKeyImpl [name=structure,
> grpName=default-volatile-ds-group], hasValBytes=true],
> masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=0|dht_local=1|near_local=0|removed=0|read=0,
> prevVer=null, nextVer=null]], rmts=null]], flags=2]]], prepared=0,
> locked=false, nodeId=null, locMapped=false, expiryPlc=null,
> transferExpiryPlc=false, flags=0, partUpdateCntr=0, serReadVer=null,
> xidVer=GridCacheVersion [topVer=143133203, order=1531653200157,
> nodeOrder=2, super=IgniteTxAdapter [xidVer=GridCacheVersion
> [topVer=143133203, order=1531653200157, nodeOrder=2], writeVer=null,
> implicit=false, loc=true, threadId=1947290, startTime=1531653200578,
> nodeId=1bf28b00-feed-412b-a20b-ca9fc111, startVer=GridCacheVersion
> [topVer=143133203, order=1531653200157, nodeOrder=2], endVer=null,
> isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, timeout=0,
> sysInvalidate=false, sys=true, plc=2, commitVer=null, finalizing=NONE,
> invalidParts=null, state=ACTIVE, timedOut=false,
> topVer=AffinityTopologyVersion [topVer=7, minorTopVer=0], duration=20632ms,
> onePhaseCommit=false], size=1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-9302) Java Thin Clients TC configuration hangs because of no timeout on tests
Eduard Shangareev created IGNITE-9302: - Summary: Java Thin Clients TC configuration hangs because of no timeout on tests Key: IGNITE-9302 URL: https://issues.apache.org/jira/browse/IGNITE-9302 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev Assignee: Eduard Shangareev https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_JavaThinClient=buildTypeHistoryList_IgniteTests24Java8=__all_branches__ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9301) Support method compute withNoResultCache in .Net
Dmitriy Pavlov created IGNITE-9301: -- Summary: Support method compute withNoResultCache in .Net Key: IGNITE-9301 URL: https://issues.apache.org/jira/browse/IGNITE-9301 Project: Ignite Issue Type: Task Components: platforms Reporter: Dmitriy Pavlov During https://issues.apache.org/jira/browse/IGNITE-6284 implementation new method was added - org.apache.ignite.IgniteCompute#withNoResultCache but this method was not supported in .NET API version. It is required to add correct support to .NET -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-3653) P2P doesn't work for remote filter and filter factory.
[ https://issues.apache.org/jira/browse/IGNITE-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Mekhanikov reassigned IGNITE-3653: Assignee: Denis Mekhanikov > P2P doesn't work for remote filter and filter factory. > -- > > Key: IGNITE-3653 > URL: https://issues.apache.org/jira/browse/IGNITE-3653 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 1.6 >Reporter: Nikolai Tikhonov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.7 > > Attachments: CCP2PTest.patch > > > Remote filter and filter factory classes were not deployed on nodes which > join to cluster after their initialization. Test attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-896) Configuration inconsistency
[ https://issues.apache.org/jira/browse/IGNITE-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582772#comment-16582772 ] ASF GitHub Bot commented on IGNITE-896: --- GitHub user zzzadruga opened a pull request: https://github.com/apache/ignite/pull/4561 IGNITE-896 Configuration inconsistency You can merge this pull request into a Git repository by running: $ git pull https://github.com/zzzadruga/ignite IGNITE-896 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4561.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 #4561 commit 39226745ce2a620d34efe31b5bcbd54508786375 Author: zzzadruga Date: 2018-08-14T17:06:22Z IGNITE-896 Add evictionFilterFactory field, getter and setter. Mark evictionFilter as @deprecated. commit 93eaaccabdc8c778969cfb20dc3bdf60699fb7df Author: zzzadruga Date: 2018-08-14T17:08:33Z IGNITE-896 Add Factory for IgfsEvictionFilter commit 43e4696603e863b668eeb683e62fb5046a34ce1d Author: zzzadruga Date: 2018-08-14T17:10:23Z IGNITE-896 Refactor IgfsHelper commit bf7697d1b13d3e22f5fa284a08ed4dd9ce74bf1b Author: zzzadruga Date: 2018-08-14T17:11:56Z IGNITE-896 Refactor GridCacheEvictionManager commit ed38c977801d7b3fa2da3d69d9c8a329dad9ca93 Author: Nikolai Kulagin Date: 2018-08-15T12:10:48Z IGNITE-896 Add topValidatorFactory field, getter and setter. Mark topValidator as @deprecated commit c31db024012bd9a3dacb3294397a0a277909d1e8 Author: Nikolai Kulagin Date: 2018-08-16T12:36:34Z IGNITE-896 Fix some tests commit f0119237cbcdcc4001fecd1cf2aafb782c26e475 Author: Nikolai Kulagin Date: 2018-08-16T12:58:25Z IGNITE-896 Fix CacheGroupContext commit 97894930038b9c007238cb4af0ecae056f117173 Author: Nikolai Kulagin Date: 2018-08-16T13:02:12Z IGNITE-896 Apply patch [IGNITE-9005, PR 4373] + fix for evictionFilterFactory commit d56bb7ad893cdd5a70b1059f36fcd7a96d8b9928 Author: Nikolai Kulagin Date: 2018-08-16T13:08:49Z IGNITE-896 Fix GridCacheAttributes commit a2731af7475281fabe2289a18a1ee1db26aa3111 Author: Nikolai Kulagin Date: 2018-08-16T13:11:16Z IGNITE-896 Fix VisorCacheConfiguration commit d21485da5d05fe2872563ab8af3680f4dc6b3510 Author: Nikolai Kulagin Date: 2018-08-16T13:20:35Z IGNITE-896 Fix ConfigVariations commit bee2788441dddc0b07f00b03ad32ccc210413b7c Author: Nikolai Kulagin Date: 2018-08-16T15:52:29Z IGNITE-896 Add serialVersionUID in IgfsEvictionFilterFactory commit 485eb16340a8aaef162e391f652d95d5399868d7 Author: Nikolai Kulagin Date: 2018-08-16T15:53:02Z IGNITE-896 Fix ClusterCachesInfo > Configuration inconsistency > --- > > Key: IGNITE-896 > URL: https://issues.apache.org/jira/browse/IGNITE-896 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: sprint-5 >Reporter: Valentin Kulichenko >Assignee: Nikolai Kulagin >Priority: Minor > Labels: Usability > > I noticed that some entities on cache configuration are configured via > factories, while others are set directly. For example, we use factory for > ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since > factory-based approach comes from JCache, I think we should use it wherever > possible. > Here is the list of settings that need to be fixed: > * Affinity > * AffinityMapper > * EvictionFilter > * EvictionPolicy > * CacheInterceptor > * TopologyValidator > Need to add new configuration properties that use factories and deprecate old > ones (do not remove for compatibility). > Also need to check other configuration beans (list above is for cache config > only). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9169) Cache (Deadlock Detection) suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-9169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582771#comment-16582771
]
Vitaliy Biryukov commented on IGNITE-9169:
--
[~EdShangGG], please take a look.
> Cache (Deadlock Detection) suite hangs
> --
>
> Key: IGNITE-9169
> URL: https://issues.apache.org/jira/browse/IGNITE-9169
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Vitaliy Biryukov
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
> Attachments: threads_report.txt
>
>
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7f289800e000 nid=0x67bb in Object.wait()
> [0x7f289f9dc000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Thread.join(Thread.java:1252)
> - locked <0x849c82b0> (a
> org.apache.ignite.testframework.GridTestSafeThreadFactory$1)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4621)
> at
> org.apache.ignite.internal.util.IgniteUtils.join(IgniteUtils.java:4606)
> at
> org.apache.ignite.internal.util.IgniteUtils.joinThreads(IgniteUtils.java:4650)
> at
> org.apache.ignite.testframework.GridTestSafeThreadFactory.stopAllThreads(GridTestSafeThreadFactory.java:206)
> at
> org.apache.ignite.testframework.GridTestUtils.stopThreads(GridTestUtils.java:985)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1705)
> at
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.tearDown(GridCommonAbstractTest.java:497)
> at junit.framework.TestCase.runBare(TestCase.java:146)
> 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:369)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:275)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:239)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:160)
> 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
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:206)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:160)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:83)
> at
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:84)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1107)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:954)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:832)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
[jira] [Updated] (IGNITE-9300) Removal count metric is calculated improperly for transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9300:
Component/s: (was: mvcc)
> Removal count metric is calculated improperly for transactional cache
> -
>
> Key: IGNITE-9300
> URL: https://issues.apache.org/jira/browse/IGNITE-9300
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> For TRANSACTIONAL cache single remove outside of transaction is counted even
> if entry is absent when remove is called. Expected behavior is that such
> remove does not change removal counter.
> {code}
> System.out.println(cache.remove(1)); // false
> System.out.println(cache.metrics().getCacheRemovals()); // 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7165) Re-balancing is cancelled if client node joins
[ https://issues.apache.org/jira/browse/IGNITE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582743#comment-16582743 ] Anton Vinogradov commented on IGNITE-7165: -- [~Mmuzaf] Please link new Issue to this to keep discussion > Re-balancing is cancelled if client node joins > -- > > Key: IGNITE-7165 > URL: https://issues.apache.org/jira/browse/IGNITE-7165 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Cherkasov >Assignee: Maxim Muzafarov >Priority: Critical > Labels: rebalance > Fix For: 2.7 > > Attachments: GridCacheRebalancingCancelTestNoReproduce.java, > node-2-jstack.log, node-NO_REBALANCE-7165.log > > > Re-balancing is canceled if client node joins. Re-balancing can take hours > and each time when client node joins it starts again: > [15:10:05,700][INFO][disco-event-worker-#61%statement_grid%][GridDiscoveryManager] > Added new node to topology: TcpDiscoveryNode > [id=979cf868-1c37-424a-9ad1-12db501f32ef, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1, > 172.31.16.213], sockAddrs=[/0:0:0:0:0:0:0:1:0, /127.0.0.1:0, > /172.31.16.213:0], discPort=0, order=36, intOrder=24, > lastExchangeTime=1512907805688, loc=false, ver=2.3.1#20171129-sha1:4b1ec0fe, > isClient=true] > [15:10:05,701][INFO][disco-event-worker-#61%statement_grid%][GridDiscoveryManager] > Topology snapshot [ver=36, servers=7, clients=5, CPUs=128, heap=160.0GB] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][time] Started > exchange init [topVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > crd=false, evt=NODE_JOINED, evtNode=979cf868-1c37-424a-9ad1-12db501f32ef, > customEvt=null, allowMerge=true] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionsExchangeFuture] > Finish exchange future [startVer=AffinityTopologyVersion [topVer=36, > minorTopVer=0], resVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > err=null] > [15:10:05,702][INFO][exchange-worker-#62%statement_grid%][time] Finished > exchange init [topVer=AffinityTopologyVersion [topVer=36, minorTopVer=0], > crd=false] > [15:10:05,703][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion > [topVer=36, minorTopVer=0], evt=NODE_JOINED, > node=979cf868-1c37-424a-9ad1-12db501f32ef] > [15:10:08,706][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion > [topVer=35, minorTopVer=0]] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Rebalancing scheduled [order=[statementp]] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridCachePartitionExchangeManager] > Rebalancing started [top=null, evt=NODE_JOINED, > node=a8be3c14-9add-48c3-b099-3fd304cfdbf4] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=2f6bde48-ffb5-4815-bd32-df4e57dc13e0, partitionsCount=18, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,707][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=35d01141-4dce-47dd-adf6-a4f3b2bb9da9, partitionsCount=15, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=b3a8be53-e61f-4023-a906-a265923837ba, partitionsCount=15, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=f825cb4e-7dcc-405f-a40d-c1dc1a3ade5a, partitionsCount=12, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=4ae1db91-8b88-4180-a84b-127a303959e9, partitionsCount=11, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > [15:10:08,708][INFO][exchange-worker-#62%statement_grid%][GridDhtPartitionDemander] > Starting rebalancing [mode=ASYNC, > fromNode=7c286481-7638-49e4-8c68-fa6aa65d8b76, partitionsCount=18, > topology=AffinityTopologyVersion [topVer=36, minorTopVer=0], > updateSeq=-1754630006] > so in clusters with a big amount of data and the frequent client left/join > events this means that a new server will never receive its partitions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9300) Removal count metric is calculated improperly for transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9300:
Component/s: mvcc
> Removal count metric is calculated improperly for transactional cache
> -
>
> Key: IGNITE-9300
> URL: https://issues.apache.org/jira/browse/IGNITE-9300
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
>
> For TRANSACTIONAL cache single remove outside of transaction is counted even
> if entry is absent when remove is called. Expected behavior is that such
> remove does not change removal counter.
> {code}
> System.out.println(cache.remove(1)); // false
> System.out.println(cache.metrics().getCacheRemovals()); // 1
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-3479) Coordinator(s) for global transaction ordering
[ https://issues.apache.org/jira/browse/IGNITE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3479: Component/s: mvcc > Coordinator(s) for global transaction ordering > -- > > Key: IGNITE-3479 > URL: https://issues.apache.org/jira/browse/IGNITE-3479 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Alexey Goncharuk >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Current transaction ID will not work for SQL MVCC ordering because two > transaction IDs are not in total order across the cluster. > One of the approaches is to have a dedicated coordinator which will assign a > continuously growing transaction ID for each committed transaction. This ID > must be acquired by each transaction at the last step of PREPARE stage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6149) Create mvcc prototype application
[ https://issues.apache.org/jira/browse/IGNITE-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6149: Component/s: mvcc > Create mvcc prototype application > - > > Key: IGNITE-6149 > URL: https://issues.apache.org/jira/browse/IGNITE-6149 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > Attachments: MvccTestApp.java > > > Need create simple prototype application to verify major concepts: > - which data should be stored on coordinator and on data nodes > - filtering algorithm for getAll and sql operations > - clean up of committed versions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5933) Integrate mvcc support in cache.getAll protocol
[ https://issues.apache.org/jira/browse/IGNITE-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5933: Component/s: mvcc > Integrate mvcc support in cache.getAll protocol > --- > > Key: IGNITE-5933 > URL: https://issues.apache.org/jira/browse/IGNITE-5933 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Need integrate mvcc support in cache.getAll protocol: > - request current ID and list of active txs from coordinator > - pass this info in get requests and in local 'get' > - notify coordinator after getAll completed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3484) MVCC data structure for getAll operation
[ https://issues.apache.org/jira/browse/IGNITE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3484: Component/s: mvcc > MVCC data structure for getAll operation > > > Key: IGNITE-3484 > URL: https://issues.apache.org/jira/browse/IGNITE-3484 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Alexey Goncharuk >Assignee: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Need implement some data structure to store/get multiple entry versions: > - committed value at first is stored in separate data structure (there also > need store related tx id to filter out data for non-finished transactions), > probably existing BPlusTree can be used > - periodically need flush data for finished transaction in 'main' hash index > - 'getAll' operation should include max 'visible' ID and list of active > transactions, this information should be used to find last 'visible' version > in 'mvcc' or 'main' index -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5934) Integrate mvcc support in sql query protocol
[ https://issues.apache.org/jira/browse/IGNITE-5934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5934: Component/s: mvcc > Integrate mvcc support in sql query protocol > > > Key: IGNITE-5934 > URL: https://issues.apache.org/jira/browse/IGNITE-5934 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Semen Boikov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Need integrate mvcc support in sql query protocol: > - request current ID and list of active txs from coordinator > - pass this info in sql requests and in sql queries > - notify coordinator after query completed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6709) Support mvcc filter for H2TreeIndex.findFirstOrLast
[ https://issues.apache.org/jira/browse/IGNITE-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6709: Component/s: mvcc > Support mvcc filter for H2TreeIndex.findFirstOrLast > --- > > Key: IGNITE-6709 > URL: https://issues.apache.org/jira/browse/IGNITE-6709 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Semen Boikov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Need implement possibility to pass filter in findFirst/findLast (test already > exists CacheMvccSqlQueriesTest.testMaxMinTransactional). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6738) Support mvcc filter for local sql queries
[ https://issues.apache.org/jira/browse/IGNITE-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6738: Component/s: mvcc > Support mvcc filter for local sql queries > - > > Key: IGNITE-6738 > URL: https://issues.apache.org/jira/browse/IGNITE-6738 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Semen Boikov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Need receive/release mvcc version for queries with setLocal flag set, there > are already some tests in CacheMvccSqlQueriesTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6875) MVCC: advanced features
[ https://issues.apache.org/jira/browse/IGNITE-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6875: Component/s: mvcc > MVCC: advanced features > --- > > Key: IGNITE-6875 > URL: https://issues.apache.org/jira/browse/IGNITE-6875 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Vladimir Ozerov >Priority: Major > > This is umbrella ticket for advanced MVCC features, focusing on failover, > performance, scan queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6929) Preserve mvcc versions on index rebuild
[
https://issues.apache.org/jira/browse/IGNITE-6929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6929:
Component/s: mvcc
> Preserve mvcc versions on index rebuild
> ---
>
> Key: IGNITE-6929
> URL: https://issues.apache.org/jira/browse/IGNITE-6929
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.7
>
>
> Currently we may loose next available version for an index row on index
> rebuild
> ({{org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#updateIndexes}})
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8513) SQL: Write benchmarks to compare mvcc on/off
[ https://issues.apache.org/jira/browse/IGNITE-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8513: Component/s: mvcc > SQL: Write benchmarks to compare mvcc on/off > > > Key: IGNITE-8513 > URL: https://issues.apache.org/jira/browse/IGNITE-8513 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We need to compare performance with mvcc turned on and off. > Development branch is ignite-4191 > Scope > All benchmarks uses native sql api cache.query(SqlFieldsQuery) > We are using simplified data model: table containing long PK and 1 long value > field. > 1) Measure increased load of messages. > 1 client node and many (4) server nodes. > Benchmark performs updates in single thread. > backups = 0, 2 > 2) Measure contention on mvcc processor. > Many client nodes (4) and 1 server node. > Benchmark performs updates in many threads. Threads use keys from *disjoint* > ranges. > backups = 0 > 3) Measure contention on updates. > 4 client nodes and 2 server nodes. > Benchmark performs updates in many threads. Thread use keys from > *intersecting* ranges. > Exceptions due to write conflicts should be just ignored. > Update keys should be sorted to prevent dead locks in current implementation. > backups = 0 > Common parameters: > atomicity mode = transactional > cache mode = partitioned > persistence = off > some benchmark code can be reused from IGNITE-7988 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7988) SQL: jdbc benchmarks in mvcc mode
[ https://issues.apache.org/jira/browse/IGNITE-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7988: Component/s: mvcc > SQL: jdbc benchmarks in mvcc mode > - > > Key: IGNITE-7988 > URL: https://issues.apache.org/jira/browse/IGNITE-7988 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Pavel Kuznetsov >Assignee: Pavel Kuznetsov >Priority: Major > > We need to know how does mvcc sql feature affect performance. > dev branch: ignite-4191 > cache atomicity mode: TRANSACTIONAL > We need to adopt existing jdbc benchmarks to be able to run in mvcc. > Only thin driver and native sql should be benchmarked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6739) Add tests verifying queries and tx functionality when mvcc is enabled
[
https://issues.apache.org/jira/browse/IGNITE-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6739:
Component/s: mvcc
> Add tests verifying queries and tx functionality when mvcc is enabled
> -
>
> Key: IGNITE-6739
> URL: https://issues.apache.org/jira/browse/IGNITE-6739
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Reporter: Semen Boikov
>Priority: Major
>
> Add tests verifying queries functionality is not broken if mvcc is enabled:
> - full text indexes
> - queries with indexing spi
> - CacheConfiguration with setQueryParallelism
> - lazy queries (SqlFieldsQuery.setLazy(true))
> - collocated queries (SqlFieldsQuery.setCollocated)
> - queries with cache groups
> - dynamic index create
> General functionality:
> - make sure clean up is called when related future (query) is forcibly
> (exceptionally) finished (i.e. on cache stop)
> - queries without involved caches (i.e. {{SELECT 1}}) don't request MVCC
> version
> - Mvcc coordinator assignment on cluster activate
> - cache entry reload
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6702) Get rid of values deserialization in H2TreeIndex.getRowCount
[
https://issues.apache.org/jira/browse/IGNITE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6702:
Component/s: (was: mvcc)
> Get rid of values deserialization in H2TreeIndex.getRowCount
>
>
> Key: IGNITE-6702
> URL: https://issues.apache.org/jira/browse/IGNITE-6702
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Semen Boikov
>Assignee: Kirill Shirokov
>Priority: Major
> Labels: performance
> Fix For: 2.4
>
>
> It seems H2TreeIndex.getRowCount is called for {{select count(\*) from x}}
> queries, now it is implemented via {{BPlusTree.find(x, x)}} method which
> deserializes all values. Actually values are not needed there, need implement
> method on BPlusTree computing size without deserialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6874) MVCC: base functionality
[ https://issues.apache.org/jira/browse/IGNITE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6874: Component/s: mvcc > MVCC: base functionality > > > Key: IGNITE-6874 > URL: https://issues.apache.org/jira/browse/IGNITE-6874 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Vladimir Ozerov >Priority: Major > > This is an umbrella ticket for base MVCC functionality: > 1) Version management > 2) Cache transactions support > 3) SQL SELECTs support -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6702) Get rid of values deserialization in H2TreeIndex.getRowCount
[
https://issues.apache.org/jira/browse/IGNITE-6702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6702:
Component/s: mvcc
> Get rid of values deserialization in H2TreeIndex.getRowCount
>
>
> Key: IGNITE-6702
> URL: https://issues.apache.org/jira/browse/IGNITE-6702
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Semen Boikov
>Assignee: Kirill Shirokov
>Priority: Major
> Labels: performance
> Fix For: 2.4
>
>
> It seems H2TreeIndex.getRowCount is called for {{select count(\*) from x}}
> queries, now it is implemented via {{BPlusTree.find(x, x)}} method which
> deserializes all values. Actually values are not needed there, need implement
> method on BPlusTree computing size without deserialization.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7701) SQL system view for node attributes
[ https://issues.apache.org/jira/browse/IGNITE-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7701: Labels: iep-13 (was: iep-13 sql) > SQL system view for node attributes > --- > > Key: IGNITE-7701 > URL: https://issues.apache.org/jira/browse/IGNITE-7701 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > Fix For: 2.7 > > > Implement SQL system view to show attributes for each node in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6314) Fix ALTER TABLE tests failures
[ https://issues.apache.org/jira/browse/IGNITE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6314: Labels: MakeTeamcityGreenAgain (was: MakeTeamcityGreenAgain sql) > Fix ALTER TABLE tests failures > -- > > Key: IGNITE-6314 > URL: https://issues.apache.org/jira/browse/IGNITE-6314 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Alexander Paschenko >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.3 > > > The following tests need to be fixed as they are failed when run on TeamCity. > The tests pass when run locally. > H2DynamicColumnsClientBasicSelfTest.testAddColumnToNonDynamicCacheWithRealValueType > > H2DynamicColumnsClientBasicSelfTest.testComplexOperations > H2DynamicColumnsServerBasicSelfTest.testAddColumnToNonDynamicCacheWithRealValueType > > H2DynamicColumnsServerBasicSelfTest.testComplexOperations > H2DynamicColumnsServerCoordinatorBasicSelfTest.testAddColumnToNonDynamicCacheWithRealValueType > > H2DynamicColumnsServerCoordinatorBasicSelfTest.testComplexOperations > DynamicColumnsConcurrentAtomicReplicatedSelfTest.testConcurrentRebalance > DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testConcurrentOperationsAndNodeStartStopMultithreaded > > DynamicColumnsConcurrentTransactionalReplicatedSelfTest.testCoordinatorChange -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7688) DDL does not work properly on sql queries.
[ https://issues.apache.org/jira/browse/IGNITE-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7688: Labels: persistant persistence persistence.xml (was: persistant persistence persistence.xml sql) > DDL does not work properly on sql queries. > -- > > Key: IGNITE-7688 > URL: https://issues.apache.org/jira/browse/IGNITE-7688 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3 > Environment: we have 5 node running on Ubuntu 16.04(VM). we > donwloaded binary dist. from download page. >Reporter: Muratcan TUKSAL >Assignee: Vladimir Ozerov >Priority: Critical > Labels: persistant, persistence, persistence.xml > Fix For: 2.7 > > Attachments: buggy-config.xml > > > * start ignite cluster persistent enabled mode (tried on 5 node) > * activate cluster via ignitevisor > * Create a table through jdbc > * kill all nodes > * start all nodes again > * activate cluster via ignitevisor > * drop that specific table > * deactivate cluster(doesnt matter via top -deactivate or kill all nodes) > * activate cluster > * dropped table still there with no data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7535) SQL COPY command: implement encoding option
[
https://issues.apache.org/jira/browse/IGNITE-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7535:
Labels: (was: sql)
> SQL COPY command: implement encoding option
> ---
>
> Key: IGNITE-7535
> URL: https://issues.apache.org/jira/browse/IGNITE-7535
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.5
>Reporter: Kirill Shirokov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.5
>
>
> The syntax can be something like:
> {noformat}
> COPY
> ...
> FORMAT CSV
> ...
> [CHARSET ""]
> {noformat}
> CHARSET is optional. By default the encoding is UTF-8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7688) DDL does not work properly on sql queries.
[ https://issues.apache.org/jira/browse/IGNITE-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7688: Component/s: sql > DDL does not work properly on sql queries. > -- > > Key: IGNITE-7688 > URL: https://issues.apache.org/jira/browse/IGNITE-7688 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3 > Environment: we have 5 node running on Ubuntu 16.04(VM). we > donwloaded binary dist. from download page. >Reporter: Muratcan TUKSAL >Assignee: Vladimir Ozerov >Priority: Critical > Labels: persistant, persistence, persistence.xml > Fix For: 2.7 > > Attachments: buggy-config.xml > > > * start ignite cluster persistent enabled mode (tried on 5 node) > * activate cluster via ignitevisor > * Create a table through jdbc > * kill all nodes > * start all nodes again > * activate cluster via ignitevisor > * drop that specific table > * deactivate cluster(doesnt matter via top -deactivate or kill all nodes) > * activate cluster > * dropped table still there with no data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7527) SQL system view for current node transactions
[ https://issues.apache.org/jira/browse/IGNITE-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7527: Labels: iep-13 (was: iep-13 sql) > SQL system view for current node transactions > - > > Key: IGNITE-7527 > URL: https://issues.apache.org/jira/browse/IGNITE-7527 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > Fix For: 2.7 > > > Implement SQL system view to show active transactions on local node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7700) SQL system view for list of nodes
[ https://issues.apache.org/jira/browse/IGNITE-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7700: Labels: iep-13 (was: iep-13 sql) > SQL system view for list of nodes > - > > Key: IGNITE-7700 > URL: https://issues.apache.org/jira/browse/IGNITE-7700 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-13 > Fix For: 2.7 > > > Implement SQL system view to show list of nodes in topology. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-1039) Need to inspect nested objects for indexing automatically
[
https://issues.apache.org/jira/browse/IGNITE-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-1039:
Labels: Usability (was: Usability sql)
> Need to inspect nested objects for indexing automatically
> -
>
> Key: IGNITE-1039
> URL: https://issues.apache.org/jira/browse/IGNITE-1039
> Project: Ignite
> Issue Type: Task
> Components: cache, sql
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Priority: Major
> Labels: Usability
>
> Imagine we have this data model with {{Organization}} object nested into
> {{Person}}:
> {code}
> Person {
> @QuerySqlField
> String name;
> Organization org;
> }
> Organization {
> @QuerySqlField
> String name;
> }
> {code}
> This currently doesn't work because {{Organization}} is not inspected until
> we put {{@QuerySqlField}} annotation on {{Person.org}} field.
> Such design is not good because it is:
> * Counterintuitive
> * Adds {{org}} field to tables which is not needed.
> We should inspect nested objects automatically.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-3608) QuerySqlFunction methods with Object type var args do not work
[
https://issues.apache.org/jira/browse/IGNITE-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-3608:
Labels: UDF (was: SQL UDF)
> QuerySqlFunction methods with Object type var args do not work
> --
>
> Key: IGNITE-3608
> URL: https://issues.apache.org/jira/browse/IGNITE-3608
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 1.5.0.final, 1.6
>Reporter: Edward Kaganovich
>Priority: Major
> Labels: UDF
> Fix For: 1.9
>
>
> We often use interactive sql consoles to query caches. Several field values
> as well as _key in caches are stored as objects. To support queries by these
> fields we have registered a generic UDF that should let us instantiate
> certain types:
> {code} @QuerySqlFunction
> public static Object t(String clz, Object... ctorArgs) throws
> Exception {
> Class c = Class.forName(keyClz);
> Class[] argTypes = new Class[ctorArgs.length];
> for (int i=0; i < ctorArgs.length; i++) {
> argTypes[i] = ctorArgs[i].getClass();
> }
> Constructor ctor = c.getConstructor(argTypes);
> return ctor.newInstance(ctorArgs);
> }
> {code}
> Unfortunately Ignite fails to find and execute this function for the
> following SQL:
> {color:blue}select t('java.lang.String', 'key20'){color}{color:red} <-
> Fails{color}
> However, there is no problems with this function:
> {code} @QuerySqlFunction
> public static Object t1(String clz, String... ctorArgs) throws Exception
> {
> return t(clz, ctorArgs);
> }
> {code}
> {color:blue}select t1('java.lang.String', 'key20'){color}{color:green} <-
> Works as expected{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-4509) SQL: query with condition on affinity columns and without joins and subqueries should go to affinity node only
[
https://issues.apache.org/jira/browse/IGNITE-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4509:
Labels: important performance (was: important performance sql)
> SQL: query with condition on affinity columns and without joins and
> subqueries should go to affinity node only
> --
>
> Key: IGNITE-4509
> URL: https://issues.apache.org/jira/browse/IGNITE-4509
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 1.8
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
>Priority: Major
> Labels: important, performance
> Fix For: 2.1
>
>
> Simple SQL queries usually demonstrate negative scalability when more nodes
> are added.
> Consider the following query:
> {code}
> SELECT * FROM Person p
> WHERE p.id = ?
> {code}
> If {{Person.id}} is affinity field, then query can be replaced with plain
> {{IgniteCache.get}} or some specialized version of GET, which will return
> only desired fields. This optimization will guarantee smooth scale with any
> number of nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-2367) Document design of an existing SQL DML support on Wiki
[ https://issues.apache.org/jira/browse/IGNITE-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2367: Labels: (was: sql) > Document design of an existing SQL DML support on Wiki > -- > > Key: IGNITE-2367 > URL: https://issues.apache.org/jira/browse/IGNITE-2367 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ershov >Priority: Major > Original Estimate: 8h > Remaining Estimate: 8h > > In order to design an effective and precise solution for a new SQL DML > features, we have to make an overview of an existing sql-supporting code and > document that design at wiki page. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3013) Support sorted merge index for SQL
[ https://issues.apache.org/jira/browse/IGNITE-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3013: Labels: important (was: SQL important) > Support sorted merge index for SQL > -- > > Key: IGNITE-3013 > URL: https://issues.apache.org/jira/browse/IGNITE-3013 > Project: Ignite > Issue Type: Improvement >Reporter: Sergi Vladykin >Assignee: Sergi Vladykin >Priority: Major > Labels: important > Fix For: 2.0 > > > Currently for sorting we have to fetch all the result sets from remote nodes > and sort them on the client side, need to implement sorted merge index which > will do it lazily in streaming fashion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6111) SQL: Add ability to do INSERT without specifying the column names
[
https://issues.apache.org/jira/browse/IGNITE-6111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6111:
Labels: usability (was: sql usability)
> SQL: Add ability to do INSERT without specifying the column names
> -
>
> Key: IGNITE-6111
> URL: https://issues.apache.org/jira/browse/IGNITE-6111
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Alexandr Fedotov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: usability
> Fix For: 2.4
>
>
> Having the following classes
> {code:java}
> class PersonKey {
> private Long id;
> }
> class Person {
> private Long id;
> private String name;
> }
> {code}
> with proper configuration it should be possible to execute queries
> of the following type passing {{id}} and {{name}} as the arguments
> {code:sql}"insert into Person values(?,?)"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7447) SQL: Wrong BatchUpdateException error code if request fails on remote nod
[
https://issues.apache.org/jira/browse/IGNITE-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7447:
Labels: (was: jdbc sql)
> SQL: Wrong BatchUpdateException error code if request fails on remote nod
> -
>
> Key: IGNITE-7447
> URL: https://issues.apache.org/jira/browse/IGNITE-7447
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.3
>Reporter: Roman Kondakov
>Priority: Major
>
> If request fails on remote node (i.e. because of the data conversion), we get
> wrong error code in {{BatchUpdateException}}. For example in test
> {{JdbcThinBatchSelfTest#testBatchDeleteExceptionPrepared}} returned code
> should be {{SqlStateCode.CONVERSION_FAILED}} due to wrong argument type, but
> have {{SqlStateCode.INTERNAL_ERROR}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6054) SQL: Add option to store primitive keys in plain form for CREATE TABLE
[
https://issues.apache.org/jira/browse/IGNITE-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6054:
Labels: performance (was: performance sql)
> SQL: Add option to store primitive keys in plain form for CREATE TABLE
> --
>
> Key: IGNITE-6054
> URL: https://issues.apache.org/jira/browse/IGNITE-6054
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Labels: performance
> Fix For: 2.3
>
>
> Currently we create separate internal type for primary key columns. This is
> necessary to avoid clashes between keys of the same type within the same
> caches (ironically, we do not allow multiple dynamic tables per cache).
> The most widely used PK is single-column key of {{Long}} or {{String}} data
> type. If we store a key plain {{long}}, it will consume 9 bytes. If we store
> it as an object with long field, it will consume 24 + 9 = 33 bytes. What is
> worse, in the latter case we will have to copy key object back and forth
> between page memory and application code many times, while for plain long key
> we simply do {{Unsafe.getLong}}.
> For this reason, it makes sense to introduce special mode for {{CREATE
> TABLE}} command, when key will not be wrapped into a class, and will be
> stored as is. Let's name it {{plainPrimaryKey}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6921) Optimise tx/queries tracking when mvcc is enabled and local caches are used
[ https://issues.apache.org/jira/browse/IGNITE-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6921: Labels: (was: sql) > Optimise tx/queries tracking when mvcc is enabled and local caches are used > --- > > Key: IGNITE-6921 > URL: https://issues.apache.org/jira/browse/IGNITE-6921 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Seems we don't need to request mvcc version and track tx/queries on mvcc > coordinator when only local caches are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5197) Introduce AFFINITY KEY keywords and Ignite SQL mode to H2
[ https://issues.apache.org/jira/browse/IGNITE-5197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5197: Labels: (was: sql) > Introduce AFFINITY KEY keywords and Ignite SQL mode to H2 > - > > Key: IGNITE-5197 > URL: https://issues.apache.org/jira/browse/IGNITE-5197 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7388) MVCC TX Support async tx rollback (e.g. on timeout)
[ https://issues.apache.org/jira/browse/IGNITE-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7388: Component/s: mvcc > MVCC TX Support async tx rollback (e.g. on timeout) > --- > > Key: IGNITE-7388 > URL: https://issues.apache.org/jira/browse/IGNITE-7388 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > Currently TX timeout isn't taken into consideration while MVCC version is > requesting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9265) MVCC TX: Two rows with the same key in one MERGE statement produce an exception
[
https://issues.apache.org/jira/browse/IGNITE-9265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9265:
Component/s: mvcc
> MVCC TX: Two rows with the same key in one MERGE statement produce an
> exception
> ---
>
> Key: IGNITE-9265
> URL: https://issues.apache.org/jira/browse/IGNITE-9265
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Igor Seliverstov
>Priority: Major
>
> In case the operation like {{MERGE INTO INTEGER (_key, _val) KEY(_key) VALUES
> (1,1),(1,2)}} is called an exception is occurred.
> Correct behavior: each next update on the same key overwrites pervious one
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7306) Incorrect force key request processing when MVCC is enabled
[
https://issues.apache.org/jira/browse/IGNITE-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7306:
Component/s: mvcc
> Incorrect force key request processing when MVCC is enabled
> ---
>
> Key: IGNITE-7306
> URL: https://issues.apache.org/jira/browse/IGNITE-7306
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> Reproducer: {{IgniteCacheMultiTxLockSelfTest#testExplicitLockManyKeys}}
> Root cause: when {{GridDhtForceKeysRequest}} is processed locally, we obtain
> {{GridCacheEntryInfo}} through {{GridCacheMapEntry.info}}. Returned instance
> is unaware of MVCC version. Need to return {{GridCacheMvccEntryInfo}} instead.
> {code}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccInitialValue(IgniteCacheOffheapManagerImpl.java:1433)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccInitialValue(IgniteCacheOffheapManagerImpl.java:396)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.initialValue(GridCacheMapEntry.java:2624)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture$MiniFuture.onResult(GridDhtForceKeysFuture.java:537)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtForceKeysFuture.onResult(GridDhtForceKeysFuture.java:199)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processForceKeyResponse(GridDhtCacheAdapter.java:176)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:193)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$11.onMessage(GridDhtTransactionalCacheAdapter.java:191)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1406)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$MessageHandler.apply(GridDhtCacheAdapter.java:1388)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1567)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1195)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:128)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1092)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7267) Fix transactional inserts.
[ https://issues.apache.org/jira/browse/IGNITE-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7267: Component/s: mvcc > Fix transactional inserts. > -- > > Key: IGNITE-7267 > URL: https://issues.apache.org/jira/browse/IGNITE-7267 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Inserts optimisation (IGNITE-4490) breaks transactional inserts. Need to > rework the feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7321) DML operation hangs in case exception is thrown from DHT enlist future
[ https://issues.apache.org/jira/browse/IGNITE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7321: Component/s: mvcc > DML operation hangs in case exception is thrown from DHT enlist future > -- > > Key: IGNITE-7321 > URL: https://issues.apache.org/jira/browse/IGNITE-7321 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Vladimir Ozerov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Root cause: when exception is thrown on primary node (e.g. double-insert or > MVCC version conflict), primary future is completed, but exception doesn't > seem to be propagated to near node. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7371) MVCC TX Repeatable read semantic
[ https://issues.apache.org/jira/browse/IGNITE-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7371: Component/s: mvcc > MVCC TX Repeatable read semantic > > > Key: IGNITE-7371 > URL: https://issues.apache.org/jira/browse/IGNITE-7371 > Project: Ignite > Issue Type: New Feature > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Repeatable read isolation implies that each GET operation whithin tx gets a > last commited version of entry *at the time the tx was started*. Curentrly we > get a last commited version of entry *at the time the first read operation > invokes on a particular key whithin tx.* We need to fix this unconsistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7302) SQL TX: Failed to query INFORMATIONAL_SCHEMA
[
https://issues.apache.org/jira/browse/IGNITE-7302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7302:
Component/s: mvcc
> SQL TX: Failed to query INFORMATIONAL_SCHEMA
>
>
> Key: IGNITE-7302
> URL: https://issues.apache.org/jira/browse/IGNITE-7302
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.7
>
>
> {code}
> javax.cache.CacheException: class org.apache.ignite.IgniteException:
> Unsupported query: Unexpected Table implementation [cls=MetaTable]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.assert0(GridSqlQueryParser.java:1876)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTable(GridSqlQueryParser.java:612)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTableFilter(GridSqlQueryParser.java:565)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseSelect(GridSqlQueryParser.java:665)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseQuery(GridSqlQueryParser.java:1539)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1490)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.mvccTracker(IgniteH2Indexing.java:1294)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:926)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:870)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:1163)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1951)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1936)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2521)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1968)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> org.apache.ignite.internal.processors.cache.local.IgniteCacheLocalFieldsQuerySelfTest.testInformationSchema(IgniteCacheLocalFieldsQuerySelfTest.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7342) SQL TX: Fix checking whether currently updating row was updated after it pass query filter
[ https://issues.apache.org/jira/browse/IGNITE-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7342: Component/s: mvcc > SQL TX: Fix checking whether currently updating row was updated after it pass > query filter > -- > > Key: IGNITE-7342 > URL: https://issues.apache.org/jira/browse/IGNITE-7342 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3478) Multi-version concurrency control
[ https://issues.apache.org/jira/browse/IGNITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3478: Component/s: mvcc > 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 >Priority: Major > Labels: important > Fix For: 2.7 > > > 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 (v7.6.3#76005)
[jira] [Updated] (IGNITE-7271) UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode
[ https://issues.apache.org/jira/browse/IGNITE-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7271: Component/s: mvcc > UPDATE and DELETE statements do not work through thin JDBC work in MVCC mode > > > Key: IGNITE-7271 > URL: https://issues.apache.org/jira/browse/IGNITE-7271 > Project: Ignite > Issue Type: Bug > Components: jdbc, mvcc, sql >Reporter: Vladimir Ozerov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > See relevant failures JDBC suite. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7280) SQL TX: improve JDBC test coverage
[ https://issues.apache.org/jira/browse/IGNITE-7280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7280: Component/s: mvcc > SQL TX: improve JDBC test coverage > -- > > Key: IGNITE-7280 > URL: https://issues.apache.org/jira/browse/IGNITE-7280 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > The following cases must be handled: > 1) Single update stmt in TX > 2) Multiple update stmts in TX > 3) Changes to multiple caches in TX > 4) Mix of both selects and updates (e.g. get data from select and then build > updates based on it) > 5) Different operation types - INSERT, UPDATE, MERGE (take in count various > DML optimizations to ensure that as much code paths are covered as possible) > 6) Batch updates > 7) Joins (both co-located and distributed) > 8) Different cache modes - PARTITIONED, REPLICATED > 9) Different backup counts > 10) Communication with client node vs communication with server node > 11) Both implicit and explicit transactions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-3478) Multi-version concurrency control
[ https://issues.apache.org/jira/browse/IGNITE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-3478: Component/s: (was: mvcc) > 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 >Priority: Major > Labels: important > Fix For: 2.7 > > > 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 (v7.6.3#76005)
[jira] [Updated] (IGNITE-7307) H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations fails with assertion
[
https://issues.apache.org/jira/browse/IGNITE-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7307:
Component/s: mvcc
> H2DynamicIndexingComplexServerTransactionalReplicatedTest.testOperations
> fails with assertion
> -
>
> Key: IGNITE-7307
> URL: https://issues.apache.org/jira/browse/IGNITE-7307
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> {code}
> [2017-12-26 11:40:53,187][ERROR][main][root] Test failed.
> java.lang.AssertionError: localNode = cde0ed21-5bfa-48ee-8e47-53d85880,
> dhtNodes = [TcpDiscoveryNode [id=49318149-4b22-40d1-b68f-8b6b2d52,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47501], discPort=47501, order=3,
> intOrder=3, lastExchangeTime=1514277649002, loc=false,
> ver=2.4.0#19700101-sha1:, isClient=false], TcpDiscoveryNode
> [id=cde0ed21-5bfa-48ee-8e47-53d85880, addrs=[127.0.0.1],
> sockAddrs=[/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1514277652494, loc=true, ver=2.4.0#19700101-sha1:,
> isClient=false], TcpDiscoveryNode [id=7530f231-3bd4-4cc0-b295-0e2f11b3,
> addrs=[127.0.0.1], sockAddrs=[/127.0.0.1:47502], discPort=47502, order=4,
> intOrder=4, lastExchangeTime=1514277649456, loc=false,
> ver=2.4.0#19700101-sha1:, isClient=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1274)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:678)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1056)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:3619)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:257)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepareLocal(GridNearPessimisticTxPrepareFuture.java:256)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.preparePessimistic(GridNearPessimisticTxPrepareFuture.java:406)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.prepare(GridNearPessimisticTxPrepareFuture.java:190)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3390)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commit(GridNearTxLocal.java:3350)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.executeUpdateStatement(DmlStatementsProcessor.java:429)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:177)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1809)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1645)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2034)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$6.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2527)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:2039)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFieldsNoCache(GridQueryProcessor.java:1995)
> at
> org.apache.ignite.internal.processors.cache.index.H2DynamicIndexingComplexTest.executeSql(H2DynamicIndexingComplexTest.java:333)
> at
>
[jira] [Updated] (IGNITE-9062) MVCC SQL: H2 connection and statement cache refactoring
[ https://issues.apache.org/jira/browse/IGNITE-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9062: Component/s: mvcc > MVCC SQL: H2 connection and statement cache refactoring > --- > > Key: IGNITE-9062 > URL: https://issues.apache.org/jira/browse/IGNITE-9062 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > H2 connection and statement caching logic is currently spread between several > variables. It seems feasible to extract and encapsulate such logic into some > H2ConnectionManager class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6921) Optimise tx/queries tracking when mvcc is enabled and local caches are used
[ https://issues.apache.org/jira/browse/IGNITE-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6921: Component/s: mvcc > Optimise tx/queries tracking when mvcc is enabled and local caches are used > --- > > Key: IGNITE-6921 > URL: https://issues.apache.org/jira/browse/IGNITE-6921 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > Labels: sql > Fix For: 2.7 > > > Seems we don't need to request mvcc version and track tx/queries on mvcc > coordinator when only local caches are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6888) Cache involved tables set for statement
[
https://issues.apache.org/jira/browse/IGNITE-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6888:
Component/s: mvcc
> Cache involved tables set for statement
> ---
>
> Key: IGNITE-6888
> URL: https://issues.apache.org/jira/browse/IGNITE-6888
> Project: Ignite
> Issue Type: Improvement
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
>
> Currently we have to create AST from {{PreparedStatement}} to collect and
> process all involved
> in the query caches (See {{IgniteH2Indexing#mvccTracker}}). It makes sense
> to cache parse results per statements by analogy with statements itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-6459) Implement metrics to monitor mvcc coordinator performance
[ https://issues.apache.org/jira/browse/IGNITE-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6459: Component/s: mvcc > Implement metrics to monitor mvcc coordinator performance > - > > Key: IGNITE-6459 > URL: https://issues.apache.org/jira/browse/IGNITE-6459 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Need provide some public metrics which allow to to monitor mvcc coordinator > performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9125) MVCC SQL: Streaming SQL data load operations support
[ https://issues.apache.org/jira/browse/IGNITE-9125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9125: Component/s: mvcc > MVCC SQL: Streaming SQL data load operations support > > > Key: IGNITE-9125 > URL: https://issues.apache.org/jira/browse/IGNITE-9125 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > Since DataStreamer is already enabled for MVCC COPY command and *streaming* > INSERT operations should be enabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7249) SQL TX: Commit/rollback active TX before DDL statement processing
[ https://issues.apache.org/jira/browse/IGNITE-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7249: Labels: (was: sql) > SQL TX: Commit/rollback active TX before DDL statement processing > - > > Key: IGNITE-7249 > URL: https://issues.apache.org/jira/browse/IGNITE-7249 > Project: Ignite > Issue Type: Test > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Commit/rollback active TX before DDL statement processing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-6458) Implement possibility to manually change mvcc coordinator
[ https://issues.apache.org/jira/browse/IGNITE-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-6458: Component/s: mvcc > Implement possibility to manually change mvcc coordinator > - > > Key: IGNITE-6458 > URL: https://issues.apache.org/jira/browse/IGNITE-6458 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Priority: Major > Fix For: 2.7 > > > Need provide some ability to manually switch mvcc coordinator, probably via > MBean. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7249) SQL TX: Commit/rollback active TX before DDL statement processing
[ https://issues.apache.org/jira/browse/IGNITE-7249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7249: Component/s: mvcc > SQL TX: Commit/rollback active TX before DDL statement processing > - > > Key: IGNITE-7249 > URL: https://issues.apache.org/jira/browse/IGNITE-7249 > Project: Ignite > Issue Type: Test > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Commit/rollback active TX before DDL statement processing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8982) SQL TX: reuse H2 connections
[ https://issues.apache.org/jira/browse/IGNITE-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8982: Component/s: mvcc > SQL TX: reuse H2 connections > > > Key: IGNITE-8982 > URL: https://issues.apache.org/jira/browse/IGNITE-8982 > Project: Ignite > Issue Type: Improvement > Components: mvcc >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > > H2 Connection creation is not very fast. Reusing already created connections > could speed up execution in several cases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7991) MVCC TX Crash recovery
[ https://issues.apache.org/jira/browse/IGNITE-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7991: Component/s: mvcc > MVCC TX Crash recovery > -- > > Key: IGNITE-7991 > URL: https://issues.apache.org/jira/browse/IGNITE-7991 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Igor Seliverstov >Priority: Major > > Implement crash recovery for MVCC enabled caches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7956) MVCC TX: cache eviction operations for key-value API
[ https://issues.apache.org/jira/browse/IGNITE-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7956: Component/s: mvcc > MVCC TX: cache eviction operations for key-value API > > > Key: IGNITE-7956 > URL: https://issues.apache.org/jira/browse/IGNITE-7956 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > We need to implement MVCC-compatible cache eviction operations for key-value > API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7966) MVCC TX Review cache/Ignite configuration for MVCC needs
[ https://issues.apache.org/jira/browse/IGNITE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7966: Component/s: mvcc > MVCC TX Review cache/Ignite configuration for MVCC needs > > > Key: IGNITE-7966 > URL: https://issues.apache.org/jira/browse/IGNITE-7966 > Project: Ignite > Issue Type: Task > Components: cache, mvcc, sql >Reporter: Igor Seliverstov >Priority: Major > > We need to rethink Ignite and Cache configuration to have a control on such > parameters as VACUUM frequency, TxLog data-region parameters, whether MVCC > enabled or not for particular cache etc. Most of such parameters are > hardcoded now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7955) MVCC TX: cache peek for key-value API
[ https://issues.apache.org/jira/browse/IGNITE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7955: Component/s: mvcc > MVCC TX: cache peek for key-value API > - > > Key: IGNITE-7955 > URL: https://issues.apache.org/jira/browse/IGNITE-7955 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > We need to implement MVCC-compatible cache peek operation for key-value API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7954) MVCC TX: cache load routines for key-value API
[ https://issues.apache.org/jira/browse/IGNITE-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7954: Component/s: mvcc > MVCC TX: cache load routines for key-value API > -- > > Key: IGNITE-7954 > URL: https://issues.apache.org/jira/browse/IGNITE-7954 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > We need to implement MVCC-compatible cache load operations for key-value API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8692) MVCC TX: Always persistent TxLog
[ https://issues.apache.org/jira/browse/IGNITE-8692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8692: Component/s: mvcc > MVCC TX: Always persistent TxLog > > > Key: IGNITE-8692 > URL: https://issues.apache.org/jira/browse/IGNITE-8692 > Project: Ignite > Issue Type: Task > Components: cache, mvcc, sql >Reporter: Igor Seliverstov >Priority: Major > > Currently TxLog may be overflowed in case a long running Tx prevents > "vacuuming". > It can be solved by enabling persistence for TxLog data region by default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7311) Expiration does not work with enabled MVCC
[
https://issues.apache.org/jira/browse/IGNITE-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7311:
Component/s: mvcc
> Expiration does not work with enabled MVCC
> --
>
> Key: IGNITE-7311
> URL: https://issues.apache.org/jira/browse/IGNITE-7311
> Project: Ignite
> Issue Type: Task
> Components: cache, mvcc
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Reproducer: {{RedisProtocolStringSelfTest#testExpire}}
> Root cause: MVCC is not honored when updating entry TTL.
> {code}
> Exception in thread "pub-#101%redis.RedisProtocolStringSelfTest0%"
> java.lang.AssertionError: Assertion error on search row: SearchRow
> [key=KeyCacheObjectImpl [part=294, val=k1, hasValBytes=true], hash=3366,
> cacheId=0]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1749)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:371)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.storeValue(GridCacheMapEntry.java:3249)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateTtl(GridCacheMapEntry.java:2391)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.updateTtl(GridCacheMapEntry.java:3191)
> at
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$UpdateTllCommand$1$1.process(GridCacheCommandHandler.java:1685)
> at
> org.apache.ignite.internal.processors.rest.handlers.cache.GridCacheCommandHandler$UpdateTllCommand$1$1.process(GridCacheCommandHandler.java:1675)
> at
> org.apache.ignite.internal.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:432)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1271)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:683)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1061)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:395)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:519)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTxLocal(IgniteTxHandler.java:320)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:604)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:410)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:341)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:158)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:95)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3390)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:2550)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.invokeAsync(GridNearTxLocal.java:431)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2481)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$25.op(GridCacheAdapter.java:2473)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4085)
[jira] [Updated] (IGNITE-7265) BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
[
https://issues.apache.org/jira/browse/IGNITE-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7265:
Component/s: mvcc
> BPlusTreeSelfTest.testIterateConcurrentPutRemove_1 fails
>
>
> Key: IGNITE-7265
> URL: https://issues.apache.org/jira/browse/IGNITE-7265
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> {code}
> java.lang.AssertionError: Assertion error on row: 26
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2221)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:2156)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.iterateConcurrentPutRemove(BPlusTreeSelfTest.java:2202)
> at
> org.apache.ignite.internal.processors.database.BPlusTreeSelfTest.testIterateConcurrentPutRemove_1(BPlusTreeSelfTest.java:2169)
> 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:2008)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1923)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.AssertionError: 27
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.setLevelsCount(BPlusMetaIO.java:98)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.BPlusMetaIO.addRoot(BPlusMetaIO.java:155)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:661)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$AddRoot.run(BPlusTree.java:650)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:241)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$10500(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insertWithSplit(BPlusTree.java:3073)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.insert(BPlusTree.java:2949)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$2500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:420)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Insert.run0(BPlusTree.java:401)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5153)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:5138)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11100(BPlusTree.java:82)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryInsert(BPlusTree.java:3143)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.access$7500(BPlusTree.java:2831)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2464)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2185)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8865) SQL Transactions: Set sequential false if update query has no order
[ https://issues.apache.org/jira/browse/IGNITE-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8865: Component/s: mvcc > SQL Transactions: Set sequential false if update query has no order > --- > > Key: IGNITE-8865 > URL: https://issues.apache.org/jira/browse/IGNITE-8865 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Priority: Major > > See appropriate TODO in DmlStatementsProcessor -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8445) SQL TX: Fast finish for transactions.
[
https://issues.apache.org/jira/browse/IGNITE-8445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8445:
Component/s: mvcc
> SQL TX: Fast finish for transactions.
> -
>
> Key: IGNITE-8445
> URL: https://issues.apache.org/jira/browse/IGNITE-8445
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Reporter: Roman Kondakov
>Priority: Major
>
> Need to implement fast finish path for MVCC transactions. See
> {{org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#fastFinish}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7952) MVCC TX: cache clear routines for key-value API
[ https://issues.apache.org/jira/browse/IGNITE-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7952: Component/s: mvcc > MVCC TX: cache clear routines for key-value API > --- > > Key: IGNITE-7952 > URL: https://issues.apache.org/jira/browse/IGNITE-7952 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > We need to implement MVCC-compatible cache clear operations for Key-Value API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5935) Integrate mvcc support in tx recovery protocol
[ https://issues.apache.org/jira/browse/IGNITE-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-5935: Component/s: mvcc > Integrate mvcc support in tx recovery protocol > -- > > Key: IGNITE-5935 > URL: https://issues.apache.org/jira/browse/IGNITE-5935 > Project: Ignite > Issue Type: Task > Components: cache, mvcc >Reporter: Semen Boikov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Need make sure tx recovery work properly with mvcc enabled: > - tx IDs are generated and not lost if transaction is committed by recovery > procedure > - tx should be removed from list of active transactions on coordinator -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7259) GridIndexRebuildSelfTest hangs
[ https://issues.apache.org/jira/browse/IGNITE-7259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7259: Component/s: mvcc > GridIndexRebuildSelfTest hangs > -- > > Key: IGNITE-7259 > URL: https://issues.apache.org/jira/browse/IGNITE-7259 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Vladimir Ozerov >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7314) Iterators could return multiple values of the same key when MVCC is enabled
[
https://issues.apache.org/jira/browse/IGNITE-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7314:
Component/s: mvcc
> Iterators could return multiple values of the same key when MVCC is enabled
> ---
>
> Key: IGNITE-7314
> URL: https://issues.apache.org/jira/browse/IGNITE-7314
> Project: Ignite
> Issue Type: Task
> Components: cache, mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> It MVCC is enabled most of tests in {{IgniteCacheFullApiSelfTestSuite}} works
> fine. However, they are really *slow*. So slow, that TC cannot cope with them
> and kills the build after 1h30m of execution.
> Root cause: iterators return too much values as they do not use any specific
> version by default ({{null}} is passed). Essentially, we need to add MVCC
> support to iterators and "global" operations, which use them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8050) Throw a meaningful exception when user issues TX SQL keyword with MVCC turned off
[ https://issues.apache.org/jira/browse/IGNITE-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8050: Component/s: mvcc > Throw a meaningful exception when user issues TX SQL keyword with MVCC turned > off > - > > Key: IGNITE-8050 > URL: https://issues.apache.org/jira/browse/IGNITE-8050 > Project: Ignite > Issue Type: Task > Components: jdbc, mvcc, sql >Reporter: Alexander Paschenko >Assignee: Alexander Paschenko >Priority: Major > Fix For: 2.7 > > > An exception must be thrown when the user issues TX SQL command (BEGIN, > COMMIT, ROLLBACK) in absence of MVCC - ingoring these may be confusing and > can lead to SQL engine behavior to behaving quite differently from what the > user expects, esp. in terms of data consistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
