[jira] [Assigned] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails
[
https://issues.apache.org/jira/browse/IGNITE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Kuramshin reassigned IGNITE-7135:
--
Assignee: (was: Semen Boikov)
> IgniteCluster.startNodes() returns successful ClusterStartNodeResult even
> though the remote process fails
> -
>
> Key: IGNITE-7135
> URL: https://issues.apache.org/jira/browse/IGNITE-7135
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
> Labels: test
> Fix For: 2.4
>
>
> After unsuccessful start of three remote nodes with
> {{IgniteCluster#startNodes(Collection>,
> Map, boolean, int, int)}} we get
> {{Collection}} with three elements, each has
> {{isSuccess()}} is true.
> But the remote node startup log was
> {noformat}
> nohup: ignoring input
> /data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
> The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is
> incorrect.
> Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
> You can also download latest JDK at http://java.com/download
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails
[
https://issues.apache.org/jira/browse/IGNITE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandr Kuramshin reassigned IGNITE-7135:
--
Assignee: Semen Boikov (was: Alexandr Kuramshin)
> IgniteCluster.startNodes() returns successful ClusterStartNodeResult even
> though the remote process fails
> -
>
> Key: IGNITE-7135
> URL: https://issues.apache.org/jira/browse/IGNITE-7135
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Semen Boikov
> Labels: test
> Fix For: 2.4
>
>
> After unsuccessful start of three remote nodes with
> {{IgniteCluster#startNodes(Collection>,
> Map, boolean, int, int)}} we get
> {{Collection}} with three elements, each has
> {{isSuccess()}} is true.
> But the remote node startup log was
> {noformat}
> nohup: ignoring input
> /data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
> The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is
> incorrect.
> Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
> You can also download latest JDK at http://java.com/download
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-7135) IgniteCluster.startNodes() returns successful ClusterStartNodeResult even though the remote process fails
[
https://issues.apache.org/jira/browse/IGNITE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303606#comment-16303606
]
Alexandr Kuramshin edited comment on IGNITE-7135 at 12/26/17 7:32 AM:
--
TC done, looks good
https://ci.ignite.apache.org/viewLog.html?buildId=1016958&tab=queuedBuildOverviewTab
was (Author: ein):
TC done, looks good
> IgniteCluster.startNodes() returns successful ClusterStartNodeResult even
> though the remote process fails
> -
>
> Key: IGNITE-7135
> URL: https://issues.apache.org/jira/browse/IGNITE-7135
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Alexandr Kuramshin
>Assignee: Alexandr Kuramshin
> Labels: test
> Fix For: 2.4
>
>
> After unsuccessful start of three remote nodes with
> {{IgniteCluster#startNodes(Collection>,
> Map, boolean, int, int)}} we get
> {{Collection}} with three elements, each has
> {{isSuccess()}} is true.
> But the remote node startup log was
> {noformat}
> nohup: ignoring input
> /data/teamcity/work/820be461cd64b574/bin/ignite.sh, ERROR:
> The version of JAVA installed in JAVA_HOME=/usr/lib/jvm/java-9-oracle is
> incorrect.
> Please point JAVA_HOME variable to installation of JDK 1.7 or JDK 1.8.
> You can also download latest JDK at http://java.com/download
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-7210) Web console: Fix show time of "Connected clusters: N" label
[ https://issues.apache.org/jira/browse/IGNITE-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-7210: - Assignee: Pavel Konstantinov (was: Alexander Kalinin) Fixed. Please test. > Web console: Fix show time of "Connected clusters: N" label > --- > > Key: IGNITE-7210 > URL: https://issues.apache.org/jira/browse/IGNITE-7210 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > > Now that label showed quickly when login screen still shown or page is fully > empty. > Should appear together with page content. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7305) .NET: DataStorageConfiguration.WalBufferSize
Pavel Tupitsyn created IGNITE-7305:
--
Summary: .NET: DataStorageConfiguration.WalBufferSize
Key: IGNITE-7305
URL: https://issues.apache.org/jira/browse/IGNITE-7305
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Priority: Trivial
Add {{DataStorageConfiguration.WalBufferSize}} and
{{IDataStorageMetrics.WalBuffPollSpinsRate}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7304) Node discovery through AWS ELB
[ https://issues.apache.org/jira/browse/IGNITE-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303502#comment-16303502 ] Denis Magda commented on IGNITE-7304: - Ignite community will be more than happy to review and accept this integration. Please submit a pull-request and send a message to Ignite dev list bring the contribution request to our attention! > Node discovery through AWS ELB > -- > > Key: IGNITE-7304 > URL: https://issues.apache.org/jira/browse/IGNITE-7304 > Project: Ignite > Issue Type: New Feature > Components: aws >Affects Versions: 2.3 >Reporter: Bruno Barin > > Would be nice to have AWS ELB node discovery out of the box with Ignite. > I've already have developed code to perform this and is working well in > production if you agree, i can PR my solution -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4585) Support CLEAR command with REST
[ https://issues.apache.org/jira/browse/IGNITE-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303495#comment-16303495 ] ASF GitHub Bot commented on IGNITE-4585: GitHub user samaitra opened a pull request: https://github.com/apache/ignite/pull/3288 IGNITE-4585 Support CLEAR command with REST You can merge this pull request into a Git repository by running: $ git pull https://github.com/samaitra/ignite IGNITE-4585 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3288.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 #3288 commit 06458b954332d7d075029a5619e1649a6260b0c3 Author: samaitra Date: 2017-12-26T05:42:18Z IGNITE-4585 Support CLEAR command with REST commit 7e66a14ec32a1e241afdcf05d4a28945629ff04c Author: samaitra Date: 2017-12-26T05:42:40Z Merge remote-tracking branch 'upstream/master' into IGNITE-4585 > Support CLEAR command with REST > --- > > Key: IGNITE-4585 > URL: https://issues.apache.org/jira/browse/IGNITE-4585 > Project: Ignite > Issue Type: Improvement > Components: clients >Affects Versions: 1.8 >Reporter: Sam >Assignee: Saikat Maitra >Priority: Minor > > CLEAR command is not supported with REST Service, but DESTROY is supported. > CLEAR is more better option than DESTROY in many cases. > http://apache-ignite-users.70518.x6.nabble.com/REST-Service-for-CLEAR-td10150.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7210) Web console: Fix show time of "Connected clusters: N" label
[ https://issues.apache.org/jira/browse/IGNITE-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-7210: - Assignee: Alexander Kalinin (was: Alexey Kuznetsov) > Web console: Fix show time of "Connected clusters: N" label > --- > > Key: IGNITE-7210 > URL: https://issues.apache.org/jira/browse/IGNITE-7210 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Vasiliy Sisko >Assignee: Alexander Kalinin > > Now that label showed quickly when login screen still shown or page is fully > empty. > Should appear together with page content. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-7273) Web console: global visibility of User Profile
[ https://issues.apache.org/jira/browse/IGNITE-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-7273: - Assignee: Alexander Kalinin (was: Dmitriy Shabalin) > Web console: global visibility of User Profile > -- > > Key: IGNITE-7273 > URL: https://issues.apache.org/jira/browse/IGNITE-7273 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexander Kalinin >Priority: Minor > > # open two tabs with web console > # in the second tab open User\Profile page and make any changes, Save > # open Profile in the first tab - it doesn't show changes you made -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5764) web console: delete sql command doesn't work if max pages is not equal 'unlimited'
[ https://issues.apache.org/jira/browse/IGNITE-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-5764: - Assignee: Alexey Kuznetsov (was: Alexander Kalinin) > web console: delete sql command doesn't work if max pages is not equal > 'unlimited' > -- > > Key: IGNITE-5764 > URL: https://issues.apache.org/jira/browse/IGNITE-5764 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov > Attachments: screenshot-1.png > > > Current implementation works only with 'select' command > !screenshot-1.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-7296) Update RocketMQ dependencies to 4.2.0
[ https://issues.apache.org/jira/browse/IGNITE-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh closed IGNITE-7296. > Update RocketMQ dependencies to 4.2.0 > - > > Key: IGNITE-7296 > URL: https://issues.apache.org/jira/browse/IGNITE-7296 > Project: Ignite > Issue Type: Task >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7296) Update RocketMQ dependencies to 4.2.0
[ https://issues.apache.org/jira/browse/IGNITE-7296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303426#comment-16303426 ] ASF GitHub Bot commented on IGNITE-7296: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/3281 > Update RocketMQ dependencies to 4.2.0 > - > > Key: IGNITE-7296 > URL: https://issues.apache.org/jira/browse/IGNITE-7296 > Project: Ignite > Issue Type: Task >Reporter: Roman Shtykh >Assignee: Roman Shtykh > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7304) Node discovery through AWS ELB
Bruno Barin created IGNITE-7304: --- Summary: Node discovery through AWS ELB Key: IGNITE-7304 URL: https://issues.apache.org/jira/browse/IGNITE-7304 Project: Ignite Issue Type: New Feature Components: aws Affects Versions: 2.3 Reporter: Bruno Barin Would be nice to have AWS ELB node discovery out of the box with Ignite. I've already have developed code to perform this and is working well in production if you agree, i can PR my solution -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6740) Java 9: rework DirectBuffer.address() usages
[
https://issues.apache.org/jira/browse/IGNITE-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303375#comment-16303375
]
ASF GitHub Bot commented on IGNITE-6740:
Github user andrey-kuznetsov closed the pull request at:
https://github.com/apache/ignite/pull/3199
> Java 9: rework DirectBuffer.address() usages
>
>
> Key: IGNITE-6740
> URL: https://issues.apache.org/jira/browse/IGNITE-6740
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> We have two usages of {{DirectBuffer.address()}} method which is no longer
> accessible in Java 9:
> 1) {{DirectByteBufferStreamImplV1}}
> 2) {{DirectByteBufferStreamImplV2}}
> Need to rework this code using reflection and/or {{Unsafe}}, so that it
> compiles and work on all Java versions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7287) Thin client: idle connection timeout
[
https://issues.apache.org/jira/browse/IGNITE-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303318#comment-16303318
]
ASF GitHub Bot commented on IGNITE-7287:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/3287
IGNITE-7287 Thin client: idle connection timeout
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-7287
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3287.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 #3287
commit fafaf57003b16370dda9778bab0b2d1703a0027e
Author: Pavel Tupitsyn
Date: 2017-12-25T16:37:19Z
IGNITE-7287 Thin client: idle connection timeout
> Thin client: idle connection timeout
>
>
> Key: IGNITE-7287
> URL: https://issues.apache.org/jira/browse/IGNITE-7287
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.4
>
>
> Add an ability to drop inactive connections on server side, disabled by
> default: introduce {{ClientConnectorConfiguration.idleTimeout}}, default to
> {{long.MAX_VALUE}}.
> Currently we set {{GridNioServer.idleTimeout}} to {{MAX_VALUE}} in
> {{ClientListenerProcessor.start()}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6565) Use long type for size and keySize in cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303312#comment-16303312 ] Alexander Menshikov commented on IGNITE-6565: - [~ilyak] Please review. > Use long type for size and keySize in cache metrics > --- > > Key: IGNITE-6565 > URL: https://issues.apache.org/jira/browse/IGNITE-6565 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexander Menshikov > Labels: easyfix > > Currently it's int so for large caches there's no way to convey correct value. > Should introduce getSizeLong() and getKeySizeLong() > Also introduce the same in .Net and make sure that compatibility not broken > when passing OP_LOCAL_METRICS and OP_GLOBAL_METRICS. > BTW do we need keySize at all? What's it for? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7173) SQL: implement optional row cache
[ https://issues.apache.org/jira/browse/IGNITE-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303311#comment-16303311 ] Taras Ledkov commented on IGNITE-7173: -- [~vozerov], please review the patch. > SQL: implement optional row cache > - > > Key: IGNITE-7173 > URL: https://issues.apache.org/jira/browse/IGNITE-7173 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5623) DDL needs to support DEFAULT operator
[
https://issues.apache.org/jira/browse/IGNITE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303299#comment-16303299
]
Sergey Kalashnikov edited comment on IGNITE-5623 at 12/25/17 3:07 PM:
--
[~tledkov-gridgain], I have reviewed the changes. Overall it looks good, but I
have few comments:
1) Missing the implementation for Jdbc metadata, namely {{getColumns()}}. The
corresponding column for default value there is "COLUMN_DEF".
2) What will happen if the type of provided default value is not convertible to
the type of the column? Will the exception occur and when?
3) {{GridSqlQueryParser.parseAddColumn()}} - Perhaps we should add column name
to the exception.
4) {{BinaryFieldImpl.value()}}
You might want to move the check for zero schemaId into fieldOrder() where it
is used already and return BinarySchema.ORDER_NOT_FOUND.
5) {{QueryEntity}}
{{equals()}} and {{hashCode()}} needs to be updated.
was (Author: skalashnikov):
[~tledkov-gridgain], I have reviewed the changes. Overall it looks good, but I
have few comments:
1) Missing the implementation for Jdbc metadata, namely getColumns(). The
corresponding column for default value there is "COLUMN_DEF".
2) What will happen if the type of provided default value is not convertible to
the type of the column? Will the exception occur and when?
3) {GridSqlQueryParser.parseAddColumn()} - Perhaps we should add column name to
the exception.
4) {BinaryFieldImpl.value()}
You might want to move the check for zero schemaId into fieldOrder() where it
is used already and return BinarySchema.ORDER_NOT_FOUND.
5) {QueryEntity}
{equals()} and {hashCode()} needs to be updated.
> DDL needs to support DEFAULT operator
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
> Labels: important
> Fix For: 2.4
>
>
> There should be a way to set a default value for a column/field if the one is
> not specified during an insert operation. In general, we need to support
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
> ID int,
> FirstName varchar(255),
> Age int,
> City varchar(255) DEFAULT 'Sandnes'
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5623) DDL needs to support DEFAULT operator
[
https://issues.apache.org/jira/browse/IGNITE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303299#comment-16303299
]
Sergey Kalashnikov commented on IGNITE-5623:
[~tledkov-gridgain], I have reviewed the changes. Overall it looks good, but I
have few comments:
1) Missing the implementation for Jdbc metadata, namely getColumns(). The
corresponding column for default value there is "COLUMN_DEF".
2) What will happen if the type of provided default value is not convertible to
the type of the column? Will the exception occur and when?
3) {GridSqlQueryParser.parseAddColumn()} - Perhaps we should add column name to
the exception.
4) {BinaryFieldImpl.value()}
You might want to move the check for zero schemaId into fieldOrder() where it
is used already and return BinarySchema.ORDER_NOT_FOUND.
5) {QueryEntity}
{equals()} and {hashCode()} needs to be updated.
> DDL needs to support DEFAULT operator
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
> Labels: important
> Fix For: 2.4
>
>
> There should be a way to set a default value for a column/field if the one is
> not specified during an insert operation. In general, we need to support
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
> ID int,
> FirstName varchar(255),
> Age int,
> City varchar(255) DEFAULT 'Sandnes'
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7264) Caches with forward slash "/" in names cause problems for PDS
[
https://issues.apache.org/jira/browse/IGNITE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303297#comment-16303297
]
Stanislav Lukyanov commented on IGNITE-7264:
As said in the description, the root cause is that certain cache names are not
compatible with persistence because there is no way to create a file (a
directory) of that name. Slash leads to multiple directories being created,
some other symbols ('\0' on Unix, '<', '*' and other on Windows) just can't be
used, etc.
One way to handle that would be to check the name via `j.n.f.Paths.get()`
(check that the name is accepted on this platform and that it is a simple
name). However, I suspect that it might create more problems with portability
accross different file systems and encodings (say, a cache name "my::cache" is
valid on Unix but not on Windows).
Another way would be to disallow a large number of symbols/names on all
platforms - that requires finding this set and, possibly, widening it later.
Finally, instead of disallowing a set of characters, it could be
escaped/replaced in the file names (and left untouched in the cache names). For
instance, replace all non-alphanumeric characters in a cache name with
underscore, so that cache "foo/bar**foobar" has a persistence folder of name
"cache-foo_bar__foobar".
> Caches with forward slash "/" in names cause problems for PDS
> -
>
> Key: IGNITE-7264
> URL: https://issues.apache.org/jira/browse/IGNITE-7264
> Project: Ignite
> Issue Type: Bug
> Components: cache, persistence
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Stanislav Lukyanov
>
> If I am to create cache with name "caches/1", there's no immediate error, but
> nodes fail when trying to rejoin topology with storage already initialized.
> I think there should be an immediate exception in case persistence is enabled
> for such case.
> Moreover, I suggest first trying to create directory, then making sure it was
> created and that dir.parent == expected parent directory. Because on Windows
> there are more restrictions on FS file names, etc...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7303) BaselineTopology: API to reset branching history
[ https://issues.apache.org/jira/browse/IGNITE-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-7303: Description: Suppose there is a cluster with BaselineTopology set; some nodes from BaselineTopology are online, some nodes are offline. Some operations executed on the cluster may require that offline nodes won't be able to join the cluster back after the operation was completed, e.g. old nodes may contain conflicting data. To prevent joining of nodes that were offline at the moment of operation we need to reset BaselineTopology branching history so oflline nodes become incompatible with the cluster after operation. was: Suppose there is a cluster with BaselineTopology set; some nodes from BaselineTopology are online, some nodes are offline. Some operations executed on the cluster may require that offline nodes won't be able to join the cluster back after the operation was completed, e.g. old nodes may contain conflicting data. To prevent joining of nodes that were offline at the moment of operation BaselineTopology branching history should be reset so oflline nodes become incompatible with the cluster after operation. > BaselineTopology: API to reset branching history > > > Key: IGNITE-7303 > URL: https://issues.apache.org/jira/browse/IGNITE-7303 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov > Fix For: 2.4 > > > Suppose there is a cluster with BaselineTopology set; some nodes from > BaselineTopology are online, some nodes are offline. > Some operations executed on the cluster may require that offline nodes won't > be able to join the cluster back after the operation was completed, e.g. old > nodes may contain conflicting data. > To prevent joining of nodes that were offline at the moment of operation we > need to reset BaselineTopology branching history so oflline nodes become > incompatible with the cluster after operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7303) BaselineTopology: API to reset branching history
Sergey Chugunov created IGNITE-7303: --- Summary: BaselineTopology: API to reset branching history Key: IGNITE-7303 URL: https://issues.apache.org/jira/browse/IGNITE-7303 Project: Ignite Issue Type: Improvement Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.4 Suppose there is a cluster with BaselineTopology set; some nodes from BaselineTopology are online, some nodes are offline. Some operations executed on the cluster may require that offline nodes won't be able to join the cluster back after the operation was completed, e.g. old nodes may contain conflicting data. To prevent joining of nodes that were offline at the moment of operation BaselineTopology branching history should be reset so oflline nodes become incompatible with the cluster after operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-7264) Caches with forward slash "/" in names cause problems for PDS
[ https://issues.apache.org/jira/browse/IGNITE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303293#comment-16303293 ] Stanislav Lukyanov edited comment on IGNITE-7264 at 12/25/17 2:39 PM: -- There seem to be several flavors of this problem, but the one I can more or les consistently reproduce is 1) Create a cache with a '/' in the name on a cluster with persistence enabled 2) Kill the cluster without deactivation The key is to kill the cluster with records left in WAL that are not applied to the persistence storage. Then the activation fails to find the cache, but tries to apply WAL records related to that cache - and fails. 3) Restart the cluster and activate it Then the following stack trace appears with NPE killing the ExchangeWorker thread but not the node java.lang.NullPointerException at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:1781) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:1641) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1074) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:865) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1035) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:748) The question is whether there should be more graceful error handling in the case when WAL contains records for non-existing caches. Should exchange worker be prepared for an unchecked exception during a task execution? If not, should it trigger node shutdown if it exits with an unhandled exception? Should WAL be allowed to contain a record for an unknown cache? Should such records be ignored? At the very least, an `assert cacheCtx != null` in the `applyLastUpdates` would be helpful. This (potential) problem is not the root cause of the issue though. was (Author: slukyanov): There seem to be several flavors of this problem, but the one I can more or les consistently reproduce is 1) Create a cache with a '/' in the name on a cluster with persistence enabled 2) Kill the cluster without deactivation The key is to kill the cluster with records left in WAL that are not applied to the persistence storage. Then the activation fails to find the cache, but tries to apply WAL records related to that cache - and fails. 3) Restart the cluster and activate it Then the following stack trace appears with NPE killing the ExchangeWorker thread but not the node java.lang.NullPointerException at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:1781) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:1641) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1074) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:865) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1035) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:748) The question is whether there should be more graceful error handling in the case when WAL contains records for non-existing caches. Should exchange worker be prepared for an unchecked exception during a task execution? If not, should it trigger node shutdown if it exits with an unhandled exception? Should WAL be allowed to contain a record
[jira] [Commented] (IGNITE-7264) Caches with forward slash "/" in names cause problems for PDS
[ https://issues.apache.org/jira/browse/IGNITE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303293#comment-16303293 ] Stanislav Lukyanov commented on IGNITE-7264: There seem to be several flavors of this problem, but the one I can more or les consistently reproduce is 1) Create a cache with a '/' in the name on a cluster with persistence enabled 2) Kill the cluster without deactivation The key is to kill the cluster with records left in WAL that are not applied to the persistence storage. Then the activation fails to find the cache, but tries to apply WAL records related to that cache - and fails. 3) Restart the cluster and activate it Then the following stack trace appears with NPE killing the ExchangeWorker thread but not the node java.lang.NullPointerException at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyUpdate(GridCacheDatabaseSharedManager.java:1781) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.applyLastUpdates(GridCacheDatabaseSharedManager.java:1641) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.restoreState(GridCacheDatabaseSharedManager.java:1074) at org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.beforeExchange(GridCacheDatabaseSharedManager.java:865) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1035) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:649) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2279) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) at java.lang.Thread.run(Thread.java:748) The question is whether there should be more graceful error handling in the case when WAL contains records for non-existing caches. Should exchange worker be prepared for an unchecked exception during a task execution? If not, should it trigger node shutdown if it exits with an unhandled exception? Should WAL be allowed to contain a record for an unknown cache? Should such records be ignored? At the very least, an `assert cacheCtx != null` in the `applyLastUpdates` would be helpful. > Caches with forward slash "/" in names cause problems for PDS > - > > Key: IGNITE-7264 > URL: https://issues.apache.org/jira/browse/IGNITE-7264 > Project: Ignite > Issue Type: Bug > Components: cache, persistence >Affects Versions: 2.3 >Reporter: Ilya Kasnacheev >Assignee: Stanislav Lukyanov > > If I am to create cache with name "caches/1", there's no immediate error, but > nodes fail when trying to rejoin topology with storage already initialized. > I think there should be an immediate exception in case persistence is enabled > for such case. > Moreover, I suggest first trying to create directory, then making sure it was > created and that dir.parent == expected parent directory. Because on Windows > there are more restrictions on FS file names, etc... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-7144) Java 9: fix build issue with tools.jar not found
[
https://issues.apache.org/jira/browse/IGNITE-7144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303278#comment-16303278
]
ASF GitHub Bot commented on IGNITE-7144:
Github user vveider closed the pull request at:
https://github.com/apache/ignite/pull/3172
> Java 9: fix build issue with tools.jar not found
>
>
> Key: IGNITE-7144
> URL: https://issues.apache.org/jira/browse/IGNITE-7144
> Project: Ignite
> Issue Type: Bug
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>
> {code}
> [ERROR] Failed to execute goal on project ignite-tools: Could not resolve
> dependencies for project org.apache.ignite:ignite-tools:jar:2.4.0-SNAPSHOT:
> Could not find artifact com.sun:tools:jar:9.0.1 at specified path
> /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home/../lib/tools.jar
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6743) Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303276#comment-16303276
]
Andrey Kuznetsov commented on IGNITE-6743:
--
[~agura], I've added separate cleaner interface, please take a look.
> Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer
>
>
> Key: IGNITE-6743
> URL: https://issues.apache.org/jira/browse/IGNITE-6743
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> When session is closed we clean allocated {{DirectByteBuffer}}-s using
> {{sun.misc.Cleaner}}. Need to rework this piece to reflection-based approach
> which will work for supported Java versions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6894) Hanged Tx monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-6894: --- Assignee: Dmitriy Sorokin > Hanged Tx monitoring > > > Key: IGNITE-6894 > URL: https://issues.apache.org/jira/browse/IGNITE-6894 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin > Labels: iep-7 > Fix For: 2.4 > > > Hanging Transactions not Related to Deadlock > Description > This situation can occur if user explicitly markups the transaction (esp > Pessimistic Repeatable Read) and, for example, calls remote service (which > may be unresponsive) after acquiring some locks. All other transactions > depending on the same keys will hang. > Detection and Solution > This most likely cannot be resolved automatically other than rollback TX by > timeout and release all the locks acquired so far. Also such TXs can be > rolled back from Web Console as described above. > If transaction has been rolled back on timeout or via UI then any further > action in the transaction, e.g. lock acquisition or commit attempt should > throw exception. > Report > Web Console should provide ability to rollback any transaction via UI. > Long running transaction should be reported to logs. Log record should > contain: near nodes, transaction IDs, cache names, keys (limited to several > tens of), etc ( ?). > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the info as above. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-6895: --- Assignee: Dmitriy Sorokin > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin > Labels: iep-7 > Fix For: 2.4 > > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7302) SQL TX: Failed to query INFORMATIONAL_SCHEMA
Vladimir Ozerov created IGNITE-7302:
---
Summary: SQL TX: Failed to query INFORMATIONAL_SCHEMA
Key: IGNITE-7302
URL: https://issues.apache.org/jira/browse/IGNITE-7302
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
Fix For: 2.4
{code}
javax.cache.CacheException: class org.apache.ignite.IgniteException:
Unsupported query: Unexpected Table implementation [cls=MetaTable]
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.assert0(GridSqlQueryParser.java:1876)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTable(GridSqlQueryParser.java:612)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseTableFilter(GridSqlQueryParser.java:565)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseSelect(GridSqlQueryParser.java:665)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseQuery(GridSqlQueryParser.java:1539)
at
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1490)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.mvccTracker(IgniteH2Indexing.java:1294)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:926)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:870)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryLocalSqlFields(IgniteH2Indexing.java:1163)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1951)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:1936)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2521)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1968)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
at
org.apache.ignite.internal.processors.cache.local.IgniteCacheLocalFieldsQuerySelfTest.testInformationSchema(IgniteCacheLocalFieldsQuerySelfTest.java:49)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7189) ODBC: ODBC return weird names for tables created with DDL
[
https://issues.apache.org/jira/browse/IGNITE-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303267#comment-16303267
]
Taras Ledkov commented on IGNITE-7189:
--
[~isapego], the Ignite's server part is OK with me.
> ODBC: ODBC return weird names for tables created with DDL
> -
>
> Key: IGNITE-7189
> URL: https://issues.apache.org/jira/browse/IGNITE-7189
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.3
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> If the table has been created by the {{CREATE TABLE}} statement, and then its
> metadata requested, returned names for tables are looking like the following:
> {{SQL_PUBLIC_TABLE_NAME_00112233_4455_6677_8899_aabbccddeeff}}
> Instead of:
> {{TABLE_NAME}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7301) .NET: Cluster auto activation (baseline topology)
[ https://issues.apache.org/jira/browse/IGNITE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-7301: - Labels: .NET IEP-4 Phase-1 (was: .NET) > .NET: Cluster auto activation (baseline topology) > - > > Key: IGNITE-7301 > URL: https://issues.apache.org/jira/browse/IGNITE-7301 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET, IEP-4, Phase-1 > Fix For: 2.4 > > > Add auto activation related APIs to .NET, see > https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7301) .NET: Cluster auto activation (baseline topology)
[ https://issues.apache.org/jira/browse/IGNITE-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-7301: --- Description: Add auto activation related APIs to .NET, see https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches (was: Add auuto activation related APIs to .NET, see https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches) > .NET: Cluster auto activation (baseline topology) > - > > Key: IGNITE-7301 > URL: https://issues.apache.org/jira/browse/IGNITE-7301 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn > Labels: .NET > Fix For: 2.4 > > > Add auto activation related APIs to .NET, see > https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7301) .NET: Cluster auto activation (baseline topology)
Pavel Tupitsyn created IGNITE-7301: -- Summary: .NET: Cluster auto activation (baseline topology) Key: IGNITE-7301 URL: https://issues.apache.org/jira/browse/IGNITE-7301 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 2.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.4 Add auuto activation related APIs to .NET, see https://cwiki.apache.org/confluence/display/IGNITE/IEP-4+Baseline+topology+for+caches -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6579) WAL history does not used when node returns to cluster again
[
https://issues.apache.org/jira/browse/IGNITE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303257#comment-16303257
]
Vladislav Pyatkov commented on IGNITE-6579:
---
[~xtern]
If you are right, you should to show correct message.
Instead of {{haveHistory=false}}, would by better to see something like:
{{Size of partition too little, full rebalanse will be passed.}}
> WAL history does not used when node returns to cluster again
>
>
> Key: IGNITE-6579
> URL: https://issues.apache.org/jira/browse/IGNITE-6579
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Vladislav Pyatkov
>
> When I have set big enough value to "WAL history size" and stop node on 20
> minutes, I got the message from coordinator (order=1):
> {noformat}
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424,
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427,
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426,
> haveHistory=false]
> {noformat}
> after start node again.
> I think, history size should be enough, but I see it is not by logs
> (haveHistory=false).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions
[
https://issues.apache.org/jira/browse/IGNITE-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-7300:
Description: The problem is related to IGNITE-7267 - the latter honors raw
rows, but drops support for inserts with expressions which yield local
subqueries. To fix this, {{UpdatePlan.isLocalSubquery()}} must be honored.
> Allow expressions in SQL INSERTs within transactions
>
>
> Key: IGNITE-7300
> URL: https://issues.apache.org/jira/browse/IGNITE-7300
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Paschenko
>Assignee: Igor Seliverstov
> Fix For: 2.4
>
>
> The problem is related to IGNITE-7267 - the latter honors raw rows, but drops
> support for inserts with expressions which yield local subqueries. To fix
> this, {{UpdatePlan.isLocalSubquery()}} must be honored.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions
[
https://issues.apache.org/jira/browse/IGNITE-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Paschenko updated IGNITE-7300:
Environment: (was: The problem is related to IGNITE-7267 - the latter
honors raw rows, but drops support for inserts with expressions which yield
local subqueries. To fix this, {{UpdatePlan.isLocalSubquery()}} must be
honored.)
> Allow expressions in SQL INSERTs within transactions
>
>
> Key: IGNITE-7300
> URL: https://issues.apache.org/jira/browse/IGNITE-7300
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Paschenko
>Assignee: Igor Seliverstov
> Fix For: 2.4
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-7300) Allow expressions in SQL INSERTs within transactions
Alexander Paschenko created IGNITE-7300:
---
Summary: Allow expressions in SQL INSERTs within transactions
Key: IGNITE-7300
URL: https://issues.apache.org/jira/browse/IGNITE-7300
Project: Ignite
Issue Type: Bug
Environment: The problem is related to IGNITE-7267 - the latter honors
raw rows, but drops support for inserts with expressions which yield local
subqueries. To fix this, {{UpdatePlan.isLocalSubquery()}} must be honored.
Reporter: Alexander Paschenko
Assignee: Igor Seliverstov
Fix For: 2.4
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6579) WAL history does not used when node returns to cluster again
[
https://issues.apache.org/jira/browse/IGNITE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303251#comment-16303251
]
Pavel Pereslegin edited comment on IGNITE-6579 at 12/25/17 12:07 PM:
-
Hello [~v.pyatkov],
I retested with the following scenario:
# Set IGNITE_PDS_WAL_REBALANCE_THRESHOLD to 1.
# Start nodes A, B and C with one replicated cache (RendezvousAffinityFunction
with 10 partitions).
# Put 10 values to cache (1 keys per partition).
# Stop node C.
# Put 3000 values to cache (10300 keys per partition).
# Rejoin node C (nodeId = 606c6f4d-c314-4345-8b6d-cc3f3792).
# Observing messages from coordinator (haveHistory=true).
{noformat}
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=0, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=1, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=2, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=3, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=4, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=5, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=6, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=7, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=8, haveHistory=true]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=9, haveHistory=true]
{noformat}
If I set IGNITE_PDS_WAL_REBALANCE_THRESHOLD larger than the partition size
(10301 for example) - WAL history is not used.
{noformat}
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=0, haveHistory=false]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=1, haveHistory=false]
...{noformat}
was (Author: xtern):
Hello [~v.pyatkov],
I tried the following scenario:
# Set JVM option -DIGNITE_PDS_WAL_REBALANCE_THRESHOLD=1.
# Start nodes A, B and C with one replicated cache (no backups,
RendezvousAffinityFunction with 10 partitions).
# Put 10 values to cache (1 keys per partition).
# Stop node C.
# Put 3000 values to cache (10300 keys per partition).
# Rejoin node C (nodeId = 606c6f4d-c314-4345-8b6d-cc3f3792).
# Observing messages from coordinator (haveHistory=true).
{noformat}
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=0, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=1, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=2, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=3, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=4, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=5, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc
[jira] [Commented] (IGNITE-6743) Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-6743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303255#comment-16303255
]
Andrey Gura commented on IGNITE-6743:
-
Guys, I like current implementation. Moreover, I think that it would be better
to introduce interface and couple of cleaner implementations (for Java < 9 and
Java 9+) instead of closure. It will just more supportable.
> Java 9: rework DirectBuffer.cleaner().clean() usage in GridNioServer
>
>
> Key: IGNITE-6743
> URL: https://issues.apache.org/jira/browse/IGNITE-6743
> Project: Ignite
> Issue Type: Task
> Components: general
>Reporter: Vladimir Ozerov
>Assignee: Andrey Kuznetsov
> Fix For: 2.4
>
>
> When session is closed we clean allocated {{DirectByteBuffer}}-s using
> {{sun.misc.Cleaner}}. Need to rework this piece to reflection-based approach
> which will work for supported Java versions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6579) WAL history does not used when node returns to cluster again
[
https://issues.apache.org/jira/browse/IGNITE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303251#comment-16303251
]
Pavel Pereslegin commented on IGNITE-6579:
--
Hello [~v.pyatkov],
I tried the following scenario:
# Set JVM option -DIGNITE_PDS_WAL_REBALANCE_THRESHOLD=1.
# Start nodes A, B and C with one replicated cache (no backups,
RendezvousAffinityFunction with 10 partitions).
# Put 10 values to cache (1 keys per partition).
# Stop node C.
# Put 3000 values to cache (10300 keys per partition).
# Rejoin node C (nodeId = 606c6f4d-c314-4345-8b6d-cc3f3792).
# Observing messages from coordinator (haveHistory=true).
{noformat}
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=0, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=1, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=2, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=3, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=4, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=5, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=6, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=7, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=8, haveHistory=true]
[GridDhtPartitionTopologyImpl] Partition has been scheduled for rebalancing due
to outdated update counter [nodeId=606c6f4d-c314-4345-8b6d-cc3f3792,
cacheOrGroupName=default, partId=9, haveHistory=true]
{noformat}
If I set IGNITE_PDS_WAL_REBALANCE_THRESHOLD larger than the partition size
(10301 for example) - WAL history is not used.
{noformat}
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=0, haveHistory=false]
Partition has been scheduled for rebalancing due to outdated update counter
[nodeId=606c6f4d-c314-4345-8b6d-cc3f3792, cacheOrGroupName=default,
partId=1, haveHistory=false]
...{noformat}
> WAL history does not used when node returns to cluster again
>
>
> Key: IGNITE-6579
> URL: https://issues.apache.org/jira/browse/IGNITE-6579
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Vladislav Pyatkov
>
> When I have set big enough value to "WAL history size" and stop node on 20
> minutes, I got the message from coordinator (order=1):
> {noformat}
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424,
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427,
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426,
> haveHistory=false]
> {noformat}
> after start node again.
> I think, history size should be enough, but I see it is not by
[jira] [Created] (IGNITE-7299) Document internal CREATE TABLE SQL command
Kirill Shirokov created IGNITE-7299: --- Summary: Document internal CREATE TABLE SQL command Key: IGNITE-7299 URL: https://issues.apache.org/jira/browse/IGNITE-7299 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.3 Reporter: Kirill Shirokov Assignee: Kirill Shirokov Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6772) SQL exception messages are not descriptive
[
https://issues.apache.org/jira/browse/IGNITE-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6772:
Fix Version/s: 2.4
> SQL exception messages are not descriptive
> --
>
> Key: IGNITE-6772
> URL: https://issues.apache.org/jira/browse/IGNITE-6772
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
> Labels: usability
> Fix For: 2.4
>
>
> Top level SQL exception messages are cryptic and not descriptive. Real
> details are buried deep inside inner exceptions.
> For example, when there is a typo in table name, exception looks like this:
> {code}
> class org.apache.ignite.IgniteCheckedException: Failed to parse query: SELECT
> "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:510)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1219)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:875)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:77)
> Caused by: javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807)
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1213)
> ... 2 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> parse query: SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL
> from Person1, "orgs-sql".Organization where Person.OrgId =
> "orgs-sql".Organization._key and "orgs-sql".Organization.Name = ?
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1293)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSql(IgniteH2Indexing.java:1198)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1957)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$8.applyx(GridQueryProcessor.java:1955)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2293)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.queryDistributedSql(GridQueryProcessor.java:1954)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySql(GridQueryProcessor.java:1934)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:792)
> ... 3 more
> Caused by: org.h2.jdbc.JdbcSQLException: Table "PERSON1" not found; SQL
> statement:
> SELECT "persons-sql"."PERSON"._KEY, "persons-sql"."PERSON"._VAL from Person1,
> "orgs-sql".Organization where Person.OrgId = "orgs-sql".Organization._key and
> "orgs-sql".Organization.Name = ? [42102-195]
> at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> at org.h2.message.DbException.get(DbException.java:179)
> at org.h2.message.DbException.get(DbException.java:155)
> at org.h2.command.Parser.readTableOrView(Parser.java:5506)
> at org.h2.command.Parser.readTableFilter(Parser.java:1260)
> at org.h2.command.Parser.parseSelectSimpleFromPart(Parser.java:1940)
> at org.h2.command.Parser.parseSelectSimple(Parser.java:2089)
> at org.h2.command.Parser.parseSelectSub(Parser.java:1934)
> at org.h2.command.Parser.parseSelectUnion(Parser.java:1749)
> at org.h2.command.Parser.parseSelect(Parser.java:1737)
> at org.h2.command.Parser.parsePrepared(Parser.java:448)
> at org.h2.command.Parser.parse(Parser.java:320)
> at org.h2.command.Parser.parse(Parser.java:292)
> at org.h2.command.Parser.prepareCommand(Parser.java:257)
> at org.h2.engine.Session.prepareLocal(Session.java:573)
> at org.h2.engine.Session.prepareCommand(Session.java:514)
> at org.h2.jdbc.JdbcConnection.prepareCommand(JdbcConnection.java:1204)
> at org.h2.jdbc.JdbcPreparedStatement.(JdbcPreparedStatement.java:73)
> at org.h2.jdbc.JdbcConnection.prepareStatement(JdbcConnec
[jira] [Commented] (IGNITE-7288) Thin client: partial cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303240#comment-16303240
]
Pavel Tupitsyn commented on IGNITE-7288:
Done, [~vozerov], please have a look.
> Thin client: partial cache configuration
>
>
> Key: IGNITE-7288
> URL: https://issues.apache.org/jira/browse/IGNITE-7288
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.4
>
>
> {{OP_CACHE_CREATE_WITH_CONFIGURATION}} and
> {{OP_CACHE_GET_OR_CREATE_WITH_CONFIGURATION}} should not require complete
> {{CacheConfiguration}}. User should be able to specify any combination of
> properties in any order, leaving others at default state.
> Prefix each property with unique ID, then do a switch in a loop.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7288) Thin client: partial cache configuration
[
https://issues.apache.org/jira/browse/IGNITE-7288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303238#comment-16303238
]
ASF GitHub Bot commented on IGNITE-7288:
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/3286
IGNITE-7288 Thin client: partial cache configuration
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-7288
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3286.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 #3286
commit a6bc94934910ef5f7b970e3eba7dc006d6ec6c26
Author: Pavel Tupitsyn
Date: 2017-12-25T10:43:45Z
IGNITE-7288 Thin client: partial cache configuration
> Thin client: partial cache configuration
>
>
> Key: IGNITE-7288
> URL: https://issues.apache.org/jira/browse/IGNITE-7288
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Fix For: 2.4
>
>
> {{OP_CACHE_CREATE_WITH_CONFIGURATION}} and
> {{OP_CACHE_GET_OR_CREATE_WITH_CONFIGURATION}} should not require complete
> {{CacheConfiguration}}. User should be able to specify any combination of
> properties in any order, leaving others at default state.
> Prefix each property with unique ID, then do a switch in a loop.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7261) SQL TX: SELECT and DML operations must share the same MVCC version
[ https://issues.apache.org/jira/browse/IGNITE-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303234#comment-16303234 ] ASF GitHub Bot commented on IGNITE-7261: GitHub user gvvinblade opened a pull request: https://github.com/apache/ignite/pull/3285 IGNITE-7261 MVCC enabled You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7261-mvcc-on Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3285.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 #3285 commit f6e982540e65ab17d439dba990794f35616a30dd Author: sboikov Date: 2017-08-30T09:45:40Z ignite-3478 commit 275a85db5cd6923b36126166ae99b15e876192be Author: sboikov Date: 2017-08-31T07:44:07Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2 Author: sboikov Date: 2017-08-31T09:00:36Z disco cache cleanup commit 855c2d45794c300d41e386b4e6fa40736cc3e40d Author: sboikov Date: 2017-08-31T09:09:58Z Merge branch 'ignite-3478-1' into ignite-3478 commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31 Author: sboikov Date: 2017-08-31T09:52:23Z ignite-3478 commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90 Author: sboikov Date: 2017-09-04T08:13:50Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 commit d3c049952384750c5543a9f88b383c033ef74096 Author: sboikov Date: 2017-09-04T08:52:11Z ignite-3478 commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab Author: sboikov Date: 2017-09-04T10:16:03Z ignite-3478 commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c Author: sboikov Date: 2017-09-05T10:16:44Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4 Author: sboikov Date: 2017-09-05T11:30:55Z ignite-3478 commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e Author: sboikov Date: 2017-09-05T11:31:14Z ignite-3478 commit cbada3934a386668da0b11d4de7d0f58a4d04dfe Author: sboikov Date: 2017-09-05T11:49:49Z ignite-3484 commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b Author: sboikov Date: 2017-09-05T11:59:49Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 commit bc9134c94b7a738dc1664e96ca6eabb059f1c268 Author: sboikov Date: 2017-09-05T12:03:39Z Merge branch 'ignite-3478' into ignite-3484 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/tree/AbstractDataInnerIO.java commit b4bfcde78825c6517232e49d389bdb5de19f05a9 Author: sboikov Date: 2017-09-05T12:27:51Z ignite-3484 commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599 Author: sboikov Date: 2017-09-05T13:13:00Z ignite-3478 commit d1b828095713fcadfa260cf94fef01b42a1b12fd Author: sboikov Date: 2017-09-05T13:13:33Z Merge branch 'ignite-3478' into ignite-3484 commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5 Author: sboikov Date: 2017-09-05T13:47:11Z ignite-3484 commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5 Author: sboikov Date: 2017-09-06T07:10:26Z ignite-3484 commit dd0afb28466094b801506da8afa3601bfaebd853 Author: sboikov Date: 2017-09-06T07:30:04Z ignite-3484 commit 27b87b413348b03986a463551db24b7726321732 Author: sboikov Date: 2017-09-06T08:19:18Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java commit dcaf8801accd6ee089849a82b2ccd558aec81895 Author: sboikov Date: 2017-09-06T08:19:30Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java commit c966451d0bf7059575de92bcfae43d72096ebce4 Author: sboikov Date: 2017-09-06T08:27:04Z Merge branch 'ignite-3478' into ignite-3484 commit 91b9911731a387a3199ddbbc22704bc14af09995 Author: sboikov Date: 2017-09-06T09:22:22Z ignite-3484 commit e40b4d9dcd6fe6c1cd2640bdd7116ca5a08ed781 Author: sboikov Date: 2017-09-07T09:12:32Z ignite-3484 commit 41a1c571e6ba1765941e2f1679dc4ac1582275c4 Author: sboikov Date: 2017-09-08T07:55:24Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3484 commit 1626130801dc330bcaf693f46906f6564cce6802 Author: sboikov Date: 2017-09-08T08:04:57Z ignite-3484 commit 91bbb7cd24f38a38e2e65fc3ebf5637572b11b
[jira] [Commented] (IGNITE-7261) SQL TX: SELECT and DML operations must share the same MVCC version
[ https://issues.apache.org/jira/browse/IGNITE-7261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303210#comment-16303210 ] ASF GitHub Bot commented on IGNITE-7261: GitHub user gvvinblade opened a pull request: https://github.com/apache/ignite/pull/3284 IGNITE-7261 MVCC disabled You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7261-mvcc-off Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3284.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 #3284 commit f6e982540e65ab17d439dba990794f35616a30dd Author: sboikov Date: 2017-08-30T09:45:40Z ignite-3478 commit 275a85db5cd6923b36126166ae99b15e876192be Author: sboikov Date: 2017-08-31T07:44:07Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 commit b7b9089f0102b8cab9942a9c887d93e9f26cc7d2 Author: sboikov Date: 2017-08-31T09:00:36Z disco cache cleanup commit 855c2d45794c300d41e386b4e6fa40736cc3e40d Author: sboikov Date: 2017-08-31T09:09:58Z Merge branch 'ignite-3478-1' into ignite-3478 commit 08be7310a93d3ce455215b97cf8ab1a2c3f0ab31 Author: sboikov Date: 2017-08-31T09:52:23Z ignite-3478 commit fce2e31f0fd2f4f6a9944422e40408a0c65cfe90 Author: sboikov Date: 2017-09-04T08:13:50Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 commit d3c049952384750c5543a9f88b383c033ef74096 Author: sboikov Date: 2017-09-04T08:52:11Z ignite-3478 commit e71ce1937a18dd32448e92b1038dc48d4cb6f8ab Author: sboikov Date: 2017-09-04T10:16:03Z ignite-3478 commit 5fac5b0965e97f8951e16e10ca9229a2e78ddb0c Author: sboikov Date: 2017-09-05T10:16:44Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java commit 2e0c9c08e046e8d6af1b5358d9053eae999b1fb4 Author: sboikov Date: 2017-09-05T11:30:55Z ignite-3478 commit e1e07ffdf2d711ba3e72f316f5a3970eff27372e Author: sboikov Date: 2017-09-05T11:31:14Z ignite-3478 commit cbada3934a386668da0b11d4de7d0f58a4d04dfe Author: sboikov Date: 2017-09-05T11:49:49Z ignite-3484 commit 5a82c68dcd1927bb6fded8b7def38c91ff6e145b Author: sboikov Date: 2017-09-05T11:59:49Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 commit bc9134c94b7a738dc1664e96ca6eabb059f1c268 Author: sboikov Date: 2017-09-05T12:03:39Z Merge branch 'ignite-3478' into ignite-3484 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/tree/AbstractDataInnerIO.java commit b4bfcde78825c6517232e49d389bdb5de19f05a9 Author: sboikov Date: 2017-09-05T12:27:51Z ignite-3484 commit 43834aaab9e2c3cd5fdd55289fdc4a9ff8ab6599 Author: sboikov Date: 2017-09-05T13:13:00Z ignite-3478 commit d1b828095713fcadfa260cf94fef01b42a1b12fd Author: sboikov Date: 2017-09-05T13:13:33Z Merge branch 'ignite-3478' into ignite-3484 commit 6be6779b6336c36cd71eef0a25199a6a877ce6b5 Author: sboikov Date: 2017-09-05T13:47:11Z ignite-3484 commit e3bba83256c1eb53c4b40fbd9ddba47fcf9d58d5 Author: sboikov Date: 2017-09-06T07:10:26Z ignite-3484 commit dd0afb28466094b801506da8afa3601bfaebd853 Author: sboikov Date: 2017-09-06T07:30:04Z ignite-3484 commit 27b87b413348b03986a463551db24b7726321732 Author: sboikov Date: 2017-09-06T08:19:18Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java commit dcaf8801accd6ee089849a82b2ccd558aec81895 Author: sboikov Date: 2017-09-06T08:19:30Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3478 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtTxPrepareFuture.java commit c966451d0bf7059575de92bcfae43d72096ebce4 Author: sboikov Date: 2017-09-06T08:27:04Z Merge branch 'ignite-3478' into ignite-3484 commit 91b9911731a387a3199ddbbc22704bc14af09995 Author: sboikov Date: 2017-09-06T09:22:22Z ignite-3484 commit e40b4d9dcd6fe6c1cd2640bdd7116ca5a08ed781 Author: sboikov Date: 2017-09-07T09:12:32Z ignite-3484 commit 41a1c571e6ba1765941e2f1679dc4ac1582275c4 Author: sboikov Date: 2017-09-08T07:55:24Z Merge remote-tracking branch 'remotes/origin/master' into ignite-3484 commit 1626130801dc330bcaf693f46906f6564cce6802 Author: sboikov Date: 2017-09-08T08:04:57Z ignite-3484 commit 91bbb7cd24f38a38e2e65fc3ebf5637572b1
[jira] [Updated] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used
[ https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5795: - Fix Version/s: 2.5 > @AffinityKeyMapped ignored if QueryEntity used > -- > > Key: IGNITE-5795 > URL: https://issues.apache.org/jira/browse/IGNITE-5795 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.0 >Reporter: Dmitry Karachentsev >Assignee: Alexey Kukushkin > Labels: usability > Fix For: 2.5 > > > When cache configured with QueryEntity and used key type with > @AffinityKeyMapped field, it will be ignored and wrong partition calculated. > This happens because QueryEntity processing precedes key type registering in > binary meta cache. On that step > CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve > type, so null returned and null putted in affKeyFields. > On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField > will return null from affKeyFields, but should be affinity key field. > Test that reproduces problem in [PR > 2330|https://github.com/apache/ignite/pull/2330] > To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it > will force registering key. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5551) Optimize service deployment assignments object
[ https://issues.apache.org/jira/browse/IGNITE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kukushkin updated IGNITE-5551: - Fix Version/s: (was: 2.4) 2.5 > Optimize service deployment assignments object > -- > > Key: IGNITE-5551 > URL: https://issues.apache.org/jira/browse/IGNITE-5551 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 1.7 >Reporter: Alexey Goncharuk >Assignee: Alexey Kukushkin >Priority: Critical > Fix For: 2.5 > > > 1) The deployment assignment is stored using a map [node ID -> number of > assigned services]. However, this assignment is not very effective for cases > when service configuration is (maxPerCluster = 0, maxPerNode > 0), because in > this case, we can avoid assignment recalculation at all. The assignment for > this case may look like (eachNode=N). In this case, the assignment does not > change and we can effectively skip it during the reassign loop. > 2) We store zero assignment counters, which does not make sense at all - if > there are no service deployments for a node, there should be no corresponding > entry in the map at all. The size of assignments for (maxPerCluster > 0) > configurations is O(number of nodes in the cluster), but it should be > O(maxPerCluster). > 3) If an assignment did not change, we should not commit the assignment > transaction - this is redundant > 4) Perhaps, it also makes sense to calculate several assignments at once and > do a putAll commit instead of single puts - this should also decrease the > assignment calculation latency -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[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: 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: Vasiliy Sisko
>
> {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
(v6.4.14#64029)
[jira] [Updated] (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
]
Pavel Konstantinov updated IGNITE-7298:
---
Summary: Web console: error on web agent start in case if demo is opened in
browser (was: Web console: error on web agent start)
> 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
>
> {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
(v6.4.14#64029)
[jira] [Created] (IGNITE-7298) Web console: error on web agent start
Pavel Konstantinov created IGNITE-7298:
--
Summary: Web console: error on web agent start
Key: IGNITE-7298
URL: https://issues.apache.org/jira/browse/IGNITE-7298
Project: Ignite
Issue Type: Bug
Reporter: Pavel Konstantinov
{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
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4750) SQL: Support GROUP_CONCAT function
[ https://issues.apache.org/jira/browse/IGNITE-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-4750: Fix Version/s: (was: 2.4) 2.5 > SQL: Support GROUP_CONCAT function > -- > > Key: IGNITE-4750 > URL: https://issues.apache.org/jira/browse/IGNITE-4750 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Denis Magda >Assignee: Taras Ledkov > Fix For: 2.5 > > > GROUP_CONCAT function is not supported at the moment. Makes sense to fill > this gap: > http://apache-ignite-users.70518.x6.nabble.com/GROUP-CONCAT-function-is-unsupported-td10757.html > Presently the function doc is hidden: > https://apacheignite-sql.readme.io/docs/group_concat > Open it up once the ticket is released. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5439) JDBC thin: support query cancel
[
https://issues.apache.org/jira/browse/IGNITE-5439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5439:
Fix Version/s: (was: 2.4)
2.5
> JDBC thin: support query cancel
> ---
>
> Key: IGNITE-5439
> URL: https://issues.apache.org/jira/browse/IGNITE-5439
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.5
>
>
> The JDBC {{Statement.cancel}} method must be supported.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7113:
Fix Version/s: (was: 2.4)
2.5
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexander Paschenko
> Fix For: 2.5
>
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-7039: Fix Version/s: (was: 2.4) 2.5 > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov > Fix For: 2.5 > > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5623) DDL needs to support DEFAULT operator
[
https://issues.apache.org/jira/browse/IGNITE-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303179#comment-16303179
]
Taras Ledkov edited comment on IGNITE-5623 at 12/25/17 9:49 AM:
Tests results are OK with me.
[~vozerov], please review the patch.
was (Author: tledkov-gridgain):
Tests results are OK with me.
> DDL needs to support DEFAULT operator
> --
>
> Key: IGNITE-5623
> URL: https://issues.apache.org/jira/browse/IGNITE-5623
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Taras Ledkov
> Labels: important
> Fix For: 2.4
>
>
> There should be a way to set a default value for a column/field if the one is
> not specified during an insert operation. In general, we need to support
> {{ DEFAULT }} in a way it's show below:
> {code}
> CREATE TABLE Persons (
> ID int,
> FirstName varchar(255),
> Age int,
> City varchar(255) DEFAULT 'Sandnes'
> );
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode
[
https://issues.apache.org/jira/browse/IGNITE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303175#comment-16303175
]
ASF GitHub Bot commented on IGNITE-6904:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3074
> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However,
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need
> to release partitions only after the whole query is executed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6827) Configurable rollback for long running transactions before partition exchange
[
https://issues.apache.org/jira/browse/IGNITE-6827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov reassigned IGNITE-6827:
-
Assignee: Alexei Scherbakov (was: Alexandr Kuramshin)
> Configurable rollback for long running transactions before partition exchange
> -
>
> Key: IGNITE-6827
> URL: https://issues.apache.org/jira/browse/IGNITE-6827
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
> Fix For: 2.4
>
>
> Currently long running / buggy user transactions force partition exchange
> block on waiting for
> org.apache.ignite.internal.processors.cache.GridCacheSharedContext#partitionReleaseFuture,
> preventing all grid progress.
> I suggest introducing new global flag in TransactionConfiguration, like
> {{txRollbackTimeoutOnTopologyChange}}
> which will rollback exchange blocking transaction after the timeout.
> Still need to think what to do with other topology locking activities.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-7204) Unexpected behavior if passing null to binaryObject.field method
[
https://issues.apache.org/jira/browse/IGNITE-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303174#comment-16303174
]
Alexei Scherbakov commented on IGNITE-7204:
---
[~dmitryvinn]
Method argument must be checked for null value using build-in utility method [1]
[1] org.apache.ignite.internal.util.GridArgumentCheck#notNull(java.lang.Object,
java.lang.String)
> Unexpected behavior if passing null to binaryObject.field method
>
>
> Key: IGNITE-7204
> URL: https://issues.apache.org/jira/browse/IGNITE-7204
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.3
>Reporter: Alexei Scherbakov
>Assignee: Dmitry Vinnik
> Labels: newbie
> Fix For: 2.4
>
>
> If assertions are disabled, when first field value will be returned.
> If not, an AssertionError will be thrown.
> Reproducer:
> {noformat}
> public void testNullField() throws Exception {
> try {
> final IgniteEx ex = startGrid(0);
> final IgniteCache test =
> ex.cache("test").withKeepBinary();
> final BinaryObjectBuilder bldr = ex.binary().builder("obj");
> bldr.setField("x", 1);
> test.put(0, bldr.build());
> test.query(new ScanQuery<>(new IgniteBiPredicate BinaryObject>() {
> @Override public boolean apply(Integer o, BinaryObject o2) {
> final Object q = o2.field(null);
> return false;
> }
> })).getAll();
> }
> finally {
> stopAllGrids();
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6742) Java 9: rework Cleaner usage in PlatformMemoryPool class
[
https://issues.apache.org/jira/browse/IGNITE-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303163#comment-16303163
]
ASF GitHub Bot commented on IGNITE-6742:
GitHub user x-kreator opened a pull request:
https://github.com/apache/ignite/pull/3283
IGNITE-6742: + GridCleaner, using one in PlatformMemoryPool
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/x-kreator/ignite ignite-6742
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3283.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 #3283
commit f130e2ccb71836d0f1bf0fcab389d387c82f1422
Author: Dmitriy Sorokin
Date: 2017-12-23T19:04:25Z
IGNITE-6742: + GridCleaner, using one in PlatformMemoryPool
> Java 9: rework Cleaner usage in PlatformMemoryPool class
>
>
> Key: IGNITE-6742
> URL: https://issues.apache.org/jira/browse/IGNITE-6742
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Reporter: Vladimir Ozerov
>Assignee: Dmitriy Sorokin
> Fix For: 2.4
>
>
> We attach special cleaner to {{PlatformMemoryPool}} using
> {{sun.misc.Cleaner.create}} method. This way we ensure that thread-local
> native memory (which is used to pass data between platform and Java) is
> released properly.
> Need to rework this API to reflection-based approach, which works for both
> Java 7/8 and Java 9.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode
[
https://issues.apache.org/jira/browse/IGNITE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303161#comment-16303161
]
Roman Kondakov commented on IGNITE-6904:
[~vozerov], this is a cursor close case. And therefore as in the case of query
canceling it should be treated in the same manner - all reservations should be
released despite of the query type.
> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However,
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need
> to release partitions only after the whole query is executed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-7173) SQL: implement optional row cache
[ https://issues.apache.org/jira/browse/IGNITE-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7173: --- Assignee: Taras Ledkov (was: Vladimir Ozerov) > SQL: implement optional row cache > - > > Key: IGNITE-7173 > URL: https://issues.apache.org/jira/browse/IGNITE-7173 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-7015) SQL: index should be updated only when relevant values changed
[
https://issues.apache.org/jira/browse/IGNITE-7015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7015:
Fix Version/s: (was: 2.4)
2.5
> SQL: index should be updated only when relevant values changed
> --
>
> Key: IGNITE-7015
> URL: https://issues.apache.org/jira/browse/IGNITE-7015
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Labels: iep-1, performance
> Fix For: 2.5
>
>
> See {{GridH2Table.update}} method. Whenever value is updated, we propagate it
> to all indexes. Consider the following case:
> 1) Old row is not null, so this is "update", not "create".
> 2) Link hasn't changed
> 3) Indexed fields haven't changed
> If all conditions are met, we can skip index update completely, as state
> before and after will be the same. This is especially important when
> persistence is enabled because currently we generate unnecessary dirty pages
> what increases IO pressure.
> Suggested fix:
> 1) Iterate over index columns, skipping key and affinity columns (as they are
> guaranteed to be the same);
> 2) Compare relevant index columns of both old and new rows
> 3) If all columns are equal, do nothing.
> Fields should be read through {{GridH2KeyValueRowOnheap#getValue}}, because
> in this case we will re-use value cache transparently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6904) SQL: partition reservations are released too early in lazy mode
[
https://issues.apache.org/jira/browse/IGNITE-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303147#comment-16303147
]
Vladimir Ozerov commented on IGNITE-6904:
-
[~rkondakov], why don't we check for {{qctx.distributedJoinMode() == OFF}}
inside {{MapQueryLazyWorker.stop}}?
> SQL: partition reservations are released too early in lazy mode
> ---
>
> Key: IGNITE-6904
> URL: https://issues.apache.org/jira/browse/IGNITE-6904
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
> Fix For: 2.4
>
>
> In lazy mode we advance query execution as new page requests arrive. However,
> method {{GridMapQueryExecutor#onQueryRequest0}} releases partition
> reservations when only the very first page is processed:
> {code}
> finally {
> GridH2QueryContext.clearThreadLocal();
> if (distributedJoinMode == OFF)
> qctx.clearContext(false);
> }
> {code}
> It means that incorrect results may be returned on unstable topology. We need
> to release partitions only after the whole query is executed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6739) Add tests verifying queries and tx functionality when mvcc is enabled
[
https://issues.apache.org/jira/browse/IGNITE-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6739:
Fix Version/s: (was: 2.4)
2.5
> Add tests verifying queries and tx functionality when mvcc is enabled
> -
>
> Key: IGNITE-6739
> URL: https://issues.apache.org/jira/browse/IGNITE-6739
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Semen Boikov
> Fix For: 2.5
>
>
> Add tests verifying queries functionality is not broken if mvcc is enabled:
> - full text indexes
> - queries with indexing spi
> - CacheConfiguration with setQueryParallelism
> - lazy queries (SqlFieldsQuery.setLazy(true))
> - collocated queries (SqlFieldsQuery.setCollocated)
> - queries with cache groups
> General functionality:
> - make sure clean up is called when related future (query) is forcibly
> (exceptionally) finished (i.e. on cache stop)
> - queries without involved caches (i.e. {{SELECT 1}}) don't request MVCC
> version
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7285) Add default query timeout
[
https://issues.apache.org/jira/browse/IGNITE-7285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7285:
Fix Version/s: (was: 2.4)
2.5
> Add default query timeout
> -
>
> Key: IGNITE-7285
> URL: https://issues.apache.org/jira/browse/IGNITE-7285
> Project: Ignite
> Issue Type: Improvement
> Components: cache, sql
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
> Fix For: 2.5
>
>
> Currently it's possible to provide timeout only on query level. It would be
> very useful to have default timeout value provided on cache startup. Let's
> add {{CacheConfiguration#defaultQueryTimeout}} configuration property.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-7297) Javadoc warning for RProp in MLP
[ https://issues.apache.org/jira/browse/IGNITE-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Babak updated IGNITE-7297: --- Description: [Step 7/7] [WARNING] /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdater.java:32: warning - Tag @see: missing final '>': "https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." [Step 7/7] [WARNING] /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdaterParams.java:28: warning - Tag @see: missing final '>': "https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." was: [Step 7/7] [WARNING] /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdater.java:32: warning - Tag @see: missing final '>': "https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." [20:56:44][Step 7/7] [WARNING] /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdaterParams.java:28: warning - Tag @see: missing final '>': "https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." > Javadoc warning for RProp in MLP > > > Key: IGNITE-7297 > URL: https://issues.apache.org/jira/browse/IGNITE-7297 > Project: Ignite > Issue Type: Bug > Components: ml >Reporter: Yury Babak >Assignee: Yury Babak > Fix For: 2.4 > > > [Step 7/7] [WARNING] > /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdater.java:32: > warning - Tag @see: missing final '>': " href="https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." > [Step 7/7] [WARNING] > /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdaterParams.java:28: > warning - Tag @see: missing final '>': " href="https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-7297) Javadoc warning for RProp in MLP
Yury Babak created IGNITE-7297: -- Summary: Javadoc warning for RProp in MLP Key: IGNITE-7297 URL: https://issues.apache.org/jira/browse/IGNITE-7297 Project: Ignite Issue Type: Bug Components: ml Reporter: Yury Babak Assignee: Yury Babak Fix For: 2.4 [Step 7/7] [WARNING] /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdater.java:32: warning - Tag @see: missing final '>': "https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." [20:56:44][Step 7/7] [WARNING] /data/teamcity/work/bd85361428dcdb1/modules/ml/src/main/java/org/apache/ignite/ml/nn/updaters/RPropUpdaterParams.java:28: warning - Tag @see: missing final '>': "https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf";>https://paginas.fe.up.pt/~ee02162/dissertacao/RPROP%20paper.pdf." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6611) Optionally disable binary metadata for type
[
https://issues.apache.org/jira/browse/IGNITE-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6611:
Fix Version/s: (was: 2.4)
2.5
> Optionally disable binary metadata for type
> ---
>
> Key: IGNITE-6611
> URL: https://issues.apache.org/jira/browse/IGNITE-6611
> Project: Ignite
> Issue Type: Task
> Components: binary, sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
>Assignee: Sergey Kalashnikov
> Fix For: 2.5
>
>
> We need to introduce special metadata mode for type - without metadata. This
> way we will have a kind of "flexible" type with no restrictions. This will be
> especially useful for SQL-related types where schema changes are possible
> (e.g. ADD COLUMN -> DROP COLUMN).
> Public part should be exposed to:
> 1) {{BinaryTypeConfiguration}}
> 2) {{BinaryType}} - add a flag here.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-6785:
---
Assignee: Denis Magda (was: Roman Kondakov)
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Denis Magda
> Labels: important, usability
> Fix For: 2.4
>
> Attachments: sql_bug.zip
>
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6579) WAL history does not used when node returns to cluster again
[
https://issues.apache.org/jira/browse/IGNITE-6579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303139#comment-16303139
]
Vladislav Pyatkov commented on IGNITE-6579:
---
[~xtern]
Setting IGNITE_PDS_WAL_REBALANCE_THRESHOLD to 0 is very extreme condition.
Please, try to set it more then zero, and purposely puts know quantity of keys
to partition (in order to the quantity will be more then the
REBALANCE_THRESHOLD).
> WAL history does not used when node returns to cluster again
>
>
> Key: IGNITE-6579
> URL: https://issues.apache.org/jira/browse/IGNITE-6579
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Vladislav Pyatkov
>
> When I have set big enough value to "WAL history size" and stop node on 20
> minutes, I got the message from coordinator (order=1):
> {noformat}
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2424,
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2427,
> haveHistory=false]
> 2017-10-06 15:46:33.429 [WARN
> ][sys-#10740%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.GridDhtPartitionTopologyImpl]
> Partition has been scheduled for rebalancing due to outdated update counter
> [nodeId=e51a1db2-f49b-44a9-b122-adde4016d9e7,
> cacheOrGroupName=CACHEGROUP_PARTICLE_DServiceZone, partId=2426,
> haveHistory=false]
> {noformat}
> after start node again.
> I think, history size should be enough, but I see it is not by logs
> (haveHistory=false).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6785) Affinity field name forced to be upper-case
[
https://issues.apache.org/jira/browse/IGNITE-6785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303131#comment-16303131
]
Vladimir Ozerov commented on IGNITE-6785:
-
[~dmagda], I think I am lost again. Could you please provide steps to
reproduce? I mean exact SQL or native API commands.
> Affinity field name forced to be upper-case
> ---
>
> Key: IGNITE-6785
> URL: https://issues.apache.org/jira/browse/IGNITE-6785
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Denis Magda
>Assignee: Roman Kondakov
> Labels: important, usability
> Fix For: 2.4
>
> Attachments: sql_bug.zip
>
>
> If an SQL schema and cache is created with CREATE TABLE command and a user
> wants to use key-value APIs creating its own custom key class, then (at
> least) the key class's affinity field forced to be written in upper-case.
> Steps to reproduce using the project attached:
> * start a node with {{./ignite.sh ../examples/config/example-ignite.xml}}.
> * create {{City}} table using {{ignite_world.sql}}. SQLline is one of the
> quickest ways: https://apacheignite-sql.readme.io/docs/sqlline
> * Run {{KeyValueDataProcessing}} to catch the exception below
> {noformat}
> Exception in thread "main" class
> org.apache.ignite.binary.BinaryObjectException: Binary type has different
> affinity key fields [typeName=demo.model.CityKey,
> affKeyFieldName1=COUNTRYCODE, affKeyFieldName2=countryCode]
> at
> org.apache.ignite.internal.binary.BinaryUtils.mergeMetadata(BinaryUtils.java:987)
> {noformat}
> If fact {{CityKey}} names the affinity field in the same way as in CREATE
> TABLE - {{countryCode}}.
> Next, run {{KeyValueBinaryDataProcessing}} to spot another weird thing:
> * BinaryObject key accepts `countryCode` as the affinity field name.
> * If to print our a binary object value then all the fields are in the
> upper-case (they were not defined this way in CREATE TABLE):
> {noformat}
> demo.model.City [idHash=1613627715, hash=-1386587499, DISTRICT=Noord-Holland,
> POPULATION=711200, NAME=Amsterdam]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
