[jira] [Commented] (IGNITE-18083) .NET: Thin 3.0: LINQ: Groupings
[ https://issues.apache.org/jira/browse/IGNITE-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637050#comment-17637050 ] Pavel Tupitsyn commented on IGNITE-18083: - Merged to main: 24531434f0ad2f49e65ee2480bdcd6064b5dbda0 > .NET: Thin 3.0: LINQ: Groupings > --- > > Key: IGNITE-18083 > URL: https://issues.apache.org/jira/browse/IGNITE-18083 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Support queries with groupings in the LINQ provider. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18210) ODBC driver does not work with ADODB
[
https://issues.apache.org/jira/browse/IGNITE-18210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-18210:
Assignee: Igor Sapego
> ODBC driver does not work with ADODB
>
>
> Key: IGNITE-18210
> URL: https://issues.apache.org/jira/browse/IGNITE-18210
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.14
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: cpp, odbc
> Attachments: SQL_odbcadmin_cursorLocation_Client.LOG,
> SQL_odbcadmin_cursorLocation_Server.LOG,
> ignite_odbc_cursorLocation_Client.log, ignite_odbc_cusorLocation_Server.log
>
>
> Here is the code that reproduce problem:
> {code}
> Public Sub QueryIgnite()
> Dim ADOrs As ADODB.Recordset
> Dim ADOcon As ADODB.Connection
> Set ADOcon = New ADODB.Connection
> ADOcon.ConnectionString = "DSN=Apache-Ignite-DSN"
> 'ADOcon.CursorLocation = adUseClient
> ADOcon.Open
> Set ADOrs = New ADODB.Recordset
> ADOrs.Open "select * from city", ADOcon, adOpenForwardOnly
> ADOrs.MoveNext
> Debug.Print ADOrs.Fields("NAME")
> ADOrs.Close
> ADOcon.Close
> End Sub
> {code}
> Attached are the logs produced by the code.
> It seems like we do not support a bunch of connection and statement
> attributes used by ADO. Need to find out which of them are critical and
> implement them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18218) Cluster initialization should be covered in docs better
[ https://issues.apache.org/jira/browse/IGNITE-18218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Khitrin updated IGNITE-18218: Description: While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' service doesn't join any cluster after being installed and started. That may be fine from the DB's point of view, but this behavior may not obvious for a mere user. In order to make AI3 ready to work, user needs to run 'ignite3 cluster init ...' first. Unfortunately, this point is not currently covered properly neither in [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor in [existing docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide]. Command 'systemctl status ignite3db.service' says "active (running)", command 'ignite3 node status' shows "state: starting", DB log says "Components started, joining the cluster". Everything seem to work fine, but the next user's step is not obvious here. User may try to open SQL console but it will not work until cluster is initialized. I'm afraid a significant part of newcomers may be discouraged by this behavior. They could be a step close to the final line, but think "it doesn't work with no reason", and refuse to try AI3 anymore. To avoid this, some words about "cluster init" should be added to "Getting started guide" and, probably, to DEVNOTES. was: While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' service doesn't join any cluster after being installed and started. That may be fine from the DB's point of view, but this behavior may not obvious for a mere user. In order to make AI3 ready to work, user needs to run 'ignite3 cluster init ...' first. Unfortunately, this point is not currently covered properly neither in [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor in [existing docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide]. Command 'systemctl status ignite3db.service' says "active (running)", command 'ignite3 node status' shows "state: starting", DB log says "Components started, joining the cluster". Everything seem to work fine, but the next user's step is not obvious here. User may try to open SQL console but it will not work until cluster is initialized. I'm afraid a significant part of newcomers may be discouraged by this behavior. They could be a step close to the final line, but think "it doesn't work with no reason", and refuse to try AI3 anymore. To avoid this, some words about "cluster init" should be added to "Getting started guide" and, probably, to DEVNOTES. > Cluster initialization should be covered in docs better > --- > > Key: IGNITE-18218 > URL: https://issues.apache.org/jira/browse/IGNITE-18218 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.0-beta1 >Reporter: Andrey Khitrin >Priority: Major > Labels: ignite-3 > > While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' > service doesn't join any cluster after being installed and started. That may > be fine from the DB's point of view, but this behavior may not obvious for a > mere user. In order to make AI3 ready to work, user needs to run 'ignite3 > cluster init ...' first. Unfortunately, this point is not currently covered > properly neither in > [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor in > [existing > docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide]. > Command 'systemctl status ignite3db.service' says "active (running)", > command 'ignite3 node status' shows "state: starting", DB log says > "Components started, joining the cluster". Everything seem to work fine, but > the next user's step is not obvious here. User may try to open SQL console > but it will not work until cluster is initialized. > I'm afraid a significant part of newcomers may be discouraged by this > behavior. They could be a step close to the final line, but think "it doesn't > work with no reason", and refuse to try AI3 anymore. To avoid this, some > words about "cluster init" should be added to "Getting started guide" and, > probably, to DEVNOTES. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18218) Cluster initialization should be covered in docs better
Andrey Khitrin created IGNITE-18218: --- Summary: Cluster initialization should be covered in docs better Key: IGNITE-18218 URL: https://issues.apache.org/jira/browse/IGNITE-18218 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 3.0.0-beta1 Reporter: Andrey Khitrin While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' service doesn't join any cluster after being installed and started. That may be fine from the DB's point of view, but this behavior may not obvious for a mere user. In order to make AI3 ready to work, user needs to run 'ignite3 cluster init ...' first. Unfortunately, this point is not currently covered properly neither in [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor in [existing docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide]. Command 'systemctl status ignite3db.service' says "active (running)", command 'ignite3 node status' shows "state: starting", DB log says "Components started, joining the cluster". Everything seem to work fine, but the next user's step is not obvious here. User may try to open SQL console but it will not work until cluster is initialized. I'm afraid a significant part of newcomers may be discouraged by this behavior. They could be a step close to the final line, but think "it doesn't work with no reason", and refuse to try AI3 anymore. To avoid this, some words about "cluster init" should be added to "Getting started guide" and, probably, to DEVNOTES. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18083) .NET: Thin 3.0: LINQ: Groupings
[ https://issues.apache.org/jira/browse/IGNITE-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637028#comment-17637028 ] Igor Sapego commented on IGNITE-18083: -- [~ptupitsyn] Looks good to me. > .NET: Thin 3.0: LINQ: Groupings > --- > > Key: IGNITE-18083 > URL: https://issues.apache.org/jira/browse/IGNITE-18083 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Support queries with groupings in the LINQ provider. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18196) .NET: Thin 3.0: LINQ: Aggregates
[
https://issues.apache.org/jira/browse/IGNITE-18196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18196:
Description:
* Add support for Sum, Count, Min, Max, Average, Count, Any, All.
* Handle the case with SQL engine returning *long* instead of *int* for COUNT
and SUM, which causes an exception during materialization:
{code}
System.ArgumentException : Object of type 'System.Int64' cannot be converted to
type 'System.Int32'.
at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo
culture, Boolean needsSpecialCast)
at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo
culture, BindingFlags invokeAttr)
at System.Reflection.MethodBase.CheckArguments(StackAllocedArguments&
stackArgs, ReadOnlySpan`1 parameters, Binder binder, BindingFlags invokeAttr,
CultureInfo culture, Signature sig)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr,
Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
at
Apache.Ignite.Internal.Linq.IgniteQueryExecutor.<>c__DisplayClass9_0`1.b__0(IReadOnlyList`1
cols, BinaryTupleReader& reader) in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
146
at Apache.Ignite.Internal.Sql.ResultSet`1.ReadRow(IReadOnlyList`1 cols,
MessagePackReader& reader) in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
226
at
Apache.Ignite.Internal.Sql.ResultSet`1.<>c__DisplayClass29_0.d.MoveNext()
in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
269
at Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+MoveNext() in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
236
at
Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+System.Threading.Tasks.Sources.IValueTaskSource.GetResult()
at
Apache.Ignite.Internal.Linq.IgniteQueryExecutor.ExecuteCollection[T](QueryModel
queryModel)+MoveNext() in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
85
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Apache.Ignite.Tests.Linq.LinqTests.TestGroupByWithCountAndSum() in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/Linq/LinqTests.GroupBy.cs:line
57
{code}
Reproducer:
{code}
var query = PocoByteView.AsQueryable()
.GroupBy(x => x.Val)
.Select(x => new { x.Key, Count = (long)x.Count(), Sum = x.Sum(e =>
e.Key) })
.OrderBy(x => x.Key);
var res = query.ToList();
{code}
was:
SQL engine returns *long* instead of *int* for COUNT and SUM, which causes an
exception during materialization:
{code}
System.ArgumentException : Object of type 'System.Int64' cannot be converted to
type 'System.Int32'.
at System.RuntimeType.TryChangeType(Object value, Binder binder, CultureInfo
culture, Boolean needsSpecialCast)
at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo
culture, BindingFlags invokeAttr)
at System.Reflection.MethodBase.CheckArguments(StackAllocedArguments&
stackArgs, ReadOnlySpan`1 parameters, Binder binder, BindingFlags invokeAttr,
CultureInfo culture, Signature sig)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr,
Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
at
Apache.Ignite.Internal.Linq.IgniteQueryExecutor.<>c__DisplayClass9_0`1.b__0(IReadOnlyList`1
cols, BinaryTupleReader& reader) in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
146
at Apache.Ignite.Internal.Sql.ResultSet`1.ReadRow(IReadOnlyList`1 cols,
MessagePackReader& reader) in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
226
at
Apache.Ignite.Internal.Sql.ResultSet`1.<>c__DisplayClass29_0.d.MoveNext()
in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
269
at Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+MoveNext() in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
236
at
Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+System.Threading.Tasks.Sources.IValueTaskSource.GetResult()
at
Apache.Ignite.Internal.Linq.IgniteQueryExecutor.ExecuteCollection[T](QueryModel
queryModel)+MoveNext() in
/home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
85
at
[jira] [Updated] (IGNITE-18196) .NET: Thin 3.0: LINQ: Aggregates
[
https://issues.apache.org/jira/browse/IGNITE-18196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18196:
Issue Type: Improvement (was: Bug)
> .NET: Thin 3.0: LINQ: Aggregates
>
>
> Key: IGNITE-18196
> URL: https://issues.apache.org/jira/browse/IGNITE-18196
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, LINQ, ignite-3
> Fix For: 3.0.0-beta2
>
>
> SQL engine returns *long* instead of *int* for COUNT and SUM, which causes an
> exception during materialization:
> {code}
> System.ArgumentException : Object of type 'System.Int64' cannot be converted
> to type 'System.Int32'.
>at System.RuntimeType.TryChangeType(Object value, Binder binder,
> CultureInfo culture, Boolean needsSpecialCast)
>at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo
> culture, BindingFlags invokeAttr)
>at System.Reflection.MethodBase.CheckArguments(StackAllocedArguments&
> stackArgs, ReadOnlySpan`1 parameters, Binder binder, BindingFlags invokeAttr,
> CultureInfo culture, Signature sig)
>at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
>at
> Apache.Ignite.Internal.Linq.IgniteQueryExecutor.<>c__DisplayClass9_0`1.b__0(IReadOnlyList`1
> cols, BinaryTupleReader& reader) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
> 146
>at Apache.Ignite.Internal.Sql.ResultSet`1.ReadRow(IReadOnlyList`1 cols,
> MessagePackReader& reader) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 226
>at
> Apache.Ignite.Internal.Sql.ResultSet`1.<>c__DisplayClass29_0.d.MoveNext()
> in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 269
>at Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+MoveNext() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 236
>at
> Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+System.Threading.Tasks.Sources.IValueTaskSource.GetResult()
>at
> Apache.Ignite.Internal.Linq.IgniteQueryExecutor.ExecuteCollection[T](QueryModel
> queryModel)+MoveNext() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
> 85
>at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
>at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
>at Apache.Ignite.Tests.Linq.LinqTests.TestGroupByWithCountAndSum() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/Linq/LinqTests.GroupBy.cs:line
> 57
> {code}
> Reproducer:
> {code}
> var query = PocoByteView.AsQueryable()
> .GroupBy(x => x.Val)
> .Select(x => new { x.Key, Count = (long)x.Count(), Sum = x.Sum(e
> => e.Key) })
> .OrderBy(x => x.Key);
> var res = query.ToList();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18196) .NET: Thin 3.0: LINQ: Aggregates
[
https://issues.apache.org/jira/browse/IGNITE-18196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18196:
Summary: .NET: Thin 3.0: LINQ: Aggregates (was: .NET: Thin 3.0: LINQ: Sum
and Count fail with cast exception)
> .NET: Thin 3.0: LINQ: Aggregates
>
>
> Key: IGNITE-18196
> URL: https://issues.apache.org/jira/browse/IGNITE-18196
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, LINQ, ignite-3
> Fix For: 3.0.0-beta2
>
>
> SQL engine returns *long* instead of *int* for COUNT and SUM, which causes an
> exception during materialization:
> {code}
> System.ArgumentException : Object of type 'System.Int64' cannot be converted
> to type 'System.Int32'.
>at System.RuntimeType.TryChangeType(Object value, Binder binder,
> CultureInfo culture, Boolean needsSpecialCast)
>at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo
> culture, BindingFlags invokeAttr)
>at System.Reflection.MethodBase.CheckArguments(StackAllocedArguments&
> stackArgs, ReadOnlySpan`1 parameters, Binder binder, BindingFlags invokeAttr,
> CultureInfo culture, Signature sig)
>at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
>at
> Apache.Ignite.Internal.Linq.IgniteQueryExecutor.<>c__DisplayClass9_0`1.b__0(IReadOnlyList`1
> cols, BinaryTupleReader& reader) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
> 146
>at Apache.Ignite.Internal.Sql.ResultSet`1.ReadRow(IReadOnlyList`1 cols,
> MessagePackReader& reader) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 226
>at
> Apache.Ignite.Internal.Sql.ResultSet`1.<>c__DisplayClass29_0.d.MoveNext()
> in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 269
>at Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+MoveNext() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 236
>at
> Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+System.Threading.Tasks.Sources.IValueTaskSource.GetResult()
>at
> Apache.Ignite.Internal.Linq.IgniteQueryExecutor.ExecuteCollection[T](QueryModel
> queryModel)+MoveNext() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
> 85
>at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
>at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
>at Apache.Ignite.Tests.Linq.LinqTests.TestGroupByWithCountAndSum() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/Linq/LinqTests.GroupBy.cs:line
> 57
> {code}
> Reproducer:
> {code}
> var query = PocoByteView.AsQueryable()
> .GroupBy(x => x.Val)
> .Select(x => new { x.Key, Count = (long)x.Count(), Sum = x.Sum(e
> => e.Key) })
> .OrderBy(x => x.Key);
> var res = query.ToList();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18214) [IEP-80] Remove ThreadPool legacy JMX metrics bean
[ https://issues.apache.org/jira/browse/IGNITE-18214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637021#comment-17637021 ] Nikolay Izhikov commented on IGNITE-18214: -- Hello, [~mmuzaf] Can you, please, take a look at my changes? > [IEP-80] Remove ThreadPool legacy JMX metrics bean > -- > > Key: IGNITE-18214 > URL: https://issues.apache.org/jira/browse/IGNITE-18214 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Remove ThreadPool legacy JMX metrics bean > > org.apache.ignite.mxbean.ThreadPoolMXBean -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18217) [IEP-80] Enable JMX metrics exporter by default
Nikolay Izhikov created IGNITE-18217: Summary: [IEP-80] Enable JMX metrics exporter by default Key: IGNITE-18217 URL: https://issues.apache.org/jira/browse/IGNITE-18217 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov Enable JMX metrics exporter by default -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15367) Socket shutdown produce unnecessary output
[
https://issues.apache.org/jira/browse/IGNITE-15367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Pavlov updated IGNITE-15367:
---
Labels: ise (was: )
> Socket shutdown produce unnecessary output
> --
>
> Key: IGNITE-15367
> URL: https://issues.apache.org/jira/browse/IGNITE-15367
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10, 2.11
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Minor
> Labels: ise
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Socket shutdown and close operations produce unnecessary output when a socket
> is expected to be closed.
> {code}
> [2021-08-24 15:35:15,380][WARN
> ][grid-nio-worker-tcp-comm-1-#33%TestRecordingCommunicationSpi%][TestRecordingCommunicationSpi]
> Failed to shutdown socket: null
> java.nio.channels.ClosedChannelException
> at
> sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:794)
> at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:420)
> at
> org.apache.ignite.internal.util.IgniteUtils.close(IgniteUtils.java:4242)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.closeKey(GridNioServer.java:2784)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.close(GridNioServer.java:2835)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.close(GridNioServer.java:2794)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1357)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2508)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2273)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1910)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18196) .NET: Thin 3.0: LINQ: Sum and Count fail with cast exception
[
https://issues.apache.org/jira/browse/IGNITE-18196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18196:
Issue Type: Bug (was: Improvement)
> .NET: Thin 3.0: LINQ: Sum and Count fail with cast exception
>
>
> Key: IGNITE-18196
> URL: https://issues.apache.org/jira/browse/IGNITE-18196
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, LINQ, ignite-3
> Fix For: 3.0.0-beta2
>
>
> SQL engine returns *long* instead of *int* for COUNT and SUM, which causes an
> exception during materialization:
> {code}
> System.ArgumentException : Object of type 'System.Int64' cannot be converted
> to type 'System.Int32'.
>at System.RuntimeType.TryChangeType(Object value, Binder binder,
> CultureInfo culture, Boolean needsSpecialCast)
>at System.RuntimeType.CheckValue(Object value, Binder binder, CultureInfo
> culture, BindingFlags invokeAttr)
>at System.Reflection.MethodBase.CheckArguments(StackAllocedArguments&
> stackArgs, ReadOnlySpan`1 parameters, Binder binder, BindingFlags invokeAttr,
> CultureInfo culture, Signature sig)
>at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags
> invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
>at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
>at
> Apache.Ignite.Internal.Linq.IgniteQueryExecutor.<>c__DisplayClass9_0`1.b__0(IReadOnlyList`1
> cols, BinaryTupleReader& reader) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
> 146
>at Apache.Ignite.Internal.Sql.ResultSet`1.ReadRow(IReadOnlyList`1 cols,
> MessagePackReader& reader) in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 226
>at
> Apache.Ignite.Internal.Sql.ResultSet`1.<>c__DisplayClass29_0.d.MoveNext()
> in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 269
>at Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+MoveNext() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Sql/ResultSet.cs:line
> 236
>at
> Apache.Ignite.Internal.Sql.ResultSet`1.EnumerateRows()+System.Threading.Tasks.Sources.IValueTaskSource.GetResult()
>at
> Apache.Ignite.Internal.Linq.IgniteQueryExecutor.ExecuteCollection[T](QueryModel
> queryModel)+MoveNext() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite/Internal/Linq/IgniteQueryExecutor.cs:line
> 85
>at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
>at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
>at Apache.Ignite.Tests.Linq.LinqTests.TestGroupByWithCountAndSum() in
> /home/pavel/w/ignite-3/modules/platforms/dotnet/Apache.Ignite.Tests/Linq/LinqTests.GroupBy.cs:line
> 57
> {code}
> Reproducer:
> {code}
> var query = PocoByteView.AsQueryable()
> .GroupBy(x => x.Val)
> .Select(x => new { x.Key, Count = (long)x.Count(), Sum = x.Sum(e
> => e.Key) })
> .OrderBy(x => x.Key);
> var res = query.ToList();
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18216) Duplicated CDC test runs on TeamCity
[
https://issues.apache.org/jira/browse/IGNITE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18216:
---
Description:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[23:33:09] : [Step 3/3] [23:33:09] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:51:14] : [Step 3/3] [23:51:14] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[23:51:15] : [Step 3/3] [23:51:15] >>> Starting test class:
CdcKafkaReplicationTest <<<
[00:32:29] : [Step 3/3] [00:32:29] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
{color:#de350b}[01:14:03] : [Step 3/3] [01:14:03] >>> Starting test class:
ConflictResolverRestartTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
KafkaToIgniteLoaderTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<{color}
{color:#de350b}[01:14:04] >>> Starting test class: KafkaToIgniteLoaderTest
<<<{color}
{color:#de350b}[01:55:29] : [Step 3/3] [01:55:29] >>> Starting test class:
CdcKafkaReplicationTest <<<{color}
{quote}
It seems, that tests implicitly runs outside of the scope
{{{}IgniteCdcTestSuite{}}}. We should remove such duplication, because it
blocks testing of CDC extension. Moreover, we should check, that other
extensions are tested without such duplication.
Build logs:
# [^_TESTS_CDC_350.log.zip]
Links on corresponding TC build:
# [TC1 build
#350|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6922925?buildTab=overview=false=true=false=true=true]
# [TC2 build
#285|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6919480?expandBuildProblemsSection=true=false=true=false=true]
was:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3]
[jira] [Updated] (IGNITE-18216) Duplicated CDC test runs on TeamCity
[
https://issues.apache.org/jira/browse/IGNITE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18216:
---
Description:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[23:33:09] : [Step 3/3] [23:33:09] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:51:14] : [Step 3/3] [23:51:14] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[23:51:15] : [Step 3/3] [23:51:15] >>> Starting test class:
CdcKafkaReplicationTest <<<
[00:32:29] : [Step 3/3] [00:32:29] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
{color:#de350b}[01:14:03] : [Step 3/3] [01:14:03] >>> Starting test class:
ConflictResolverRestartTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
KafkaToIgniteLoaderTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<{color}
{color:#de350b}[01:14:04] >>> Starting test class: KafkaToIgniteLoaderTest
<<<{color}
{color:#de350b}[01:55:29] : [Step 3/3] [01:55:29] >>> Starting test class:
CdcKafkaReplicationTest <<<{color}
{quote}
It seems, that tests implicitly runs outside of the scope
{{{}IgniteCdcTestSuite{}}}. We should remove such duplication, because it
blocks testing of CDC extension. Moreover, we should check, that other
extensions are tested without such duplication.
Build logs:
# TC1: [^_TESTS_CDC_350.log.zip]
# TC2: [^_TESTS_CDC_285.log.zip]
Links on corresponding TC build:
# [TC1 build
#350|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6922925?buildTab=overview=false=true=false=true=true]
# [TC2 build
#285|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6919480?expandBuildProblemsSection=true=false=true=false=true]
was:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
[jira] [Updated] (IGNITE-18216) Duplicated CDC test runs on TeamCity
[
https://issues.apache.org/jira/browse/IGNITE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18216:
---
Description:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[23:33:09] : [Step 3/3] [23:33:09] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:51:14] : [Step 3/3] [23:51:14] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[23:51:15] : [Step 3/3] [23:51:15] >>> Starting test class:
CdcKafkaReplicationTest <<<
[00:32:29] : [Step 3/3] [00:32:29] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
{color:#de350b}[01:14:03] : [Step 3/3] [01:14:03] >>> Starting test class:
ConflictResolverRestartTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
KafkaToIgniteLoaderTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<{color}
{color:#de350b}[01:14:04] >>> Starting test class: KafkaToIgniteLoaderTest
<<<{color}
{color:#de350b}[01:55:29] : [Step 3/3] [01:55:29] >>> Starting test class:
CdcKafkaReplicationTest <<<{color}
{quote}
It seems, that tests implicitly runs outside of the scope
{{{}IgniteCdcTestSuite{}}}. We should remove such duplication, because it
blocks testing of CDC extension. Moreover, we should check, that other
extensions are tested without such duplication.
Build logs:
# [^_TESTS_CDC_350.log.zip]
# [^_TESTS_CDC_285.log.zip]
Links on corresponding TC build:
# [TC1 build
#350|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6922925?buildTab=overview=false=true=false=true=true]
# [TC2 build
#285|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6919480?expandBuildProblemsSection=true=false=true=false=true]
was:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[jira] [Updated] (IGNITE-18216) Duplicated CDC test runs on TeamCity
[
https://issues.apache.org/jira/browse/IGNITE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18216:
---
Description:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<{color}
{color:#de350b}[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<{color}
{quote}
*Duplication in TC2 build #285:*
{quote}[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[23:33:09] : [Step 3/3] [23:33:09] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:51:14] : [Step 3/3] [23:51:14] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[23:51:15] : [Step 3/3] [23:51:15] >>> Starting test class:
CdcKafkaReplicationTest <<<
[00:32:29] : [Step 3/3] [00:32:29] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
{color:#de350b}[01:14:03] : [Step 3/3] [01:14:03] >>> Starting test class:
ConflictResolverRestartTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
KafkaToIgniteLoaderTest <<<{color}
{color:#de350b}[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<{color}
{color:#de350b}[01:14:04] >>> Starting test class: KafkaToIgniteLoaderTest
<<<{color}
{color:#de350b}[01:55:29] : [Step 3/3] [01:55:29] >>> Starting test class:
CdcKafkaReplicationTest <<<{color}
{quote}
It seems, that tests implicitly runs outside of the scope
{{{}IgniteCdcTestSuite{}}}. We should remove such duplication, because it
blocks testing of CDC extension. Moreover, we should check, that other
extensions are tested without such duplication.
Links on corresponding TC build:
# [TC1 build
#350|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6922925?buildTab=overview=false=true=false=true=true]
# [TC2 build
#285|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6919480?expandBuildProblemsSection=true=false=true=false=true]
was:
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}
[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
*[01:22:21] :[Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<
[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<*
{quote}
*Duplication in TC2 build #285:*
{quote}
[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[jira] [Created] (IGNITE-18216) Duplicated CDC test runs
Ilya Shishkov created IGNITE-18216:
--
Summary: Duplicated CDC test runs
Key: IGNITE-18216
URL: https://issues.apache.org/jira/browse/IGNITE-18216
Project: Ignite
Issue Type: Bug
Components: extensions
Reporter: Ilya Shishkov
Attachments: _TESTS_CDC_285.log.zip, _TESTS_CDC_350.log.zip
As I see, now CDC Test Suite on both TC instances runs tests twice:
*Duplication in TC1 build #350:*
{quote}
[22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
CdcKafkaReplicationTest <<<
*[01:22:21] :[Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
CacheConflictOperationsTest <<<
[01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<*
{quote}
*Duplication in TC2 build #285:*
{quote}
[23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
ConflictResolverRestartTest <<<
[23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
CacheConflictOperationsTest <<<
[23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[23:33:09] : [Step 3/3] [23:33:09] >>> Starting test class:
CdcIgniteToIgniteReplicationTest <<<
[23:51:14] : [Step 3/3] [23:51:14] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[23:51:15] : [Step 3/3] [23:51:15] >>> Starting test class:
CdcKafkaReplicationTest <<<
[00:32:29] : [Step 3/3] [00:32:29] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
*[01:14:03] :[Step 3/3] [01:14:03] >>> Starting test class:
ConflictResolverRestartTest <<<
[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CacheConflictOperationsWithFieldTest <<<
[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
KafkaToIgniteLoaderTest <<<
[01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
CdcKafkaReplicationAppsTest <<<
[01:14:04] >>> Starting test class: KafkaToIgniteLoaderTest <<<
[01:55:29] : [Step 3/3] [01:55:29] >>> Starting test class:
CdcKafkaReplicationTest <<<*
{quote}
It seems, that tests implicitly runs outside of the scope
{{IgniteCdcTestSuite}}. We should remove such duplication, because it blocks
testing of CDC extension. Moreover, we should check, that other extensions are
tested without such duplication.
Links on corresponding TC build:
# [TC1 build
#350|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6922925?buildTab=overview=false=true=false=true=true]
# [TC2 build
#285|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6919480?expandBuildProblemsSection=true=false=true=false=true]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18216) Duplicated CDC test runs on TeamCity
[
https://issues.apache.org/jira/browse/IGNITE-18216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18216:
---
Summary: Duplicated CDC test runs on TeamCity (was: Duplicated CDC test
runs)
> Duplicated CDC test runs on TeamCity
>
>
> Key: IGNITE-18216
> URL: https://issues.apache.org/jira/browse/IGNITE-18216
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Major
> Labels: IEP-59, teamcity
> Attachments: _TESTS_CDC_285.log.zip, _TESTS_CDC_350.log.zip
>
>
> As I see, now CDC Test Suite on both TC instances runs tests twice:
> *Duplication in TC1 build #350:*
> {quote}
> [22:39:32] : [Step 3/3] [22:39:32] >>> Starting test class:
> CdcIgniteToIgniteReplicationTest <<<
> [23:00:48] : [Step 3/3] [23:00:48] >>> Starting test class:
> ConflictResolverRestartTest <<<
> [23:00:50] : [Step 3/3] [23:00:50] >>> Starting test class:
> CacheConflictOperationsTest <<<
> [23:00:51] : [Step 3/3] [23:00:51] >>> Starting test class:
> CdcKafkaReplicationAppsTest <<<
> [00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
> KafkaToIgniteLoaderTest <<<
> [00:13:57] : [Step 3/3] [00:13:57] >>> Starting test class:
> CdcKafkaReplicationTest <<<
> *[01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
> CacheConflictOperationsWithFieldTest <<<
> [01:22:21] : [Step 3/3] [01:22:21] >>> Starting test class:
> CacheConflictOperationsTest <<<
> [01:22:22] : [Step 3/3] [01:22:22] >>> Starting test class:
> CacheConflictOperationsWithFieldTest <<<
> [01:22:23] : [Step 3/3] [01:22:23] >>> Starting test class:
> CdcIgniteToIgniteReplicationTest <<<*
> {quote}
> *Duplication in TC2 build #285:*
> {quote}
> [23:14:52] : [Step 3/3] [23:14:52] >>> Starting test class:
> ConflictResolverRestartTest <<<
> [23:14:55] : [Step 3/3] [23:14:55] >>> Starting test class:
> CdcIgniteToIgniteReplicationTest <<<
> [23:33:07] : [Step 3/3] [23:33:07] >>> Starting test class:
> CacheConflictOperationsTest <<<
> [23:33:08] : [Step 3/3] [23:33:08] >>> Starting test class:
> CacheConflictOperationsWithFieldTest <<<
> [23:33:09] : [Step 3/3] [23:33:09] >>> Starting test class:
> CdcIgniteToIgniteReplicationTest <<<
> [23:51:14] : [Step 3/3] [23:51:14] >>> Starting test class:
> KafkaToIgniteLoaderTest <<<
> [23:51:15] : [Step 3/3] [23:51:15] >>> Starting test class:
> CdcKafkaReplicationTest <<<
> [00:32:29] : [Step 3/3] [00:32:29] >>> Starting test class:
> CdcKafkaReplicationAppsTest <<<
> *[01:14:03] : [Step 3/3] [01:14:03] >>> Starting test class:
> ConflictResolverRestartTest <<<
> [01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
> CacheConflictOperationsWithFieldTest <<<
> [01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
> KafkaToIgniteLoaderTest <<<
> [01:14:04] : [Step 3/3] [01:14:04] >>> Starting test class:
> CdcKafkaReplicationAppsTest <<<
> [01:14:04] >>> Starting test class: KafkaToIgniteLoaderTest <<<
> [01:55:29] : [Step 3/3] [01:55:29] >>> Starting test class:
> CdcKafkaReplicationTest <<<*
> {quote}
> It seems, that tests implicitly runs outside of the scope
> {{IgniteCdcTestSuite}}. We should remove such duplication, because it blocks
> testing of CDC extension. Moreover, we should check, that other extensions
> are tested without such duplication.
> Links on corresponding TC build:
> # [TC1 build
> #350|https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6922925?buildTab=overview=false=true=false=true=true]
> # [TC2 build
> #285|https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc/6919480?expandBuildProblemsSection=true=false=true=false=true]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last Kafka partition polling in this chain will happen at
least after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example
for default timeout and 16 Kafka partitions _last partition will be consumed
after 1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are blocked for Kafka partitions with unhandled update markers.
As I understand possible solutions are
* Hold information about replicated types or get it from {{BinaryContext}}.
Information about type can be sent with {{META_UPDATE_MARKER}}.
* Any other ways to sync appliers?
As a PoC of approach with {{BinaryContext}} I have prepared PR [2].
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
# https://github.com/apache/ignite-extensions/pull/187
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last Kafka partition polling in this chain will happen at
least after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example
for default timeout and 16 Kafka partitions _last partition will be consumed
after 1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are blocked for Kafka partitions with unhandled update markers.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> #
[jira] [Updated] (IGNITE-18215) .NET: Thin 3.0: LINQ: Group by calculated value
[ https://issues.apache.org/jira/browse/IGNITE-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18215: Description: Support calculated values in Group By clauses. Requires IGNITE-18212 to use aliases. was:Support calculated values in Group By clauses. > .NET: Thin 3.0: LINQ: Group by calculated value > --- > > Key: IGNITE-18215 > URL: https://issues.apache.org/jira/browse/IGNITE-18215 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Support calculated values in Group By clauses. > Requires IGNITE-18212 to use aliases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18215) .NET: Thin 3.0: LINQ: Group by calculated value
[ https://issues.apache.org/jira/browse/IGNITE-18215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18215: Description: Support calculated values in Group By clauses. (was: Support queries with groupings in the LINQ provider.) > .NET: Thin 3.0: LINQ: Group by calculated value > --- > > Key: IGNITE-18215 > URL: https://issues.apache.org/jira/browse/IGNITE-18215 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > > Support calculated values in Group By clauses. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18215) .NET: Thin 3.0: LINQ: Group by calculated value
Pavel Tupitsyn created IGNITE-18215: --- Summary: .NET: Thin 3.0: LINQ: Group by calculated value Key: IGNITE-18215 URL: https://issues.apache.org/jira/browse/IGNITE-18215 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Support queries with groupings in the LINQ provider. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18214) [IEP-80] Remove ThreadPool legacy JMX metrics bean
[ https://issues.apache.org/jira/browse/IGNITE-18214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-18214: Assignee: Nikolay Izhikov > [IEP-80] Remove ThreadPool legacy JMX metrics bean > -- > > Key: IGNITE-18214 > URL: https://issues.apache.org/jira/browse/IGNITE-18214 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Minor > > Remove ThreadPool legacy JMX metrics bean > > org.apache.ignite.mxbean.ThreadPoolMXBean -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18214) [IEP-80] Remove ThreadPool legacy JMX metrics bean
Nikolay Izhikov created IGNITE-18214: Summary: [IEP-80] Remove ThreadPool legacy JMX metrics bean Key: IGNITE-18214 URL: https://issues.apache.org/jira/browse/IGNITE-18214 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov Remove ThreadPool legacy JMX metrics bean org.apache.ignite.mxbean.ThreadPoolMXBean -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-13919) Calcite integration. Single group aggregates
[
https://issues.apache.org/jira/browse/IGNITE-13919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-13919:
--
Assignee: Aleksey Plekhanov
> Calcite integration. Single group aggregates
>
>
> Key: IGNITE-13919
> URL: https://issues.apache.org/jira/browse/IGNITE-13919
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Minor
> Labels: calcite2-required, calcite3-required
>
> Investigate the optimization for single group aggregates,
> e.g.: {{SELECT FROM }}
> Now the hash based aggregates are used for this case.
> We can obtain a little performance improvement.
> Also the special cases (e.g.: {{SELECT COUNT() FROM }})
> may be optimized to use table/cache size.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18213) Sql. Make exchange rewindable
Konstantin Orlov created IGNITE-18213: - Summary: Sql. Make exchange rewindable Key: IGNITE-18213 URL: https://issues.apache.org/jira/browse/IGNITE-18213 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov This causes the whole table being send over the network and being stored in the spool node. This could be improved by making the exchange operator rewindable. Need to introduce new type of message similar to InboxCloseMessage, but for 'rewind' operation. The message should contain list of correlated variables. Outbox, in turn, should accept this message, update correlation variables in the local context with the received one, and rewind the local execution tree. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18212) GROUP BY with alias causes column not found in any table error
[
https://issues.apache.org/jira/browse/IGNITE-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636768#comment-17636768
]
Konstantin Orlov commented on IGNITE-18212:
---
Support of aliases in GROUP BY clause can be enabled in parser's/validator's
configuration
{{org.apache.ignite.internal.sql.engine.sql.IgniteSqlConformance}}.
> GROUP BY with alias causes column not found in any table error
> --
>
> Key: IGNITE-18212
> URL: https://issues.apache.org/jira/browse/IGNITE-18212
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query*
> {code}
> select _T0.VAL as G0 from PUBLIC.TBL_INT8 as _T0 group by G0 order by (G0) asc
> {code}
> *Error*
> {code}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 59 to
> line 1, column 60: Column 'G0' not found in any table
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:273)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6511)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6740)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6685)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:324)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6500)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandGroupByOrHavingExpr(SqlValidatorImpl.java:6109)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:4327)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3701)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:207)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$1(PrepareServiceImpl.java:227)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Column 'G0'
> not found in any table
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
>
[jira] [Updated] (IGNITE-18212) GROUP BY with alias causes column not found in any table error
[
https://issues.apache.org/jira/browse/IGNITE-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18212:
Description:
*Query: *
{code}
select _T0.VAL as G0 from PUBLIC.TBL_INT8 as _T0 group by G0 order by (G0) asc
{code}
*Error:*
{code}
org.apache.calcite.runtime.CalciteContextException: From line 1, column 59 to
line 1, column 60: Column 'G0' not found in any table
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
at
org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:273)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6511)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6740)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6685)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:324)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6500)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandGroupByOrHavingExpr(SqlValidatorImpl.java:6109)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:4327)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3701)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:207)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$1(PrepareServiceImpl.java:227)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Column 'G0'
not found in any table
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
{code}
> GROUP BY with alias causes column not found in any table error
> --
>
> Key: IGNITE-18212
> URL: https://issues.apache.org/jira/browse/IGNITE-18212
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query: *
> {code}
> select _T0.VAL as G0 from PUBLIC.TBL_INT8 as _T0 group by G0 order by (G0) asc
> {code}
> *Error:*
> {code}
>
[jira] [Updated] (IGNITE-18212) GROUP BY with alias causes column not found in any table error
[
https://issues.apache.org/jira/browse/IGNITE-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18212:
Issue Type: Bug (was: Improvement)
> GROUP BY with alias causes column not found in any table error
> --
>
> Key: IGNITE-18212
> URL: https://issues.apache.org/jira/browse/IGNITE-18212
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Query*
> {code}
> select _T0.VAL as G0 from PUBLIC.TBL_INT8 as _T0 group by G0 order by (G0) asc
> {code}
> *Error*
> {code}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 59 to
> line 1, column 60: Column 'G0' not found in any table
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
> at
> org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:273)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6511)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6740)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6685)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:324)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6500)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandGroupByOrHavingExpr(SqlValidatorImpl.java:6109)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:4327)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3701)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:207)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
> at
> org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
> at
> org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$1(PrepareServiceImpl.java:227)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Column 'G0'
> not found in any table
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
> at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18212) GROUP BY with alias causes column not found in any table error
[
https://issues.apache.org/jira/browse/IGNITE-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-18212:
Description:
*Query*
{code}
select _T0.VAL as G0 from PUBLIC.TBL_INT8 as _T0 group by G0 order by (G0) asc
{code}
*Error*
{code}
org.apache.calcite.runtime.CalciteContextException: From line 1, column 59 to
line 1, column 60: Column 'G0' not found in any table
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:5362)
at
org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:273)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:6511)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6740)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$ExtendedExpander.visit(SqlValidatorImpl.java:6685)
at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:324)
at
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.go(SqlValidatorImpl.java:6500)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.expandGroupByOrHavingExpr(SqlValidatorImpl.java:6109)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateGroupClause(SqlValidatorImpl.java:4327)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3701)
at
org.apache.ignite.internal.sql.engine.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:207)
at
org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:64)
at
org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:89)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1107)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:1078)
at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:248)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:1053)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:759)
at
org.apache.ignite.internal.sql.engine.prepare.IgnitePlanner.validateAndGetTypeMetadata(IgnitePlanner.java:210)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.lambda$prepareQuery$1(PrepareServiceImpl.java:227)
at
java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Column 'G0'
not found in any table
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
at
org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
{code}
was:
*Query: *
{code}
select _T0.VAL as G0 from PUBLIC.TBL_INT8 as _T0 group by G0 order by (G0) asc
{code}
*Error:*
{code}
org.apache.calcite.runtime.CalciteContextException: From line 1, column 59 to
line 1, column 60: Column 'G0' not found in any table
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
[jira] [Updated] (IGNITE-18212) GROUP BY with alias causes column not found in any table error
[ https://issues.apache.org/jira/browse/IGNITE-18212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18212: Fix Version/s: 3.0.0-beta2 > GROUP BY with alias causes column not found in any table error > -- > > Key: IGNITE-18212 > URL: https://issues.apache.org/jira/browse/IGNITE-18212 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18212) GROUP BY with alias causes column not found in any table error
Pavel Tupitsyn created IGNITE-18212: --- Summary: GROUP BY with alias causes column not found in any table error Key: IGNITE-18212 URL: https://issues.apache.org/jira/browse/IGNITE-18212 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}, which returns immediately [1] when data is present in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last Kafka partition polling in this chain will happen at
least after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example
for default timeout and 16 Kafka partitions _last partition will be consumed
after 1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are blocked for Kafka partitions with unhandled update markers.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last Kafka partition polling in this chain will happen at
least after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example
for default timeout and 16 Kafka partitions _last partition will be consumed
after 1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are blocked for Kafka partitions with unhandled update markers.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event
> topic: firstly, in case of type mappings updates,
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last Kafka partition polling in this chain will happen at
least after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example
for default timeout and 16 Kafka partitions _last partition will be consumed
after 1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are blocked for Kafka partitions with unhandled update markers.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen at least
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example for
default timeout and 16 partitions _last partition will be consumed after 1.5
minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are in fact blocked for partitions with unhandled update markers.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each Kafka partition of event
> topic: firstly, in case of type mappings updates,
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen at least
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example for
default timeout and 16 partitions _last partition will be consumed after 1.5
minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
# Data updates are in fact blocked for partitions with unhandled update markers.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen at least
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example for
default timeout and 16 partitions _last partition will be consumed after 1.5
minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen at least
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}} period. For example for
default timeout and 16 partitions _last partition will be consumed after 1.5
minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen after
{{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen after
{{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
Links:
#
https://kafka.apache.org/27/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html#poll-java.time.Duration-
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen after
{{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata
[jira] [Updated] (IGNITE-18211) Sql. Adjust Affinity distribution to the new colocation rules
[
https://issues.apache.org/jira/browse/IGNITE-18211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18211:
--
Ignite Flags: (was: Release Notes Required)
> Sql. Adjust Affinity distribution to the new colocation rules
> -
>
> Key: IGNITE-18211
> URL: https://issues.apache.org/jira/browse/IGNITE-18211
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Need to adjust affinity function to be prepared to upcoming concept of
> [Distribution Zones|https://issues.apache.org/jira/browse/IGNITE-17924].
> Following changes are required:
> * AffinityFunction has to be updated with id (name) of the distribution zone
> * (De-)Serialization of the DistributionFunction need to be adjusted as well
> * Integration with table
> Besides, it looks like the following condition is no more valid, thus should
> be removed:
> {code:java}
> //
> org.apache.ignite.internal.sql.engine.trait.TraitUtils#convertDistribution
> if (toTrait.function().affinity() && toTrait.getKeys().size() > 1) {
> return null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18211) Sql. Adjust Affinity distribution to the new colocation rules
Konstantin Orlov created IGNITE-18211:
-
Summary: Sql. Adjust Affinity distribution to the new colocation
rules
Key: IGNITE-18211
URL: https://issues.apache.org/jira/browse/IGNITE-18211
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Konstantin Orlov
Need to adjust affinity function to be prepared to upcoming concept of
[Distribution Zones|https://issues.apache.org/jira/browse/IGNITE-17924].
Following changes are required:
* AffinityFunction has to be updated with id (name) of the distribution zone
* (De-)Serialization of the DistributionFunction need to be adjusted as well
* Integration with table
Besides, it looks like the following condition is no more valid, thus should be
removed:
{code:java}
//
org.apache.ignite.internal.sql.engine.trait.TraitUtils#convertDistribution
if (toTrait.function().affinity() && toTrait.getKeys().size() > 1) {
return null;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18211) Sql. Adjust Affinity distribution to the new colocation rules
[
https://issues.apache.org/jira/browse/IGNITE-18211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18211:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Sql. Adjust Affinity distribution to the new colocation rules
> -
>
> Key: IGNITE-18211
> URL: https://issues.apache.org/jira/browse/IGNITE-18211
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> Need to adjust affinity function to be prepared to upcoming concept of
> [Distribution Zones|https://issues.apache.org/jira/browse/IGNITE-17924].
> Following changes are required:
> * AffinityFunction has to be updated with id (name) of the distribution zone
> * (De-)Serialization of the DistributionFunction need to be adjusted as well
> * Integration with table
> Besides, it looks like the following condition is no more valid, thus should
> be removed:
> {code:java}
> //
> org.apache.ignite.internal.sql.engine.trait.TraitUtils#convertDistribution
> if (toTrait.function().affinity() && toTrait.getKeys().size() > 1) {
> return null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen after
{{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_.
# Amount of threads in {{KafkaToIgniteCdcStreamer}} does not make sence.
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen after
{{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
[jira] [Updated] (IGNITE-18191) .NET: Add specific Java launch arguments for Java 15+
[ https://issues.apache.org/jira/browse/IGNITE-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18191: Release Note: .NET: Fixed startup on Java 15+. > .NET: Add specific Java launch arguments for Java 15+ > - > > Key: IGNITE-18191 > URL: https://issues.apache.org/jira/browse/IGNITE-18191 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Andrey Khitrin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > Looks like .Net platform and examples do not support recent versions of Java. > It requires a special set of JVM arguments to run AI on Java 15+ (see > [jvmdefaults.sh|https://github.com/apache/ignite/blob/master/bin/include/jvmdefaults.sh]), > but .Net runner only contains checks and arguments for Java 9+ (see > [Jmv.cs|https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/Jni/Jvm.cs]). > Looks like new arguments should be added here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. last partition polling in this chain will happen after
{{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
> # All other threads of all
[jira] [Updated] (IGNITE-18191) .NET: Add specific Java launch arguments for Java 15+
[ https://issues.apache.org/jira/browse/IGNITE-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-18191: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > .NET: Add specific Java launch arguments for Java 15+ > - > > Key: IGNITE-18191 > URL: https://issues.apache.org/jira/browse/IGNITE-18191 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Andrey Khitrin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > Looks like .Net platform and examples do not support recent versions of Java. > It requires a special set of JVM arguments to run AI on Java 15+ (see > [jvmdefaults.sh|https://github.com/apache/ignite/blob/master/bin/include/jvmdefaults.sh]), > but .Net runner only contains checks and arguments for Java 9+ (see > [Jmv.cs|https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/Jni/Jvm.cs]). > Looks like new arguments should be added here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining appliers threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
> # All other threads of all
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will remain blocked
until new data becomes available or request timeout occurs [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will be blocked until
new data will become available or request timeout will occur [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
> # All other threads of
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} from empty metadata topic, which will be blocked until
new data will become available or request timeout will occur [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
was:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} for empty metadata topic, which will be blocked until
new data will become available or request timeout will occur [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
> # All other threads
[jira] [Commented] (IGNITE-17708) Add specific java launch arguments for Java15+ in Ignition.cpp
[ https://issues.apache.org/jira/browse/IGNITE-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636739#comment-17636739 ] Pavel Tupitsyn commented on IGNITE-17708: - [~isapego] looks good to me. > Add specific java launch arguments for Java15+ in Ignition.cpp > -- > > Key: IGNITE-17708 > URL: https://issues.apache.org/jira/browse/IGNITE-17708 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Roman Puchkovskiy >Assignee: Igor Sapego >Priority: Major > Fix For: 2.15 > > Time Spent: 20m > Remaining Estimate: 0h > > In a few places (like FeatureChecker), we have same logic of adding specific > java command line keys (like add-opens). In all cases, keys for Java 15+ is > different from keys for Java 9-14. But in Ignition.cpp, only Java 9+ is > handled. Probably, handling for Java 15+ should be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Currently, there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} for empty metadata topic, which will be blocked until
new data will become available or request timeout will occur [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
was:
Now there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} for empty metadata topic, which will be blocked until
new data will become available or request timeout will occur [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Currently, there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
> # All other threads of all
[jira] [Updated] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
[
https://issues.apache.org/jira/browse/IGNITE-18209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18209:
---
Description:
Now there is a bottleneck in synchronized method
{{KafkaToIgniteMetadataUpdater#updateMetadata}}:
# {{KafkaToIgniteCdcStreamer}} contains multiple
{{KafkaToIgniteCdcStreamerApplier}} which shares _single_
{{KafkaToIgniteMetadataUpdater}}.
# All appliers handle corrsponding partitions consequently.
# {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
firstly, in case of type mappings updates, secondly, in case of binary types
update.
# When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
{{KafkaConsumer#poll}}.
# {{KafkaConsumer#poll}} returns immediately [1] when there are data in
metadata topic. If there are few binary types and mappings to update, some
{{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
metadata topic.
# All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
{{KafkaConsumer#poll}} for empty metadata topic, which will be blocked until
new data will become available or request timeout will occur [1].
# Because of {{synchronized}} access to
{{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
{{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
will block remaining applier threads for {{kafkaReqTimeout}} period (if
metadata topic remains empty).
# The last call, i.e. part last partition update in this chain will happen
after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for default
timeout and 16 partitions _last partition will be consumed after approximately
1.5 minutes_. Amount of thread does not make sence.
> Reduce binary metadata synchronization time for CDC through Kafka
> -
>
> Key: IGNITE-18209
> URL: https://issues.apache.org/jira/browse/IGNITE-18209
> Project: Ignite
> Issue Type: Improvement
> Components: extensions
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
>
> Now there is a bottleneck in synchronized method
> {{KafkaToIgniteMetadataUpdater#updateMetadata}}:
> # {{KafkaToIgniteCdcStreamer}} contains multiple
> {{KafkaToIgniteCdcStreamerApplier}} which shares _single_
> {{KafkaToIgniteMetadataUpdater}}.
> # All appliers handle corrsponding partitions consequently.
> # {{META_UPDATE_MARKER}} is sent twice to each partition of event topic:
> firstly, in case of type mappings updates, secondly, in case of binary types
> update.
> # When first {{KafkaToIgniteCdcStreamerApplier}} meets {{META_UPDATE_MARKER}}
> it calls {{KafkaToIgniteMetadataUpdater#updateMetadata}} which in turn calls
> {{KafkaConsumer#poll}}.
> # {{KafkaConsumer#poll}} returns immediately [1] when there are data in
> metadata topic. If there are few binary types and mappings to update, some
> {{KafkaToIgniteCdcStreamerApplier}} thread will consume all entries from
> metadata topic.
> # All other threads of all {{KafkaToIgniteCdcStreamerApplier}} will call
> {{KafkaConsumer#poll}} for empty metadata topic, which will be blocked until
> new data will become available or request timeout will occur [1].
> # Because of {{synchronized}} access to
> {{KafkaToIgniteMetadataUpdater#updateMetadata}} all threads of all
> {{KafkaToIgniteCdcStreamerApplier}} will form a sequence of calls. Each call
> will block remaining applier threads for {{kafkaReqTimeout}} period (if
> metadata topic remains empty).
> # The last call, i.e. part last partition update in this chain will happen
> after {{(partitionsCount x 2 - 1) x kafkaReqTimeout}}. For example for
> default timeout and 16 partitions _last partition will be consumed after
> approximately 1.5 minutes_. Amount of thread does not make sence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18156) Sql. Extend SQL grammar with CREATE/DROP ZONE statement
[
https://issues.apache.org/jira/browse/IGNITE-18156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-18156:
-
Assignee: Pavel Pereslegin
> Sql. Extend SQL grammar with CREATE/DROP ZONE statement
> ---
>
> Key: IGNITE-18156
> URL: https://issues.apache.org/jira/browse/IGNITE-18156
> Project: Ignite
> Issue Type: Sub-task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to provide an ability to configure distribution zones by DDL
> commands.
> Let's extend SQL grammar with following syntax:
> {code:java}
> CREATE ZONE
> { fq_zone_name | simple_zone_name }
> [WITH
> [
> |
> DATA_NODES_FILTER filter |
> (, DATA_NODES_FILTER filter)
> ],
> [PARTITIONS = partitions],
> [REPLICAS = replicas],
> [AFFINITY_FUNCTION = function]
> ]
> [;]
>
> ::= [
> DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value |
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value |
> (DATA_NODES_AUTO_ADJUST_SCALE_UP = scale_up_value &
> DATA_NODES_AUTO_ADJUST_SCALE_DOWN = scale_down_value) |
> DATA_NODES_AUTO_ADJUST = auto_adjust_value
> ]{code}
> {code:java}
> DROP ZONE {fq_zone_name | simple_zone_name}{code}
> As a result the parser should be able to parse mentioned statements and
> provide a valid AST representing those statements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17708) Add specific java launch arguments for Java15+ in Ignition.cpp
[
https://issues.apache.org/jira/browse/IGNITE-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636722#comment-17636722
]
Ignite TC Bot commented on IGNITE-17708:
{panel:title=Branch: [pull/10388/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ CMake (Win x64 / Debug){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6922567]]
* IgniteThinClientTest: SslTestSuite: SslConnectionErrorNonExistingKey -
History for base branch is absent.
{panel}
{panel:title=Branch: [pull/10388/head] Base: [master] : New Tests
(1064)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
1064|https://ci.ignite.apache.org/viewLog.html?buildId=6922567]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 1053 new tests
{panel}
[TeamCity *- Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6922571buildTypeId=IgniteTests24Java8_RunCpp]
> Add specific java launch arguments for Java15+ in Ignition.cpp
> --
>
> Key: IGNITE-17708
> URL: https://issues.apache.org/jira/browse/IGNITE-17708
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Roman Puchkovskiy
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In a few places (like FeatureChecker), we have same logic of adding specific
> java command line keys (like add-opens). In all cases, keys for Java 15+ is
> different from keys for Java 9-14. But in Ignition.cpp, only Java 9+ is
> handled. Probably, handling for Java 15+ should be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18155) Update changePeersAsync method to support learners configuration
[
https://issues.apache.org/jira/browse/IGNITE-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-18155:
-
Fix Version/s: 3.0.0-beta2
> Update changePeersAsync method to support learners configuration
>
>
> Key: IGNITE-18155
> URL: https://issues.apache.org/jira/browse/IGNITE-18155
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Update {{RaftGroupService#changePeersAsync}} method to support changing
> learners configuration. It should work the same way, we simply need to update
> internal Raft configuration for learners as well as for peers. The new
> signature will look like the following:
> {code:java}
> /**
> * @param peers New peers.
> * @param learners New leaners.
> * @param term Current known leader term.
> * If real raft group term will be different - changePeers will
> be skipped.
> * @return A future.
> */
> CompletableFuture changePeersAsync(List peers, List
> learners, long term);
> {code}
> This also implies changing the signature of
> {{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
> {code:java}
> /**
> * Invoked on the leader, when new peers' configuration applied to raft group.
> *
> * @param peers list of peers, which was applied by raft group membership
> configuration.
> * @param learners list of learners, which was applied by raft group
> membership configuration.
> */
> void onNewPeersConfigurationApplied(List peers, List
> learners);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18210) ODBC driver does not work with ADODB
[
https://issues.apache.org/jira/browse/IGNITE-18210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-18210:
-
Attachment: SQL_odbcadmin_cursorLocation_Server.LOG
SQL_odbcadmin_cursorLocation_Client.LOG
ignite_odbc_cusorLocation_Server.log
ignite_odbc_cursorLocation_Client.log
> ODBC driver does not work with ADODB
>
>
> Key: IGNITE-18210
> URL: https://issues.apache.org/jira/browse/IGNITE-18210
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.14
>Reporter: Igor Sapego
>Priority: Major
> Labels: cpp, odbc
> Attachments: SQL_odbcadmin_cursorLocation_Client.LOG,
> SQL_odbcadmin_cursorLocation_Server.LOG,
> ignite_odbc_cursorLocation_Client.log, ignite_odbc_cusorLocation_Server.log
>
>
> Here is the code that reproduce problem:
> {code}
> Public Sub QueryIgnite()
> Dim ADOrs As ADODB.Recordset
> Dim ADOcon As ADODB.Connection
> Set ADOcon = New ADODB.Connection
> ADOcon.ConnectionString = "DSN=Apache-Ignite-DSN"
> 'ADOcon.CursorLocation = adUseClient
> ADOcon.Open
> Set ADOrs = New ADODB.Recordset
> ADOrs.Open "select * from city", ADOcon, adOpenForwardOnly
> ADOrs.MoveNext
> Debug.Print ADOrs.Fields("NAME")
> ADOrs.Close
> ADOcon.Close
> End Sub
> {code}
> Attached are the logs produced by the code.
> It seems like we do not support a bunch of connection and statement
> attributes used by ADO. Need to find out which of them are critical and
> implement them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18210) ODBC driver does not work with ADODB
Igor Sapego created IGNITE-18210:
Summary: ODBC driver does not work with ADODB
Key: IGNITE-18210
URL: https://issues.apache.org/jira/browse/IGNITE-18210
Project: Ignite
Issue Type: Bug
Components: odbc
Affects Versions: 2.14
Reporter: Igor Sapego
Attachments: SQL_odbcadmin_cursorLocation_Client.LOG,
SQL_odbcadmin_cursorLocation_Server.LOG, ignite_odbc_cursorLocation_Client.log,
ignite_odbc_cusorLocation_Server.log
Here is the code that reproduce problem:
{code}
Public Sub QueryIgnite()
Dim ADOrs As ADODB.Recordset
Dim ADOcon As ADODB.Connection
Set ADOcon = New ADODB.Connection
ADOcon.ConnectionString = "DSN=Apache-Ignite-DSN"
'ADOcon.CursorLocation = adUseClient
ADOcon.Open
Set ADOrs = New ADODB.Recordset
ADOrs.Open "select * from city", ADOcon, adOpenForwardOnly
ADOrs.MoveNext
Debug.Print ADOrs.Fields("NAME")
ADOrs.Close
ADOcon.Close
End Sub
{code}
Attached are the logs produced by the code.
It seems like we do not support a bunch of connection and statement attributes
used by ADO. Need to find out which of them are critical and implement them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18155) Update changePeersAsync method to support learners configuration
[
https://issues.apache.org/jira/browse/IGNITE-18155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636703#comment-17636703
]
Kirill Gusakov commented on IGNITE-18155:
-
LGTM, thanks!
> Update changePeersAsync method to support learners configuration
>
>
> Key: IGNITE-18155
> URL: https://issues.apache.org/jira/browse/IGNITE-18155
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Update {{RaftGroupService#changePeersAsync}} method to support changing
> learners configuration. It should work the same way, we simply need to update
> internal Raft configuration for learners as well as for peers. The new
> signature will look like the following:
> {code:java}
> /**
> * @param peers New peers.
> * @param learners New leaners.
> * @param term Current known leader term.
> * If real raft group term will be different - changePeers will
> be skipped.
> * @return A future.
> */
> CompletableFuture changePeersAsync(List peers, List
> learners, long term);
> {code}
> This also implies changing the signature of
> {{RaftGroupEventsListener#onNewPeersConfigurationApplied}}:
> {code:java}
> /**
> * Invoked on the leader, when new peers' configuration applied to raft group.
> *
> * @param peers list of peers, which was applied by raft group membership
> configuration.
> * @param learners list of learners, which was applied by raft group
> membership configuration.
> */
> void onNewPeersConfigurationApplied(List peers, List
> learners);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18191) .NET: Add specific Java launch arguments for Java 15+
[ https://issues.apache.org/jira/browse/IGNITE-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636691#comment-17636691 ] Pavel Tupitsyn commented on IGNITE-18191: - Merged to master: 3fda745063ce2a0c969147aadb88a6025c4ce0bc > .NET: Add specific Java launch arguments for Java 15+ > - > > Key: IGNITE-18191 > URL: https://issues.apache.org/jira/browse/IGNITE-18191 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Andrey Khitrin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 40m > Remaining Estimate: 0h > > Looks like .Net platform and examples do not support recent versions of Java. > It requires a special set of JVM arguments to run AI on Java 15+ (see > [jvmdefaults.sh|https://github.com/apache/ignite/blob/master/bin/include/jvmdefaults.sh]), > but .Net runner only contains checks and arguments for Java 9+ (see > [Jmv.cs|https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/Jni/Jvm.cs]). > Looks like new arguments should be added here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18209) Reduce binary metadata synchronization time for CDC through Kafka
Ilya Shishkov created IGNITE-18209: -- Summary: Reduce binary metadata synchronization time for CDC through Kafka Key: IGNITE-18209 URL: https://issues.apache.org/jira/browse/IGNITE-18209 Project: Ignite Issue Type: Improvement Components: extensions Reporter: Ilya Shishkov -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18179) KafkaPoducer and KafkaConsumer classes missed in ignite-cdc-ext build
[
https://issues.apache.org/jira/browse/IGNITE-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-18179:
---
Labels: IEP-59 ise (was: ise)
> KafkaPoducer and KafkaConsumer classes missed in ignite-cdc-ext build
> -
>
> Key: IGNITE-18179
> URL: https://issues.apache.org/jira/browse/IGNITE-18179
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: IEP-59, ise
> Attachments: cdc-ext-build-patch.patch, ignite-cdc-ext-current.txt,
> ignite-cdc-ext-old.txt, ignite-cdc-ext-patch.txt
>
>
> CDC though Kafka uses {{KafkaConsumer}} and {{KafkaProducer}}, which are
> parts of {{kafka-clients}} module.
> But when you build ignite-cdc-ext with a below command:
> {code}
> mvn clean package -f modules/cdc-ext/ -P checkstyle,extension-release
> -DskipTests
> {code}
> you will obtain zip file with a structure [^ignite-cdc-ext-current.txt],
> where {{kafka-clients}} dependency _*is missing*_.
> So, when you try to start {{KafkaToIgniteCdcStreamer}} or
> {{IgniteToKafkaCdcStreamer}} you will obtain missing classes error.
> Building of module changed after IGNITE-16847, IGNITE-16815. Structure was:
> [^ignite-cdc-ext-old.txt]. As you can see, there was many jar libraries
> included, but i'm not sure whether all of them needed to run CDC.
> I have prepared a patch [^cdc-ext-build-patch.patch], which replaces
> _kafka_2.12-2.7.0.jar_ by _kafka-clients-2.7.0.jar_ and tested it locally:
> problems with missed classes eliminated and it seems, that simple
> active-active replication cases works fine. But, patch does not fix other
> dependencies from old build assembly structure (I'm not sure, that all
> dependencies satisfied).
> Structure after patch: [^ignite-cdc-ext-patch.txt]
> Also, proposed patch affects other modules, which uses
> {{/assembly/bin-component-shared.xml}} in build process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18191) .NET: Add specific Java launch arguments for Java 15+
[ https://issues.apache.org/jira/browse/IGNITE-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636688#comment-17636688 ] Igor Sapego commented on IGNITE-18191: -- [~ptupitsyn] looks good to me, added only one question. > .NET: Add specific Java launch arguments for Java 15+ > - > > Key: IGNITE-18191 > URL: https://issues.apache.org/jira/browse/IGNITE-18191 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Andrey Khitrin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.15 > > Time Spent: 10m > Remaining Estimate: 0h > > Looks like .Net platform and examples do not support recent versions of Java. > It requires a special set of JVM arguments to run AI on Java 15+ (see > [jvmdefaults.sh|https://github.com/apache/ignite/blob/master/bin/include/jvmdefaults.sh]), > but .Net runner only contains checks and arguments for Java 9+ (see > [Jmv.cs|https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/Jni/Jvm.cs]). > Looks like new arguments should be added here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18191) .NET: Add specific Java launch arguments for Java 15+
[
https://issues.apache.org/jira/browse/IGNITE-18191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636680#comment-17636680
]
Ignite TC Bot commented on IGNITE-18191:
{panel:title=Branch: [pull/10387/head] Base: [master] : Possible Blockers
(7)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code , Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=6922365]]
{color:#d04437}SPI (Discovery){color} [[tests 0 TIMEOUT , Exit Code , Failure
on metric |https://ci.ignite.apache.org/viewLog.html?buildId=6922445]]
{color:#d04437}Queries 1 (lazy=true){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6922431]]
* IgniteBinaryCacheQueryLazyTestSuite:
DynamicIndexServerCoordinatorBasicSelfTest.testCreateReplicatedAtomic - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 1{color} [[tests 1 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=6922356]]
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceSelfTest.testReplicatedIsolated - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Client Nodes{color} [[tests 1 TIMEOUT , Exit Code , Failure on
metric |https://ci.ignite.apache.org/viewLog.html?buildId=6922384]]
* IgniteClientReconnectTestSuite:
IgniteClientReconnectAtomicsWithLostPartitionsTest.testAtomicSequenceGetAndIncrement
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10387/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=6922461buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Add specific Java launch arguments for Java 15+
> -
>
> Key: IGNITE-18191
> URL: https://issues.apache.org/jira/browse/IGNITE-18191
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Andrey Khitrin
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.15
>
>
> Looks like .Net platform and examples do not support recent versions of Java.
> It requires a special set of JVM arguments to run AI on Java 15+ (see
> [jvmdefaults.sh|https://github.com/apache/ignite/blob/master/bin/include/jvmdefaults.sh]),
> but .Net runner only contains checks and arguments for Java 9+ (see
> [Jmv.cs|https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/Jni/Jvm.cs]).
> Looks like new arguments should be added here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18085) Implement logical topology events subscription and notification
[ https://issues.apache.org/jira/browse/IGNITE-18085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-18085: -- Assignee: Roman Puchkovskiy > Implement logical topology events subscription and notification > --- > > Key: IGNITE-18085 > URL: https://issues.apache.org/jira/browse/IGNITE-18085 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Roman Puchkovskiy >Priority: Major > > h3. Motivation > There are two types of typologies in Apache Ignite 3 > * Physical(Network) - nodes that are visible through network layer. > * Logical - nodes that successfully passed the join procedure including > local recovery and catch up phases, thus nodes that are ready to handle user > load. More details in IEP-77 > In order to recalculate data nodes for specific distribution zone (see > [IEP-97|https://cwiki.apache.org/confluence/display/IGNITE/IEP-97%3A+Distribution+Zones]) > it's required for distribution zone manager to receive notifications about > logical topology updates along with logical topology version similar to ones > we have in network topology: > * onAppeared > * onDisappeared > h3. Definition of Done > * It's possible to register listeners for logical topology > onAppeared/onDisappeared events > * Events are fired in a distributed manner to all recipients. > * Each event produces ClusterNode.consistentId that was either added or > removed and *logical topology version.* It's required to solve ABA problem on > topology events, see https://issues.apache.org/jira/browse/IGNITE-18087 for > more details. > * Events are ordered within each Producer to Recipient communication channel. > * It's valid to have multiple producers, e.g. during CMG leader change, thus > it's valid to send same set of event twice but order still matters. > * It's not valid to skip events, even in case of of CMG leader change. > * Delivery guarantee is required. > * Besides events, there should be a method to get current logical topology > along with topology version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18195) Improve message for restart after WAL disabled
[
https://issues.apache.org/jira/browse/IGNITE-18195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636669#comment-17636669
]
Ignite TC Bot commented on IGNITE-18195:
{panel:title=Branch: [pull/10386/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10386/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=6918230buildTypeId=IgniteTests24Java8_RunAll]
> Improve message for restart after WAL disabled
> --
>
> Key: IGNITE-18195
> URL: https://issues.apache.org/jira/browse/IGNITE-18195
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Chugunov
>Assignee: Sergey Chugunov
>Priority: Major
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently we have this message
> {noformat}
> Cache groups with potentially corrupted partition files found. To cleanup
> them maintenance is needed, node will enter maintenance mode on next restart.
> Cleanup cache group folders manually or trigger maintenance action to do that
> and restart the node. Corrupted files are located in subdirectories
> {noformat}
> The message is not very informative and doesn't provide detailed instructions
> of how to deal with the situation.
> The better message could be:
> {noformat}
> Ignite node with disabled WAL was stopped in the middle of a checkpoint, data
> files may be corrupted. Node will stop and enter the Maintenance Mode on next
> start.
> In the Maintenance Mode, use the Control Utility *persistence* command to
> clean and optionally back up corrupted files. When cleaning is done, restart
> the node manually.
> Possible corruption affects the following cache groups:
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17908) AssertionError LWM after reserved on data insertion after the cluster restart
[
https://issues.apache.org/jira/browse/IGNITE-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin reassigned IGNITE-17908:
---
Assignee: Maksim Timonin
> AssertionError LWM after reserved on data insertion after the cluster restart
> -
>
> Key: IGNITE-17908
> URL: https://issues.apache.org/jira/browse/IGNITE-17908
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Attachments: LwmAfterReservedTest.java
>
>
> After the cluster restart you may see the following assertion:
> {code}
> java.lang.AssertionError: LWM after reserved: lwm=2030, reserved=2010,
> cntr=Counter [lwm=2030, missed=[], hwm=2030, reserved=2011]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.reserve(PartitionUpdateCounterTrackingImpl.java:270)
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.reserve(PartitionUpdateCounterErrorWrapper.java:58)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.getAndIncrementUpdateCounter(IgniteCacheOffheapManagerImpl.java:1594)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.getAndIncrementUpdateCounter(GridCacheOffheapManager.java:2483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.getAndIncrementUpdateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:510)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1356)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:726)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1132)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareAsyncLocal(GridNearTxLocal.java:4282)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareColocatedTx(IgniteTxHandler.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.proceedPrepare(GridNearOptimisticTxPrepareFuture.java:565)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepareSingle(GridNearOptimisticTxPrepareFuture.java:392)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.prepare0(GridNearOptimisticTxPrepareFuture.java:335)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepareOnTopology(GridNearOptimisticTxPrepareFutureAdapter.java:205)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFutureAdapter.prepare(GridNearOptimisticTxPrepareFutureAdapter.java:129)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.prepareNearTxLocal(GridNearTxLocal.java:3946)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.commitNearTxLocalAsync(GridNearTxLocal.java:3994)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.optimisticPutFuture(GridNearTxLocal.java:3051)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:729)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:484)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$20.op(GridCacheAdapter.java:2511)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$20.op(GridCacheAdapter.java:2509)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4284)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2509)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2487)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2466)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1332)
> at
>
[jira] [Commented] (IGNITE-18049) Cursor#close() should not declare any exceptions in throws clause
[
https://issues.apache.org/jira/browse/IGNITE-18049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636653#comment-17636653
]
Roman Puchkovskiy commented on IGNITE-18049:
Thanks!
> Cursor#close() should not declare any exceptions in throws clause
> -
>
> Key: IGNITE-18049
> URL: https://issues.apache.org/jira/browse/IGNITE-18049
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> When an {{AutoCloseable}} subinterface/implementation declares {{throws
> Exception}} in its {{close()}} method, it makes it very inconvenient to work
> with such a type using try-with-resources because the using code must use
> something like {{catch (Exception e)}} which makes it difficult to process
> exceptions that might arise in the {{try}} block.
> The suggestion is to make {{Cursor#close()}} not declare any checked
> exceptions. Most of the current implementations of {{Cursor}} already obey to
> this restriction, and a few that don't can be easily reworked to obey.
> The only problem is adapters (when we adapt an {{Iterator}} producing a
> {{{}Cursor{}}}). Here, we must be prepared to get an {{Iterator}} that is a
> resource itself (is an {{{}AutoCloseable{}}}) and hence needs to be closed
> when the cursor is closed. But {{AutoCloseable#close()}} might throw a
> checked exception. It is unacceptable to swallow it, and it is not too good
> to just automatically wrap it in an unchecked exception.
> # The best thing is that developers (who know their resources) write their
> own custom {{Cursor}} implementations handling the closure.
> # We also need a way to adapt 'safe close' iterators (obtained from
> in-memory collections, for example). We should add a method like
> {{Cursor#fromPurIterator(Iterator)}} that will check (at the moment of
> invocation that the provided iterator is NOT an AutoCloseable and will throw
> if it is)
> # We can also provide a generic way to adapt a closeable iterator with a
> method like {{ & AutoCloseable>
> Cursor#fromCloseableIterator(IT iterator)}} adding a Javadoc urging the user
> to use this method only when absolutely necessary
> # We probably should not add an omnivorous method that could adapt both pure
> and closeable iterators for now to prevent abuses.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18208) Sql. Restructuring of the planner tests for aggregates
Konstantin Orlov created IGNITE-18208: - Summary: Sql. Restructuring of the planner tests for aggregates Key: IGNITE-18208 URL: https://issues.apache.org/jira/browse/IGNITE-18208 Project: Ignite Issue Type: Improvement Reporter: Konstantin Orlov Currently, planner tests for aggregates doesn't have any logical structure. As a result it hard to say which queries should be processed by 2-phase aggregate, and which by colocated aggregates. Let's restructure the tests in order to get answer on following questions: * which queries should be processed by colocated aggregates * which queries should be processed by 2-phase aggregates * which queries should leverage the sorted aggregates -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18207) Sql. Pushdown DISTINCT aggregate with no particular function
Konstantin Orlov created IGNITE-18207: - Summary: Sql. Pushdown DISTINCT aggregate with no particular function Key: IGNITE-18207 URL: https://issues.apache.org/jira/browse/IGNITE-18207 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov In order to reduce amount of rows to send over the network, for cases with DISTINCT aggregates and no particular aggregation function, IgniteAggregate[dist=single] can be copied to under the exchange with hash distribution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-18206) Sql. Prohibit using of DISTINCT 2-phase aggregates
Konstantin Orlov created IGNITE-18206: - Summary: Sql. Prohibit using of DISTINCT 2-phase aggregates Key: IGNITE-18206 URL: https://issues.apache.org/jira/browse/IGNITE-18206 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Currently, 2-phase aggregate is used even for aggregates with DISTINCT and ORDER BY clauses. This is possible because of unnatural resulting row produced by a MAP aggregate: in a single column it accumulates all rows belonging to a particular group. Such an approach causes errors in cost calculation, as well as closes the door for further optimizations, like reusing BinaryTuple for sql row, because of a complex structure of the row. As a first step, let's prohibit using of 2-phase aggregates for cases where collection of rows for particular row should be preserved in order to compute the final result (DISTINCT aggregates). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18179) KafkaPoducer and KafkaConsumer classes missed in ignite-cdc-ext build
[
https://issues.apache.org/jira/browse/IGNITE-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov reassigned IGNITE-18179:
--
Assignee: Ilya Shishkov
> KafkaPoducer and KafkaConsumer classes missed in ignite-cdc-ext build
> -
>
> Key: IGNITE-18179
> URL: https://issues.apache.org/jira/browse/IGNITE-18179
> Project: Ignite
> Issue Type: Bug
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Major
> Labels: ise
> Attachments: cdc-ext-build-patch.patch, ignite-cdc-ext-current.txt,
> ignite-cdc-ext-old.txt, ignite-cdc-ext-patch.txt
>
>
> CDC though Kafka uses {{KafkaConsumer}} and {{KafkaProducer}}, which are
> parts of {{kafka-clients}} module.
> But when you build ignite-cdc-ext with a below command:
> {code}
> mvn clean package -f modules/cdc-ext/ -P checkstyle,extension-release
> -DskipTests
> {code}
> you will obtain zip file with a structure [^ignite-cdc-ext-current.txt],
> where {{kafka-clients}} dependency _*is missing*_.
> So, when you try to start {{KafkaToIgniteCdcStreamer}} or
> {{IgniteToKafkaCdcStreamer}} you will obtain missing classes error.
> Building of module changed after IGNITE-16847, IGNITE-16815. Structure was:
> [^ignite-cdc-ext-old.txt]. As you can see, there was many jar libraries
> included, but i'm not sure whether all of them needed to run CDC.
> I have prepared a patch [^cdc-ext-build-patch.patch], which replaces
> _kafka_2.12-2.7.0.jar_ by _kafka-clients-2.7.0.jar_ and tested it locally:
> problems with missed classes eliminated and it seems, that simple
> active-active replication cases works fine. But, patch does not fix other
> dependencies from old build assembly structure (I'm not sure, that all
> dependencies satisfied).
> Structure after patch: [^ignite-cdc-ext-patch.txt]
> Also, proposed patch affects other modules, which uses
> {{/assembly/bin-component-shared.xml}} in build process.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18163) Old-style join on different column types fails with ClassCastException
[
https://issues.apache.org/jira/browse/IGNITE-18163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636564#comment-17636564
]
Konstantin Orlov commented on IGNITE-18163:
---
Looks like we miss a cast when creating a comparator for MergeJoin
> Old-style join on different column types fails with ClassCastException
> --
>
> Key: IGNITE-18163
> URL: https://issues.apache.org/jira/browse/IGNITE-18163
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Labels: calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Query:
> {code}
> select _T0.KEY, _T1.VAL from PUBLIC.TBL1 as _T0, PUBLIC.TBL_INT32 as _T1
> where _T0.KEY IS NOT DISTINCT FROM _T1.KEY
> {code}
> Result:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:ef4217b1-04ef-4f08-b1c3-76effc3fc262 class java.lang.Long cannot be
> cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at org.apache.ignite.lang.IgniteException.wrap(IgniteException.java:289)
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:77)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:193)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:193)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.onError(MergeJoinNode.java:124)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:155)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.onMessage(ExchangeServiceImpl.java:205)
> at
> org.apache.ignite.internal.sql.engine.exec.ExchangeServiceImpl.lambda$start$2(ExchangeServiceImpl.java:81)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:164)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$3(MessageServiceImpl.java:133)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:80)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.lang.ClassCastException: class java.lang.Long cannot be cast
> to class java.lang.Integer (java.lang.Long and java.lang.Integer are in
> module java.base of loader 'bootstrap')
> at java.base/java.lang.Integer.compareTo(Integer.java:59)
> at
> org.apache.calcite.rel.RelFieldCollation.compare(RelFieldCollation.java:43)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl.compare(ExpressionFactoryImpl.java:235)
> at
> org.apache.ignite.internal.sql.engine.exec.exp.ExpressionFactoryImpl$2.compare(ExpressionFactoryImpl.java:217)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$InnerJoin.join(MergeJoinNode.java:318)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode.pushLeft(MergeJoinNode.java:162)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.MergeJoinNode$1.push(MergeJoinNode.java:112)
> at
>
[jira] [Commented] (IGNITE-18174) SQL: implement expanded NULL predicate
[
https://issues.apache.org/jira/browse/IGNITE-18174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636557#comment-17636557
]
Andrey Mashenkov commented on IGNITE-18174:
---
Feature is not supported in Calcite yet.
> SQL: implement expanded NULL predicate
> --
>
> Key: IGNITE-18174
> URL: https://issues.apache.org/jira/browse/IGNITE-18174
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> "Expanded NULL predicate" is referenced in SQL standard as F481 feature. It
> allows to use something other than a column reference as row value expression.
> The following query works in AI2:
> {code:sql}
> create table tmp_simple_table (key_field INT PRIMARY KEY,x INT,y INT,z INT);
> insert into tmp_simple_table (key_field,x,y,z) values (1, 1,1,1);
> insert into tmp_simple_table (key_field,x,y,z) values (2, 2,2,2);
> insert into tmp_simple_table (key_field,x,y,z) values (3, null,3,null);
> insert into tmp_simple_table (key_field,x,y,z) values (4, 4,null,null);
> insert into tmp_simple_table (key_field,x,y,z) values (5, null,null,null);
> select x, y, z from tmp_simple_table t
> where (select x, z from tmp_simple_table where x=t.x and y=t.y and z=t.z)
> is not NULL; -- expanded NULL predicate
> {code}
> But in AI3 beta1 it's not implemented yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
