[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0
[ https://issues.apache.org/jira/browse/IGNITE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504270#comment-16504270 ] Peter Ivanov commented on IGNITE-8534: -- PR is ok for me. > Upgrade Ignite Spark Module's Spark version to 2.3.0 > > > Key: IGNITE-8534 > URL: https://issues.apache.org/jira/browse/IGNITE-8534 > Project: Ignite > Issue Type: Improvement > Components: spark >Reporter: Ray >Assignee: Ray >Priority: Major > Fix For: 2.6 > > > Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite > Spark module to to the latest version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0
[ https://issues.apache.org/jira/browse/IGNITE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504264#comment-16504264 ] Ray commented on IGNITE-8534: - [~vveider] [~dpavlov] Can you review the PR and give some comments please? All unit tests in spark module and build passed in my local environment. There're two users in the user list trying to use spark 2.3 with Ignite last week only. [http://apache-ignite-users.70518.x6.nabble.com/Spark-Ignite-connection-using-Config-file-td21827.html] [http://apache-ignite-users.70518.x6.nabble.com/Spark-Ignite-standalone-mode-on-Kubernetes-cluster-td21739.html] > Upgrade Ignite Spark Module's Spark version to 2.3.0 > > > Key: IGNITE-8534 > URL: https://issues.apache.org/jira/browse/IGNITE-8534 > Project: Ignite > Issue Type: Improvement > Components: spark >Reporter: Ray >Assignee: Ray >Priority: Major > Fix For: 2.6 > > > Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite > Spark module to to the latest version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0
[ https://issues.apache.org/jira/browse/IGNITE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504225#comment-16504225 ] Peter Ivanov commented on IGNITE-8534: -- [~ldz], I see now. Thanks for explaining! > Upgrade Ignite Spark Module's Spark version to 2.3.0 > > > Key: IGNITE-8534 > URL: https://issues.apache.org/jira/browse/IGNITE-8534 > Project: Ignite > Issue Type: Improvement > Components: spark >Reporter: Ray >Assignee: Ray >Priority: Major > Fix For: 2.6 > > > Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite > Spark module to to the latest version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8506) Visor CMD: Show consistent ID in node tables.
[ https://issues.apache.org/jira/browse/IGNITE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-8506: - Assignee: Pavel Konstantinov (was: Vasiliy Sisko) > Visor CMD: Show consistent ID in node tables. > - > > Key: IGNITE-8506 > URL: https://issues.apache.org/jira/browse/IGNITE-8506 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov >Priority: Major > Attachments: screenshot-1.png > > > Add for topology command. > Check other command and add on node tables if exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8506) Visor CMD: Show consistent ID in node tables.
[ https://issues.apache.org/jira/browse/IGNITE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504205#comment-16504205 ] Vasiliy Sisko commented on IGNITE-8506: --- Fixed default message. > Visor CMD: Show consistent ID in node tables. > - > > Key: IGNITE-8506 > URL: https://issues.apache.org/jira/browse/IGNITE-8506 > Project: Ignite > Issue Type: Bug >Reporter: Vasiliy Sisko >Assignee: Vasiliy Sisko >Priority: Major > Attachments: screenshot-1.png > > > Add for topology command. > Check other command and add on node tables if exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8287) Web console: place sign up inputs in two columns
[ https://issues.apache.org/jira/browse/IGNITE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8287. -- > Web console: place sign up inputs in two columns > > > Key: IGNITE-8287 > URL: https://issues.apache.org/jira/browse/IGNITE-8287 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Andrey Novikov >Priority: Minor > Fix For: 2.5 > > > The sign up page controls take a lot of vertical space, let's put some of > these side by side, like on configuration and user profile pages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7298) Web console: error on web agent start in case if demo is opened in browser
[
https://issues.apache.org/jira/browse/IGNITE-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-7298:
-
Assignee: Pavel Konstantinov (was: Vasiliy Sisko)
> Web console: error on web agent start in case if demo is opened in browser
> --
>
> Key: IGNITE-7298
> URL: https://issues.apache.org/jira/browse/IGNITE-7298
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
>Priority: Major
>
> {code}
> [ERROR][demo-nodes-start-0][] Failed to resolve default logging config file:
> config/java.util.logging.properties
> Console logging handler is not configured.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7298) Web console: error on web agent start in case if demo is opened in browser
[
https://issues.apache.org/jira/browse/IGNITE-7298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504196#comment-16504196
]
Vasiliy Sisko commented on IGNITE-7298:
---
Fixed for Windows.
> Web console: error on web agent start in case if demo is opened in browser
> --
>
> Key: IGNITE-7298
> URL: https://issues.apache.org/jira/browse/IGNITE-7298
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Konstantinov
>Assignee: Vasiliy Sisko
>Priority: Major
>
> {code}
> [ERROR][demo-nodes-start-0][] Failed to resolve default logging config file:
> config/java.util.logging.properties
> Console logging handler is not configured.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-8298) Broken UI of the latest table cell
[ https://issues.apache.org/jira/browse/IGNITE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov closed IGNITE-8298. -- > Broken UI of the latest table cell > -- > > Key: IGNITE-8298 > URL: https://issues.apache.org/jira/browse/IGNITE-8298 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Dmitriy Shabalin >Assignee: Dmitriy Shabalin >Priority: Major > Fix For: 2.6 > > > Check the latest cell in a table. It's UI looks broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8298) Broken UI of the latest table cell
[ https://issues.apache.org/jira/browse/IGNITE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Novikov resolved IGNITE-8298. Resolution: Fixed > Broken UI of the latest table cell > -- > > Key: IGNITE-8298 > URL: https://issues.apache.org/jira/browse/IGNITE-8298 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Dmitriy Shabalin >Assignee: Dmitriy Shabalin >Priority: Major > Fix For: 2.6 > > > Check the latest cell in a table. It's UI looks broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0
[ https://issues.apache.org/jira/browse/IGNITE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16504174#comment-16504174 ] Ray commented on IGNITE-8534: - Hi [~vveider] I removed spark-2.10 module in this ticket, not scalar-2.10. I believe you're talking about spark-2.10 module here. As I explained here [http://apache-ignite-developers.2346864.n4.nabble.com/Review-request-for-IGNITE-8534-Upgrade-Ignite-Spark-Module-s-Spark-version-to-2-3-td30979.html#a31078], before Spark 2.3, spark user can use either scala 2.10 or 2.11 to write their application. So in Ignite, spark-2.10 module exists to accommodate user uses scala 2.10 to write their spark application. But in Spark 2.3, spark community removed support for scala 2.10 so it's only reasonable to remove spark-2.10 module in Ignite. Because if we don't remove spark-2.10 module we can't upgrade spark module to spark 2.3.0. > Upgrade Ignite Spark Module's Spark version to 2.3.0 > > > Key: IGNITE-8534 > URL: https://issues.apache.org/jira/browse/IGNITE-8534 > Project: Ignite > Issue Type: Improvement > Components: spark >Reporter: Ray >Assignee: Ray >Priority: Major > Fix For: 2.6 > > > Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite > Spark module to to the latest version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-8589) Prepare Node.JS Thin Client documentation
[ https://issues.apache.org/jira/browse/IGNITE-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda resolved IGNITE-8589. - Resolution: Fixed Looks good, did minor improvements. > Prepare Node.JS Thin Client documentation > - > > Key: IGNITE-8589 > URL: https://issues.apache.org/jira/browse/IGNITE-8589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Pavel Petroshenko >Priority: Major > Fix For: 2.6 > > > The hidden page is presently here: > https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client > Once all the suggestions are resolved, we might split this page into several > pages. I can do this closer to 2.6 release. > [~pavel.petroshenko], [~alexey.kosenchuk], please address the following > suggestions for now: > Installation section: > * Ignite repository has to be used instead of the private one > * The section needs to explain the installation steps once the NPM module is > released. It's fine to put the current installation instructions under > "Installing from Sources" section. > Data Types: > * The term "field" is truly confusing. Does it really imply any possible data > (value, key, element of an array)? Why can't we use the term "value" instead? > * Provide a code snippet that shows how to configure the explicit mapping > * Default mapping has to be documented in place on readme.io (no references > to the private GIT repo) > Configuring Ignite Client > *Failover on a reconnect code snippet. How to pass a list of the endpoints. > General: > * You use CacheClient or just Cache notion to refer to an instance of the > cache class. Let's use one term. I prefer the Cache one or IgniteCache if > it's named this way. > * Add a reference to the examples once they are merged to Ignite repo (see > the latest section on the readme page) > * Add a reference to Node.JS APIs within supported APIs section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-8589) Prepare Node.JS Thin Client documentation
[ https://issues.apache.org/jira/browse/IGNITE-8589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda closed IGNITE-8589. --- > Prepare Node.JS Thin Client documentation > - > > Key: IGNITE-8589 > URL: https://issues.apache.org/jira/browse/IGNITE-8589 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Pavel Petroshenko >Priority: Major > Fix For: 2.6 > > > The hidden page is presently here: > https://apacheignite.readme.io/v2.4/docs/nodejs-thin-client > Once all the suggestions are resolved, we might split this page into several > pages. I can do this closer to 2.6 release. > [~pavel.petroshenko], [~alexey.kosenchuk], please address the following > suggestions for now: > Installation section: > * Ignite repository has to be used instead of the private one > * The section needs to explain the installation steps once the NPM module is > released. It's fine to put the current installation instructions under > "Installing from Sources" section. > Data Types: > * The term "field" is truly confusing. Does it really imply any possible data > (value, key, element of an array)? Why can't we use the term "value" instead? > * Provide a code snippet that shows how to configure the explicit mapping > * Default mapping has to be documented in place on readme.io (no references > to the private GIT repo) > Configuring Ignite Client > *Failover on a reconnect code snippet. How to pass a list of the endpoints. > General: > * You use CacheClient or just Cache notion to refer to an instance of the > cache class. Let's use one term. I prefer the Cache one or IgniteCache if > it's named this way. > * Add a reference to the examples once they are merged to Ignite repo (see > the latest section on the readme page) > * Add a reference to Node.JS APIs within supported APIs section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8727) Provide way to test MMap WAL modes failures
[ https://issues.apache.org/jira/browse/IGNITE-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8727: --- Description: Currently tests 4 are failed in PDS 2 suite with timeout: IgnitePdsTestSuite2: IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailAfterStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailWhileStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailAfterStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailWhileStart (fail rate 100,0%) Tests were introduced in ticket [IGNITE-7809]. Tests try to emulate failure using exceptions in file IO, but MMap-ed modes does not allow currently to be tested with current tests approach. It is suggested to create new testing opportunities for MMap modes. was: Currently tests 4 are failed in PDS 2 suite with timeout: IgnitePdsTestSuite2: IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailAfterStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailWhileStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailAfterStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailWhileStart (fail rate 100,0%) Tests tries to emulate failure using exceptions in file IO, but MMap-ed modes does not allow currently to be tested with current tests approach. It is suggested to create new testing opportunities for MMap modes. > Provide way to test MMap WAL modes failures > --- > > Key: IGNITE-8727 > URL: https://issues.apache.org/jira/browse/IGNITE-8727 > Project: Ignite > Issue Type: Test > Components: persistence >Reporter: Dmitriy Pavlov >Assignee: Andrey Gura >Priority: Major > Labels: MakeTeamcityGreenAgain > > Currently tests 4 are failed in PDS 2 suite with timeout: > IgnitePdsTestSuite2: > IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailAfterStart (fail rate > 100,0%) > IgnitePdsTestSuite2: > IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailWhileStart (fail rate > 100,0%) > IgnitePdsTestSuite2: > IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailAfterStart (fail rate > 100,0%) > IgnitePdsTestSuite2: > IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailWhileStart (fail rate > 100,0%) > Tests were introduced in ticket [IGNITE-7809]. > Tests try to emulate failure using exceptions in file IO, but MMap-ed modes > does not allow currently to be tested with current tests approach. > It is suggested to create new testing opportunities for MMap modes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8727) Provide way to test MMap WAL modes failures
Dmitriy Pavlov created IGNITE-8727: -- Summary: Provide way to test MMap WAL modes failures Key: IGNITE-8727 URL: https://issues.apache.org/jira/browse/IGNITE-8727 Project: Ignite Issue Type: Test Components: persistence Reporter: Dmitriy Pavlov Assignee: Andrey Gura Currently tests 4 are failed in PDS 2 suite with timeout: IgnitePdsTestSuite2: IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailAfterStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushBackgroundWithMmapBufferSelfTest.testFailWhileStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailAfterStart (fail rate 100,0%) IgnitePdsTestSuite2: IgniteWalFlushLogOnlyWithMmapBufferSelfTest.testFailWhileStart (fail rate 100,0%) Tests tries to emulate failure using exceptions in file IO, but MMap-ed modes does not allow currently to be tested with current tests approach. It is suggested to create new testing opportunities for MMap modes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8625) Dynamic SQL index recreate after cache clear may result in AssertionError or JVM crash
[ https://issues.apache.org/jira/browse/IGNITE-8625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-8625: --- Labels: MakeTeamcityGreenAgain (was: ) > Dynamic SQL index recreate after cache clear may result in AssertionError or > JVM crash > -- > > Key: IGNITE-8625 > URL: https://issues.apache.org/jira/browse/IGNITE-8625 > Project: Ignite > Issue Type: Bug > Components: persistence, sql >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Critical > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > Attachments: dyn_idx_reproducer.patch > > > After recreation of previously dropped SQL index (in persistent mode), root > page of new index B+ tree may contain links to data entries from previous > index tree. If these entries were removed or relocated to another data page, > attempt to dereference these links may throw AssertionError or even cause JVM > crash. > Patch with reproducer is attached. > P.S. Please note that with IGNITE-4958 fix old invalid links may refer to > non-data page - it might have been recycled into page with any other type. > Such case will cause AssertionError on page read lock attempt. Rolling back > IGNITE-4958 may help with debugging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8726) Highlight that memory metrics are local for a node in the docs
Stanislav Lukyanov created IGNITE-8726:
--
Summary: Highlight that memory metrics are local for a node in the
docs
Key: IGNITE-8726
URL: https://issues.apache.org/jira/browse/IGNITE-8726
Project: Ignite
Issue Type: Improvement
Components: documentation
Reporter: Stanislav Lukyanov
Memory Metrics (DataRegionMetrics and DataStorageMetrics) in Ignite are local
for each node. However, this is not highlighted in the documentation enough.
The code snippets suggest to just call `ignite.dataRegionMetrics()` which seems
to be a bit at odds with the general use case of Ignite servers being started
via ignite.sh.
It would be good to have an easily noticeable warning that the metrics will
only return data for the local node (and that, for example, on client they
would typically always print 0).
Also, would be nice to include a couple of practical approaches other than JMX
to collect metrics. E.g. a snippet of client code getting metrics from all
servers:
{code}
Collection metricsFromNodes = ignite.compute().broadcast(() -> {
Ignite ignite = Ignition.localIgnite();
StringBuilder sb = new StringBuilder();
sb.append("Node: " + ignite.name());
for (DataRegionMetrics metrics : ignite.dataRegionMetrics()) {
// append metrics to the builder
}
return sb.toString();
});
for (String metricsString : metricsFromNodes)
System.out.println(metricsString);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503044#comment-16503044
]
Alexey Kuznetsov edited comment on IGNITE-955 at 6/6/18 4:16 PM:
-
[~vkulichenko] [~yzhdanov]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If no listeners or filters set, should exception be thrown ? I, believe yes
was (Author: alexey kuznetsov):
[~vkulichenko] [~yzhdanov]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If local listener not set, primary node must not send notifications to node,
started continuous query, am I right ?
4)If no listeners or filters set, should exception be thrown ? I, believe yes
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Labels: Usability
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8702) Crash in ODBC driver under Informatica connection checker
[
https://issues.apache.org/jira/browse/IGNITE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503494#comment-16503494
]
ASF GitHub Bot commented on IGNITE-8702:
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/4144
IGNITE-8702: Replaced select() with poll() for Linux
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8702
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4144.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 #4144
commit d9cb7bd1eadd1153eb1e69cfe090071bfe065c7c
Author: Igor Sapego
Date: 2018-06-06T15:28:36Z
IGNITE-8702: Replaced select() with poll() for Linux
> Crash in ODBC driver under Informatica connection checker
> -
>
> Key: IGNITE-8702
> URL: https://issues.apache.org/jira/browse/IGNITE-8702
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Igor Sapego
>Priority: Major
>
> I'm trying to connect Informatica to Ignite via ODBC.
> When I try to specify my connection as a ready-made DSN by its name, it
> starts connecting to remote but then fails:
> {code}
> [ikasnacheev@lab15 ODBC7.1]$ IGNITE_ODBC_LOG_PATH=/home/ikasnacheev/odbc2.log
> INFA_HOME=/storage/ssd/ikasnacheev
> LD_LIBRARY_PATH=/storage/ssd/ikasnacheev/ODBC7.1/lib:$LD_LIBRARY_PATH:/storage/ssd/ikasnacheev/services/shared/bin
> /storage/ssd/ikasnacheev/java/jre/bin/java -d64 -DpwdDecrypt=true
> -DconnectionName=Lab -DuserName=lab -Dpassword="nq/Jypc7Q2EhoQ2iAQlOCA=="
> -DconnectionString=LABignite -DdataStoreType=ODBC
> -DINFA_HOME=/storage/ssd/ikasnacheev -classpath
> '.:/storage/ssd/ikasnacheev/services/AdministratorConsole/webapps/administrator/WEB-INF/lib/*:/storage/ssd/ikasnacheev/services/shared/jars/platform/*:/storage/ssd/ikasnacheev/services/shared/jars/thirdparty/*:/storage/ssd/ikasnacheev/plugins/osgi/*:/storage/ssd/ikasnacheev/plugins/infa/*:/storage/ssd/ikasnacheev/plugins/dynamic/*'
> com.informatica.adminconsole.app.chain.commands.TestODBCConnection
> ...
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7faeb806d5e4, pid=26471, tid=140392269498112
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build
> 1.8.0_77-b03)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libignite-odbc.so+0x2c5e4]
> ignite::odbc::system::TcpSocketClient::Connect(char const*, unsigned short,
> int, ignite::odbc::diagnostic::Diagnosable&)+0x7b4
> {code}
> The contents of Ignite driver log file as follows:
> {code}
> SQLAllocEnv: SQLAllocEnv called
> SQLSetEnvAttr: SQLSetEnvAttr called
> AddStatusRecord: Adding new record: ODBC version is not supported., rowNum:
> 0, columnNum: 0
> SQLAllocConnect: SQLAllocConnect called
> SQLGetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> GetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> SQLSetConnectOption: SQLSetConnectOption called
> SQLConnect: SQLConnect called
> SQLConnect: DSN: LABignite
> Connect: Host: 172.25.1.16, port: 10800
> Connect: Addr: 172.25.1.16
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8702) Crash in ODBC driver under Informatica connection checker
[
https://issues.apache.org/jira/browse/IGNITE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503422#comment-16503422
]
Igor Sapego commented on IGNITE-8702:
-
Ok, it seems like an issue is really a {{select()}} call with the socket handle
which is larger than 1023. I'm going to use {{poll()}} instead for Linux.
> Crash in ODBC driver under Informatica connection checker
> -
>
> Key: IGNITE-8702
> URL: https://issues.apache.org/jira/browse/IGNITE-8702
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Igor Sapego
>Priority: Major
>
> I'm trying to connect Informatica to Ignite via ODBC.
> When I try to specify my connection as a ready-made DSN by its name, it
> starts connecting to remote but then fails:
> {code}
> [ikasnacheev@lab15 ODBC7.1]$ IGNITE_ODBC_LOG_PATH=/home/ikasnacheev/odbc2.log
> INFA_HOME=/storage/ssd/ikasnacheev
> LD_LIBRARY_PATH=/storage/ssd/ikasnacheev/ODBC7.1/lib:$LD_LIBRARY_PATH:/storage/ssd/ikasnacheev/services/shared/bin
> /storage/ssd/ikasnacheev/java/jre/bin/java -d64 -DpwdDecrypt=true
> -DconnectionName=Lab -DuserName=lab -Dpassword="nq/Jypc7Q2EhoQ2iAQlOCA=="
> -DconnectionString=LABignite -DdataStoreType=ODBC
> -DINFA_HOME=/storage/ssd/ikasnacheev -classpath
> '.:/storage/ssd/ikasnacheev/services/AdministratorConsole/webapps/administrator/WEB-INF/lib/*:/storage/ssd/ikasnacheev/services/shared/jars/platform/*:/storage/ssd/ikasnacheev/services/shared/jars/thirdparty/*:/storage/ssd/ikasnacheev/plugins/osgi/*:/storage/ssd/ikasnacheev/plugins/infa/*:/storage/ssd/ikasnacheev/plugins/dynamic/*'
> com.informatica.adminconsole.app.chain.commands.TestODBCConnection
> ...
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7faeb806d5e4, pid=26471, tid=140392269498112
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build
> 1.8.0_77-b03)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libignite-odbc.so+0x2c5e4]
> ignite::odbc::system::TcpSocketClient::Connect(char const*, unsigned short,
> int, ignite::odbc::diagnostic::Diagnosable&)+0x7b4
> {code}
> The contents of Ignite driver log file as follows:
> {code}
> SQLAllocEnv: SQLAllocEnv called
> SQLSetEnvAttr: SQLSetEnvAttr called
> AddStatusRecord: Adding new record: ODBC version is not supported., rowNum:
> 0, columnNum: 0
> SQLAllocConnect: SQLAllocConnect called
> SQLGetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> GetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> SQLSetConnectOption: SQLSetConnectOption called
> SQLConnect: SQLConnect called
> SQLConnect: DSN: LABignite
> Connect: Host: 172.25.1.16, port: 10800
> Connect: Addr: 172.25.1.16
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7618) validateCache synchronously waits for state change
[
https://issues.apache.org/jira/browse/IGNITE-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503420#comment-16503420
]
Ryabov Dmitrii commented on IGNITE-7618:
[~agoncharuk], can you write reproducer for this hanging? Also
{{GridDhtTopologyFutureAdapter}} and it's inheritor
{{ClientCacheDhtTopologyFuture}} doesn't have {{ExchangeActions}}, but it
validates cache too. So what we should do in this case? We can move
{{ExchangeActions}} from {{GridDhtPartitionsExchangeFuture}} to the abstract
class and set every time, so {{ClientCacheDhtTopologyFuture}} will have it too.
Or we can use something else.
> validateCache synchronously waits for state change
> --
>
> Key: IGNITE-7618
> URL: https://issues.apache.org/jira/browse/IGNITE-7618
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Alexey Goncharuk
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> Currently, we call publicApiActiveState(waitForTransition=true) in
> GridDhtTopologyFutureAdapter#validateCache. This is incorrect, because the
> cluster state is updated from discovery thread, and mapping may be happening
> on a previous topology version. We must capture the cluster active state flag
> to the exchange future (I believe we already have all the mechanics for this
> in ExchangeActions class) and validate the state in the exchange future
> itself, without touching ClusterStateProcessor.
> Below is an example of a deadlock happened because of synchronous wait:
> {code}
> "db-checkpoint-thread-#12318%database.IgniteDbBaselineTopologySelfTest0%"
> #15498 prio=5 os_prio=0 tid=0x7fa173e80800 nid=0x3d08 waiting on
> condition [0x7fa2069a8000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007abfc16e8> (a
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:943)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:2991)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2797)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2722)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> "snapshot-scheduler-restats-#12202%database.IgniteDbBaselineTopologySelfTest0%"
> #15332 prio=5 os_prio=0 tid=0x7fa228143000 nid=0x3c65 waiting on
> condition [0x7fa2be919000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.publicApiActiveState(GridClusterStateProcessor.java:194)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:83)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:787)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:763)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:646)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.txLockAsync(GridDistributedCacheAdapter.java:109)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.getAllAsync(GridNearTxLocal.java:1723)
> at
>
[jira] [Commented] (IGNITE-8610) Searching checkpoint / WAL history for rebalancing is not properly working in case of local/global WAL disabling
[
https://issues.apache.org/jira/browse/IGNITE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503419#comment-16503419
]
Alexey Goncharuk commented on IGNITE-8610:
--
[~Jokser], a few comments:
* In {{GridDhtPreloader}} you've added the following code:
{code}
if (!assignments.isEmpty() && grp.persistenceEnabled()) {
ctx.database().checkpointReadLock();
try {
((GridCacheDatabaseSharedManager)
ctx.database()).lastCheckpointInapplicableForWalRebalance(grp.groupId());
}
finally {
ctx.database().checkpointReadUnlock();
}
}
{code}
I suggest to introduce such a method to the DatabaseSharedManager and have it
empty for default implementation, while persistence-enabled implementation will
acquire checkpoint read lock and du necessary work. This will hide both
{{instanceof}} and {{if (persistenceEnabled())}}
* You've added a synchronous wait for partition re-creation in
{{generateAssignments}}, which happens in exchange thread. Let's add our
generic timed-spin-wait and warn if the wait is too long.
> Searching checkpoint / WAL history for rebalancing is not properly working in
> case of local/global WAL disabling
>
>
> Key: IGNITE-8610
> URL: https://issues.apache.org/jira/browse/IGNITE-8610
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.6
>
>
> After implementation IGNITE-6411 and IGNITE-8087 we can face with situation
> when after some checkpoint, WAL was temporarily disabled and enabled again.
> In this case we can't treat that checkpoint as start point to rebalance,
> because WAL history after such checkpoint may contain gaps.
> We should rework our checkpoint / wal history searching mechanism and ignore
> such checkpoints.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
[
https://issues.apache.org/jira/browse/IGNITE-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503410#comment-16503410
]
Denis Garus commented on IGNITE-8183:
-
[~sergey-chugunov], done. Thank.
> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> 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:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch
> fails. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6010) ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes
[
https://issues.apache.org/jira/browse/IGNITE-6010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503407#comment-16503407
]
Vitaliy Biryukov commented on IGNITE-6010:
--
[~NSAmelchev], LGTM.
> ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper fails sometimes
> ---
>
> Key: IGNITE-6010
> URL: https://issues.apache.org/jira/browse/IGNITE-6010
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Affects Versions: 2.1
>Reporter: Ilya Lantukh
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.6
>
>
> {noformat}
> junit.framework.AssertionFailedError: null
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.ZookeeperIpFinderTest.testFourNodesKillRestartZookeeper(ZookeeperIpFinderTest.java:365)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8183) ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
[
https://issues.apache.org/jira/browse/IGNITE-8183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503395#comment-16503395
]
Sergey Chugunov commented on IGNITE-8183:
-
[~garus.d.g],
Now change seems good to me, please fix minor typo in java comment (*[tickTime
* initLimit]* should be instead of *[tickTime + initLimit]*) and proceed with
merging.
> ZookeeperDiscoverySpiTest#testSegmentation3 fails on TC and locally
> ---
>
> Key: IGNITE-8183
> URL: https://issues.apache.org/jira/browse/IGNITE-8183
> Project: Ignite
> Issue Type: Bug
> Components: zookeeper
>Reporter: Sergey Chugunov
>Assignee: Denis Garus
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test fails with assertion on awaits on latch:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:55)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.Assert.assertTrue(Assert.java:31)
> at junit.framework.TestCase.assertTrue(TestCase.java:201)
> at
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testSegmentation3(ZookeeperDiscoverySpiTest.java:1060)
> 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:2080)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> For some reason SEGMENTATION event is never fired, so assertion on latch
> fails. Investigation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8725) Make IGNITE_DISABLE_WAL_DURING_REBALANCING enabled by default
[ https://issues.apache.org/jira/browse/IGNITE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh updated IGNITE-8725: - Description: In IGNITE-8017 we introduced ability to automatically disable WAL during rebalancing, but now this mechanism is controlled by aforementioned system property, which is set to *false* by default. > Make IGNITE_DISABLE_WAL_DURING_REBALANCING enabled by default > - > > Key: IGNITE-8725 > URL: https://issues.apache.org/jira/browse/IGNITE-8725 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Lantukh >Priority: Major > > In IGNITE-8017 we introduced ability to automatically disable WAL during > rebalancing, but now this mechanism is controlled by aforementioned system > property, which is set to *false* by default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8725) Make IGNITE_DISABLE_WAL_DURING_REBALANCING enabled by default
Ilya Lantukh created IGNITE-8725: Summary: Make IGNITE_DISABLE_WAL_DURING_REBALANCING enabled by default Key: IGNITE-8725 URL: https://issues.apache.org/jira/browse/IGNITE-8725 Project: Ignite Issue Type: Improvement Reporter: Ilya Lantukh -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8685) Incorrect size for switch segment record
[ https://issues.apache.org/jira/browse/IGNITE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503379#comment-16503379 ] ASF GitHub Bot commented on IGNITE-8685: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4130 > Incorrect size for switch segment record > - > > Key: IGNITE-8685 > URL: https://issues.apache.org/jira/browse/IGNITE-8685 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.6 > > > We have invariant that switch segment record should have the size of one byte. > Although, in the current implementation, size calculation with overhard for > storing CRC and WAL pointer. > In current implementation, we can suddenly stop WAL iteration which may > result in random data store corruptions or missing updates on node recovery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503044#comment-16503044
]
Alexey Kuznetsov edited comment on IGNITE-955 at 6/6/18 2:18 PM:
-
[~vkulichenko] [~yzhdanov]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If local listener not set, primary node must not send notifications to node,
started continuous query, am I right ?
4)If no listeners or filters set, should exception be thrown ? I, believe yes
was (Author: alexey kuznetsov):
[~vkulichenko] [~yzhdanov]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If no listeners or filters set, should exception be thrown ? I, believe yes
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Labels: Usability
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8668) K-fold cross validation of models
[ https://issues.apache.org/jira/browse/IGNITE-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503361#comment-16503361 ] ASF GitHub Bot commented on IGNITE-8668: GitHub user dmitrievanthony opened a pull request: https://github.com/apache/ignite/pull/4143 IGNITE-8668 K-fold cross validation of models You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8668 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4143.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 #4143 commit e392b6acafb3fa2752b77fcd942dc85b482b4bec Author: Anton Dmitriev Date: 2018-05-31T14:57:26Z IGNITE-8666 Add predicates into CacheBasedDatasetBuilder and LocalDatasetBuilder. commit c50a645e3f3a0e277f98e02916eaf4b62731ff52 Author: Anton Dmitriev Date: 2018-05-31T15:08:58Z IGNITE-8666 Add dataset predicate support to examples. commit efa7e33ced5e9f313f4b9521aef76568f0e9d1bf Author: Anton Dmitriev Date: 2018-05-31T15:09:08Z IGNITE-8666 Add dataset predicate support to examples. commit 737738febe0bedd8ceb362f6204b6a0d79679579 Author: Anton Dmitriev Date: 2018-05-31T15:26:13Z IGNITE-8666 Add constructor with default predicate to CacheBased and Local Dataset Builders. commit 28565c356057bc36c09fc17c8daf7aa3e2827eb5 Author: Anton Dmitriev Date: 2018-05-31T16:18:17Z IGNITE-8666 Use default ScanQuery filter instead of custom cursor wrapper. commit a7932692789b3ef59bfb713839bffb9b73aa0597 Author: dmitrievanthony Date: 2018-05-31T20:30:36Z IGNITE-8666 Use default transformer instead of UpstreamCursorAdapter. commit f77f13e9c7698be7bd0176d9f531875c572cd4d3 Author: dmitrievanthony Date: 2018-05-31T20:49:32Z IGNITE-8666 Use default constructs of CacheBased and Local Dataset Builders. commit e6eb7473645ed0bf248f7c4badd87ac4c20e34d4 Author: dmitrievanthony Date: 2018-05-31T20:52:58Z IGNITE-8666 Fix code style. commit b9e8a105a61912f9e7ceb6064d5528ba12f017b1 Author: Anton Dmitriev Date: 2018-06-01T08:06:49Z IGNITE-8666 Add KNNRegressionTrainer to trainers hierarchy. commit dd09c0a809c81c34a6ae8ac95278080565965b47 Author: Anton Dmitriev Date: 2018-06-01T08:23:34Z IGNITE-8666 Fix javadoc in ComputeUtils class. commit a004bf20342fef500045f830e821954616a2164b Author: Anton Dmitriev Date: 2018-06-01T09:10:04Z IGNITE-8666 Add concurrent modification checker to dataset builders. commit 88b2483cf3a601935140f43edafe2e13b03506eb Author: Anton Dmitriev Date: 2018-06-01T09:32:54Z Merge branch 'ignite-8666' into ignite-8667 commit c2291f3e01b98c3f22a57652ecab500e67e29aef Author: Anton Dmitriev Date: 2018-06-01T11:23:29Z IGNITE-8666 Rename pred -> filter. commit 05b527dd346cdedf3e2f823a6a5761d240ff381a Author: Anton Dmitriev Date: 2018-06-01T11:24:49Z Merge branch 'ignite-8666' into ignite-8667 commit 7bab5832d5a94f0f9f46f17286161b2738538179 Author: Anton Dmitriev Date: 2018-06-01T13:37:16Z IGNITE-8667 First version of TrainTest dataset splitter. commit 206a9cbaf132ea515b3e8aa7b3832df3332d2c71 Author: Anton Dmitriev Date: 2018-06-04T14:27:49Z IGNITE-8667 Add unified mapper for train test splitter and tests. commit fe6a7f05eb0926f8bfc07885c6f6ed3ab335956f Author: Anton Dmitriev Date: 2018-06-04T14:34:45Z Merge remote-tracking branch 'origin/master' into ignite-8667 # Conflicts: # modules/ml/src/main/java/org/apache/ignite/ml/dataset/impl/cache/util/ComputeUtils.java commit 7f206303bc3f0782b65765ca2894c18c07c6c11b Author: Anton Dmitriev Date: 2018-06-04T14:41:25Z IGNITE-8667 Revert wrong changes. commit d65e2c48973e8d82617d5c22e2ee51fecb5a5787 Author: Anton Dmitriev Date: 2018-06-05T08:03:04Z IGNITE-8667 Add licence header to UniformMapper. commit 35bbeda25832b21685cbaa9633e8d4b38b0bd0a5 Author: Anton Dmitriev Date: 2018-06-05T08:13:49Z Merge branch 'ignite-8667' into ignite-8668 commit 88269b86b3e6c668276984470f16a4bee9ffc013 Author: Anton Dmitriev Date: 2018-06-05T13:27:33Z IGNITE-8667 Add ability to make recursive train test split. commit 6a68cf32ba577e1b85132cc891ab50363397a541 Author: Anton Dmitriev Date: 2018-06-05T13:28:52Z Merge branch 'ignite-8667' into ignite-8668 commit 6e9d9b38b0d58733ffe7113d3d32853cedf0a20f Author: Anton Dmitriev Date: 2018-06-05T16:40:37Z IGNITE-8667 Fix code style. commit 84b74a64723137314a420e8199d7185b98212bff Author: Anton Dmitriev Date: 2018-06-05T16:41:45Z Merge branch 'ignite-8667' into ignite-8668 commit 23788ead8aae7e67cde925787a08b68eebfc263b Author: Anton Dmitriev Date: 2018-06-06T10:11:56Z IGNITE-8668 Initial version of cross validation score
[jira] [Created] (IGNITE-8724) Skip logging 3-rd parameter while calling U.warn with initialized logger.
Stanilovsky Evgeny created IGNITE-8724:
--
Summary: Skip logging 3-rd parameter while calling U.warn with
initialized logger.
Key: IGNITE-8724
URL: https://issues.apache.org/jira/browse/IGNITE-8724
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 2.5
Reporter: Stanilovsky Evgeny
Assignee: Stanilovsky Evgeny
There are a lot of places where exception need to be logged, for example :
{code:java}
U.warn(log,"Unable to await partitions release future", e);
{code}
but current U.warn realization silently swallow it.
{code:java}
public static void warn(@Nullable IgniteLogger log, Object longMsg, Object
shortMsg) {
assert longMsg != null;
assert shortMsg != null;
if (log != null)
log.warning(compact(longMsg.toString()));
else
X.println("[" + SHORT_DATE_FMT.format(new java.util.Date()) + "]
(wrn) " +
compact(shortMsg.toString()));
}
{code}
fix, looks like simple add:
{code:java}
public static void warn(@Nullable IgniteLogger log, Object longMsg,
Throwable ex) {
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8377) Add cluster (de)activation LifecycleBean callbacks
[
https://issues.apache.org/jira/browse/IGNITE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503351#comment-16503351
]
Alexey Goncharuk commented on IGNITE-8377:
--
[~stalkxt] this ticket is a duplicate. Are you planning to work on it?
> Add cluster (de)activation LifecycleBean callbacks
> --
>
> Key: IGNITE-8377
> URL: https://issues.apache.org/jira/browse/IGNITE-8377
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Sergey Dorozhkin
>Priority: Major
> Labels: newbie
> Fix For: 2.6
>
>
> I suggest to add new {{LifecycleEventType}}, {{BEFORE_CLUSTER_ACTIVATE}},
> {{AFTER_CLUSTER_ACTIVATE}}, {{BEFORE_CLUSTER_DEACTIVATE}},
> {{AFTER_CLUSTER_DEACTIVATE}} and fire corresponding lifecycle events along
> with regular events.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8723) Detect index corruption at runtime
[
https://issues.apache.org/jira/browse/IGNITE-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503349#comment-16503349
]
Vladimir Ozerov edited comment on IGNITE-8723 at 6/6/18 2:10 PM:
-
[~agoncharuk], I doubt it would work for MVCC. Consider an {{UPDATE}} or
{{SELECT FOR UPDATE}} query which needs to take a lock on a key. All such
queries must lock a key on a primary node.
I think more generic approach here is to disable an index cluster-wide. This is
common practice in other databases - indexes could be switched off ("offline")
either manually, or automatically in case of corrupt. We already has necessary
infrastructure for this - exchange-like consensus protocol to initiate DDL
change, and hidden indexes, which are not used in queries, but are still
updated (we can disable it if needed).
I think this would be better solution than adding more complexity to request
routing logic which is already non trivial (partitioned vs replicated,
multicast vsunicast, update w/ and w/o reducer, MVCC cases, etc).
was (Author: vozerov):
[~agoncharuk], I doubt it would work for MVCC. Consider an {{UPDATE}} or
{{SELECT FOR UPDATE}} query which needs to take a lock on a key. All such
queries must lock a kay on a primary node.
I think more generic approach here is to disable an index cluster-wide. This is
common practice in other databases - indexes could be switched off ("offline")
either manually, or automatically in case of corrupt. We already has necessary
infrastructure for this - exchange-like consensus protocol to initiate DDL
change, and hidden indexes, which are not used in queries, but are still
updated (we can disable it if needed).
I think this would be better solution than adding more complexity to request
routing logic which is already non trivial (partitioned vs replicated,
multicast vsunicast, update w/ and w/o reducer, MVCC cases, etc).
> Detect index corruption at runtime
> --
>
> Key: IGNITE-8723
> URL: https://issues.apache.org/jira/browse/IGNITE-8723
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.6
>
>
> Several times Ignite users faced a situation when SQL indexes were corrupted
> (linked to invalid or removed data).
> I think it makes sense to slightly rework such errors during index
> dereference, and
> 1) Fail all ongoing and further SQL queries assigned to this node. SQL mapper
> should cache this and try to re-route SQL requests to other OWNING nodes
> 2) After index corruption is detected, all or only corrupted indexes should
> be deallocated (the decision depends on what is faster) and rebuilt
> 3) After indexes are rebuilt, we should notify other nodes that the node is
> available for queries again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8723) Detect index corruption at runtime
[
https://issues.apache.org/jira/browse/IGNITE-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503349#comment-16503349
]
Vladimir Ozerov commented on IGNITE-8723:
-
[~agoncharuk], I doubt it would work for MVCC. Consider an {{UPDATE}} or
{{SELECT FOR UPDATE}} query which needs to take a lock on a key. All such
queries must lock a kay on a primary node.
I think more generic approach here is to disable an index cluster-wide. This is
common practice in other databases - indexes could be switched off ("offline")
either manually, or automatically in case of corrupt. We already has necessary
infrastructure for this - exchange-like consensus protocol to initiate DDL
change, and hidden indexes, which are not used in queries, but are still
updated (we can disable it if needed).
I think this would be better solution than adding more complexity to request
routing logic which is already non trivial (partitioned vs replicated,
multicast vsunicast, update w/ and w/o reducer, MVCC cases, etc).
> Detect index corruption at runtime
> --
>
> Key: IGNITE-8723
> URL: https://issues.apache.org/jira/browse/IGNITE-8723
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.6
>
>
> Several times Ignite users faced a situation when SQL indexes were corrupted
> (linked to invalid or removed data).
> I think it makes sense to slightly rework such errors during index
> dereference, and
> 1) Fail all ongoing and further SQL queries assigned to this node. SQL mapper
> should cache this and try to re-route SQL requests to other OWNING nodes
> 2) After index corruption is detected, all or only corrupted indexes should
> be deallocated (the decision depends on what is faster) and rebuilt
> 3) After indexes are rebuilt, we should notify other nodes that the node is
> available for queries again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0
[ https://issues.apache.org/jira/browse/IGNITE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503347#comment-16503347 ] Peter Ivanov commented on IGNITE-8534: -- Hi, [~dpavlov]. >From the point of Ignite Releases view, there should be no problems. I just do not have 100% understanding where scalar-2.10 module was used to be 100% sure there will no usability problems of ignite itself. > Upgrade Ignite Spark Module's Spark version to 2.3.0 > > > Key: IGNITE-8534 > URL: https://issues.apache.org/jira/browse/IGNITE-8534 > Project: Ignite > Issue Type: Improvement > Components: spark >Reporter: Ray >Assignee: Ray >Priority: Major > Fix For: 2.6 > > > Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite > Spark module to to the latest version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8723) Detect index corruption at runtime
[ https://issues.apache.org/jira/browse/IGNITE-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-8723: - Fix Version/s: 2.6 > Detect index corruption at runtime > -- > > Key: IGNITE-8723 > URL: https://issues.apache.org/jira/browse/IGNITE-8723 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.6 > > > Several times Ignite users faced a situation when SQL indexes were corrupted > (linked to invalid or removed data). > I think it makes sense to slightly rework such errors during index > dereference, and > 1) Fail all ongoing and further SQL queries assigned to this node. SQL mapper > should cache this and try to re-route SQL requests to other OWNING nodes > 2) After index corruption is detected, all or only corrupted indexes should > be deallocated (the decision depends on what is faster) and rebuilt > 3) After indexes are rebuilt, we should notify other nodes that the node is > available for queries again -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8534) Upgrade Ignite Spark Module's Spark version to 2.3.0
[ https://issues.apache.org/jira/browse/IGNITE-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503324#comment-16503324 ] Dmitriy Pavlov commented on IGNITE-8534: Hi [~vveider], do you see any risks from point of view of Ignite releases? > Upgrade Ignite Spark Module's Spark version to 2.3.0 > > > Key: IGNITE-8534 > URL: https://issues.apache.org/jira/browse/IGNITE-8534 > Project: Ignite > Issue Type: Improvement > Components: spark >Reporter: Ray >Assignee: Ray >Priority: Major > Fix For: 2.6 > > > Spark released its newest version 2.3.0 on Feb 28th, we should upgrade Ignite > Spark module to to the latest version. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8723) Detect index corruption at runtime
Alexey Goncharuk created IGNITE-8723: Summary: Detect index corruption at runtime Key: IGNITE-8723 URL: https://issues.apache.org/jira/browse/IGNITE-8723 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk Several times Ignite users faced a situation when SQL indexes were corrupted (linked to invalid or removed data). I think it makes sense to slightly rework such errors during index dereference, and 1) Fail all ongoing and further SQL queries assigned to this node. SQL mapper should cache this and try to re-route SQL requests to other OWNING nodes 2) After index corruption is detected, all or only corrupted indexes should be deallocated (the decision depends on what is faster) and rebuilt 3) After indexes are rebuilt, we should notify other nodes that the node is available for queries again -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8722) Issue in REST API 2.5
[
https://issues.apache.org/jira/browse/IGNITE-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503317#comment-16503317
]
Denis Dijak commented on IGNITE-8722:
-
I'll throw something together
> Issue in REST API 2.5
> -
>
> Key: IGNITE-8722
> URL: https://issues.apache.org/jira/browse/IGNITE-8722
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: Denis Dijak
>Priority: Major
> Labels: rest
>
> In 2.5 ignite REST-API dosent show cache value structure correctly
> rest-api 2.4
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU"],
> "child":
> { "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
> "child": null }
> }
>
> rest-api2.5
> "0013289414":
> { "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
> As you can see the child is missing. If i switch back to 2.4 REST-API
> everything works as expected.
> The above structure is class ValidityNode and the child that is missing in
> 2.5 is also a ValidityNode. The structure is meant to be as parent-child
> implementation.
> public class ValidityNode {
> private long timeFrom;
> private long timeTo;
> private ArrayList results = null;
> private ValidityNode child = null;
> public ValidityNode()
> { // default constructor }
> public long getTimeFrom()
> { return timeFrom; }
> public void setTimeFrom(long timeFrom)
> { this.timeFrom = timeFrom; }
> public long getTimeTo()
> { return timeTo; }
> public void setTimeTo(long timeTo)
> { this.timeTo = timeTo; }
> public ArrayList getResults()
> { return results; }
> public void setResults(ArrayList results)
> { this.results = results; }
> public ValidityNode getChild()
> { return child; }
> public void setChild(ValidityNode child)
> { this.child = child; }
> @Override
> public String toString()
> { return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
> results=" + results + ", child=" + child + "]"; }
> Is this issue maybe related to keyType and valueType that were intruduced in
> 2.5?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8702) Crash in ODBC driver under Informatica connection checker
[
https://issues.apache.org/jira/browse/IGNITE-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503332#comment-16503332
]
Igor Sapego commented on IGNITE-8702:
-
It seems that informatica assumes that ODBC driver is thread-safe and tries to
destroy connection, while another thread still sending data to a server.
> Crash in ODBC driver under Informatica connection checker
> -
>
> Key: IGNITE-8702
> URL: https://issues.apache.org/jira/browse/IGNITE-8702
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.4
>Reporter: Ilya Kasnacheev
>Assignee: Igor Sapego
>Priority: Major
>
> I'm trying to connect Informatica to Ignite via ODBC.
> When I try to specify my connection as a ready-made DSN by its name, it
> starts connecting to remote but then fails:
> {code}
> [ikasnacheev@lab15 ODBC7.1]$ IGNITE_ODBC_LOG_PATH=/home/ikasnacheev/odbc2.log
> INFA_HOME=/storage/ssd/ikasnacheev
> LD_LIBRARY_PATH=/storage/ssd/ikasnacheev/ODBC7.1/lib:$LD_LIBRARY_PATH:/storage/ssd/ikasnacheev/services/shared/bin
> /storage/ssd/ikasnacheev/java/jre/bin/java -d64 -DpwdDecrypt=true
> -DconnectionName=Lab -DuserName=lab -Dpassword="nq/Jypc7Q2EhoQ2iAQlOCA=="
> -DconnectionString=LABignite -DdataStoreType=ODBC
> -DINFA_HOME=/storage/ssd/ikasnacheev -classpath
> '.:/storage/ssd/ikasnacheev/services/AdministratorConsole/webapps/administrator/WEB-INF/lib/*:/storage/ssd/ikasnacheev/services/shared/jars/platform/*:/storage/ssd/ikasnacheev/services/shared/jars/thirdparty/*:/storage/ssd/ikasnacheev/plugins/osgi/*:/storage/ssd/ikasnacheev/plugins/infa/*:/storage/ssd/ikasnacheev/plugins/dynamic/*'
> com.informatica.adminconsole.app.chain.commands.TestODBCConnection
> ...
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7faeb806d5e4, pid=26471, tid=140392269498112
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_77-b03) (build
> 1.8.0_77-b03)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.77-b03 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libignite-odbc.so+0x2c5e4]
> ignite::odbc::system::TcpSocketClient::Connect(char const*, unsigned short,
> int, ignite::odbc::diagnostic::Diagnosable&)+0x7b4
> {code}
> The contents of Ignite driver log file as follows:
> {code}
> SQLAllocEnv: SQLAllocEnv called
> SQLSetEnvAttr: SQLSetEnvAttr called
> AddStatusRecord: Adding new record: ODBC version is not supported., rowNum:
> 0, columnNum: 0
> SQLAllocConnect: SQLAllocConnect called
> SQLGetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> GetInfo: SQLGetInfo called: 77 (SQL_DRIVER_ODBC_VER), 7faec08d1450, 6,
> 7faf9f5a29ee
> SQLSetConnectOption: SQLSetConnectOption called
> SQLConnect: SQLConnect called
> SQLConnect: DSN: LABignite
> Connect: Host: 172.25.1.16, port: 10800
> Connect: Addr: 172.25.1.16
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8722) Issue in REST API 2.5
[
https://issues.apache.org/jira/browse/IGNITE-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503297#comment-16503297
]
Alexey Kuznetsov commented on IGNITE-8722:
--
[~skymania] It is possible to attach a full reproducer?
> Issue in REST API 2.5
> -
>
> Key: IGNITE-8722
> URL: https://issues.apache.org/jira/browse/IGNITE-8722
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: Denis Dijak
>Priority: Major
> Labels: rest
>
> In 2.5 ignite REST-API dosent show cache value structure correctly
> rest-api 2.4
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU"],
> "child":
> { "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
> "child": null }
> }
>
> rest-api2.5
> "0013289414":
> { "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
> As you can see the child is missing. If i switch back to 2.4 REST-API
> everything works as expected.
> The above structure is class ValidityNode and the child that is missing in
> 2.5 is also a ValidityNode. The structure is meant to be as parent-child
> implementation.
> public class ValidityNode {
> private long timeFrom;
> private long timeTo;
> private ArrayList results = null;
> private ValidityNode child = null;
> public ValidityNode()
> { // default constructor }
> public long getTimeFrom()
> { return timeFrom; }
> public void setTimeFrom(long timeFrom)
> { this.timeFrom = timeFrom; }
> public long getTimeTo()
> { return timeTo; }
> public void setTimeTo(long timeTo)
> { this.timeTo = timeTo; }
> public ArrayList getResults()
> { return results; }
> public void setResults(ArrayList results)
> { this.results = results; }
> public ValidityNode getChild()
> { return child; }
> public void setChild(ValidityNode child)
> { this.child = child; }
> @Override
> public String toString()
> { return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
> results=" + results + ", child=" + child + "]"; }
> Is this issue maybe related to keyType and valueType that were intruduced in
> 2.5?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503291#comment-16503291
]
Ryabov Dmitrii commented on IGNITE-2313:
[~agoncharuk], yes, this subject was discussed in separate ticket [1], and
users in the thread were agree about this change.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-4188-savepoints-with-atomic-cache-td15827.html
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8722) Issue in REST API 2.5
[
https://issues.apache.org/jira/browse/IGNITE-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Dijak updated IGNITE-8722:
Description:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"],
"child":
{ "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
"child": null }
}
rest-api2.5
"0013289414":
{ "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
was:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
],
"child": {
"timeFrom": 1527166800,
"timeTo": 10413788400,
"results": ["BUSINESS-EU"],
"child": null
}
}
rest-api2.5
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"]
}
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
> Issue in REST API 2.5
> -
>
> Key: IGNITE-8722
> URL: https://issues.apache.org/jira/browse/IGNITE-8722
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: Denis Dijak
>Priority: Major
> Labels: rest
>
> In 2.5 ignite REST-API dosent show cache value structure correctly
> rest-api 2.4
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU"],
> "child":
> { "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
> "child": null }
> }
>
> rest-api2.5
> "0013289414":
> { "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
> As you can see the child is missing. If i switch back to 2.4 REST-API
> everything works as expected.
> The above structure is class ValidityNode and the child that is missing in
> 2.5 is also a ValidityNode. The structure is meant to be as parent-child
> implementation.
> public class ValidityNode {
> private long timeFrom;
> private long timeTo;
> private ArrayList results = null;
> private ValidityNode child = null;
> public ValidityNode()
> { // default constructor }
> public long getTimeFrom()
> { return timeFrom; }
> public void setTimeFrom(long timeFrom)
> { this.timeFrom = timeFrom; }
> public long getTimeTo()
> { return timeTo; }
> public void setTimeTo(long timeTo)
> { this.timeTo = timeTo; }
> public ArrayList getResults()
> { return results; }
> public void
[jira] [Updated] (IGNITE-8722) Issue in REST API 2.5
[
https://issues.apache.org/jira/browse/IGNITE-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Dijak updated IGNITE-8722:
Description:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
],
"child": {
"timeFrom": 1527166800,
"timeTo": 10413788400,
"results": ["BUSINESS-EU"],
"child": null
}
}
rest-api2.5
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"]
}
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
was:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
],
"child": {
"timeFrom": 1527166800,
"timeTo": 10413788400,
"results": ["BUSINESS-EU"],
"child": null
}
}
rest-api2.5
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"]
}
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
> Issue in REST API 2.5
> -
>
> Key: IGNITE-8722
> URL: https://issues.apache.org/jira/browse/IGNITE-8722
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: Denis Dijak
>Priority: Major
> Labels: rest
>
> In 2.5 ignite REST-API dosent show cache value structure correctly
> rest-api 2.4
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU",
> ],
> "child": {
> "timeFrom": 1527166800,
> "timeTo": 10413788400,
> "results": ["BUSINESS-EU"],
> "child": null
> }
> }
>
> rest-api2.5
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU"]
> }
> As you can see the child is missing. If i switch back to 2.4 REST-API
> everything works as expected.
> The above structure is class ValidityNode and the child that is missing in
> 2.5 is also a ValidityNode. The structure is meant to be as parent-child
> implementation.
> public class ValidityNode {
> private long timeFrom;
> private long timeTo;
> private ArrayList results = null;
> private ValidityNode child = null;
> public ValidityNode()
> { // default constructor }
> public long getTimeFrom()
> { return timeFrom; }
> public void setTimeFrom(long timeFrom)
> { this.timeFrom = timeFrom; }
> public long getTimeTo()
> { return timeTo; }
> public void setTimeTo(long timeTo)
> { this.timeTo = timeTo; }
> public ArrayList getResults()
> { return
[jira] [Updated] (IGNITE-8722) Issue in REST API 2.5
[
https://issues.apache.org/jira/browse/IGNITE-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Dijak updated IGNITE-8722:
Description:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
],
"child": {
"timeFrom": 1527166800,
"timeTo": 10413788400,
"results": ["BUSINESS-EU"],
"child": null
}
}
rest-api2.5
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"]
}
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
was:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"],
"child":
{ "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
"child": null }
}
rest-api2.5
"0013289414":
{ "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
> Issue in REST API 2.5
> -
>
> Key: IGNITE-8722
> URL: https://issues.apache.org/jira/browse/IGNITE-8722
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: Denis Dijak
>Priority: Major
> Labels: rest
>
> In 2.5 ignite REST-API dosent show cache value structure correctly
> rest-api 2.4
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU",
> ],
> "child": {
> "timeFrom": 1527166800,
> "timeTo": 10413788400,
> "results": ["BUSINESS-EU"],
> "child": null
> }
> }
>
> rest-api2.5
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU"]
> }
> As you can see the child is missing. If i switch back to 2.4 REST-API
> everything works as expected.
> The above structure is class ValidityNode and the child that is missing in
> 2.5 is also a ValidityNode. The structure is meant to be as parent-child
> implementation.
> public class ValidityNode {
> private long timeFrom;
> private long timeTo;
> private ArrayList results = null;
> private ValidityNode child = null;
> public ValidityNode()
> { // default constructor }
> public long getTimeFrom()
> { return timeFrom; }
> public void setTimeFrom(long timeFrom)
> { this.timeFrom = timeFrom; }
> public long getTimeTo()
> { return timeTo; }
> public void setTimeTo(long timeTo)
> { this.timeTo = timeTo; }
> public ArrayList getResults()
> { return
[jira] [Updated] (IGNITE-8722) Issue in REST API 2.5
[
https://issues.apache.org/jira/browse/IGNITE-8722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Dijak updated IGNITE-8722:
Description:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU"],
"child":
{ "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
"child": null }
}
rest-api2.5
"0013289414":
{ "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode()
{ // default constructor }
public long getTimeFrom()
{ return timeFrom; }
public void setTimeFrom(long timeFrom)
{ this.timeFrom = timeFrom; }
public long getTimeTo()
{ return timeTo; }
public void setTimeTo(long timeTo)
{ this.timeTo = timeTo; }
public ArrayList getResults()
{ return results; }
public void setResults(ArrayList results)
{ this.results = results; }
public ValidityNode getChild()
{ return child; }
public void setChild(ValidityNode child)
{ this.child = child; }
@Override
public String toString()
{ return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child=" + child + "]"; }
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
was:
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
],
"child": {
"timeFrom": 1527166800,
"timeTo": 10413788400,
"results": ["BUSINESS-EU",
],
"child": null
}
}
rest-api2.5
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
]
}
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode() {
// default constructor
}
public long getTimeFrom() {
return timeFrom;
}
public void setTimeFrom(long timeFrom) {
this.timeFrom = timeFrom;
}
public long getTimeTo() {
return timeTo;
}
public void setTimeTo(long timeTo) {
this.timeTo = timeTo;
}
public ArrayList getResults() {
return results;
}
public void setResults(ArrayList results) {
this.results = results;
}
public ValidityNode getChild() {
return child;
}
public void setChild(ValidityNode child) {
this.child = child;
}
@Override
public String toString() {
return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child="
+ child + "]";
}
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
> Issue in REST API 2.5
> -
>
> Key: IGNITE-8722
> URL: https://issues.apache.org/jira/browse/IGNITE-8722
> Project: Ignite
> Issue Type: Bug
> Components: rest
>Affects Versions: 2.5
>Reporter: Denis Dijak
>Priority: Major
> Labels: rest
>
> In 2.5 ignite REST-API dosent show cache value structure correctly
> rest-api 2.4
> "0013289414": {
> "timeFrom": 1527166800,
> "timeTo": 1528199550,
> "results": ["BUSINESS-EU"],
> "child":
> { "timeFrom": 1527166800, "timeTo": 10413788400, "results": ["BUSINESS-EU"],
> "child": null }
> }
>
> rest-api2.5
> "0013289414":
> { "timeFrom": 1527166800, "timeTo": 1528199550, "results": ["BUSINESS-EU"] }
> As you can see the child is missing. If i switch back to 2.4 REST-API
> everything works as expected.
> The above structure is class ValidityNode and the child that is missing in
> 2.5 is also a ValidityNode. The structure is meant to be as parent-child
> implementation.
> public class ValidityNode {
> private long timeFrom;
> private long timeTo;
> private ArrayList results = null;
> private ValidityNode child = null;
> public ValidityNode()
> { // default constructor }
> public long getTimeFrom()
> { return timeFrom; }
> public void setTimeFrom(long timeFrom)
> { this.timeFrom = timeFrom; }
> public long getTimeTo()
> { return timeTo; }
> public void setTimeTo(long timeTo)
> { this.timeTo = timeTo; }
> public ArrayList getResults()
> { return results;
[jira] [Created] (IGNITE-8722) Issue in REST API 2.5
Denis Dijak created IGNITE-8722:
---
Summary: Issue in REST API 2.5
Key: IGNITE-8722
URL: https://issues.apache.org/jira/browse/IGNITE-8722
Project: Ignite
Issue Type: Bug
Components: rest
Affects Versions: 2.5
Reporter: Denis Dijak
In 2.5 ignite REST-API dosent show cache value structure correctly
rest-api 2.4
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
],
"child": {
"timeFrom": 1527166800,
"timeTo": 10413788400,
"results": ["BUSINESS-EU",
],
"child": null
}
}
rest-api2.5
"0013289414": {
"timeFrom": 1527166800,
"timeTo": 1528199550,
"results": ["BUSINESS-EU",
]
}
As you can see the child is missing. If i switch back to 2.4 REST-API
everything works as expected.
The above structure is class ValidityNode and the child that is missing in 2.5
is also a ValidityNode. The structure is meant to be as parent-child
implementation.
public class ValidityNode {
private long timeFrom;
private long timeTo;
private ArrayList results = null;
private ValidityNode child = null;
public ValidityNode() {
// default constructor
}
public long getTimeFrom() {
return timeFrom;
}
public void setTimeFrom(long timeFrom) {
this.timeFrom = timeFrom;
}
public long getTimeTo() {
return timeTo;
}
public void setTimeTo(long timeTo) {
this.timeTo = timeTo;
}
public ArrayList getResults() {
return results;
}
public void setResults(ArrayList results) {
this.results = results;
}
public ValidityNode getChild() {
return child;
}
public void setChild(ValidityNode child) {
this.child = child;
}
@Override
public String toString() {
return "ValidityNode [timeFrom=" + timeFrom + ", timeTo=" + timeTo + ",
results=" + results + ", child="
+ child + "]";
}
Is this issue maybe related to keyType and valueType that were intruduced in
2.5?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-2313) Need to add a mode to fail atomic operations within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503262#comment-16503262
]
Alexey Goncharuk commented on IGNITE-2313:
--
[~SomeFire], in this implementation this is a breaking change and will likely
affect existing users. Was there any discussion on the dev-list regarding this
change? If not, please start one, the community have to agree whether default
behavior should be to thrown an exception (new behavior) or not (existing
behavior).
My preference would be to keep the old behavior.
> Need to add a mode to fail atomic operations within a transaction
> -
>
> Key: IGNITE-2313
> URL: https://issues.apache.org/jira/browse/IGNITE-2313
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Dmitriy Setrakyan
>Assignee: Ryabov Dmitrii
>Priority: Major
> Fix For: 2.6
>
>
> Currently atomic operations within a transaction succeed without alarming a
> user that no transaction really occurs. We should add a mode to fail such
> operations (such mode should be turned off by default).
> New transaction configuration flag (default is {{false}}):
> {code}TransactionConfiguration.isAllowAtomicUpdatesInTransaction(){code}
> If the flag is violated, we should throw an exception with the following
> error message: {{Transaction spans operations on atomic cache (consider
> setting TransactionConfiguration.isAllowAttomicUpdatesInTransaction() flag to
> true)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8482) Skip 2-phase partition release wait in case of activation or dynamic caches start
[ https://issues.apache.org/jira/browse/IGNITE-8482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503249#comment-16503249 ] ASF GitHub Bot commented on IGNITE-8482: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4078 > Skip 2-phase partition release wait in case of activation or dynamic caches > start > - > > Key: IGNITE-8482 > URL: https://issues.apache.org/jira/browse/IGNITE-8482 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.6 > > > Currently we perform 2-phase partitions release waiting on any type of > distributed exchange. We can optimize this behaviour, skipping such waiting > on cluster activation (obviously if we activate cluster it means that before > activation no caches were running and there is no reason to wait for > finishing operations) and on dynamic caches start. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8688) Pending tree is initialized outside of checkpoint lock
[
https://issues.apache.org/jira/browse/IGNITE-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503246#comment-16503246
]
Andrew Mashenkov commented on IGNITE-8688:
--
[~Jokser],
Would you please recheck this issue against latest master with IGNITE-8682 fix?
> Pending tree is initialized outside of checkpoint lock
> --
>
> Key: IGNITE-8688
> URL: https://issues.apache.org/jira/browse/IGNITE-8688
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Pavel Kovalenko
>Assignee: Andrew Mashenkov
>Priority: Critical
> Fix For: 2.6
>
>
> This may lead to possible page corruption.
> {noformat}
> handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.AssertionError]]
> [00:11:56]W: [org.gridgain:gridgain-compatibility]
> java.lang.AssertionError
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.allocatePage(PageMemoryImpl.java:463)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.allocateForTree(IgniteCacheOffheapManagerImpl.java:818)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.initPendingTree(IgniteCacheOffheapManagerImpl.java:164)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.onCacheStarted(IgniteCacheOffheapManagerImpl.java:151)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onCacheStarted(CacheGroupContext.java:283)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1965)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:791)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onClusterStateChangeRequest(GridDhtPartitionsExchangeFuture.java:946)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:651)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2458)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2338)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> [00:11:56]W: [org.gridgain:gridgain-compatibility] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8642) Failure processor should dump state of all threads
[
https://issues.apache.org/jira/browse/IGNITE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503243#comment-16503243
]
ASF GitHub Bot commented on IGNITE-8642:
Github user andrey-kuznetsov closed the pull request at:
https://github.com/apache/ignite/pull/4091
> Failure processor should dump state of all threads
> --
>
> Key: IGNITE-8642
> URL: https://issues.apache.org/jira/browse/IGNITE-8642
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Gura
>Assignee: Andrey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> Failure processor should dump state of all threads before failure handler is
> invoked.
> Use {{org.apache.ignite.internal.util.IgniteUtils#dumpThreads}} method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8663) L1,L2 normalization
[ https://issues.apache.org/jira/browse/IGNITE-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503223#comment-16503223 ] ASF GitHub Bot commented on IGNITE-8663: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4117 > L1,L2 normalization > --- > > Key: IGNITE-8663 > URL: https://issues.apache.org/jira/browse/IGNITE-8663 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Aleksey Zinoviev >Priority: Major > Fix For: 2.6 > > > We want to add L1 and L2 normalization using Model/Trainer API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503205#comment-16503205 ] Dmitriy Pavlov commented on IGNITE-8286: Hi [~ilantukh], could you please take a look? > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > Fix For: 2.6 > > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7339) RENTING partition is not evicted after restore from storage
[ https://issues.apache.org/jira/browse/IGNITE-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503204#comment-16503204 ] Dmitriy Pavlov commented on IGNITE-7339: [~Jokser], could you please take a look? > RENTING partition is not evicted after restore from storage > --- > > Key: IGNITE-7339 > URL: https://issues.apache.org/jira/browse/IGNITE-7339 > Project: Ignite > Issue Type: Bug >Reporter: Semen Boikov >Assignee: Alexei Scherbakov >Priority: Critical > > If partition was in RENTING state at the moment when node is stopped, then > after restart it is not evicted. > It seems it is an issue in GridDhtLocalPartition.rent, 'tryEvictAsync' is not > called is partition was already in RENTING state. > Also there is error in GridDhtPartitionTopologyImpl.checkEvictions: partition > state is always treated as changed after part.rent call even if part.rent > does not actually change state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8721) Third-party security is not integrated with JDBC and ODBC handlers (thin)
[
https://issues.apache.org/jira/browse/IGNITE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503200#comment-16503200
]
Vladimir Ozerov commented on IGNITE-8721:
-
Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=1364390
> Third-party security is not integrated with JDBC and ODBC handlers (thin)
> -
>
> Key: IGNITE-8721
> URL: https://issues.apache.org/jira/browse/IGNITE-8721
> Project: Ignite
> Issue Type: Task
> Components: jdbc, odbc, security
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> See
> {{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
> {code}
> if (kernalCtx.security().enabled())
> authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
> else if (kernalCtx.authentication().enabled()) {
> // Our own authentication.
> }
> {code}
> But we do not have the same check for JDBC and ODBC handlers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8721) Third-party security is not integrated with JDBC and ODBC handlers (thin)
[
https://issues.apache.org/jira/browse/IGNITE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503199#comment-16503199
]
ASF GitHub Bot commented on IGNITE-8721:
GitHub user devozerov opened a pull request:
https://github.com/apache/ignite/pull/4142
IGNITE-8721
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8721
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4142.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 #4142
commit 178edafcd8a3f605bf503ddf0c8566dbbc350111
Author: devozerov
Date: 2018-06-06T12:00:45Z
Client base.
commit 6a81509e4b498b93ab4481230cfd4e098b478420
Author: devozerov
Date: 2018-06-06T12:09:31Z
Done.
> Third-party security is not integrated with JDBC and ODBC handlers (thin)
> -
>
> Key: IGNITE-8721
> URL: https://issues.apache.org/jira/browse/IGNITE-8721
> Project: Ignite
> Issue Type: Task
> Components: jdbc, odbc, security
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> See
> {{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
> {code}
> if (kernalCtx.security().enabled())
> authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
> else if (kernalCtx.authentication().enabled()) {
> // Our own authentication.
> }
> {code}
> But we do not have the same check for JDBC and ODBC handlers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503196#comment-16503196
]
Pavel Kuznetsov edited comment on IGNITE-8720 at 6/6/18 12:12 PM:
--
Query is created as attempt to rewrite query 15.sql.original without "create
view" (views are currently unsupported)
was (Author: pkouznet):
Query is created as attempt to rewrite query 15.sql.original
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, 15.sql.original, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see output of sqlline (out.log) attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Attachment: 15.sql.original
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, 15.sql.original, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see output of sqlline (out.log) attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Attachment: (was: 15.sql.original)
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, 15.sql.original, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see output of sqlline (out.log) attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503196#comment-16503196
]
Pavel Kuznetsov commented on IGNITE-8720:
-
Query is created as attempt to rewrite query 15.sql.original
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, 15.sql.original, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see output of sqlline (out.log) attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Attachment: 15.sql.original
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, 15.sql.original, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see output of sqlline (out.log) attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException
[ https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503186#comment-16503186 ] ASF GitHub Bot commented on IGNITE-5823: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2364 > Need to remove CacheAtomicUpdateTimeoutException > > > Key: IGNITE-5823 > URL: https://issues.apache.org/jira/browse/IGNITE-5823 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Sergey Dorozhkin >Priority: Minor > Labels: newbie > Fix For: 2.6 > > > And releated - CacheAtomicUpdateTimeoutCheckedException > These exceptions are not used any more and can be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException
[ https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-5823: --- Fix Version/s: 2.6 > Need to remove CacheAtomicUpdateTimeoutException > > > Key: IGNITE-5823 > URL: https://issues.apache.org/jira/browse/IGNITE-5823 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Sergey Dorozhkin >Priority: Minor > Labels: newbie > Fix For: 2.6 > > > And releated - CacheAtomicUpdateTimeoutCheckedException > These exceptions are not used any more and can be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8503) IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry which should be expired by TTL policy is available after grid restart
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-8503:
-
Labels: MakeTeamcityGreenAgain Muted_test tck_issues (was:
MakeTeamcityGreenAgain Muted_test)
> IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry
> which should be expired by TTL policy is available after grid restart
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: cache, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test, tck_issues
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5798755758125626876=testDetails_IgniteTests24Java8=%3Cdefault%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8503) IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry which should be expired by TTL policy is available after grid restart
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-8503:
-
Component/s: cache
> IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry
> which should be expired by TTL policy is available after grid restart
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: cache, persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5798755758125626876=testDetails_IgniteTests24Java8=%3Cdefault%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8721) Third-party security is not integrated with JDBC and ODBC handlers (thin)
[
https://issues.apache.org/jira/browse/IGNITE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8721:
Description:
See
{{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
{code}
if (kernalCtx.security().enabled())
authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
else if (kernalCtx.authentication().enabled()) {
// Our own authentication.
}
{code}
But we do not have the same check for JDBC and ODBC handlers.
was:
See
{{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
{code}
if (kernalCtx.security().enabled())
authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
else if (kernalCtx.authentication().enabled()) {
// Our own authentication.
}
{code}
But we do not have the same check for
> Third-party security is not integrated with JDBC and ODBC handlers (thin)
> -
>
> Key: IGNITE-8721
> URL: https://issues.apache.org/jira/browse/IGNITE-8721
> Project: Ignite
> Issue Type: Task
> Components: jdbc, odbc, security
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> See
> {{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
> {code}
> if (kernalCtx.security().enabled())
> authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
> else if (kernalCtx.authentication().enabled()) {
> // Our own authentication.
> }
> {code}
> But we do not have the same check for JDBC and ODBC handlers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8721) Third-party security is not integrated with JDBC and ODBC handlers (thin)
[
https://issues.apache.org/jira/browse/IGNITE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8721:
Component/s: security
> Third-party security is not integrated with JDBC and ODBC handlers (thin)
> -
>
> Key: IGNITE-8721
> URL: https://issues.apache.org/jira/browse/IGNITE-8721
> Project: Ignite
> Issue Type: Task
> Components: jdbc, odbc, security
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> See
> {{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
> {code}
> if (kernalCtx.security().enabled())
> authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
> else if (kernalCtx.authentication().enabled()) {
> // Our own authentication.
> }
> {code}
> But we do not have the same check for
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8721) Third-party security is not integrated with JDBC and ODBC handlers (thin)
[
https://issues.apache.org/jira/browse/IGNITE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8721:
Description:
See
{{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
{code}
if (kernalCtx.security().enabled())
authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
else if (kernalCtx.authentication().enabled()) {
// Our own authentication.
}
{code}
But we do not have the same check for
> Third-party security is not integrated with JDBC and ODBC handlers (thin)
> -
>
> Key: IGNITE-8721
> URL: https://issues.apache.org/jira/browse/IGNITE-8721
> Project: Ignite
> Issue Type: Task
> Components: jdbc, odbc, security
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.6
>
>
> See
> {{org.apache.ignite.internal.processors.platform.client.ClientConnectionContext#initializeFromHandshake}}:
> {code}
> if (kernalCtx.security().enabled())
> authCtx = thirdPartyAuthentication(user, pwd).authorizationContext();
> else if (kernalCtx.authentication().enabled()) {
> // Our own authentication.
> }
> {code}
> But we do not have the same check for
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8721) Third-party security is not integrated with JDBC and ODBC handlers (thin)
Vladimir Ozerov created IGNITE-8721: --- Summary: Third-party security is not integrated with JDBC and ODBC handlers (thin) Key: IGNITE-8721 URL: https://issues.apache.org/jira/browse/IGNITE-8721 Project: Ignite Issue Type: Task Components: jdbc, odbc Affects Versions: 2.5 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.6 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException
[ https://issues.apache.org/jira/browse/IGNITE-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503163#comment-16503163 ] Anton Kalashnikov commented on IGNITE-5823: --- Looks good for me. Please merge. [~dpavlov] > Need to remove CacheAtomicUpdateTimeoutException > > > Key: IGNITE-5823 > URL: https://issues.apache.org/jira/browse/IGNITE-5823 > Project: Ignite > Issue Type: Task >Reporter: Yakov Zhdanov >Assignee: Sergey Dorozhkin >Priority: Minor > Labels: newbie > > And releated - CacheAtomicUpdateTimeoutCheckedException > These exceptions are not used any more and can be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503156#comment-16503156 ] Alexey Goncharuk commented on IGNITE-4111: -- I am moving this ticket to in-progress because the PR has conflicts with master. > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Minor > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503156#comment-16503156 ] Alexey Goncharuk edited comment on IGNITE-4111 at 6/6/18 11:23 AM: --- I am moving this ticket to in-progress because the PR has conflicts with master. [~sboikov] can you please unassign the ticket if you are not planning to work on it? was (Author: agoncharuk): I am moving this ticket to in-progress because the PR has conflicts with master. > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Minor > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503152#comment-16503152 ] Alexey Goncharuk edited comment on IGNITE-4111 at 6/6/18 11:22 AM: --- [~dpavlov] The ticket is still relevant, it would be great to merge it. was (Author: agoncharuk): [~dpavlov] The ticket is still relevant, it would be great to merged it. > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Minor > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503152#comment-16503152 ] Alexey Goncharuk edited comment on IGNITE-4111 at 6/6/18 11:22 AM: --- [~dpavlov] The ticket is still relevant, it would be great to merged it. was (Author: agoncharuk): [~dpavlov] The ticket is still relevant, it would be great to merged it. [~ein] will you be able to pull up master to resolve merge conflicts? If not, please move the ticket to the open state. > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Minor > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-4111) Communication fails to send message if target node did not finish join process
[ https://issues.apache.org/jira/browse/IGNITE-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503152#comment-16503152 ] Alexey Goncharuk commented on IGNITE-4111: -- [~dpavlov] The ticket is still relevant, it would be great to merged it. [~ein] will you be able to pull up master to resolve merge conflicts? If not, please move the ticket to the open state. > Communication fails to send message if target node did not finish join process > -- > > Key: IGNITE-4111 > URL: https://issues.apache.org/jira/browse/IGNITE-4111 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Semen Boikov >Assignee: Semen Boikov >Priority: Minor > Attachments: test onFirstMessage hang.log > > > Currently this scenario is possible: > - joining node sent join request and waits for > TcpDiscoveryNodeAddFinishedMessage inside ServerImpl.joinTopology > - others nodes already see this node and can send messages to it (for example > try to run compute job on this node) > - joining node can not receive message: TcpCommunicationSpi will hang inside > 'onFirstMessage' on 'getSpiContext' call, so sending node will get error > trying to establish connection > Possible fix: if in onFirstMessage() spi context is not available, then > TcpCommunicationSpi should send special response which indicates that this > node is not ready yet, and sender should retry after some time. > Also need check internal code for places where message can be unnecessarily > sent to node: one such place is > GridCachePartitionExchangeManager.refreshPartitions - message is sent to all > known nodes, but here we can filter by node order / finished exchage version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-1678) IgniteAtomicSequence: make following reservations in advance
[
https://issues.apache.org/jira/browse/IGNITE-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503143#comment-16503143
]
Alexey Goncharuk commented on IGNITE-1678:
--
[~DmitriyGovorukhin] can you please pull master to your PR so we can re-run
benchmarks?
> IgniteAtomicSequence: make following reservations in advance
>
>
> Key: IGNITE-1678
> URL: https://issues.apache.org/jira/browse/IGNITE-1678
> Project: Ignite
> Issue Type: Improvement
> Components: data structures
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.6
>
> Attachments: Screenshot from 2016-12-15 10-50-22.png
>
>
> In current implementation a new reservation is made when the current local
> sequence boundary is exceeded.
> In cases when there are many nodes that use the same atomic sequence there
> can be a situation when all the nodes start doing a new reservation at the
> same time. This can lead to performance drops.
> As a performance optimization it makes sense to start reserving new sequence
> slot in advance (in background), like when around 80% of current reservation
> has already been used. Probably we should add a special parameter to
> {{AtomicConfiguration}} that will manage such behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8503) IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry which should be expired by TTL policy is available after grid restart
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503131#comment-16503131
]
ASF GitHub Bot commented on IGNITE-8503:
GitHub user AMashenkov opened a pull request:
https://github.com/apache/ignite/pull/4141
IGNITE-8503: Fix IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart test.
WIP. Fix entry startVersion.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8503
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/4141.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 #4141
commit 613915624251de8c0d907ec35e835323b1f62c60
Author: Andrey V. Mashenkov
Date: 2018-06-06T11:01:14Z
WIP. Fix entry startVersion.
> IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry
> which should be expired by TTL policy is available after grid restart
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5798755758125626876=testDetails_IgniteTests24Java8=%3Cdefault%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Description:
Attached query (15.sql) fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
see output of sqlline (out.log) attached
was:
Attached query (15.sql) fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
see out.log attached
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see output of sqlline (out.log) attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503044#comment-16503044
]
Alexey Kuznetsov edited comment on IGNITE-955 at 6/6/18 10:53 AM:
--
[~vkulichenko] [~yzhdanov]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If no listeners or filters set, should exception be thrown ? I, believe yes
was (Author: alexey kuznetsov):
[~vkulichenko]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If no listeners or filters set, should exception be thrown ? I, believe yes
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Labels: Usability
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Description:
Attached query (15.sql) fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
see out.log attached
was:
Attached query (15.sql) fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
> see out.log attached
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Attachment: out.log
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, create_tables.sql, out.log
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Attachment: create_tables.sql
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql, create_tables.sql
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Attachment: 15.sql
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql
>
>
> Attached query fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8720) SQL: Failed to generate REDUCE query
Pavel Kuznetsov created IGNITE-8720:
---
Summary: SQL: Failed to generate REDUCE query
Key: IGNITE-8720
URL: https://issues.apache.org/jira/browse/IGNITE-8720
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Pavel Kuznetsov
Attached query fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8720) SQL: Failed to generate REDUCE query
[
https://issues.apache.org/jira/browse/IGNITE-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8720:
Description:
Attached query (15.sql) fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
was:
Attached query fails with
{noformat}
java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
generate REDUCE query. Data table found: PUBLIC.LINEITEM
{noformat}
> SQL: Failed to generate REDUCE query
>
>
> Key: IGNITE-8720
> URL: https://issues.apache.org/jira/browse/IGNITE-8720
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Attachments: 15.sql
>
>
> Attached query (15.sql) fails with
> {noformat}
> java.sql.SQLException: class org.apache.ignite.IgniteException: Failed to
> generate REDUCE query. Data table found: PUBLIC.LINEITEM
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7339) RENTING partition is not evicted after restore from storage
[ https://issues.apache.org/jira/browse/IGNITE-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503111#comment-16503111 ] Dmitriy Pavlov commented on IGNITE-7339: [~vozerov] has deleted mentioning of TC, I don't know reason for it. In how to contribute in section 'submit review process' there is also recommendation to mention committer/maineteiner you are expecting to do a review. This is best pracrice to run review faster, not a mandatory requirement. > RENTING partition is not evicted after restore from storage > --- > > Key: IGNITE-7339 > URL: https://issues.apache.org/jira/browse/IGNITE-7339 > Project: Ignite > Issue Type: Bug >Reporter: Semen Boikov >Assignee: Alexei Scherbakov >Priority: Critical > > If partition was in RENTING state at the moment when node is stopped, then > after restart it is not evicted. > It seems it is an issue in GridDhtLocalPartition.rent, 'tryEvictAsync' is not > called is partition was already in RENTING state. > Also there is error in GridDhtPartitionTopologyImpl.checkEvictions: partition > state is always treated as changed after part.rent call even if part.rent > does not actually change state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8657) Simultaneous start of bunch of client nodes may lead to some clients hangs
[ https://issues.apache.org/jira/browse/IGNITE-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503110#comment-16503110 ] Alexey Goncharuk commented on IGNITE-8657: -- Sergey, changes look good to me, but I have some suggestions for the test completeness: 1) Please verify that after the client is connected to the grid, it has the same affinity mapping as servers (you can match mapPartitionToNodes for the client and a server) 2) Add some cache put/get operations to verify that the client is operational 3) Check that after the last client is connected, all nodes have the same ready affinity topology version > Simultaneous start of bunch of client nodes may lead to some clients hangs > -- > > Key: IGNITE-8657 > URL: https://issues.apache.org/jira/browse/IGNITE-8657 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.6 > > > h3. Description > PartitionExchangeManager uses a system property > *IGNITE_EXCHANGE_HISTORY_SIZE* to manage max number of exchange objects and > optimize memory consumption. > Default value of the property is 1000 but in scenarios with many caches and > partitions it is reasonable to set exchange history size to a smaller values > around few dozens. > Then if user starts up at once more client nodes than history size some > clients may hang because their exchange information was preempted and no > longer available. > h3. Workarounds > Two workarounds are possible: > * Do not start at once more clients than history size. > * Restart hanging client node. > h3. Solution > Forcing client node to reconnect when server detected loosing its exchange > information prevents client nodes hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8503) IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry which should be expired by TTL policy is available after grid restart
[
https://issues.apache.org/jira/browse/IGNITE-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov reassigned IGNITE-8503:
Assignee: Andrew Mashenkov (was: Dmitriy Pavlov)
> IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart has flaky failure: Entry
> which should be expired by TTL policy is available after grid restart
>
>
> Key: IGNITE-8503
> URL: https://issues.apache.org/jira/browse/IGNITE-8503
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Dmitriy Pavlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, Muted_test
>
> Test was added during https://issues.apache.org/jira/browse/IGNITE-5874
> development.
> This test restarts grid and checks all entries are not present in grid.
> But with high possiblity one from 7000 entries to be expired is resurrected
> instead and returned by cache get.
> {noformat}
> After timeout {{
> >>>
> >>> Cache memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> Cache size: 0
> >>> Cache partition topology stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, grp=group1]
> >>>
> >>> Cache event manager memory stats
> >>> [igniteInstanceName=db.IgnitePdsWithTtlTest0, cache=expirableCache,
> >>> stats=N/A]
> >>>
> >>> Query manager memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> threadsSize: 0
> >>> futsSize: 0
> >>>
> >>> TTL processor memory stats [igniteInstanceName=db.IgnitePdsWithTtlTest0,
> >>> cache=expirableCache]
> >>> pendingEntriesSize: 0
> }} After timeout
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5798755758125626876=testDetails_IgniteTests24Java8=%3Cdefault%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8685) Incorrect size for switch segment record
[ https://issues.apache.org/jira/browse/IGNITE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503105#comment-16503105 ] Dmitriy Govorukhin commented on IGNITE-8685: [~agoncharuk] I fixed all your comments, please review again. > Incorrect size for switch segment record > - > > Key: IGNITE-8685 > URL: https://issues.apache.org/jira/browse/IGNITE-8685 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.6 > > > We have invariant that switch segment record should have the size of one byte. > Although, in the current implementation, size calculation with overhard for > storing CRC and WAL pointer. > In current implementation, we can suddenly stop WAL iteration which may > result in random data store corruptions or missing updates on node recovery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8657) Simultaneous start of bunch of client nodes may lead to some clients hangs
[ https://issues.apache.org/jira/browse/IGNITE-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503101#comment-16503101 ] Dmitriy Govorukhin commented on IGNITE-8657: [~sergey-chugunov] Could you please add external links in "Issue Links" section. > Simultaneous start of bunch of client nodes may lead to some clients hangs > -- > > Key: IGNITE-8657 > URL: https://issues.apache.org/jira/browse/IGNITE-8657 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.6 > > > h3. Description > PartitionExchangeManager uses a system property > *IGNITE_EXCHANGE_HISTORY_SIZE* to manage max number of exchange objects and > optimize memory consumption. > Default value of the property is 1000 but in scenarios with many caches and > partitions it is reasonable to set exchange history size to a smaller values > around few dozens. > Then if user starts up at once more client nodes than history size some > clients may hang because their exchange information was preempted and no > longer available. > h3. Workarounds > Two workarounds are possible: > * Do not start at once more clients than history size. > * Restart hanging client node. > h3. Solution > Forcing client node to reconnect when server detected loosing its exchange > information prevents client nodes hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-5977) [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence
[ https://issues.apache.org/jira/browse/IGNITE-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Gura updated IGNITE-5977: Fix Version/s: 2.6 > [Test Failed] IgniteClientDiscoveryDataStructuresTest.testSequence > --- > > Key: IGNITE-5977 > URL: https://issues.apache.org/jira/browse/IGNITE-5977 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Eduard Shangareev >Assignee: Aleksey Plekhanov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.6 > > > Fails locally. > Example of failing > http://ci.ignite.apache.org/viewLog.html?buildId=760759=buildResultsDiv=Ignite20Tests_IgniteDataStrucutures#testNameId2829619862655631000 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.
[ https://issues.apache.org/jira/browse/IGNITE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503083#comment-16503083 ] Andrew Mashenkov edited comment on IGNITE-8681 at 6/6/18 10:18 AM: --- I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart [2]. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [1] https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck|https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck] [2] https://issues.apache.org/jira/browse/IGNITE-8503 was (Author: amashenkov): I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart [2]. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [[1]https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck|https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck] [2] https://issues.apache.org/jira/browse/IGNITE-8503 > Using ExpiryPolicy with persistence causes significant slowdown. > > > Key: IGNITE-8681 > URL: https://issues.apache.org/jira/browse/IGNITE-8681 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: performance > Fix For: 2.6 > > > Almost all ignite operations calls CU.unwindEvicts() on finish to help to > evict expired entries. > In unwindEvicts(), threads iterate over all node partitions and check every > partition PendingTree for expired entries. This costs too much. > We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is > used. It raised once expiring entry has been put to cache or we initialize > non-empty pending tree from persistence. > So, we have to optimize a case when there is no expired pending entries, but > pending tree is non-empty. > We can add some throttling on per-partition basis to reduce useless pending > tree lookups. > E.g. if there is nothing to clean, no thread should check partition during > next 100ms interval. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.
[ https://issues.apache.org/jira/browse/IGNITE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503083#comment-16503083 ] Andrew Mashenkov edited comment on IGNITE-8681 at 6/6/18 10:18 AM: --- I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart [2]. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [1] [https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck] [2] https://issues.apache.org/jira/browse/IGNITE-8503 was (Author: amashenkov): I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart [2]. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [1] https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck|https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck] [2] https://issues.apache.org/jira/browse/IGNITE-8503 > Using ExpiryPolicy with persistence causes significant slowdown. > > > Key: IGNITE-8681 > URL: https://issues.apache.org/jira/browse/IGNITE-8681 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: performance > Fix For: 2.6 > > > Almost all ignite operations calls CU.unwindEvicts() on finish to help to > evict expired entries. > In unwindEvicts(), threads iterate over all node partitions and check every > partition PendingTree for expired entries. This costs too much. > We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is > used. It raised once expiring entry has been put to cache or we initialize > non-empty pending tree from persistence. > So, we have to optimize a case when there is no expired pending entries, but > pending tree is non-empty. > We can add some throttling on per-partition basis to reduce useless pending > tree lookups. > E.g. if there is nothing to clean, no thread should check partition during > next 100ms interval. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.
[ https://issues.apache.org/jira/browse/IGNITE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503083#comment-16503083 ] Andrew Mashenkov edited comment on IGNITE-8681 at 6/6/18 10:17 AM: --- I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart [2]. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [[1]https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck|https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck] [2] https://issues.apache.org/jira/browse/IGNITE-8503 was (Author: amashenkov): I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [1]https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck > Using ExpiryPolicy with persistence causes significant slowdown. > > > Key: IGNITE-8681 > URL: https://issues.apache.org/jira/browse/IGNITE-8681 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: performance > Fix For: 2.6 > > > Almost all ignite operations calls CU.unwindEvicts() on finish to help to > evict expired entries. > In unwindEvicts(), threads iterate over all node partitions and check every > partition PendingTree for expired entries. This costs too much. > We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is > used. It raised once expiring entry has been put to cache or we initialize > non-empty pending tree from persistence. > So, we have to optimize a case when there is no expired pending entries, but > pending tree is non-empty. > We can add some throttling on per-partition basis to reduce useless pending > tree lookups. > E.g. if there is nothing to clean, no thread should check partition during > next 100ms interval. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8657) Simultaneous start of bunch of client nodes may lead to some clients hangs
[ https://issues.apache.org/jira/browse/IGNITE-8657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503093#comment-16503093 ] Sergey Chugunov commented on IGNITE-8657: - Patch artifacts: [PR|https://github.com/apache/ignite/pull/4102], [TC|https://ci.ignite.apache.org/viewLog.html?buildId=1359981;], [review|https://reviews.ignite.apache.org/ignite/review/IGNT-CR-633] > Simultaneous start of bunch of client nodes may lead to some clients hangs > -- > > Key: IGNITE-8657 > URL: https://issues.apache.org/jira/browse/IGNITE-8657 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.6 > > > h3. Description > PartitionExchangeManager uses a system property > *IGNITE_EXCHANGE_HISTORY_SIZE* to manage max number of exchange objects and > optimize memory consumption. > Default value of the property is 1000 but in scenarios with many caches and > partitions it is reasonable to set exchange history size to a smaller values > around few dozens. > Then if user starts up at once more client nodes than history size some > clients may hang because their exchange information was preempted and no > longer available. > h3. Workarounds > Two workarounds are possible: > * Do not start at once more clients than history size. > * Restart hanging client node. > h3. Solution > Forcing client node to reconnect when server detected loosing its exchange > information prevents client nodes hanging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8696) control.sh utility does not show atomicity mode
[ https://issues.apache.org/jira/browse/IGNITE-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503091#comment-16503091 ] ASF GitHub Bot commented on IGNITE-8696: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4127 > control.sh utility does not show atomicity mode > --- > > Key: IGNITE-8696 > URL: https://issues.apache.org/jira/browse/IGNITE-8696 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Minor > Fix For: 2.6 > > > In current implementation cache viewer list function: > ./control.sh --cache list > does not show atomicity mode for caches. Please add this to the output. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8681) Using ExpiryPolicy with persistence causes significant slowdown.
[ https://issues.apache.org/jira/browse/IGNITE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503083#comment-16503083 ] Andrew Mashenkov commented on IGNITE-8681: -- I believe this failure caused by throttling for in-memory mode. I've disable it and re-run test [1]. We have flacky test IgnitePdsWithTtlTest.testTtlIsAppliedAfterRestart. I'm in the middle of investigation and seems, we have a bug in GridCacheMapEntry.innerGet0() method that ignores entry expiration is some cases. Most probably, this bug is causes TCK test failures. [1]https://ci.ignite.apache.org/viewLog.html?buildId=1363555=buildResultsDiv=IgniteTests24Java8_JCacheTck > Using ExpiryPolicy with persistence causes significant slowdown. > > > Key: IGNITE-8681 > URL: https://issues.apache.org/jira/browse/IGNITE-8681 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Critical > Labels: performance > Fix For: 2.6 > > > Almost all ignite operations calls CU.unwindEvicts() on finish to help to > evict expired entries. > In unwindEvicts(), threads iterate over all node partitions and check every > partition PendingTree for expired entries. This costs too much. > We already have a flag on per-cachegroup basis that indicated ExpiryPolicy is > used. It raised once expiring entry has been put to cache or we initialize > non-empty pending tree from persistence. > So, we have to optimize a case when there is no expired pending entries, but > pending tree is non-empty. > We can add some throttling on per-partition basis to reduce useless pending > tree lookups. > E.g. if there is nothing to clean, no thread should check partition during > next 100ms interval. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-955) Local listener in continuous queries should not be mandatory
[
https://issues.apache.org/jira/browse/IGNITE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503044#comment-16503044
]
Alexey Kuznetsov edited comment on IGNITE-955 at 6/6/18 10:02 AM:
--
[~vkulichenko]
1)What is the point of creating continuous query without local listener ?
2)What if we set transformer via _setRemoteTransformerFactory_ only, should
local listener be optional?
3)If no listeners or filters set, should exception be thrown ? I, believe yes
was (Author: alexey kuznetsov):
[~vkulichenko] what is the point of creating continuous query without local
listener ?
> Local listener in continuous queries should not be mandatory
>
>
> Key: IGNITE-955
> URL: https://issues.apache.org/jira/browse/IGNITE-955
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Major
> Labels: Usability
>
> We need to support the use case when remote filter is needed, but local
> listener is not (filter always returns {{false}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-8719: - Fix Version/s: 2.6 > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Critical > Fix For: 2.6 > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8719) Index left partially built if a node crashes during index create or rebuild
[ https://issues.apache.org/jira/browse/IGNITE-8719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-8719: - Issue Type: Bug (was: Improvement) > Index left partially built if a node crashes during index create or rebuild > --- > > Key: IGNITE-8719 > URL: https://issues.apache.org/jira/browse/IGNITE-8719 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Priority: Critical > Fix For: 2.6 > > > Currently, we do not have any state associated with the index tree. Consider > the following scenario: > 1) Start node, put some data > 2) start CREATE INDEX operation > 3) Wait for a checkpoint and stop node before index create finished > 4) Restart node > Since the checkpoint finished, the new index tree will be persisted to the > disk, but not all data will be present in the index. > We should somehow store information about initializing index tree and mark it > valid only after all data is indexed. The state should be persisted as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
