[jira] [Closed] (IGNITE-17658) Unable to make field private final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass accessible: module java.base does not "opens java.lang.invoke" to unn
[ https://issues.apache.org/jira/browse/IGNITE-17658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li closed IGNITE-17658. - > Unable to make field private final java.lang.Class > java.lang.invoke.SerializedLambda.capturingClass accessible: module java.base > does not "opens java.lang.invoke" to unnamed module > > > Key: IGNITE-17658 > URL: https://issues.apache.org/jira/browse/IGNITE-17658 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.13 > Environment: jdk17 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Minor > Fix For: 2.15 > > Attachments: > 0001-IGNITE-17658-Unable-to-make-field-private-final-java.patch, > IgniteClient.java > > Time Spent: 20m > Remaining Estimate: 0h > > start a node with peerClassLoadingEnabled = true; > execute the reproducer; > then error occurs: > [19:14:24,425][SEVERE][pub-#17][BinaryContext] Failed to deserialize object > [typeName=o.a.i.i.processors.closure.GridClosureProcessor$C4] > java.lang.reflect.InaccessibleObjectException: Unable to make field private > final java.lang.Class java.lang.invoke.SerializedLambda.capturingClass > accessible: mo > dule java.base does not "opens java.lang.invoke" to unnamed module @694e1548 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17664) Transactions ErrorGroup id conflicts with Client
[ https://issues.apache.org/jira/browse/IGNITE-17664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602502#comment-17602502 ] Pavel Tupitsyn commented on IGNITE-17664: - Merged to main: 8fbbb62faf8e821beae28e8fe82d151e112044cb > Transactions ErrorGroup id conflicts with Client > > > Key: IGNITE-17664 > URL: https://issues.apache.org/jira/browse/IGNITE-17664 > Project: Ignite > Issue Type: Task >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > TX_ERR_GROUP and CLIENT_ERR_GROUP use the same id. The check in `newGroup` > does not uncover this because classes are loaded on demand. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17621) InFlightFutures does not properly register a new future which is already in completed state
[
https://issues.apache.org/jira/browse/IGNITE-17621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602490#comment-17602490
]
Vyacheslav Koptilin commented on IGNITE-17621:
--
Hi [~rpuch],
Could you please take a look?
> InFlightFutures does not properly register a new future which is already in
> completed state
> ---
>
> Key: IGNITE-17621
> URL: https://issues.apache.org/jira/browse/IGNITE-17621
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Trivial
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following method does not clean up the internal collection of futures in
> case the registered future was completed before calling the _registerFuture_:
> {code:java}
> /**
> * Registers a future in the in-flight futures collection. When it
> completes (either normally or exceptionally),
> * it will be removed from the collection.
> *
> * @param future the future to register
> */
> public void registerFuture(CompletableFuture future) {
> future.whenComplete((result, ex) -> inFlightFutures.remove(future));
> inFlightFutures.add(future);
> }
> {code}
> The fix is quite obvious - we just need to re-order these two lines :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17510) NPE in cluster configuration REST calls
[
https://issues.apache.org/jira/browse/IGNITE-17510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17510:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> NPE in cluster configuration REST calls
> ---
>
> Key: IGNITE-17510
> URL: https://issues.apache.org/jira/browse/IGNITE-17510
> Project: Ignite
> Issue Type: Task
> Components: cli, rest
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When calling {{/management/v1/configuration/cluster}} on the cluster that is
> not initialized, then we got the NPE and as a result, a 500 error code is
> returned.
> {{ItNotInitializedClusterRestTest#clusterConfiguration}} and
> {{ItNotInitializedClusterRestTest#clusterConfigurationUpdate}} reproduce the
> issue and have TODO for that.
> I would suggest to return 404 in that case as
> {{/management/v1/cluster/topology/logical}} does. So, there is no such
> resource on the cluster that is not initialized.
> The {{cluster config show/update}} error handling should be updated as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17510) NPE in cluster configuration REST calls
[
https://issues.apache.org/jira/browse/IGNITE-17510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-17510:
-
Issue Type: Bug (was: Task)
> NPE in cluster configuration REST calls
> ---
>
> Key: IGNITE-17510
> URL: https://issues.apache.org/jira/browse/IGNITE-17510
> Project: Ignite
> Issue Type: Bug
> Components: cli, rest
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When calling {{/management/v1/configuration/cluster}} on the cluster that is
> not initialized, then we got the NPE and as a result, a 500 error code is
> returned.
> {{ItNotInitializedClusterRestTest#clusterConfiguration}} and
> {{ItNotInitializedClusterRestTest#clusterConfigurationUpdate}} reproduce the
> issue and have TODO for that.
> I would suggest to return 404 in that case as
> {{/management/v1/cluster/topology/logical}} does. So, there is no such
> resource on the cluster that is not initialized.
> The {{cluster config show/update}} error handling should be updated as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-14744) Restore snapshot taken on different topologies
[ https://issues.apache.org/jira/browse/IGNITE-14744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-14744: --- Labels: iep-43 important ise (was: iep-43 important) > Restore snapshot taken on different topologies > -- > > Key: IGNITE-14744 > URL: https://issues.apache.org/jira/browse/IGNITE-14744 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.10 >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: iep-43, important, ise > Fix For: 2.12 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently, the snapshot restore procedure can be performed in the same > cluster topology. This means that it will not work in topologies with a > different number of cluster nodes (for example, fewer nodes) since it > requires a complete rebuild of the index for the cache groups. > We must support the restore procedure on different cluster topologies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15849) Remove ambiguity from the snapshot check procedure error message
[
https://issues.apache.org/jira/browse/IGNITE-15849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-15849:
---
Labels: ise (was: )
> Remove ambiguity from the snapshot check procedure error message
>
>
> Key: IGNITE-15849
> URL: https://issues.apache.org/jira/browse/IGNITE-15849
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: ise
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently the snapshot verify command has amibutiy output message like the
> following message below and must be fixed.
> {code}
> The check procedure failed on 1 node.
> The check procedure has finished, no conflicts have been found.
> The check procedure failed on nodes:
> Node ID: 200a3a77-594b-442c-9814-f6838ea2 [127.0.0.1]
> Consistent ID: snapshot.IgniteClusterSnapshotCheckTest2
> Exception: org.apache.ignite.IgniteException
> Snapshot data doesn't contain required cache group partition
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-12139) RPM for 2.7.5 release built from incorrect version
[
https://issues.apache.org/jira/browse/IGNITE-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-12139:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> RPM for 2.7.5 release built from incorrect version
> --
>
> Key: IGNITE-12139
> URL: https://issues.apache.org/jira/browse/IGNITE-12139
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7.5
>Reporter: Jan Kupec
>Assignee: Dmitry Pavlov
>Priority: Minor
>
> The {{apache-ignite-2.7.5}} RPM found in the [official RPM
> repository|https://ignite.apache.org/download.cgi#rpm-package] has been built
> from commit *{{c9521338}}*, which is several weeks of development away from
> the head of the {{ignite-2.7.5}} release branch (*{{be4f2a15}}*) and
> apparently contains incompatible changes.
> Is this a result of a human error or an error in the automated build system?
> Can this easily be fixed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-12139) RPM for 2.7.5 release built from incorrect version
[
https://issues.apache.org/jira/browse/IGNITE-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov resolved IGNITE-12139.
Resolution: Won't Fix
It seems that this issue is outdated
> RPM for 2.7.5 release built from incorrect version
> --
>
> Key: IGNITE-12139
> URL: https://issues.apache.org/jira/browse/IGNITE-12139
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 2.7.5
>Reporter: Jan Kupec
>Assignee: Dmitry Pavlov
>Priority: Minor
>
> The {{apache-ignite-2.7.5}} RPM found in the [official RPM
> repository|https://ignite.apache.org/download.cgi#rpm-package] has been built
> from commit *{{c9521338}}*, which is several weeks of development away from
> the head of the {{ignite-2.7.5}} release branch (*{{be4f2a15}}*) and
> apparently contains incompatible changes.
> Is this a result of a human error or an error in the automated build system?
> Can this easily be fixed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-11975) Fix Ignite Examples on site - Data Grid feature, how to start
[ https://issues.apache.org/jira/browse/IGNITE-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov resolved IGNITE-11975. Resolution: Won't Fix Not actual anymore, website does not contain that examples > Fix Ignite Examples on site - Data Grid feature, how to start > - > > Key: IGNITE-11975 > URL: https://issues.apache.org/jira/browse/IGNITE-11975 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitry Pavlov >Assignee: Dmitry Pavlov >Priority: Major > > 1) https://ignite.apache.org/features/datagrid.html > Contains several examples, which won't compile. > 2) > Check https://ignite.apache.org/features/collocatedprocessing.html if it is > runnable -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17131) Wrong result if subquery is on the left child of LEFT JOIN operator
[
https://issues.apache.org/jira/browse/IGNITE-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17131:
---
Release Note: Fixed incorrect query result if a subquery with a filter was
used on the left shoulder of a LEFT JOIN (was: Fixed an issue causing a wrong
result to be returned if subquery with filter is used on the left shoulder of
LEFT JOIN)
> Wrong result if subquery is on the left child of LEFT JOIN operator
> ---
>
> Key: IGNITE-17131
> URL: https://issues.apache.org/jira/browse/IGNITE-17131
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Critical
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently a query with a filtering subquery of a left side of a LEFT JOIN
> returns an invalid result. Looks like the problem is somewhere inside
> {{{}GridSubqueryJoinOptimizer{}}}.
> The possible workaround is to turn the join rewriting off by setting the
> system property {{IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION}} to false.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17145) Fix handle BinaryObjectException at the thin JDBC
[
https://issues.apache.org/jira/browse/IGNITE-17145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17145:
---
Release Note: Fixed handling of BinaryObjectException on response to
deserialization at the thin JDBC client (was: Fixed handle
BinaryObjectException on response deserialize at the thin JDBC.)
> Fix handle BinaryObjectException at the thin JDBC
> -
>
> Key: IGNITE-17145
> URL: https://issues.apache.org/jira/browse/IGNITE-17145
> Project: Ignite
> Issue Type: Bug
> Components: jdbc
>Affects Versions: 2.13
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I am trying to get enum field using sqlline, but failed with error Statement
> is closed.
> {code}
> 0: jdbc:ignite:thin://127.0.0.1> select status from nebulaclusterinfo;
> Error: Statement is closed. (state=,code=0)
> java.sql.SQLException: Statement is closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.ensureNotClosed(JdbcThinStatement.java:950)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.getWarnings(JdbcThinStatement.java:546)
> at sqlline.Commands.execute(Commands.java:849)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1> select count(status) from nebulaclusterinfo;
> ++
> | COUNT(STATUS) |
> ++
> | 310|
> ++
> 1 row selected (0.108 seconds)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17217) Java thin: addresses are not reloaded from ClientAddressFinder on connection loss
[ https://issues.apache.org/jira/browse/IGNITE-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17217: --- Release Note: Java thin: Fixed an issue that caused addresses not to be reloaded from ClientAddressFinder on connection loss in Kubernetes. (was: Java thin: reload addresses from ClientAddressFinder on connection loss to handle changing server address in Kubernetes and other scenarios.) > Java thin: addresses are not reloaded from ClientAddressFinder on connection > loss > - > > Key: IGNITE-17217 > URL: https://issues.apache.org/jira/browse/IGNITE-17217 > Project: Ignite > Issue Type: Bug > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: wkhappy >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When all node connections are lost, *ClientAddressFinder.getAddresses* is not > called to refresh the list of known endpoints. > For example, when a Kubernetes pod restarts, it may have a different address. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16337) Update lucene version up to 8.11.2 or above
[ https://issues.apache.org/jira/browse/IGNITE-16337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16337: --- Release Note: Updated Lucene library version to 8.11.2 (was: Lucene library version was updated to 8.11.2) > Update lucene version up to 8.11.2 or above > --- > > Key: IGNITE-16337 > URL: https://issues.apache.org/jira/browse/IGNITE-16337 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.11 >Reporter: Ilya Korol >Assignee: Ilya Korol >Priority: Major > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > Our Lucene version is quite outdated right now (7.4), while there are 2 major > releases available: 8.x.x with latest 8.11.1 and 9.0.0. So it would be good > to update this library because there were dozens of bugfixes, improvements > and optimizations since 7.4.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17274) Startup of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17274: --- Release Note: Improved service name lookup performance and reduced service startup time (was: Improved service name lookup performance and reduced service startup times.) > Startup of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > - > > Key: IGNITE-17274 > URL: https://issues.apache.org/jira/browse/IGNITE-17274 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Fix For: 2.14 > > Time Spent: 2h > Remaining Estimate: 0h > > Using a small POC, spinning up many servers is slow. In addition, the > startup time appears to be exponential. > Using timing measurements, found a linear lookup inside the > IgniteServiceProcessor that is taking most of the time. > Replacing that linear lookup with a Map lookup, and maintaining the map, > significantly speeds up the process, and startup time is now linear with the > number of services started. > Note this was tested with 20K and 50K services on a 1-node ignite cluster. > Timings against the stock 2.13.0 code come in at 30s for 20K and 250s for 50K > services. Modifying the linear lookup to use a Map, the timing come in at 8s > for 20K and 14s for 50K services. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17524: --- Release Note: Improved registered service name lookup performance and reduced service shutdown time was:Improved registered service name lookup performance and reduced service shutdown times. > Shutdown of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > -- > > Key: IGNITE-17524 > URL: https://issues.apache.org/jira/browse/IGNITE-17524 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Cloned from IGNITE-17274. That ticket addresses startup timing, and this one > addresses shutdown timing. > Shutting down large numbers of services is slowed down by a linear lookup > that can be addressed by adding a map to perform the lookups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17524: --- Release Note: Improved registered service name lookup performance and reduced service shutdown time (was: Improved registered service name lookup performance and reduced service shutdown time ) > Shutdown of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > -- > > Key: IGNITE-17524 > URL: https://issues.apache.org/jira/browse/IGNITE-17524 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Cloned from IGNITE-17274. That ticket addresses startup timing, and this one > addresses shutdown timing. > Shutting down large numbers of services is slowed down by a linear lookup > that can be addressed by adding a map to perform the lookups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17191) Consistency check should support cacheGroup as a param as well
[ https://issues.apache.org/jira/browse/IGNITE-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17191: --- Release Note: Improved consistency check, it now supports cacheGroup as a param as well was:Improved consistency check, it now supports cacheGroup as a param as well. > Consistency check should support cacheGroup as a param as well > -- > > Key: IGNITE-17191 > URL: https://issues.apache.org/jira/browse/IGNITE-17191 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31, ise > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > Both cache and cacheGroup should be supported at --cache param -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17112) Consistency check must fix counter after the consistency fix
[
https://issues.apache.org/jira/browse/IGNITE-17112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17112:
---
Release Note: Improved consistency check, it's now able to fix counters
(was: Consistency check now able to fix counters after the consistency fix)
> Consistency check must fix counter after the consistency fix
>
>
> Key: IGNITE-17112
> URL: https://issues.apache.org/jira/browse/IGNITE-17112
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31, ise
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Consistency repair repairs the consistency for the data committed on at least
> single node.
> But partition counter may have gaps for prepared, but not committed data, and
> such gaps will cause exception on cluster activation:
> {noformat}
> 2022-06-03 22:01:59.695
> [ERROR][sys-#322][org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager]
> Failed to update partition counter. Most probably a node with most actual
> data is out of topology or data streamer is used in preload mode
> (allowOverride=false) concurrently with cache transactions [grpName=XXX,
> partId=9099]
> org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=4854911, curState=Counter [lwm=4854911, holes={4854912=Item
> [start=4854912, delta=1]}, maxApplied=4854913, hwm=4854911]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:153)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.update(PartitionUpdateCounterErrorWrapper.java:97)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1687)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2530)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.updateCounter(GridDhtLocalPartition.java:913)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1491)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.lambda$updatePartitionFullMap$81bdb8e8$1(GridDhtPartitionsExchangeFuture.java:4817)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at
> org.apache.ignite.internal.util.IgniteUtils.lambda$null$1(IgniteUtils.java:11358)
> ~[ignite-core-2.11.0-p5.jar:2.11.0-p5]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_322]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_322]
> at java.lang.Thread.run(Thread.java:750)
> {noformat}
> Consistency check via cli must close this gaps on successful consistency
> repair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17025) Remove the ability to manually set INLINE_SIZE for types with a fixed length
[
https://issues.apache.org/jira/browse/IGNITE-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17025:
---
Release Note: Improved inline size adjustment for fixed size index items
(was: Improved adjustment inline size for fixed size index items.)
> Remove the ability to manually set INLINE_SIZE for types with a fixed length
>
>
> Key: IGNITE-17025
> URL: https://issues.apache.org/jira/browse/IGNITE-17025
> Project: Ignite
> Issue Type: Improvement
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Minor
> Labels: ise
> Fix For: 2.14
>
> Attachments: InlineIndexTest1.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The reproducer ( [^InlineIndexTest1.patch] ) shows index.bin size growing
> when INLINE_SIZE increases when creating indexes on fixed length fields.The
> negative point is that a place is reserved that does not carry any profit.
> As a solution. When trying to build an index on a field with a fixed length
> type, do not allow this. The value of INLINE_SIZE for such types is
> calculated automatically. And display a WARN level message about it.
> To see the size of index.bin, run the
> {code:java}
> du -sh IGNITE_HOME/db/node*/*INLINE*/* | grep index.bin"
> {code}
> after running the reproducer.
> {code:java}
> 36K BIGINT_INLINE10/index.bin
> 320K BIGINT_INLINE100/index.bin
> 128K INT_INLINE10/index.bin
> 324K INT_INLINE100/index.bin
> 64K NUMBER_INLINE10/index.bin
> 64K NUMBER_INLINE100/index.bin
> 128K VARCHAR_INLINE10/index.bin
> 256K VARCHAR_INLINE100/index.bin
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17191) Consistency check should support cacheGroup as a param as well
[ https://issues.apache.org/jira/browse/IGNITE-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17191: --- Release Note: Improved consistency check, it now supports cacheGroup as a param as well. (was: Consistency check now support cacheGroup as a param as well) > Consistency check should support cacheGroup as a param as well > -- > > Key: IGNITE-17191 > URL: https://issues.apache.org/jira/browse/IGNITE-17191 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > Both cache and cacheGroup should be supported at --cache param -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17191) Consistency check should support cacheGroup as a param as well
[ https://issues.apache.org/jira/browse/IGNITE-17191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17191: --- Labels: iep-31 ise (was: iep-31) > Consistency check should support cacheGroup as a param as well > -- > > Key: IGNITE-17191 > URL: https://issues.apache.org/jira/browse/IGNITE-17191 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31, ise > Fix For: 2.14 > > Time Spent: 1h > Remaining Estimate: 0h > > Both cache and cacheGroup should be supported at --cache param -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15329: --- Release Note: Improved `--consistency repair` command of the control.sh utility; atomic caches can now be repaired by Read Repair (was: Improved `--consistency repair` command of the control.sh utility; atomic caches now repairable by Read Repair) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16582) Improve behavior of speed-based throttling when dirty pages ratio is low
[
https://issues.apache.org/jira/browse/IGNITE-16582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16582:
---
Release Note: Improved behavior of the speed-based throttling when a
dirty-page ratio is low. (was: Improved behavior of speed-based throttling
when dirty pages ratio is low.)
> Improve behavior of speed-based throttling when dirty pages ratio is low
>
>
> Key: IGNITE-16582
> URL: https://issues.apache.org/jira/browse/IGNITE-16582
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Affects Versions: 2.12
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> There is a log:
> {{Throttling is applied to page modifications [}}
> percentOfPartTime=0.59,
> markDirty=7424 pages/sec,
> checkpointWrite=6268 pages/sec,
> estIdealMarkDirty=0 pages/sec,
> curDirty=0.00,
> maxDirty=0.24,
> avgParkTime=79770 ns,
> {{pages: (total=67085, evicted=0, written=40916, synced=0, cpBufUsed=3,
> cpBufTotal=518215)]}}
> Here, it can be seen that, although there are plenty of non-dirty pages,
> throttling is applied. This happens because our speed-based throttling has 2
> algorithms for protecting non-dirty pages from exhaustion:
> # A more complex one that computes max allowable dirty ratio and ideal
> marking speed and throttles when both dirty ratio and current marking speed
> surpass these values
> # A simpler one that throttles if the current marking speed is higher than
> the average checkpointing speed
> In the shown example the first algorithm does not throttle, but the second
> one does.
> It looks like the throttling is enabled too early.
> One way to solve this problem is to just disable the second algorithm as the
> first seems to be more adequate (but this needs careful consideration of all
> possible cases).
> Another way is to consider averaged marking speed instead of (or in addition
> to) the current marking speed when deciding whether to throttle or not.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15329: --- Labels: iep-12 iep-31 ise (was: iep-12 iep-31) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31, ise > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15834: --- Labels: iep-31 ise (was: iep-31) > Read Repair should support arrays and collections as values > --- > > Key: IGNITE-15834 > URL: https://issues.apache.org/jira/browse/IGNITE-15834 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31, ise > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15834) Read Repair should support arrays and collections as values
[ https://issues.apache.org/jira/browse/IGNITE-15834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15834: --- Release Note: Improved `--consistency repair` command of the control.sh utility; Read Repair now supports arrays and collections as values. (was: Improved `--consistency repair` command of the control.sh utility; Read Repair now support arrays and collections as values.) > Read Repair should support arrays and collections as values > --- > > Key: IGNITE-15834 > URL: https://issues.apache.org/jira/browse/IGNITE-15834 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15837) Read Repair should support binary keys
[ https://issues.apache.org/jira/browse/IGNITE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15837: --- Labels: iep-31 ise (was: iep-31) > Read Repair should support binary keys > -- > > Key: IGNITE-15837 > URL: https://issues.apache.org/jira/browse/IGNITE-15837 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31, ise > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15837) Read Repair should support binary keys
[ https://issues.apache.org/jira/browse/IGNITE-15837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15837: --- Release Note: Improved `--consistency repair` command of the control.sh utility; Read Repair now supports binary keys. (was: Improved `--consistency repair` command of the control.sh utility; Read Repair now support binary keys.) > Read Repair should support binary keys > -- > > Key: IGNITE-15837 > URL: https://issues.apache.org/jira/browse/IGNITE-15837 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16318) Empty binary object is incorrect written/read/modified
[
https://issues.apache.org/jira/browse/IGNITE-16318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16318:
---
Labels: ise (was: )
> Empty binary object is incorrect written/read/modified
> --
>
> Key: IGNITE-16318
> URL: https://issues.apache.org/jira/browse/IGNITE-16318
> Project: Ignite
> Issue Type: Bug
> Components: binary, cache
>Reporter: Andrey Belyaev
>Assignee: Taras Ledkov
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Cache interceptor cause problem of missing binary scheme if sql insert
> contains only entry key fields and no one value field pass in query.
> There is exception happened if inside interceptor we try to make
> BinaryObjectBuilder from entry value BinaryObject (#toBuilder()) and then
> request builder for any field.
> Interceptor example:
> {code:java}
> new CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> // ...
> }
> } {code}
> It's a pretty serious error which currupt and shutdown grid.
> Code example:
> {code:java}
> LinkedHashMap fields = new LinkedHashMap<>();
> fields.put("A", "java.lang.String");
> fields.put("B", "java.lang.String");
> fields.put("C", "java.lang.String");
> Set keyFields = new LinkedHashSet<>();
> keyFields.add("A");
> CacheInterceptorAdapter cacheInterceptorAdapter = new
> CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> if (bValue == null || bValue.isEmpty()) {
> newValBuilder.setField("B", "Some value");
> }
> return newValBuilder.build();
> }
> };
> CacheConfiguration cacheConfiguration = new CacheConfiguration<>()
> .setName("TEST_CACHE")
> .setKeyConfiguration(new CacheKeyConfiguration()
> .setTypeName("TEST_CACHE_KEY")
> .setAffinityKeyFieldName("InternalId"))
> .setQueryEntities(Collections.singleton(new QueryEntity()
> .setTableName("TEST_CACHE")
> .setKeyType("TEST_CACHE_KEY")
> .setValueType("TEST_CACHE_VALUE")
> .setFields(fields)
> .setKeyFields(keyFields)))
> .setInterceptor(cacheInterceptorAdapter);
> IgniteConfiguration igniteConfiguration = new IgniteConfiguration()
> .setCacheConfiguration(cacheConfiguration);
> try (Ignite ignite = Ignition.start(igniteConfiguration)) {
> IgniteCache testCache = ignite.getOrCreateCache("TEST_CACHE");
> // putSql
> testCache.query(new SqlFieldsQuery("INSERT INTO TEST_CACHE (A) VALUES
> ('1234')"));
> }{code}
> Exception:
> {code:java}
> [2022-01-18 13:12:32,727][ERROR][main][CacheObjectBinaryProcessorImpl] Timed
> out while waiting for schema update [typeId=1147851335, schemaId=0]
> [2022-01-18 13:12:32,730][ERROR][main][root] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [groupId=-838655627, pageIds=[844420635166307], msg=Runtime failure
> on search row: SearchRow [key=TEST_CACHE_KEY [idHash=100929741,
> hash=-639470899, A=123], hash=-639470899, cacheId=0
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=-838655627, pageIds=[844420635166307],
> msg=Runtime failure on search row: SearchRow [key=TEST_CACHE_KEY
> [idHash=100929741, hash=-639470899, A=123], hash=-639470899, cacheId=0]]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6237)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1988)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1742)
> at
>
[jira] [Updated] (IGNITE-16318) Empty binary object is incorrect written/read/modified
[
https://issues.apache.org/jira/browse/IGNITE-16318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16318:
---
Release Note: Fixed writing of an empty binary object. (was: Fixed write
empty binary object.)
> Empty binary object is incorrect written/read/modified
> --
>
> Key: IGNITE-16318
> URL: https://issues.apache.org/jira/browse/IGNITE-16318
> Project: Ignite
> Issue Type: Bug
> Components: binary, cache
>Reporter: Andrey Belyaev
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Cache interceptor cause problem of missing binary scheme if sql insert
> contains only entry key fields and no one value field pass in query.
> There is exception happened if inside interceptor we try to make
> BinaryObjectBuilder from entry value BinaryObject (#toBuilder()) and then
> request builder for any field.
> Interceptor example:
> {code:java}
> new CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> // ...
> }
> } {code}
> It's a pretty serious error which currupt and shutdown grid.
> Code example:
> {code:java}
> LinkedHashMap fields = new LinkedHashMap<>();
> fields.put("A", "java.lang.String");
> fields.put("B", "java.lang.String");
> fields.put("C", "java.lang.String");
> Set keyFields = new LinkedHashSet<>();
> keyFields.add("A");
> CacheInterceptorAdapter cacheInterceptorAdapter = new
> CacheInterceptorAdapter() {
> @Nullable
> @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) {
> BinaryObjectBuilder newValBuilder = newVal.toBuilder();
> String bValue = newValBuilder.getField("B"); // Cannot find schema
> for object with compact footer
> if (bValue == null || bValue.isEmpty()) {
> newValBuilder.setField("B", "Some value");
> }
> return newValBuilder.build();
> }
> };
> CacheConfiguration cacheConfiguration = new CacheConfiguration<>()
> .setName("TEST_CACHE")
> .setKeyConfiguration(new CacheKeyConfiguration()
> .setTypeName("TEST_CACHE_KEY")
> .setAffinityKeyFieldName("InternalId"))
> .setQueryEntities(Collections.singleton(new QueryEntity()
> .setTableName("TEST_CACHE")
> .setKeyType("TEST_CACHE_KEY")
> .setValueType("TEST_CACHE_VALUE")
> .setFields(fields)
> .setKeyFields(keyFields)))
> .setInterceptor(cacheInterceptorAdapter);
> IgniteConfiguration igniteConfiguration = new IgniteConfiguration()
> .setCacheConfiguration(cacheConfiguration);
> try (Ignite ignite = Ignition.start(igniteConfiguration)) {
> IgniteCache testCache = ignite.getOrCreateCache("TEST_CACHE");
> // putSql
> testCache.query(new SqlFieldsQuery("INSERT INTO TEST_CACHE (A) VALUES
> ('1234')"));
> }{code}
> Exception:
> {code:java}
> [2022-01-18 13:12:32,727][ERROR][main][CacheObjectBinaryProcessorImpl] Timed
> out while waiting for schema update [typeId=1147851335, schemaId=0]
> [2022-01-18 13:12:32,730][ERROR][main][root] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [groupId=-838655627, pageIds=[844420635166307], msg=Runtime failure
> on search row: SearchRow [key=TEST_CACHE_KEY [idHash=100929741,
> hash=-639470899, A=123], hash=-639470899, cacheId=0
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=-838655627, pageIds=[844420635166307],
> msg=Runtime failure on search row: SearchRow [key=TEST_CACHE_KEY
> [idHash=100929741, hash=-639470899, A=123], hash=-639470899, cacheId=0]]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6237)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1988)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1742)
> at
>
[jira] [Updated] (IGNITE-17432) ignitevisorcmd can't run in jdk17 env
[ https://issues.apache.org/jira/browse/IGNITE-17432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17432: --- Release Note: Fixed the run of ignitevisorcmd in JDK 17 environmen (was: Fixed run ignitevisorcmd in JDK 17 environment) > ignitevisorcmd can't run in jdk17 env > - > > Key: IGNITE-17432 > URL: https://issues.apache.org/jira/browse/IGNITE-17432 > Project: Ignite > Issue Type: Bug > Components: cli >Affects Versions: 2.13 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Minor > Fix For: 2.14 > > Attachments: > 0001-IGNITE-17432-ignitevisorcmd-can-t-run-in-jdk17-env.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Unrecognized VM option 'MaxPermSize=128M' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17140) Snapshot restore: use the snapshot pool to copy transferred partitions.
[ https://issues.apache.org/jira/browse/IGNITE-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17140: --- Release Note: Fixed the move of remote partition files during snapshot restore operations (was: Fixed the move of remote partition files during snapshot restore operations) > Snapshot restore: use the snapshot pool to copy transferred partitions. > --- > > Key: IGNITE-17140 > URL: https://issues.apache.org/jira/browse/IGNITE-17140 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Labels: ise > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > For now, TransmissionHandler#fileHandler is used to process transferred > partitions (files move I/O operation). It can cause socket timeout and > restore process stop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17140) Snapshot restore: use the snapshot pool to copy transferred partitions.
[ https://issues.apache.org/jira/browse/IGNITE-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17140: --- Labels: ise (was: ) > Snapshot restore: use the snapshot pool to copy transferred partitions. > --- > > Key: IGNITE-17140 > URL: https://issues.apache.org/jira/browse/IGNITE-17140 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Labels: ise > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > For now, TransmissionHandler#fileHandler is used to process transferred > partitions (files move I/O operation). It can cause socket timeout and > restore process stop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17140) Snapshot restore: use the snapshot pool to copy transferred partitions.
[ https://issues.apache.org/jira/browse/IGNITE-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17140: --- Release Note: Fixed the move of remote partition files during snapshot restore operations (was: Fixed remote partitions files move on snapshot restore operation) > Snapshot restore: use the snapshot pool to copy transferred partitions. > --- > > Key: IGNITE-17140 > URL: https://issues.apache.org/jira/browse/IGNITE-17140 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Labels: ise > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > For now, TransmissionHandler#fileHandler is used to process transferred > partitions (files move I/O operation). It can cause socket timeout and > restore process stop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17587) The "io.datastorage.StorageSize" metric shows incorrect values in case of multiple persistence dataregions
[
https://issues.apache.org/jira/browse/IGNITE-17587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17587:
---
Release Note: Fixed the "io.datastorage.StorageSize" metrics in case of
multiple persistence data regions. (was: Fixed the
"io.datastorage.StorageSize" metric in case of multiple persistence dataregions)
> The "io.datastorage.StorageSize" metric shows incorrect values in case of
> multiple persistence dataregions
> --
>
> Key: IGNITE-17587
> URL: https://issues.apache.org/jira/browse/IGNITE-17587
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The metric was broken after IGNITE-13207: it sets the value of the last group
> instead of the sum of all groups. See
> {{DataStorageMetricsImpl#onStorageSizeChanged}} for details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17502) Tasks to sent the snapshot files are not ordered
[
https://issues.apache.org/jira/browse/IGNITE-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17502:
---
Release Note: Fixed tasks for sending snapshot files (was: Fixed tasks to
sent snapshot files.)
> Tasks to sent the snapshot files are not ordered
>
>
> Key: IGNITE-17502
> URL: https://issues.apache.org/jira/browse/IGNITE-17502
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Tasks to sent the snapshot files are not ordered. This leads to socket
> timeout in a file sender while thread is busy by sending to other node:
> {noformat}
> sender.send(part1);
> ...
> otherSender.send(part3);
> ...
> // `sender` throws socket timeout exception.
> sender.send(part2);
> {noformat}
> {noformat}
> java.io.EOFException: null
> at
> java.io.ObjectInputStream$BlockDataInputStream.readBoolean(ObjectInputStream.java:3120)
> ~[?:1.8.0_201]
> at java.io.ObjectInputStream.readBoolean(ObjectInputStream.java:966)
> ~[?:1.8.0_201]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.receiveFromChannel(GridIoManager.java:2935)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2895)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> [classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> [classes/:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [?:1.8.0_201]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [?:1.8.0_201]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
> ...
> Caused by: org.apache.ignite.IgniteCheckedException: Requested topic is busy
> by another transmission. It's not allowed to process different sessions over
> the same topic simultaneously. Channel will be closed
> [initMsg=SessionChannelMessage
> [sesId=9c855b38281-d8dcd34f-916f-49d0-a453-cd1866acfce1],
> channel=java.nio.channels.SocketChannel[connected local=/127.0.0.1:47102
> remote=/127.0.0.1:55621], nodeId=5ace7280-b08a-4cf9-b428-7f70ef70]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processOpenedChannel(GridIoManager.java:2867)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4900(GridIoManager.java:244)
> ~[classes/:?]
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$7.run(GridIoManager.java:1237)
> ~[classes/:?]
> ... 3 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17415) A node receives and resolves obsolete addresses from the previously restarted and killed nodes
[ https://issues.apache.org/jira/browse/IGNITE-17415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17415: --- Release Note: Fixed node resolving stale addresses from previously restarted and killed nodes (was: Fixed an issue that caused a node resolves obsolete addresses from the previously restarted and killed nodes.) > A node receives and resolves obsolete addresses from the previously restarted > and killed nodes > -- > > Key: IGNITE-17415 > URL: https://issues.apache.org/jira/browse/IGNITE-17415 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.13 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Observation: Ignite tries to resolve *all* known IP and DNS names exposed by > the nodes since the cluster startup. This might cause a delay in response if > DNS resolution takes some time and critical for Kubernetes envroments. > The issue is due to the ignite keeping track of the topology history. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17414) A node is trying to resolve its DNS even if raw IP is configured in IGNITE_LOCAL_HOST
[ https://issues.apache.org/jira/browse/IGNITE-17414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17414: --- Release Note: Fixed incorrect node hostname resolution despite IP is configured with IGNITE_LOCAL_HOST (was: Fixed an issue that caused a node is trying to resolve its hostname if IP is configured with IGNITE_LOCAL_HOST.) > A node is trying to resolve its DNS even if raw IP is configured in > IGNITE_LOCAL_HOST > - > > Key: IGNITE-17414 > URL: https://issues.apache.org/jira/browse/IGNITE-17414 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.13 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Scenario: > Given the following etc/hosts from a Kubernetes POD: > 127.0.0.1 localhost > ::1 localhost ip6-localhost ip6-loopback > fe00::0 ip6-localnet > fe00::0 ip6-mcastprefix > fe00::1 ip6-allnodes > fe00::2 ip6-allrouters > 10.1.2.108 apache-ignite-cluster-2-client-1-0 > And ENV variable IGNITE_LOCAL_HOST=10.1.2.108, we are still resolving this as > apache-ignite-cluster-2-client-1-0/10.1.2.108 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17114) Idle_verify must print and compare full partition counter state instead of just LWM
[ https://issues.apache.org/jira/browse/IGNITE-17114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17114: --- Release Note: Fixed idle_verify command of control.sh utility; the command prints and compares full partition counter state. (was: Fixed the command `idle_verify` of the control.sh utility; the command prints and compares full partition counter state.) > Idle_verify must print and compare full partition counter state instead of > just LWM > --- > > Key: IGNITE-17114 > URL: https://issues.apache.org/jira/browse/IGNITE-17114 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31, ise > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Gaps also should be printed/compared. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17664) Transactions ErrorGroup id conflicts with Client
[ https://issues.apache.org/jira/browse/IGNITE-17664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602457#comment-17602457 ] Igor Sapego commented on IGNITE-17664: -- [~ptupitsyn] looks good to me. > Transactions ErrorGroup id conflicts with Client > > > Key: IGNITE-17664 > URL: https://issues.apache.org/jira/browse/IGNITE-17664 > Project: Ignite > Issue Type: Task >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > TX_ERR_GROUP and CLIENT_ERR_GROUP use the same id. The check in `newGroup` > does not uncover this because classes are loaded on demand. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
[
https://issues.apache.org/jira/browse/IGNITE-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17656:
---
Labels: ise (was: )
> Race in DistributedProcess#onSingleNodeMessageReceived
> --
>
> Key: IGNITE-17656
> URL: https://issues.apache.org/jira/browse/IGNITE-17656
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> DistributedProcess#onSingleNodeMessageReceived
> It could be a case when 2 (one of them is the last) messages receives
> simultaneously:
> # Initial state: remaining = \{node0, node1}, singleMsg={}
> # First msg handled, thread stops after releasing the `mux`:
> remaining=\{node0}, singleMsg={}.
> # Second msg handled, thread doesn't stop and: remaining={},
> singleMsg=\{node1}. And finishes process after that.
> # Thread 1 invoked, put message to singleMsg, but process was already
> finished.
>
> Solution is changing both collections (remaining, singleMsg) under the same
> `mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
[
https://issues.apache.org/jira/browse/IGNITE-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602455#comment-17602455
]
Dmitry Pavlov commented on IGNITE-17656:
Folks, please keep in mind that adding issues to release is only possible with
approval of RM at current stage.
see Phase 3 at
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process - only
blockers are allowed to be merged.
> Race in DistributedProcess#onSingleNodeMessageReceived
> --
>
> Key: IGNITE-17656
> URL: https://issues.apache.org/jira/browse/IGNITE-17656
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> DistributedProcess#onSingleNodeMessageReceived
> It could be a case when 2 (one of them is the last) messages receives
> simultaneously:
> # Initial state: remaining = \{node0, node1}, singleMsg={}
> # First msg handled, thread stops after releasing the `mux`:
> remaining=\{node0}, singleMsg={}.
> # Second msg handled, thread doesn't stop and: remaining={},
> singleMsg=\{node1}. And finishes process after that.
> # Thread 1 invoked, put message to singleMsg, but process was already
> finished.
>
> Solution is changing both collections (remaining, singleMsg) under the same
> `mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17385:
---
Release Note: Fixed asynchronous operation permits overflow for explicit
transaction with single write entry (was: Fixed overflowing async operation
permits maximum for explicit transaction with single write entry)
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17399:
---
Release Note: Fixed applying expiration to CDC-replicated cache entries
(was: Fixed expiration doesn't apply for cache entries replicated with CDC)
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: IEP-59, ise
> Fix For: 2.14
>
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16926) Interrupted compute job may fail a node
[
https://issues.apache.org/jira/browse/IGNITE-16926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16926:
---
Release Note: Fixed an issue with potential node failure during the
cancellation of computing jobs with cache operations (was: Fixed an issue with
potential node failure during cancelling of compute jobs with cache operations.)
> Interrupted compute job may fail a node
> ---
>
> Key: IGNITE-16926
> URL: https://issues.apache.org/jira/browse/IGNITE-16926
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ise.lts
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java}
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [groupId=1234619879, pageIds=[7290201467513],
> cacheId=645096946, cacheName=*, indexName=*, msg=Runtime failure on row:
> Row@79570772[ key: 1168930235, val: Data hidden due to
> IGNITE_SENSITIVE_DATA_LOGGING flag. ][ data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden
> ","logger_name":"ROOT","thread_name":"pub-#1278%x%","level":"ERROR","level_value":4,"stack_trace":"org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=1234619879, pageIds=[7290201467513],
> cacheId=645096946, cacheName=*, indexName=*, msg=Runtime failure on row:
> Row@79570772[ key: 1168930235, val: Data hidden due to
> IGNITE_SENSITIVE_DATA_LOGGING flag. ][ data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden, data hidden, data hidden, data hidden, data hidden, data hidden,
> data hidden ]] at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:1003)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2492)
> at
>
[jira] [Updated] (IGNITE-16866) Integer value is out of bounds when the dataregion maxSize is large enough
[ https://issues.apache.org/jira/browse/IGNITE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16866: --- Release Note: Fixed 'Integer value is out of bounds' issue when the dataregion maxSize is large enough (was: Fixed Integer value is out of bounds when the dataregion maxSize is large enough.) > Integer value is out of bounds when the dataregion maxSize is large enough > -- > > Key: IGNITE-16866 > URL: https://issues.apache.org/jira/browse/IGNITE-16866 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.12 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Minor > Labels: ise, ise.lts > Fix For: 2.14 > > Attachments: > 0001-IGNITE-16866-Integer-value-is-out-of-bounds-when-the.patch, > 2022-04-17_09-12.png, IgniteServer.java > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In the Random2LruPageEvictionTracker and RandomLruPageEvictionTracker, > trackingSize is int, Therefore, when the maxSize of the dataregion is large > enough (for example, more than 1.2T), execute GridUnsafe.allocateMemory to > allocate memory, the maximum value of int will be exceeded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16866) Integer value is out of bounds when the dataregion maxSize is large enough
[ https://issues.apache.org/jira/browse/IGNITE-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-16866: --- Labels: ise ise.lts (was: ise.lts) > Integer value is out of bounds when the dataregion maxSize is large enough > -- > > Key: IGNITE-16866 > URL: https://issues.apache.org/jira/browse/IGNITE-16866 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.12 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Minor > Labels: ise, ise.lts > Fix For: 2.14 > > Attachments: > 0001-IGNITE-16866-Integer-value-is-out-of-bounds-when-the.patch, > 2022-04-17_09-12.png, IgniteServer.java > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In the Random2LruPageEvictionTracker and RandomLruPageEvictionTracker, > trackingSize is int, Therefore, when the maxSize of the dataregion is large > enough (for example, more than 1.2T), execute GridUnsafe.allocateMemory to > allocate memory, the maximum value of int will be exceeded. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16757) Add cache create/destroy events to CDCConsumer
[
https://issues.apache.org/jira/browse/IGNITE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16757:
---
Labels: IEP-59 ise (was: IEP-59)
> Add cache create/destroy events to CDCConsumer
> --
>
> Key: IGNITE-16757
> URL: https://issues.apache.org/jira/browse/IGNITE-16757
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.14
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Need to provide the way to notify {{CDCConsumer}} about creation/destroying
> caches(tables).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16757) Add cache create/destroy events to CDCConsumer
[
https://issues.apache.org/jira/browse/IGNITE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-16757:
---
Release Note: Added cache change events for CDCConsumer. (was: Added cache
change events for CDCCosumer.)
> Add cache create/destroy events to CDCConsumer
> --
>
> Key: IGNITE-16757
> URL: https://issues.apache.org/jira/browse/IGNITE-16757
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
> Fix For: 2.14
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Need to provide the way to notify {{CDCConsumer}} about creation/destroying
> caches(tables).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17455) IndexQuery should support setPartition
[ https://issues.apache.org/jira/browse/IGNITE-17455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17455: --- Release Note: Added an opportunity to specify a single partition for IndexQuery (was: Added opportunity to specify single partition for IndexQuery) > IndexQuery should support setPartition > -- > > Key: IGNITE-17455 > URL: https://issues.apache.org/jira/browse/IGNITE-17455 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71, ise > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently IndexQuery doesn't support querying specified partition. But other > types of queries provide this option - ScanQuery, SqlFieldsQuery. > It's useful option for working with affinity requests. Then IndexQuery should > work over single partition. > To make it possible to migrate to IndexQuery from others queries let's add > such opportunity. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-13510) Getting status of snapshot execution via command line and jmx
[
https://issues.apache.org/jira/browse/IGNITE-13510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-13510:
---
Release Note: Added a snapshot status command to control.sh and JMX (was:
Added snapshot status command to control.sh and JMX.)
> Getting status of snapshot execution via command line and jmx
> -
>
> Key: IGNITE-13510
> URL: https://issues.apache.org/jira/browse/IGNITE-13510
> Project: Ignite
> Issue Type: Task
>Reporter: Sergei Ryzhov
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: iep-43, ise, snapshot
> Fix For: 2.14
>
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> the control.sh utility immediately relinquishes control
> and without using metricExporter it is impossible to understand whether the
> snapshot completed or not
> Creating
> {noformat}
> Create snapshot operation is in progress.
> Snapshot name: snapshot1
> Operation ID: 0c636326-76f8-4918-b15c-1010d9c47a5f
> Started at: Aug 17, 2022 8:02:27 PM
> Duration: 00:00:00.734
> Estimated operation progress:
> Node ID Processed, bytesTotal, bytes
> Percent
> a4d3f584-bd67-4550-a26a-afa3bd54120.0 KB2.2 MB
> 5%
> ef3a27fd-86eb-4886-97e6-7b061f1116.6 MB 34.1 MB
> 48%
> ffd8a17e-1fa4-4671-aac6-e2a3447312.6 MB 34.4 MB
> 36%
> 072d4b79-d4f9-472e-8b6a-d05c34f2132.0 KB2.1 MB
> 6%
> 210db306-0aa9-45ef-a0ca-5b7f612016.7 MB 34.2 MB
> 48%
> {noformat}
> Restoring
> {noformat}
> Restore snapshot operation is in progress.
> Snapshot name: snapshot1
> Operation ID: 96201080-b1d0-4f0c-80ef-5e046c1f62cf
> Started at: Aug 17, 2022 8:02:30 PM
> Duration: 00:00:00.170
> Estimated operation progress:
> Node ID Processed, partitionsTotal,
> partitionsPercent
> a4d3f584-bd67-4550-a26a-afa3bd5499
> 100%
> ef3a27fd-86eb-4886-97e6-7b061f1111 16
> 68%
> ffd8a17e-1fa4-4671-aac6-e2a3447314 16
> 87%
> 072d4b79-d4f9-472e-8b6a-d05c34f211 12
> 91%
> 210db306-0aa9-45ef-a0ca-5b7f612012 16
> 75%
> {noformat}
> No snapshot operation
> {noformat}
> There is no create or restore snapshot operation in progress.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17316) Thin client pluggable affnity mapping for the partition awareness usage
[
https://issues.apache.org/jira/browse/IGNITE-17316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17316:
---
Labels: ise (was: )
> Thin client pluggable affnity mapping for the partition awareness usage
> ---
>
> Key: IGNITE-17316
> URL: https://issues.apache.org/jira/browse/IGNITE-17316
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> We should provie a pluggable affinity for the thin client, thus using the
> partition awareness features become possible on only for
> {{RendezvousAffinityFunction}}.
> Dev-list discussion:
> https://lists.apache.org/thread/7n7zbcgw59voxyr08ct3zx2ss5g8q9wh
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17316) Thin client pluggable affnity mapping for the partition awareness usage
[
https://issues.apache.org/jira/browse/IGNITE-17316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-17316:
---
Release Note: Added a pluggable affinity mapping function for the partition
awareness usage (was: Added pluggable affinity mapping function for the
partition awareness usage)
> Thin client pluggable affnity mapping for the partition awareness usage
> ---
>
> Key: IGNITE-17316
> URL: https://issues.apache.org/jira/browse/IGNITE-17316
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> We should provie a pluggable affinity for the thin client, thus using the
> partition awareness features become possible on only for
> {{RendezvousAffinityFunction}}.
> Dev-list discussion:
> https://lists.apache.org/thread/7n7zbcgw59voxyr08ct3zx2ss5g8q9wh
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17002) Indexes rebuild in Maintenance Mode
[ https://issues.apache.org/jira/browse/IGNITE-17002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17002: --- Release Note: Added a control.sh command that schedules index rebuild via the maintenance mode (was: Added control.sh command that schedules index rebuild via the maintenance mode) > Indexes rebuild in Maintenance Mode > --- > > Key: IGNITE-17002 > URL: https://issues.apache.org/jira/browse/IGNITE-17002 > Project: Ignite > Issue Type: Improvement > Components: control.sh, persistence >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.14 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > Now Ignite supports entering Maintenance Mode after index corruption > automatically - this was implemented in linked issue. > But there are use-cases when user needs to request rebuilding specific > indexes in MM, so we need to provide a control.sh API to make these requests. > Also for better integration with monitoring tools it is nice to provide an > API to check status of rebuilding task and print message to logs when each > task is finished and all tasks are finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17638) Implement Txn state map to optimize write intent resolution
[ https://issues.apache.org/jira/browse/IGNITE-17638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17638: --- Description: Need to implement Txn state map which contains txId -> (txState, txCoordinatorAdress, commitTimestamp). # This map will be located on all nodes in replication group (primary and followers) in PartitionReplicaListener and PartitionListener. # Updated on ReadWriteReplicaRequest receiving in PartitionReplicaListener. Initially, only txCoordinatorAddress is known. The coordinator address is available in ReplicaManager on receiving a ReplicaRequest. Need to pass it to PartitionReplicaListener. # PartitionReplicaListener use raftClient commands for replication. So need to send coordinator address with raft command and save it in PartitionListener. # On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp (if commited). Txn state map optimizes write intent resolution. If commitTs <= readTs then RO transaction treat a write intent as committed. was: Need to implement Txn state map which contains txId -> (txState, txCoordinatorAdress, commitTimestamp). # This map will be located on all nodes in replication group (primary and followers) in PartitionReplicaListener and PartitionListener. # updated on ReadWriteReplicaRequest is received. Initially, only txCoordinatorAddress is known. The address is available on receiving a ReplicaRequest. It may be necessary to store the address of the coordinator in the ReplicaRequest, in case when the message is resent. On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp. Txn state map optimizes write intent resolution. If commitTs <= readTs then RO transaction treat a write intent as committed. > Implement Txn state map to optimize write intent resolution > --- > > Key: IGNITE-17638 > URL: https://issues.apache.org/jira/browse/IGNITE-17638 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > Need to implement Txn state map which contains txId -> (txState, > txCoordinatorAdress, commitTimestamp). > # This map will be located on all nodes in replication group (primary and > followers) in PartitionReplicaListener and PartitionListener. > # Updated on ReadWriteReplicaRequest receiving in PartitionReplicaListener. > Initially, only txCoordinatorAddress is known. The coordinator address is > available in ReplicaManager on receiving a ReplicaRequest. Need to pass it to > PartitionReplicaListener. > # PartitionReplicaListener use raftClient commands for replication. So need > to send coordinator address with raft command and save it in > PartitionListener. > # On TxCleanupReplicaRequest receiving need to set txState and > commitTimestamp (if commited). > > Txn state map optimizes write intent resolution. If commitTs <= readTs then > RO transaction treat a write intent as committed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17638) Implement Txn state map to optimize write intent resolution
[ https://issues.apache.org/jira/browse/IGNITE-17638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17638: --- Description: Need to implement Txn state map which contains txId -> (txState, txCoordinatorAdress, commitTimestamp). # This map will be located on all nodes in replication group (primary and followers) in PartitionReplicaListener and PartitionListener. # updated on ReadWriteReplicaRequest is received. Initially, only txCoordinatorAddress is known. The address is available on receiving a ReplicaRequest. It may be necessary to store the address of the coordinator in the ReplicaRequest, in case when the message is resent. On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp. Txn state map optimizes write intent resolution. If commitTs <= readTs then RO transaction treat a write intent as committed. was: Need to implement Txn state map which contains txId -> (txState, txCoordinatorAdress, commitTimestamp). This map will be located on all nodes in replication group (primary and followers) in PartitionReplicaListener and updated on ReadWriteReplicaRequest is received. Initially, only txCoordinatorAddress is known. The address is available on receiving a ReplicaRequest. It may be necessary to store the address of the coordinator in the ReplicaRequest, in case when the message is resent. On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp. Txn state map optimizes write intent resolution. If commitTs <= readTs then RO transaction treat a write intent as committed. > Implement Txn state map to optimize write intent resolution > --- > > Key: IGNITE-17638 > URL: https://issues.apache.org/jira/browse/IGNITE-17638 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > Need to implement Txn state map which contains txId -> (txState, > txCoordinatorAdress, commitTimestamp). > # This map will be located on all nodes in replication group (primary and > followers) in PartitionReplicaListener and PartitionListener. > # updated on ReadWriteReplicaRequest is received. Initially, only > txCoordinatorAddress is known. The address is available on receiving a > ReplicaRequest. It may be necessary to store the address of the coordinator > in the ReplicaRequest, in case when the message is resent. > On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp. > > Txn state map optimizes write intent resolution. If commitTs <= readTs then > RO transaction treat a write intent as committed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17178) Notify preconfigured event listeners about node start after resources were injected
[ https://issues.apache.org/jira/browse/IGNITE-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17178: --- Labels: ise (was: ) > Notify preconfigured event listeners about node start after resources were > injected > --- > > Key: IGNITE-17178 > URL: https://issues.apache.org/jira/browse/IGNITE-17178 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Labels: ise > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to notify preconfigured event listeners about node start after > resources were injected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17178) Notify preconfigured event listeners about node start after resources were injected
[ https://issues.apache.org/jira/browse/IGNITE-17178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-17178: --- Release Note: Fixed nofication for node start event (was: Fixed configured event listeners resource injection order.) > Notify preconfigured event listeners about node start after resources were > injected > --- > > Key: IGNITE-17178 > URL: https://issues.apache.org/jira/browse/IGNITE-17178 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > We need to notify preconfigured event listeners about node start after > resources were injected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17628) Get rid of org.apache.ignite.sql.Statement#prepared from public API
[ https://issues.apache.org/jira/browse/IGNITE-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602411#comment-17602411 ] Yury Gerzhedovich commented on IGNITE-17628: [~korlov], LGTM. > Get rid of org.apache.ignite.sql.Statement#prepared from public API > --- > > Key: IGNITE-17628 > URL: https://issues.apache.org/jira/browse/IGNITE-17628 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We don't hash final decision about separate support of prepared statements so > let's remove it from public API before release 3.0 Beta 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17517) Clean up todo's with closed tickets in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev resolved IGNITE-17517. --- Resolution: Done > Clean up todo's with closed tickets in CLI > -- > > Key: IGNITE-17517 > URL: https://issues.apache.org/jira/browse/IGNITE-17517 > Project: Ignite > Issue Type: Task > Components: cli >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Minor > Labels: ignite-3 > > There are a couple of todo's that are forgotten, clean them up or create new > tickets that are not in CLOSED state. > https://issues.apache.org/jira/browse/IGNITE-17091 > https://issues.apache.org/jira/browse/IGNITE-17092 > https://issues.apache.org/jira/browse/IGNITE-17162 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17651) Update Apache Ignite 2.14 release notes
[ https://issues.apache.org/jira/browse/IGNITE-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602399#comment-17602399 ] Dmitry Pavlov commented on IGNITE-17651: Generally looks good, I left a few improvement ideas in the PR [~julia_bakulina], could you please take a look too? > Update Apache Ignite 2.14 release notes > --- > > Key: IGNITE-17651 > URL: https://issues.apache.org/jira/browse/IGNITE-17651 > Project: Ignite > Issue Type: Task >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.14 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Update Apache Ignite 2.14 release notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17261) Implement a coordinator path write intent resolution logic for RO reads
[
https://issues.apache.org/jira/browse/IGNITE-17261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-17261:
---
Description:
Because of lock-free nature, RO reads might interact with writeIntents, meaning
that such intents should be either evaluated as committed, aborted or pending.
In order to perform writeIntent resolution it's required to
* Checks a local txn state map for committed or aborted state - allow read if
the state is committed and commitTs <= readTs.
* If not possible, send a TxStateReq to the txn coordinator - this initiates
the {*}coordinator path{*}. Coordinator address is fetched from the [txn state
map|https://docs.google.com/document/d/1PndaylEfK7CPUN7Kv9RYPKASN299s2qlbnMA5xIOFXo/edit#heading=h.wx3zf7jlf156].
* If a coordinator path was not able to resolve the intent, one of the
following has happened - the coordinator is dead or txn state is not available
in the cache. Calculate a commit partition and send the TxStateReq to its
primary replica - this initiates the {*}commit partition path{*}.
* Retry commit partition path until a success or timeout.
On receiving TxStateReq on the coordinator:
* If the local txn is finished, return the response with the outcome: commit
or abort. The txn state is stored in a local cache
(https://issues.apache.org/jira/browse/IGNITE-17638)
* If the local txn is finishing (waiting for finish state replication), wait
for outcome and return response with the outcome: commit or abort
* If the outcome is to commit, additional timestamp check is required: a
commit timestamp must be <= readTs. If the condition is not held, the outcome
is changed to commit .
* If local txn is active, adjust the txn coordinator node HLC according to
readTs to make sure the txn commit timestamp is above the read timestamp. The
read timestamp must be installed before txn is started to commit, so commit
timestamp is assigned after the read timestamp. This must be achieved by some
sort of concurrency control, preferably non-blocking. In this case we must
ignore the write intent, so the outcome is to abort.
* If txn state is not found in a local cache and txn is not active, return
NULL.
There's an open question about MvPartitionStorage api feature:
https://issues.apache.org/jira/browse/IGNITE-17627
was:
Because of lock-free nature, RO reads might interact with writeIntents, meaning
that such intents should be either evaluated as committed, aborted or pending.
In order to perform writeIntent resolution it's required to
* Checks a local txn state map for committed or aborted state - allow read if
the state is committed and commitTs <= readTs.
* If not possible, send a TxStateReq to the txn coordinator - this initiates
the {*}coordinator path{*}. Coordinator address is fetched from the [txn state
map|https://docs.google.com/document/d/1PndaylEfK7CPUN7Kv9RYPKASN299s2qlbnMA5xIOFXo/edit#heading=h.wx3zf7jlf156].
* If a coordinator path was not able to resolve the intent, one of the
following has happened - the coordinator is dead or txn state is not available
in the cache. Calculate a commit partition and send the TxStateReq to its
primary replica - this initiates the {*}commit partition path{*}.
* Retry commit partition path until a success or timeout.
On receiving TxStateReq on the coordinator:
* If the local txn is finished, return the response with the outcome: commit
or abort. The txn state is stored in a local cache, mentioned in the RW section.
* If the local txn is finishing (waiting for finish state replication), wait
for outcome and return response with the outcome: commit or abort
* If the outcome is to commit, additional timestamp check is required: a
commit timestamp must be <= readTs. If the condition is not held, the outcome
is changed to commit .
* If local txn is active, adjust the txn coordinator node HLC according to
readTs to make sure the txn commit timestamp is above the read timestamp. The
read timestamp must be installed before txn is started to commit, so commit
timestamp is assigned after the read timestamp. This must be achieved by some
sort of concurrency control, preferably non-blocking. In this case we must
ignore the write intent, so the outcome is to abort.
* If txn state is not found in a local cache and txn is not active, return
NULL.
There's an open question about MvPartitionStorage api feature:
https://issues.apache.org/jira/browse/IGNITE-17627
> Implement a coordinator path write intent resolution logic for RO reads
> ---
>
> Key: IGNITE-17261
> URL: https://issues.apache.org/jira/browse/IGNITE-17261
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_ro
>
[jira] [Updated] (IGNITE-17637) Implement a commit partition path write intent resolution logic for RO reads
[
https://issues.apache.org/jira/browse/IGNITE-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-17637:
---
Description:
Need to perform writeIntent resolution by commit partition path if a
coordinator path was not able to resolve the intent.
# Need to get a commit partition from write intent.
# ReplicaManager send the TxStateReq to its primary replica. For this in the
ReplicaManager need to save mapping of \{uuid, short} -> replica or \{int,
short} -> replica.
# On receiving TxStateReq on commit partition read the txn state from the
persistent storage. Send txState in response. If txState not found, return NULL
outcome in a TxStateResp.
# If txState is found, validate a commit timestamp (only for committed state).
# Retry commit partition path until a success or timeout.
was:
Need to perform writeIntent resolution by commit partition path if a
coordinator path was not able to resolve the intent.
# Need to get a commit partition from write intent.
# ReplicaManager send the TxStateReq to its primary replica. For this in the
ReplicaManager need to save mapping of \{uuid, short} -> replica or \{int,
short} -> replica.
# On receiving TxStateReq on commit partition read the txn state from the
persistent storage. Send txState in response. If txState not found, return NULL
outcome in a TxStateResp.
# If txState is found, validate a commit timestamp (only for committed state).
# Retry commit partition path until a success or timeout.
> Implement a commit partition path write intent resolution logic for RO reads
>
>
> Key: IGNITE-17637
> URL: https://issues.apache.org/jira/browse/IGNITE-17637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3, transaction3_ro
>
> Need to perform writeIntent resolution by commit partition path if a
> coordinator path was not able to resolve the intent.
> # Need to get a commit partition from write intent.
> # ReplicaManager send the TxStateReq to its primary replica. For this in the
> ReplicaManager need to save mapping of \{uuid, short} -> replica or \{int,
> short} -> replica.
> # On receiving TxStateReq on commit partition read the txn state from the
> persistent storage. Send txState in response. If txState not found, return
> NULL outcome in a TxStateResp.
> # If txState is found, validate a commit timestamp (only for committed
> state).
> # Retry commit partition path until a success or timeout.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17638) Implement Txn state map to optimize write intent resolution
[ https://issues.apache.org/jira/browse/IGNITE-17638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17638: --- Description: Need to implement Txn state map which contains txId -> (txState, txCoordinatorAdress, commitTimestamp). This map will be located on all nodes in replication group (primary and followers) in PartitionReplicaListener and updated on ReadWriteReplicaRequest is received. Initially, only txCoordinatorAddress is known. The address is available on receiving a ReplicaRequest. It may be necessary to store the address of the coordinator in the ReplicaRequest, in case when the message is resent. On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp. Txn state map optimizes write intent resolution. If commitTs <= readTs then RO transaction treat a write intent as committed. was: Need to implement Txn state map which contains txId -> (txState, txCoordinatorAdress, commitTimestamp). This map will be located on all nodes in replication group (primary and followers) and updated on modification command. On cleanupCommand need to set commitTimestamp. Txn state map optimizes write intent resolution. If commitTs <= readTs then RO transaction treat a write intent as committed. > Implement Txn state map to optimize write intent resolution > --- > > Key: IGNITE-17638 > URL: https://issues.apache.org/jira/browse/IGNITE-17638 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > Need to implement Txn state map which contains txId -> (txState, > txCoordinatorAdress, commitTimestamp). > This map will be located on all nodes in replication group (primary and > followers) in PartitionReplicaListener and updated on > ReadWriteReplicaRequest is received. Initially, only txCoordinatorAddress is > known. The address is available on receiving a ReplicaRequest. It may be > necessary to store the address of the coordinator in the ReplicaRequest, in > case when the message is resent. > On TxCleanupReplicaRequest receiving need to set txState and commitTimestamp. > > Txn state map optimizes write intent resolution. If commitTs <= readTs then > RO transaction treat a write intent as committed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17637) Implement a commit partition path write intent resolution logic for RO reads
[
https://issues.apache.org/jira/browse/IGNITE-17637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-17637:
---
Description:
Need to perform writeIntent resolution by commit partition path if a
coordinator path was not able to resolve the intent.
# Need to get a commit partition from write intent.
# ReplicaManager send the TxStateReq to its primary replica. For this in the
ReplicaManager need to save mapping of \{uuid, short} -> replica or \{int,
short} -> replica.
# On receiving TxStateReq on commit partition read the txn state from the
persistent storage. Send txState in response. If txState not found, return NULL
outcome in a TxStateResp.
# If txState is found, validate a commit timestamp (only for committed state).
# Retry commit partition path until a success or timeout.
was:
In order to perform writeIntent resolution if a coordinator path was not able
to resolve the intent need to initiate the {*}commit partition path{*}.
Need to calculate a commit partition and send the TxStateReq to its primary
replica.
On receiving TxStateReq on commit partition read the txn state from the
persistent storage. If found, validate a commit timestamp (only for committed
state) and return the outcome. If not found, return NULL outcome in a
TxStateResp. Retry commit partition path until a success or timeout.
> Implement a commit partition path write intent resolution logic for RO reads
>
>
> Key: IGNITE-17637
> URL: https://issues.apache.org/jira/browse/IGNITE-17637
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3, transaction3_ro
>
> Need to perform writeIntent resolution by commit partition path if a
> coordinator path was not able to resolve the intent.
> # Need to get a commit partition from write intent.
> # ReplicaManager send the TxStateReq to its primary replica. For this in the
> ReplicaManager need to save mapping of \{uuid, short} -> replica or \{int,
> short} -> replica.
> # On receiving TxStateReq on commit partition read the txn state from the
> persistent storage. Send txState in response. If txState not found, return
> NULL outcome in a TxStateResp.
> # If txState is found, validate a commit timestamp (only for committed
> state).
> # Retry commit partition path until a success or timeout.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17582) Introduce mutipleReplica ReplicaRequests together with grouped TxCleanupReplicaRequest processing
[
https://issues.apache.org/jira/browse/IGNITE-17582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-17582:
--
Description:
h3. Motivation
Within the scope of tx commit process, enlisted partitions are grouped together
by primary replica cluster node, however during the tx finish processing brand
new TxCleanupReplicaRequest is sent to each partition even colocated ones
within same cluster node:
{code:java}
public CompletableFuture cleanup(
ClusterNode recipientNode,
List replicationGroupIds,
UUID txId,
boolean commit,
HybridTimestamp commitTimestamp
) {
// TODO: https://issues.apache.org/jira/browse/IGNITE-17582 Grouping
replica requests.
replicationGroupIds.forEach(groupId -> {
try {
replicaService.invoke(
recipientNode,
FACTORY.txCleanupReplicaRequest()
.groupId(groupId)
.txId(txId)
.commit(commit)
.commitTimestamp(commitTimestamp)
.build()
);
} catch (NodeStoppingException e) {
throw new TransactionException("Failed to perform tx cleanup, node
is stopping.");
}
});
return null;
} {code}
Seems that we may introduce multipleReplicationGroups in addition to single
ones that we already have in order to perform such collocated based requests.
h3. Definition of Done
* General solution for groupping collocated replica requests is introduced.
* TxCleanupReplicaRequests are grouped on recipient node basis.
h3. Implementation Notes
Generally speaking, it's required to:
* Introduce new interface MutipleReplicasReplicaRequest with
Collection groupsId() in addition to already existing ReplicaRequest
with single String groupId();
* Implement proper multiple replicas fun out and aggregation(including
expcetion handling) of the results within
org.apache.ignite.network.NetworkMessageHandler#onReceived
* Send such new TxCleanupReplicaRequests one per cluster node instead of one
per replica, in other words rework
org.apache.ignite.internal.tx.impl.TxManagerImpl#cleanup
was:
h3. Motivation
Within the scope of tx commit process, enlisted partitions are grouped together
by primary replica cluster node, however during the tx finish processing brand
new TxCleanupReplicaRequest is sent to each partition even colocated ones
within same cluster node:
{code:java}
public CompletableFuture cleanup(
ClusterNode recipientNode,
List replicationGroupIds,
UUID txId,
boolean commit,
HybridTimestamp commitTimestamp
) {
// TODO: https://issues.apache.org/jira/browse/IGNITE-17582 Grouping
replica requests.
replicationGroupIds.forEach(groupId -> {
try {
replicaService.invoke(
recipientNode,
FACTORY.txCleanupReplicaRequest()
.groupId(groupId)
.txId(txId)
.commit(commit)
.commitTimestamp(commitTimestamp)
.build()
);
} catch (NodeStoppingException e) {
throw new TransactionException("Failed to perform tx cleanup, node
is stopping.");
}
});
return null;
} {code}
Seems that we may introduce multipleReplicationGroups in addition to single
ones that we already have in order to perform such collocated based requests.
h3. Definition of Done
* General solution for groupping collocated replica requests is introduced.
* TxCleanupReplicaRequests are grouped on recipient node basis.
h3. Implementation Notes
Generally speaking, it's required to:
* Introduce new interface MutipleReplicasReplicaRequest with
Collection groupsId() in addition to already existing ReplicaRequest
with single String groupId();
* Implement proper multiple replicas fun out and result aggrigation(including
expcetion handling) within
org.apache.ignite.network.NetworkMessageHandler#onReceived
* Send such new TxCleanupReplicaRequests one per cluster node instead of one
per replica, in other words rework
org.apache.ignite.internal.tx.impl.TxManagerImpl#cleanup
> Introduce mutipleReplica ReplicaRequests together with grouped
> TxCleanupReplicaRequest processing
> -
>
> Key: IGNITE-17582
> URL: https://issues.apache.org/jira/browse/IGNITE-17582
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Within the scope of tx commit process, enlisted partitions are grouped
> together by primary replica
[jira] [Updated] (IGNITE-17664) Transactions ErrorGroup id conflicts with Client
[ https://issues.apache.org/jira/browse/IGNITE-17664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17664: Ignite Flags: (was: Docs Required,Release Notes Required) > Transactions ErrorGroup id conflicts with Client > > > Key: IGNITE-17664 > URL: https://issues.apache.org/jira/browse/IGNITE-17664 > Project: Ignite > Issue Type: Task >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > TX_ERR_GROUP and CLIENT_ERR_GROUP use the same id. The check in `newGroup` > does not uncover this because classes are loaded on demand. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17663) Apache ignite is giving error when execute a sql query with Top keyword
[
https://issues.apache.org/jira/browse/IGNITE-17663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adnan updated IGNITE-17663:
---
Labels: ignite-3 (was: )
> Apache ignite is giving error when execute a sql query with Top keyword
> ---
>
> Key: IGNITE-17663
> URL: https://issues.apache.org/jira/browse/IGNITE-17663
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Affects Versions: 2.7.6
> Environment: Windows 10 x64, Apache ignite .net,
>Reporter: Adnan
>Priority: Critical
> Labels: ignite-3
>
> * When I execute a simple query on apache ignite it's work fine but when I
> execute with the "TOP" keyword it's give error. The query is "SELECT TOP(5)
> a.* FROM "Orders".ORDER a WHERE IsOptionTrade=FALSE AND (ACCOUNT IN ('10001',
> '10002', '10003'))".
> * The method is given below from where error occurs.
> *
> {{public IEnumerable QueryContinous(string initalquery, string
> predicateExpression, string queryKey, ref long seekinfo){if
> (string.IsNullOrEmpty(predicateExpression))
> predicateExpression = "1 == 1";if
> (ListenerLookup.ContainsKey(queryKey))
> {if (predicateExpression ==
> ListenerLookup[queryKey].PredicateExpr)return
> Query(initalquery, ref seekinfo);else{
> //Note:Same Client not using Different Versions of Client
> logger.Warn($"PredicateExpression:{predicateExpression} is Different from
> ListenerLookUp PredicateExpression:{ListenerLookup[queryKey].PredicateExpr}");
> Unsubscribe(queryKey);
> }
>
> }var listener = new Listener(queryKey);
> listener.OnUpdate += Listener_OnUpdate;var qry = new
> ContinuousQuery(listener)
> {
> Filter = new RemoteFilter()
> {
> Query = predicateExpression,
> IsWildListener = string.IsNullOrEmpty(predicateExpression)
> }
>
> };var initialQry = new SqlQuery(typeof(TV), initalquery);
>var queryHandle = Cache.QueryContinuous(qry, initialQry);// **At this
> point error occurs**var listenerDetails = new ListenerDetails()
> \{
> QueryHandle = queryHandle,
> listener = listener
>
> };
>
>
> listenerDetails.PredicateExpr = predicateExpression;
> listenerDetails.Predicate =
> System.Linq.Dynamic.Core.DynamicExpressionParser.ParseLambda(ParsingConfig.Default,
> true, predicateExpression).Compile();
>
>
> ListenerLookup.Add(queryKey, listenerDetails);return
> createList(queryHandle.GetInitialQueryCursor(), ref seekInfo);
> }}}
> * {{}}
> * {{}}
> * This is the error i am getting.
> * {{}}
> *
> {{{} Error Message : Apache.Ignite.Core.Common.IgniteException: Failed to
> parse query. Syntax error in SQL statement SELECT TOP 10 A._KEY, TOP 10[*]
> A._VAL FROM ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT
> IN ( '10001', '10002', '10003' ) ) ;
> SQL statement: SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER"
> a WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002', '10003' )
> ) [42000-197] ---> Apache.Ignite.Core.Common.JavaException: class
> org.apache.ignite.IgniteCheckedException: Failed to parse query. Syntax error
> in SQL statement SELECT TOP 10 A._KEY, TOP 10[*] A._VAL FROM
> ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN (
> '10001', '10002', '10003' ) ) ;
> SQL statement:SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER"
> a WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002','10003') )
> [42000-197]
> at
> org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:520)
>
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1242)
>
> at
> org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:883)
>
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
> * Caused by: javax.cache.CacheException: Failed to parse query.Syntax
> error in SQL statement SELECT TOP 10 A._KEY, TOP 10[*] A._VAL FROM
> ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN (
> '10001', '10002', '10003' ) ) ;
> SQL statement: SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER"
> a WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002', '10003' )
> ) [42000-197]
> at
>
[jira] [Created] (IGNITE-17664) Transactions ErrorGroup id conflicts with Client
Pavel Tupitsyn created IGNITE-17664: --- Summary: Transactions ErrorGroup id conflicts with Client Key: IGNITE-17664 URL: https://issues.apache.org/jira/browse/IGNITE-17664 Project: Ignite Issue Type: Task Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha6 TX_ERR_GROUP and CLIENT_ERR_GROUP use the same id. The check in `newGroup` does not uncover this because classes are loaded on demand. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17660) Add missing opens/exports to java15+ configuration
[ https://issues.apache.org/jira/browse/IGNITE-17660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602342#comment-17602342 ] Semyon Danilov commented on IGNITE-17660: - I don't actually know. But it seems like adding Java15+ on TC is too much, because we'll have to wait for both Java8 and Java15+ tests to run > Add missing opens/exports to java15+ configuration > -- > > Key: IGNITE-17660 > URL: https://issues.apache.org/jira/browse/IGNITE-17660 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.13 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > `add opens/exports java.lang.invoke` should be added to the parent/pom.xml so > that Java17 compilation would work correctly along with surefire tests. > While we are it, should also add java.sql/java.sql module -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17628) Get rid of org.apache.ignite.sql.Statement#prepared from public API
[ https://issues.apache.org/jira/browse/IGNITE-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602341#comment-17602341 ] Pavel Tupitsyn commented on IGNITE-17628: - [~korlov] looks good to me. > Get rid of org.apache.ignite.sql.Statement#prepared from public API > --- > > Key: IGNITE-17628 > URL: https://issues.apache.org/jira/browse/IGNITE-17628 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > We don't hash final decision about separate support of prepared statements so > let's remove it from public API before release 3.0 Beta 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17444) Consider possibility of introducing pluggable metric exporters
[ https://issues.apache.org/jira/browse/IGNITE-17444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602332#comment-17602332 ] Andrey N. Gura commented on IGNITE-17444: - [~kgusakov] LGTM. Thanks for contribution. Please, proceed with merge. > Consider possibility of introducing pluggable metric exporters > -- > > Key: IGNITE-17444 > URL: https://issues.apache.org/jira/browse/IGNITE-17444 > Project: Ignite > Issue Type: New Feature >Reporter: Denis Chudov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 1.5h > Remaining Estimate: 0h > > Consider possibility of introducing pluggable metric exporters to provide > ability for users to create their own exporters thay need. > Pluggable metric exporters should implement the common interface, and > implementations should be loaded to the application using Java ServiceLoader. > The problems of configuration exporters and turning on and off certain > implementations should be worked out within IGNITE-17358 . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602330#comment-17602330
]
Ignite TC Bot commented on IGNITE-17541:
{panel:title=Branch: [pull/10230/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10230/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6765105buildTypeId=IgniteTests24Java8_RunAll]
> Add "set" prefix to
> ThinClientConfiguration#sendServerExceptionStackTraceToClient()
> ---
>
> Key: IGNITE-17541
> URL: https://issues.apache.org/jira/browse/IGNITE-17541
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 4h 55m
> Remaining Estimate: 0h
>
> IGNITE-13389 introduces
> {{ThinClientConfiguration#sendServerExceptionStackTraceToClient()}}, but name
> of the method does not allow to set up this option in XML configuration,
> because Spring expects "set" prefix for setters.
> As you can see below, there is a workaround, but it would be more convenient
> to set up this property directly.
> Workaround:
> {code:xml|title=Add extra ThinClientConfiguration bean with necessary
> parameters}
> class="org.apache.ignite.configuration.ThinClientConfiguration">
>
>
> {code}
> {code:xml|title=Set up thinClientConfiguration by means of SpEL}
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration">
>
> value="#{thinClientCfg.sendServerExceptionStackTraceToClient(true)}"/>
>
>
> {code}
> We should add "set" and "get" prefix to setter and getter methods
> respectively or add extra methods with such prefixes from the point of
> possible compatibility issues (see IGNITE-16549).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17628) Get rid of org.apache.ignite.sql.Statement#prepared from public API
[ https://issues.apache.org/jira/browse/IGNITE-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602328#comment-17602328 ] Konstantin Orlov commented on IGNITE-17628: --- [~jooger], [~ptupitsyn], guys, could you please do a review? > Get rid of org.apache.ignite.sql.Statement#prepared from public API > --- > > Key: IGNITE-17628 > URL: https://issues.apache.org/jira/browse/IGNITE-17628 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > We don't hash final decision about separate support of prepared statements so > let's remove it from public API before release 3.0 Beta 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17628) Get rid of org.apache.ignite.sql.Statement#prepared from public API
[ https://issues.apache.org/jira/browse/IGNITE-17628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17628: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Get rid of org.apache.ignite.sql.Statement#prepared from public API > --- > > Key: IGNITE-17628 > URL: https://issues.apache.org/jira/browse/IGNITE-17628 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > We don't hash final decision about separate support of prepared statements so > let's remove it from public API before release 3.0 Beta 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17663) Apache ignite is giving error when execute a sql query with Top keyword
Adnan created IGNITE-17663:
--
Summary: Apache ignite is giving error when execute a sql query
with Top keyword
Key: IGNITE-17663
URL: https://issues.apache.org/jira/browse/IGNITE-17663
Project: Ignite
Issue Type: Bug
Components: cache, sql
Affects Versions: 2.7.6
Environment: Windows 10 x64, Apache ignite .net,
Reporter: Adnan
* When I execute a simple query on apache ignite it's work fine but when I
execute with the "TOP" keyword it's give error. The query is "SELECT TOP(5) a.*
FROM "Orders".ORDER a WHERE IsOptionTrade=FALSE AND (ACCOUNT IN ('10001',
'10002', '10003'))".
* The method is given below from where error occurs.
*
{{public IEnumerable QueryContinous(string initalquery, string
predicateExpression, string queryKey, ref long seekinfo){if
(string.IsNullOrEmpty(predicateExpression))
predicateExpression = "1 == 1";if
(ListenerLookup.ContainsKey(queryKey))
{if (predicateExpression ==
ListenerLookup[queryKey].PredicateExpr)return
Query(initalquery, ref seekinfo);else{
//Note:Same Client not using Different Versions of Client
logger.Warn($"PredicateExpression:{predicateExpression} is Different from
ListenerLookUp PredicateExpression:{ListenerLookup[queryKey].PredicateExpr}");
Unsubscribe(queryKey);
}
}var listener = new Listener(queryKey);
listener.OnUpdate += Listener_OnUpdate;var qry = new
ContinuousQuery(listener)
{
Filter = new RemoteFilter()
{
Query = predicateExpression,
IsWildListener = string.IsNullOrEmpty(predicateExpression)
}
};var initialQry = new SqlQuery(typeof(TV), initalquery);
var queryHandle = Cache.QueryContinuous(qry, initialQry);// **At this
point error occurs**var listenerDetails = new ListenerDetails()
\{
QueryHandle = queryHandle,
listener = listener
};
listenerDetails.PredicateExpr = predicateExpression;
listenerDetails.Predicate =
System.Linq.Dynamic.Core.DynamicExpressionParser.ParseLambda(ParsingConfig.Default,
true, predicateExpression).Compile();
ListenerLookup.Add(queryKey, listenerDetails);return
createList(queryHandle.GetInitialQueryCursor(), ref seekInfo);
}}}
* {{}}
* {{}}
* This is the error i am getting.
* {{}}
*
{{{} Error Message : Apache.Ignite.Core.Common.IgniteException: Failed to
parse query. Syntax error in SQL statement SELECT TOP 10 A._KEY, TOP 10[*]
A._VAL FROM ""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN
( '10001', '10002', '10003' ) ) ;
SQL statement: SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER" a
WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002', '10003' ) )
[42000-197] ---> Apache.Ignite.Core.Common.JavaException: class
org.apache.ignite.IgniteCheckedException: Failed to parse query. Syntax error
in SQL statement SELECT TOP 10 A._KEY, TOP 10[*] A._VAL FROM
""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN ( '10001',
'10002', '10003' ) ) ;
SQL statement:SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER" a
WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002','10003') )
[42000-197]
at
org.apache.ignite.internal.processors.platform.utils.PlatformUtils.unwrapQueryException(PlatformUtils.java:520)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1242)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutObject(PlatformCache.java:883)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutObject(PlatformTargetProxyImpl.java:79)
* Caused by: javax.cache.CacheException: Failed to parse query.Syntax error
in SQL statement SELECT TOP 10 A._KEY, TOP 10[*] A._VAL FROM
""Orders"".""ORDER"" A WHERE ISOPTIONTRADE=FALSE AND ( ACCOUNT IN ( '10001',
'10002', '10003' ) ) ;
SQL statement: SELECT TOP 10 a._KEY, TOP 10 a._VAL FROM "Orders"."ORDER" a
WHERE IsOptionTrade=FALSE AND ( Account IN ( '10001', '10002', '10003' ) )
[42000-197]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:376)
at
org.apache.ignite.internal.processors.platform.cache.PlatformCache.runQuery(PlatformCache.java:1236)
... 2 more
* Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse
query. Syntax error in SQL
[jira] [Updated] (IGNITE-17662) Update Ignite version to 2.15.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/IGNITE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17662: -- Fix Version/s: 2.14 > Update Ignite version to 2.15.0-SNAPSHOT > > > Key: IGNITE-17662 > URL: https://issues.apache.org/jira/browse/IGNITE-17662 > Project: Ignite > Issue Type: Task >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.14 > > > Update Ignite version to 2.15.0-SNAPSHOT > The pom dependencies must be updated due to the ignite-2.14 branch has been > created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17662) Update Ignite version to 2.15.0-SNAPSHOT
Taras Ledkov created IGNITE-17662: - Summary: Update Ignite version to 2.15.0-SNAPSHOT Key: IGNITE-17662 URL: https://issues.apache.org/jira/browse/IGNITE-17662 Project: Ignite Issue Type: Task Reporter: Taras Ledkov Assignee: Taras Ledkov Update Ignite version to 2.15.0-SNAPSHOT The pom dependencies must be updated due to the ignite-2.14 branch has been created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17661) Update packages version to 2.14
Taras Ledkov created IGNITE-17661: - Summary: Update packages version to 2.14 Key: IGNITE-17661 URL: https://issues.apache.org/jira/browse/IGNITE-17661 Project: Ignite Issue Type: Task Reporter: Taras Ledkov Assignee: Taras Ledkov Fix For: 2.14 Update packages version to 2.13 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17651) Update Apache Ignite 2.14 release notes
[ https://issues.apache.org/jira/browse/IGNITE-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602302#comment-17602302 ] Taras Ledkov commented on IGNITE-17651: --- [~dpavlov], please review the patch. > Update Apache Ignite 2.14 release notes > --- > > Key: IGNITE-17651 > URL: https://issues.apache.org/jira/browse/IGNITE-17651 > Project: Ignite > Issue Type: Task >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Update Apache Ignite 2.14 release notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
[
https://issues.apache.org/jira/browse/IGNITE-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602291#comment-17602291
]
Maksim Timonin commented on IGNITE-17656:
-
[~NSAmelchev] [~namelchev] thanks for review! Merged to master.
Cherry-picked to 2.14
> Race in DistributedProcess#onSingleNodeMessageReceived
> --
>
> Key: IGNITE-17656
> URL: https://issues.apache.org/jira/browse/IGNITE-17656
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> DistributedProcess#onSingleNodeMessageReceived
> It could be a case when 2 (one of them is the last) messages receives
> simultaneously:
> # Initial state: remaining = \{node0, node1}, singleMsg={}
> # First msg handled, thread stops after releasing the `mux`:
> remaining=\{node0}, singleMsg={}.
> # Second msg handled, thread doesn't stop and: remaining={},
> singleMsg=\{node1}. And finishes process after that.
> # Thread 1 invoked, put message to singleMsg, but process was already
> finished.
>
> Solution is changing both collections (remaining, singleMsg) under the same
> `mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
[
https://issues.apache.org/jira/browse/IGNITE-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17656:
Fix Version/s: 2.14
> Race in DistributedProcess#onSingleNodeMessageReceived
> --
>
> Key: IGNITE-17656
> URL: https://issues.apache.org/jira/browse/IGNITE-17656
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> DistributedProcess#onSingleNodeMessageReceived
> It could be a case when 2 (one of them is the last) messages receives
> simultaneously:
> # Initial state: remaining = \{node0, node1}, singleMsg={}
> # First msg handled, thread stops after releasing the `mux`:
> remaining=\{node0}, singleMsg={}.
> # Second msg handled, thread doesn't stop and: remaining={},
> singleMsg=\{node1}. And finishes process after that.
> # Thread 1 invoked, put message to singleMsg, but process was already
> finished.
>
> Solution is changing both collections (remaining, singleMsg) under the same
> `mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17656) Race in DistributedProcess#onSingleNodeMessageReceived
[
https://issues.apache.org/jira/browse/IGNITE-17656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602279#comment-17602279
]
Ignite TC Bot commented on IGNITE-17656:
{panel:title=Branch: [pull/10241/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10241/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6599204buildTypeId=IgniteTests24Java8_RunAll]
> Race in DistributedProcess#onSingleNodeMessageReceived
> --
>
> Key: IGNITE-17656
> URL: https://issues.apache.org/jira/browse/IGNITE-17656
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> DistributedProcess#onSingleNodeMessageReceived
> It could be a case when 2 (one of them is the last) messages receives
> simultaneously:
> # Initial state: remaining = \{node0, node1}, singleMsg={}
> # First msg handled, thread stops after releasing the `mux`:
> remaining=\{node0}, singleMsg={}.
> # Second msg handled, thread doesn't stop and: remaining={},
> singleMsg=\{node1}. And finishes process after that.
> # Thread 1 invoked, put message to singleMsg, but process was already
> finished.
>
> Solution is changing both collections (remaining, singleMsg) under the same
> `mux`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17297) Thin 3.0: Adopt BinaryTuple format in transport layer
[ https://issues.apache.org/jira/browse/IGNITE-17297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602278#comment-17602278 ] Pavel Tupitsyn commented on IGNITE-17297: - Merged to main: 91f9cee9ab7130bad9b24458d563f4b06ec835a7 > Thin 3.0: Adopt BinaryTuple format in transport layer > - > > Key: IGNITE-17297 > URL: https://issues.apache.org/jira/browse/IGNITE-17297 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: iep-92, ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > BinaryTuple (see IEP-92) is a common format for data exchange in Ignite 3. > Adopt it in the thin client protocol to be able to avoid intermediate > conversions when exchanging data. > For example, we should be able to write SQL query results to the client > socket directly as byte[]. > > Update IEP-76 when done. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17510) NPE in cluster configuration REST calls
[
https://issues.apache.org/jira/browse/IGNITE-17510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602273#comment-17602273
]
Vyacheslav Koptilin commented on IGNITE-17510:
--
Hello [~vpakhnushev],
In general the patch looks good. However, please take a look at
https://github.com/apache/ignite-3/pull/1037/files#r966923583
> NPE in cluster configuration REST calls
> ---
>
> Key: IGNITE-17510
> URL: https://issues.apache.org/jira/browse/IGNITE-17510
> Project: Ignite
> Issue Type: Task
> Components: cli, rest
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When calling {{/management/v1/configuration/cluster}} on the cluster that is
> not initialized, then we got the NPE and as a result, a 500 error code is
> returned.
> {{ItNotInitializedClusterRestTest#clusterConfiguration}} and
> {{ItNotInitializedClusterRestTest#clusterConfigurationUpdate}} reproduce the
> issue and have TODO for that.
> I would suggest to return 404 in that case as
> {{/management/v1/cluster/topology/logical}} does. So, there is no such
> resource on the cluster that is not initialized.
> The {{cluster config show/update}} error handling should be updated as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17651) Update Apache Ignite 2.14 release notes
[ https://issues.apache.org/jira/browse/IGNITE-17651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-17651: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Update Apache Ignite 2.14 release notes > --- > > Key: IGNITE-17651 > URL: https://issues.apache.org/jira/browse/IGNITE-17651 > Project: Ignite > Issue Type: Task >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.14 > > > Update Apache Ignite 2.14 release notes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[
https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17659:
---
Description:
The _InternalTable#scan_ method has two issues:
1) Cancel scanning does not send a message to served side and does not clear
cursor, that is opened in server side.
The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent after
a subscriber is received a last one batch of entries or Subscription#cancel is
invoked.
2) The API does not work correctly for implicit transaction.
Implicit transaction should be started at the first retrieve batch request is
sent. The transaction shouldn't be closed until the subscriber reads to the end
or Subscription#cancel is not invoked.
was:
The _InternalTable#scan_ method has two issues:
1) Cancel scanning does not send a message to served side and does not clear
cursor, that is opened in server side.
The close message should be sent after a subscriber is received a last one
batch of entries or Subscription#cancel is invoked.
2) The API does not work correctly for implicit transaction.
Implicit transaction should be started at the first retrieve batch request is
sent. The transaction shouldn't be closed until the subscriber reads to the end
or Subscription#cancel is not invoked.
> Table Scan workflow enhancement
> ---
>
> Key: IGNITE-17659
> URL: https://issues.apache.org/jira/browse/IGNITE-17659
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> The _InternalTable#scan_ method has two issues:
> 1) Cancel scanning does not send a message to served side and does not clear
> cursor, that is opened in server side.
> The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent
> after a subscriber is received a last one batch of entries or
> Subscription#cancel is invoked.
> 2) The API does not work correctly for implicit transaction.
> Implicit transaction should be started at the first retrieve batch request is
> sent. The transaction shouldn't be closed until the subscriber reads to the
> end or Subscription#cancel is not invoked.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[
https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17659:
---
Description:
The _InternalTable#scan_ method has two issues:
# Cancel scanning does not send a message to served side and does not clear
cursor, that is opened in server side.
The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent after
a subscriber is received a last one batch of entries or Subscription#cancel is
invoked.
# The API does not work correctly for implicit transaction.
Implicit transaction should be started at the first retrieve batch request is
sent. The transaction shouldn't be closed until the subscriber reads to the end
or Subscription#cancel is not invoked.
was:
The _InternalTable#scan_ method has two issues:
1) Cancel scanning does not send a message to served side and does not clear
cursor, that is opened in server side.
The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent after
a subscriber is received a last one batch of entries or Subscription#cancel is
invoked.
2) The API does not work correctly for implicit transaction.
Implicit transaction should be started at the first retrieve batch request is
sent. The transaction shouldn't be closed until the subscriber reads to the end
or Subscription#cancel is not invoked.
> Table Scan workflow enhancement
> ---
>
> Key: IGNITE-17659
> URL: https://issues.apache.org/jira/browse/IGNITE-17659
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> The _InternalTable#scan_ method has two issues:
> # Cancel scanning does not send a message to served side and does not clear
> cursor, that is opened in server side.
> The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent
> after a subscriber is received a last one batch of entries or
> Subscription#cancel is invoked.
> # The API does not work correctly for implicit transaction.
> Implicit transaction should be started at the first retrieve batch request is
> sent. The transaction shouldn't be closed until the subscriber reads to the
> end or Subscription#cancel is not invoked.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[
https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-17659:
---
Description:
The _InternalTable#scan_ method has two issues:
# Cancel scanning does not send a message to served side and does not clear
cursor, that is opened in server side.
The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent after
a subscriber is received a last one batch of entries or _Subscription#cancel_
is invoked.
# The API does not work correctly for implicit transaction.
Implicit transaction should be started at the first retrieve batch request is
sent. The transaction shouldn't be closed until the subscriber reads to the end
or _Subscription#cancel_ is not invoked.
was:
The _InternalTable#scan_ method has two issues:
# Cancel scanning does not send a message to served side and does not clear
cursor, that is opened in server side.
The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent after
a subscriber is received a last one batch of entries or Subscription#cancel is
invoked.
# The API does not work correctly for implicit transaction.
Implicit transaction should be started at the first retrieve batch request is
sent. The transaction shouldn't be closed until the subscriber reads to the end
or Subscription#cancel is not invoked.
> Table Scan workflow enhancement
> ---
>
> Key: IGNITE-17659
> URL: https://issues.apache.org/jira/browse/IGNITE-17659
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> The _InternalTable#scan_ method has two issues:
> # Cancel scanning does not send a message to served side and does not clear
> cursor, that is opened in server side.
> The close message (look at {_}ScanCloseReplicaRequest{_}) should be sent
> after a subscriber is received a last one batch of entries or
> _Subscription#cancel_ is invoked.
> # The API does not work correctly for implicit transaction.
> Implicit transaction should be started at the first retrieve batch request is
> sent. The transaction shouldn't be closed until the subscriber reads to the
> end or _Subscription#cancel_ is not invoked.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[ https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17659: --- Description: The _InternalTable#scan_ method has two issues: 1) Cancel scanning does not send a message to served side and does not clear cursor, that is opened in server side. The close message should be sent after a subscriber is received a last one batch of entries or Subscription#cancel is invoked. 2) The API does not work correctly for implicit transaction. Implicit transaction should be started at the first retrieve batch request is sent. The transaction shouldn't be closed until the subscriber reads to the end or Subscription#cancel is not invoked. was: The _InternalTable#scan_ method has two issues: 1) Cancel scanning does not send a message to served side and does not clear cursor, that is opened in server side. 2) The API does not work correctly for implicit transaction. Implicit transaction should be started at the first retrieve batch request is sent. The transaction shouldn't be closed until the subscriber reads to the end or Subscription#cancel is not invoked. > Table Scan workflow enhancement > --- > > Key: IGNITE-17659 > URL: https://issues.apache.org/jira/browse/IGNITE-17659 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > The _InternalTable#scan_ method has two issues: > 1) Cancel scanning does not send a message to served side and does not clear > cursor, that is opened in server side. > The close message should be sent after a subscriber is received a last one > batch of entries or Subscription#cancel is invoked. > 2) The API does not work correctly for implicit transaction. > Implicit transaction should be started at the first retrieve batch request is > sent. The transaction shouldn't be closed until the subscriber reads to the > end or Subscription#cancel is not invoked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[ https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17659: --- Description: The _InternalTable#scan_ method has two issues: 1) Cancel scanning does not send a message to served side and does not clear cursor, that is opened in server side. 2) The API does not work correctly for implicit transaction. Implicit transaction should be started at the first retrieve batch request is sent. The transaction shouldn't be closed until the subscriber reads to the end or Subscription#cancel is not invoked. was: The _InternalTable#scan_ method has two issues: 1) Cancel scanning does not send a message to served side and does not clear cursor, that is opened in server side. 2) The API does not work correctly for implicit transaction. > Table Scan workflow enhancement > --- > > Key: IGNITE-17659 > URL: https://issues.apache.org/jira/browse/IGNITE-17659 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > The _InternalTable#scan_ method has two issues: > 1) Cancel scanning does not send a message to served side and does not clear > cursor, that is opened in server side. > 2) The API does not work correctly for implicit transaction. > Implicit transaction should be started at the first retrieve batch request is > sent. The transaction shouldn't be closed until the subscriber reads to the > end or Subscription#cancel is not invoked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[ https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17659: --- Description: The _InternalTable#scan_ method has two issues: 1) Cancel scanning does not send a message to served side and does not clear cursor, that is opened in server side. 2) The API does not work correctly for implicit transaction. was: The _InternalTable#scan_ method has two issues: 1) Cancel scanning does not send a message to served side and does not clear cursor, that is opened in server side. 2) The API is not work correctly for implicit transaction. > Table Scan workflow enhancement > --- > > Key: IGNITE-17659 > URL: https://issues.apache.org/jira/browse/IGNITE-17659 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > The _InternalTable#scan_ method has two issues: > 1) Cancel scanning does not send a message to served side and does not clear > cursor, that is opened in server side. > 2) The API does not work correctly for implicit transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17659) Table Scan workflow enhancement
[ https://issues.apache.org/jira/browse/IGNITE-17659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-17659: --- Summary: Table Scan workflow enhancement (was: Table Scan API enhancement) > Table Scan workflow enhancement > --- > > Key: IGNITE-17659 > URL: https://issues.apache.org/jira/browse/IGNITE-17659 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > The _InternalTable#scan_ method has two issues: > 1) Cancel scanning does not send a message to served side and does not clear > cursor, that is opened in server side. > 2) The API is not work correctly for implicit transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17541) Add "set" prefix to ThinClientConfiguration#sendServerExceptionStackTraceToClient()
[
https://issues.apache.org/jira/browse/IGNITE-17541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602237#comment-17602237
]
Ignite TC Bot commented on IGNITE-17541:
{panel:title=Branch: [pull/10230/head] Base: [master] : Possible Blockers
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 13{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6765005]]
* IgniteCacheTestSuite13:
GridCacheDataTypesCoverageTest.testObjectBasedOnPrimitivesDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=1, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=false,
useBinaryArrays=false] - Test has low fail rate in base branch 0,0% and is not
flaky
{color:#d04437}Queries 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6765075]]
* IgniteBinaryCacheQueryTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateNoTablePartitionedTransactionalNear
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6765011]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes - Test has low
fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10230/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6756488buildTypeId=IgniteTests24Java8_RunAll]
> Add "set" prefix to
> ThinClientConfiguration#sendServerExceptionStackTraceToClient()
> ---
>
> Key: IGNITE-17541
> URL: https://issues.apache.org/jira/browse/IGNITE-17541
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise, newbie
> Time Spent: 4h 35m
> Remaining Estimate: 0h
>
> IGNITE-13389 introduces
> {{ThinClientConfiguration#sendServerExceptionStackTraceToClient()}}, but name
> of the method does not allow to set up this option in XML configuration,
> because Spring expects "set" prefix for setters.
> As you can see below, there is a workaround, but it would be more convenient
> to set up this property directly.
> Workaround:
> {code:xml|title=Add extra ThinClientConfiguration bean with necessary
> parameters}
> class="org.apache.ignite.configuration.ThinClientConfiguration">
>
>
> {code}
> {code:xml|title=Set up thinClientConfiguration by means of SpEL}
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration">
>
> value="#{thinClientCfg.sendServerExceptionStackTraceToClient(true)}"/>
>
>
> {code}
> We should add "set" and "get" prefix to setter and getter methods
> respectively or add extra methods with such prefixes from the point of
> possible compatibility issues (see IGNITE-16549).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15189) Document new SQL engine based on Calcite
[ https://issues.apache.org/jira/browse/IGNITE-15189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li updated IGNITE-15189: -- Labels: documentation (was: calcite3-required documentation ignite-3) > Document new SQL engine based on Calcite > > > Key: IGNITE-15189 > URL: https://issues.apache.org/jira/browse/IGNITE-15189 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Yury Gerzhedovich >Assignee: Nikita A. Safonov >Priority: Major > Labels: documentation > Fix For: 2.13 > > Time Spent: 7h 10m > Remaining Estimate: 0h > > We need to start documenting the new SQL engine. Let's start with Contents. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-15189) Document new SQL engine based on Calcite
[ https://issues.apache.org/jira/browse/IGNITE-15189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li resolved IGNITE-15189. --- Resolution: Fixed > Document new SQL engine based on Calcite > > > Key: IGNITE-15189 > URL: https://issues.apache.org/jira/browse/IGNITE-15189 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Yury Gerzhedovich >Assignee: Nikita A. Safonov >Priority: Major > Labels: calcite3-required, documentation, ignite-3 > Fix For: 2.13 > > Time Spent: 7h 10m > Remaining Estimate: 0h > > We need to start documenting the new SQL engine. Let's start with Contents. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15189) Document new SQL engine based on Calcite
[ https://issues.apache.org/jira/browse/IGNITE-15189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li updated IGNITE-15189: -- Fix Version/s: 2.13 (was: 2.15) > Document new SQL engine based on Calcite > > > Key: IGNITE-15189 > URL: https://issues.apache.org/jira/browse/IGNITE-15189 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Yury Gerzhedovich >Assignee: Nikita A. Safonov >Priority: Major > Labels: calcite3-required, documentation, ignite-3 > Fix For: 2.13 > > Time Spent: 7h 10m > Remaining Estimate: 0h > > We need to start documenting the new SQL engine. Let's start with Contents. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-13773) Ignite Docs: Port SQL Tooling from readme.io
[ https://issues.apache.org/jira/browse/IGNITE-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] YuJue Li resolved IGNITE-13773. --- Resolution: Not A Problem > Ignite Docs: Port SQL Tooling from readme.io > > > Key: IGNITE-13773 > URL: https://issues.apache.org/jira/browse/IGNITE-13773 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.9 >Reporter: YuJue Li >Priority: Major > Labels: new-docs > Fix For: 2.15 > > > The content in the link below is missing from the new version of the document: > [https://apacheignite-sql.readme.io/docs/sql-tooling] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-13773) Ignite Docs: Port SQL Tooling from readme.io
[ https://issues.apache.org/jira/browse/IGNITE-13773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602233#comment-17602233 ] YuJue Li commented on IGNITE-13773: --- Relevant pages have been ported. The part about Apache Zeppelin is in a separate ticket. > Ignite Docs: Port SQL Tooling from readme.io > > > Key: IGNITE-13773 > URL: https://issues.apache.org/jira/browse/IGNITE-13773 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.9 >Reporter: YuJue Li >Priority: Major > Labels: new-docs > Fix For: 2.15 > > > The content in the link below is missing from the new version of the document: > [https://apacheignite-sql.readme.io/docs/sql-tooling] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
