[jira] [Closed] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov closed IGNITE-13696.
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230401#comment-17230401
]
Stepan Pilschikov commented on IGNITE-13696:
ohh, sorry then
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stepan Pilschikov resolved IGNITE-13696.
Resolution: Not A Bug
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12941) .NET: Support .NET 5
[
https://issues.apache.org/jira/browse/IGNITE-12941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12941:
Description:
.NET 5 is released. Breaking changes:
https://blog.miguelbernard.com/net-5-the-breaking-changes-you-need-to-know-about/
* Run tests on .NET 5 on Windows and Linux
* Add nightly .NET TeamCity project (?)
* Check deployment scenarios
*Self-contained single-file publish issue*
{code}
Unhandled exception. System.DllNotFoundException: Unable to load shared library
'libcoreclr.so' or one of its dependencies. In order to help diagnose loading
problems, consider setting the LD_DEBUG environment variable: liblibcoreclr.so:
cannot open shared object file: No such file or directory
at
Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
filename, Int32 flags)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
String simpleName)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
configJvmDllPath, ILogger log)
at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
at Apache.Ignite.Core.Ignition.Start()
at IgniteNet5Test.Program.Main(String[] args)
{code}
See https://github.com/dotnet/runtime/issues/41859
was:
.NET 5 is released. Breaking changes:
https://blog.miguelbernard.com/net-5-the-breaking-changes-you-need-to-know-about/
* Run tests on .NET 5 on Windows and Linux
* Check deployment scenarios
*Self-contained single-file publish issue*
{code}
Unhandled exception. System.DllNotFoundException: Unable to load shared library
'libcoreclr.so' or one of its dependencies. In order to help diagnose loading
problems, consider setting the LD_DEBUG environment variable: liblibcoreclr.so:
cannot open shared object file: No such file or directory
at
Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
filename, Int32 flags)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
String simpleName)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
configJvmDllPath, ILogger log)
at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
at Apache.Ignite.Core.Ignition.Start()
at IgniteNet5Test.Program.Main(String[] args)
{code}
See https://github.com/dotnet/runtime/issues/41859
> .NET: Support .NET 5
>
>
> Key: IGNITE-12941
> URL: https://issues.apache.org/jira/browse/IGNITE-12941
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, newbie
> Fix For: 2.10
>
>
> .NET 5 is released. Breaking changes:
> https://blog.miguelbernard.com/net-5-the-breaking-changes-you-need-to-know-about/
> * Run tests on .NET 5 on Windows and Linux
> * Add nightly .NET TeamCity project (?)
> * Check deployment scenarios
>
> *Self-contained single-file publish issue*
> {code}
> Unhandled exception. System.DllNotFoundException: Unable to load shared
> library 'libcoreclr.so' or one of its dependencies. In order to help diagnose
> loading problems, consider setting the LD_DEBUG environment variable:
> liblibcoreclr.so: cannot open shared object file: No such file or directory
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at IgniteNet5Test.Program.Main(String[] args)
> {code}
> See https://github.com/dotnet/runtime/issues/41859
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12941) .NET: Support .NET 5
[
https://issues.apache.org/jira/browse/IGNITE-12941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12941:
Description:
.NET 5 is released. Breaking changes:
https://blog.miguelbernard.com/net-5-the-breaking-changes-you-need-to-know-about/
* Run tests on .NET 5 on Windows and Linux
* Check deployment scenarios
*Self-contained single-file publish issue*
{code}
Unhandled exception. System.DllNotFoundException: Unable to load shared library
'libcoreclr.so' or one of its dependencies. In order to help diagnose loading
problems, consider setting the LD_DEBUG environment variable: liblibcoreclr.so:
cannot open shared object file: No such file or directory
at
Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
filename, Int32 flags)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
String simpleName)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
configJvmDllPath, ILogger log)
at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
at Apache.Ignite.Core.Ignition.Start()
at IgniteNet5Test.Program.Main(String[] args)
{code}
See https://github.com/dotnet/runtime/issues/41859
was:
.NET 5 is in preview. Ignite.NET does not seem to work there. Tested on Ubuntu:
* Install .NET 5 SDK from Snap
* Create new console app, add Apache.Ignite nuget package
* Add Ignition.Start
* dotnet run
{code}
Unhandled exception. Apache.Ignite.Core.Common.IgniteException: Failed to load
libjvm.so:
[option=/usr/bin/java,
path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
error=Unknown error]
[option=/usr/bin/java,
path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
error=/snap/core18/current/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29'
not found (required by
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)]
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
configJvmDllPath, ILogger log)
at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
at Apache.Ignite.Core.Ignition.Start()
at dotnet5.Program.Main(String[] args) in
/home/pavel/w/tests/dotnet5/Program.cs:line 10
{code}
*Self-contained single-file publish issue*
{code}
Unhandled exception. System.DllNotFoundException: Unable to load shared library
'libcoreclr.so' or one of its dependencies. In order to help diagnose loading
problems, consider setting the LD_DEBUG environment variable: liblibcoreclr.so:
cannot open shared object file: No such file or directory
at
Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
filename, Int32 flags)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
String simpleName)
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
configJvmDllPath, ILogger log)
at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
at Apache.Ignite.Core.Ignition.Start()
at IgniteNet5Test.Program.Main(String[] args)
{code}
See https://github.com/dotnet/runtime/issues/41859
> .NET: Support .NET 5
>
>
> Key: IGNITE-12941
> URL: https://issues.apache.org/jira/browse/IGNITE-12941
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, newbie
> Fix For: 2.10
>
>
> .NET 5 is released. Breaking changes:
> https://blog.miguelbernard.com/net-5-the-breaking-changes-you-need-to-know-about/
> * Run tests on .NET 5 on Windows and Linux
> * Check deployment scenarios
>
> *Self-contained single-file publish issue*
> {code}
> Unhandled exception. System.DllNotFoundException: Unable to load shared
> library 'libcoreclr.so' or one of its dependencies. In order to help diagnose
> loading problems, consider setting the LD_DEBUG environment variable:
> liblibcoreclr.so: cannot open shared object file: No such file or directory
>at
> Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.NativeMethodsCore.dlopen(String
> filename, Int32 flags)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.DllLoader.Load(String dllPath)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.LoadDll(String filePath,
> String simpleName)
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at IgniteNet5Test.Program.Main(String[] args)
> {code}
> See https://github.com/dotnet/runtime/issues/41859
--
This message was sent by Atlassian Jira
[jira] [Updated] (IGNITE-13674) Document Persistent store defragmentation
[ https://issues.apache.org/jira/browse/IGNITE-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13674: - Docs Text: Defragmentation Introduction As memory management mechanism of Apache Ignite can only create or reuse pages for user data but never frees them files where Ignite persists data can only grow and never shrinks. In most use cases it doesn't cause any problems as once created page can be reused multiple times. However in certain cases it is possible that cache contains very little data but occupies large chunks of disk space because a lot of data was removed from the cache. Defragmentation is aimed to enable user to shrink data files and claim back disk space. Important: defragmentation can only be used with historical rebalance enabled (link to historical rebalance page). If historical rebalance is disabled server node always triggers full rebalance after restart throwing away defragmented partition. Full set of data is transferred to the node from other nodes over network, depending of size of data set it may require a lot of time and may slow down the whole cluster as network capacity is important to fulfill user requests. How to use it Defragmentation is costly operation in terms of disk IO so to avoid slowing down user operations it cannot be executed on regular node joined to the cluster. To execute defragmentation user needs to request it first on a particular node or set of nodes and than restart these nodes. To request defragmentation use the following command: After restart node with requested defragmentation will enter special mode called maintenance mode. Node in maintenance doesn't join the rest of the cluster but stays isolated until defragmentation is completed (or cancelled by explicit user request). After that user has to restart the node one more time: it will exit maintenance mode and returns back to normal operations (joins the cluster and starts to serve regular workload). Important: as nodes in maintenance don't participate in serving usual workload, it is not recommended to execute defragmentation on several nodes at once as it reduces number of backups thus increasing the risk of partition loss. When node executes defragmentation it is possible to retrieve operation status or cancel it fully or partially using the following commands available in control utility: . For more information about commands refer to their help. Important: to reduce disk space requirements during defragmentation caches are defragmented one by one (if defragmentation of more than one cache was requested). To calculate additional space required find the cache that occupies the most disk space. The same amount of disk space is required for defragmentation at max. Conclusion In most situations defragmentation isn't needed as existing memory management mechanism effectively reuses memory left after data deletion. But in rare cases it may be necessary to employ it to free up disk space. Its usage requires taking nodes out of normal operations so it careful planning is needed. > Document Persistent store defragmentation > - > > Key: IGNITE-13674 > URL: https://issues.apache.org/jira/browse/IGNITE-13674 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Labels: IEP-47 > Original Estimate: 48h > Remaining Estimate: 48h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13674) Document Persistent store defragmentation
[ https://issues.apache.org/jira/browse/IGNITE-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-13674: - Component/s: documentation > Document Persistent store defragmentation > - > > Key: IGNITE-13674 > URL: https://issues.apache.org/jira/browse/IGNITE-13674 > Project: Ignite > Issue Type: Sub-task > Components: documentation >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Labels: IEP-47 > Original Estimate: 48h > Remaining Estimate: 48h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230393#comment-17230393
]
Ivan Daschinskiy commented on IGNITE-13696:
---
I'm sorry, but I suppose this is just a
[MAE|https://en.wikipedia.org/wiki/Mean_squared_error] or smth like this.
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13696) [ML] Tutorial examples fails
[
https://issues.apache.org/jira/browse/IGNITE-13696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230393#comment-17230393
]
Ivan Daschinskiy edited comment on IGNITE-13696 at 11/12/20, 7:04 AM:
--
I'm sorry, but I suppose this is just a
[MSE|https://en.wikipedia.org/wiki/Mean_squared_error] or smth like this.
was (Author: ivandasch):
I'm sorry, but I suppose this is just a
[MAE|https://en.wikipedia.org/wiki/Mean_squared_error] or smth like this.
> [ML] Tutorial examples fails
>
>
> Key: IGNITE-13696
> URL: https://issues.apache.org/jira/browse/IGNITE-13696
> Project: Ignite
> Issue Type: Bug
> Components: examples, ml
>Affects Versions: 2.9
>Reporter: Stepan Pilschikov
>Priority: Major
>
> Trying to run Tutorial examples from repository or from binary release and
> meet error results. Looks like a bug
> org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
> tutorials have same issue)
> {code}
> >>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 >
> >>> 0.5000) then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000)
> >>> then return 0. else return 0. else return 0. else if (x2 >
> >>> 0.5000) then if (x2 > 3.5000) then if (x1 > 0.5000) then return 0.
> >>> else return 0. else if (x2 > 1.5000) then return 0. else return
> >>> 1. else if (x1 > 0.5000) then if (x1 > 1.5000) then return 0.
> >>> else return 0. else return 0. else if (x2 > 0.5000) then if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else return 1. else if (x2 > 3.5000) then return 0. else return
> >>> 1. else if (x2 > 1.5000) then if (x0 > 1.5000) then return 1.
> >>> else return 1. else if (x0 > 1.5000) then return 1. else return
> >>> 1. else if (x0 > 1.5000) then if (x1 > 2.5000) then return 1.
> >>> else if (x1 > 1.5000) then return 0. else return 0. else if (x1 >
> >>> 0.5000) then if (x1 > 1.5000) then return 1. else return 1. else
> >>> return 1.
> >>> Accuracy 0.7117737003058104
> >>> Test Error 0.28822629969418956
> >>> Tutorial step 1 (read and learn) example completed.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13107) ODBC: Memory leak in the tests
[
https://issues.apache.org/jira/browse/IGNITE-13107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230311#comment-17230311
]
Ignite TC Bot commented on IGNITE-13107:
{panel:title=Branch: [pull/7890/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=5728990]]
* IgniteOdbcTest: ConnectionTestSuite: TestConnectionRestore - New test
duration 70s is more that 1 minute
{panel}
{panel:title=Branch: [pull/7890/head] Base: [master] : New Tests
(1890)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
954|https://ci.ignite.apache.org/viewLog.html?buildId=5728990]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- 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}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForHost - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForOldest -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForRandom -
PASSED{color}
... and 943 new tests
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
932|https://ci.ignite.apache.org/viewLog.html?buildId=5728983]]
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestBasic -
PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryScan
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApiRobustnessTestSuite: TestSQLGetStmtAttr -
PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToLong - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQuerySql
- PASSED{color}
* {color:#013220}IgniteOdbcTest: ApplicationDataBufferTestSuite:
TestPutStringToTiny - PASSED{color}
* {color:#013220}IgniteCoreTest: ContinuousQueryTestSuite: TestInitialQueryText
- PASSED{color}
... and 921 new tests
{color:#8b}Platform C++ (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728984]]
* {color:#013220}IgniteOdbcTest: ConnectionTestSuite: TestConnectionMemoryLeak
- PASSED{color}
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5729920]]
* {color:#013220}IgniteOdbcTest: ConnectionTestSuite: TestConnectionMemoryLeak
- PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728989]]
* {color:#013220}IgniteOdbcTest: ConnectionTestSuite: TestConnectionMemoryLeak
- PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728988]]
* {color:#013220}IgniteOdbcTest: ConnectionTestSuite: TestConnectionMemoryLeak
- PASSED{color}
{panel}
[TeamCity *- Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5728992buildTypeId=IgniteTests24Java8_RunCpp]
> ODBC: Memory leak in the tests
> --
>
> Key: IGNITE-13107
> URL: https://issues.apache.org/jira/browse/IGNITE-13107
> Project: Ignite
> Issue Type: Improvement
> Components: odbc
>Affects Versions: 2.9
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The memory leak, which is reproducible on TC Windows debug configuration,
> have place in case of odce-test unit tests executing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13608) .NET: Add Partitions and UpdateBatchSize to SqlFieldsQuery
[
https://issues.apache.org/jira/browse/IGNITE-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230294#comment-17230294
]
Ignite TC Bot commented on IGNITE-13608:
{panel:title=Branch: [pull/8445/head] Base: [master] : Possible Blockers
(34)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5729783]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5729718]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySplitBrainTest.testSimpleSplitBrain - Test has low fail rate
in base branch 0,0% and is not flaky
{color:#d04437}Continuous Query 4{color} [[tests 19 TIMEOUT , Out Of Memory
Error , Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=5729753]]
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackupAsyncFullSync -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testAtomicReplicatedAsync - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testTxOnheapAsync - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testTxOnheapTwoBackup - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testTxOnheapAsyncFullSync - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testTxOnheapWithoutBackup - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testAtomicOnheapWithoutBackupAsync - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testMvccTxOnheapTwoBackupAsync - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testAtomicOnheapTwoBackup - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testMvccTxOnheapAsync - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteCacheQuerySelfTestSuite6:
CacheContinuousQueryOrderingEventTest.testTxOnheapTwoBackupAsync - Test has low
fail rate in base branch 0,0% and is not flaky
... and 8 tests blockers
{color:#d04437}MVCC Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5729785]]
* IgniteCacheMvccTestSuite9:
IgniteTxCacheWriteSynchronizationModesMultithreadedTest.testMultithreadedFullSyncRestart
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}JDBC Driver{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5729704]]
* IgniteJdbcDriverTestSuite:
JdbcThinJdbcToCacheDataTypesCoverageTest.testTimeDataType[atomicityMode=ATOMIC,
cacheMode=PARTITIONED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=PRIMARY_SYNC, persistenceEnabled=false]
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteJdbcDriverTestSuite:
JdbcThinCacheToJdbcDataTypesCoverageTest.testObjectBasedOnPrimitivesDataType[atomicityMode=ATOMIC,
cacheMode=REPLICATED, ttlFactory=null, backups=2, evictionFactory=null,
onheapCacheEnabled=false, writeSyncMode=FULL_SYNC, persistenceEnabled=false] -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests 1 TC_SERVICE_MESSAGE
|https://ci.ignite.apache.org/viewLog.html?buildId=5729764]]
* dll: IgniteStartStopTest.TestStartDefault - Test has low fail rate in base
branch 0,0% and is not flaky
{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 0
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=5729720]]
{color:#d04437}Basic 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5729722]]
{color:#d04437}MVCC PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5729786]]
* IgnitePdsMvccTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testClientReconnectClusterDeactivated
- Test has low fail rate in base branch 1,3% and is not flaky
{color:#d04437}Basic 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5729723]]
* IgniteBasicWithPersistenceTestSuite:
CacheGroupReencryptionTest.testPartitionEvictionDuringReencryption - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 6{color} [[tests 1 TIMEOUT , Out Of Memory Error ,
Exit Code
[jira] [Created] (IGNITE-13696) [ML] Tutorial examples fails
Stepan Pilschikov created IGNITE-13696:
--
Summary: [ML] Tutorial examples fails
Key: IGNITE-13696
URL: https://issues.apache.org/jira/browse/IGNITE-13696
Project: Ignite
Issue Type: Bug
Components: examples, ml
Affects Versions: 2.9
Reporter: Stepan Pilschikov
Trying to run Tutorial examples from repository or from binary release and meet
error results. Looks like a bug
org.apache.ignite.examples.ml.tutorial.Step_1_Read_and_Learn (all other
tutorials have same issue)
{code}
>>> Trained model: if (x0 > 2.5000) then if (x1 > 2.5000) then if (x2 > 0.5000)
>>> then if (x1 > 4.5000) then return 0. else if (x2 > 1.5000) then return
>>> 0. else return 0. else return 0. else if (x2 > 0.5000) then if
>>> (x2 > 3.5000) then if (x1 > 0.5000) then return 0. else return 0.
>>> else if (x2 > 1.5000) then return 0. else return 1. else if (x1 >
>>> 0.5000) then if (x1 > 1.5000) then return 0. else return 0. else
>>> return 0. else if (x2 > 0.5000) then if (x1 > 0.5000) then if (x1 >
>>> 1.5000) then if (x1 > 2.5000) then return 1. else return 1. else if
>>> (x2 > 3.5000) then return 0. else return 1. else if (x2 > 1.5000)
>>> then if (x0 > 1.5000) then return 1. else return 1. else if (x0 >
>>> 1.5000) then return 1. else return 1. else if (x0 > 1.5000) then if
>>> (x1 > 2.5000) then return 1. else if (x1 > 1.5000) then return 0.
>>> else return 0. else if (x1 > 0.5000) then if (x1 > 1.5000) then return
>>> 1. else return 1. else return 1.
>>> Accuracy 0.7117737003058104
>>> Test Error 0.28822629969418956
>>> Tutorial step 1 (read and learn) example completed.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13695) Move javadoc of affection of several addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13695: -- Description: Current javadoc of affection several node addresses of failure detection is located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by `TcpDiscoverySpi.setLocalAddress()`. Perhaps, the text might be slightly changed. was: Current javadoc of affection several node addresses of failure detection is located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by `TcpDiscoverySpi.setLocalAddress()`. Perhaps, the test might be slightly changed. > Move javadoc of affection of several addresses on failure detection. > > > Key: IGNITE-13695 > URL: https://issues.apache.org/jira/browse/IGNITE-13695 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > Current javadoc of affection several node addresses of failure detection is > located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by > `TcpDiscoverySpi.setLocalAddress()`. > Perhaps, the text might be slightly changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-11704: - Fix Version/s: 2.10 > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Scherbakov >Priority: Major > Labels: rebalance > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13695) Move javadoc of affection of several addresses on failure detection.
Vladimir Steshin created IGNITE-13695: - Summary: Move javadoc of affection of several addresses on failure detection. Key: IGNITE-13695 URL: https://issues.apache.org/jira/browse/IGNITE-13695 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Assignee: Vladimir Steshin Current javadoc of affection several node addresses of failure detection is located under `TcpDiscoverySpi.setIpFinder()`. Correct place is by `TcpDiscoverySpi.setLocalAddress()`. Perhaps, the test might be slightly changed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230068#comment-17230068 ] Alexey Scherbakov commented on IGNITE-11704: [~mmuzaf] I have plans to merge it in early december. > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Scherbakov >Priority: Major > Labels: rebalance > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.
[
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-12901:
--
Priority: Major (was: Minor)
> SQL: Uncorrelated subquery should run only once.
>
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Attachments: ignite-12901-subquery.patch
>
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer
> query) are executed on each nested loop iteration in the
> org.h2.command.dml.Select#isConditionMet method.
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
> * Test local query execution.
> */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM
> B)").getAll();
> }
> /**
> * @param enforceJoinOrder Enforce join order mode.
> * @param sql SQL query.
> * @param args Query parameters.
> * @return Results cursor.
> */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12901) SQL: Uncorrelated subquery should run only once.
[
https://issues.apache.org/jira/browse/IGNITE-12901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-12901:
-
Assignee: Ivan Daschinskiy
> SQL: Uncorrelated subquery should run only once.
>
>
> Key: IGNITE-12901
> URL: https://issues.apache.org/jira/browse/IGNITE-12901
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Minor
> Labels: sbcf
> Attachments: ignite-12901-subquery.patch
>
>
> Currently uncorrelated subqueries (where subquery is not depends on the outer
> query) are executed on each nested loop iteration in the
> org.h2.command.dml.Select#isConditionMet method.
> We may avoid this, for example, using results caching.
> h2. Reproducer
> {code:java}
> public class SubQueryTest extends AbstractIndexingCommonTest {
> /** Keys counts at the RIGHT table. */
> private static final int RIGHT_CNT = 10;
> /** Keys counts at the LEFT table. */
> private static final int LEFT_CNT = 50;
> /** {@inheritDoc} */
> @SuppressWarnings("unchecked")
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> startGrids(1);
> IgniteCache cacheA = grid(0).createCache(new CacheConfiguration Long>()
> .setName("A")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getTypeName(), "A_VAL")
> .setTableName("A")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("JID", Long.class.getName(), null)
> .addQueryField("VAL", Long.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> IgniteCache cacheB = grid(0).createCache(new CacheConfiguration()
> .setCacheMode(CacheMode.REPLICATED)
> .setName("B")
> .setSqlSchema("TEST")
> .setQueryEntities(Collections.singleton(new
> QueryEntity(Long.class.getName(), "B_VAL")
> .setTableName("B")
> .addQueryField("ID", Long.class.getName(), null)
> .addQueryField("A_JID", Long.class.getName(), null)
> .addQueryField("VAL0", String.class.getName(), null)
> .setKeyFieldName("ID")
> )));
> Map batch = new HashMap<>();
> for (long i = 0; i < LEFT_CNT; ++i) {
> batch.put(i, grid(0).binary().builder("A_VAL")
> .setField("JID", i % RIGHT_CNT)
> .setField("VAL", i)
> .build());
> if (batch.size() > 1000) {
> cacheA.putAll(batch);
> batch.clear();
> }
> }
> if (batch.size() > 0) {
> cacheA.putAll(batch);
> batch.clear();
> }
> for (long i = 0; i < RIGHT_CNT; ++i)
> cacheB.put(i, grid(0).binary().builder("B_VAL")
> .setField("A_JID", i)
> .setField("VAL0", String.format("val%03d", i))
> .build());
> }
> /** {@inheritDoc} */
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> super.afterTest();
> }
> /**
> * Test local query execution.
> */
> @Test
> public void test() {
> sql(true, "SELECT * FROM A WHERE A.JID IN (SELECT A_JID FROM
> B)").getAll();
> }
> /**
> * @param enforceJoinOrder Enforce join order mode.
> * @param sql SQL query.
> * @param args Query parameters.
> * @return Results cursor.
> */
> private FieldsQueryCursor> sql(boolean enforceJoinOrder, String
> sql, Object... args) {
> return grid(0).context().query().querySqlFields(new
> SqlFieldsQuery(sql)
> .setSchema("TEST")
> .setLazy(true)
> .setEnforceJoinOrder(enforceJoinOrder)
> .setArgs(args), false);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Actual failure detection delay of this node is: `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. To avoid this, user should assign `IgniteConfiguration.localHost` or `TcpDiscoverySpi.localAddress`. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. was: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Actual failure detection delay of this node is: `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. By default, all available addresses are assigned > to node and node listens any address (0.0.0.0). Actual failure detection > delay of this node is: `failureDetectionTimeout * addressesNumber + > connRecoveryTimeout`. > To avoid this, user should assign `IgniteConfiguration.localHost` or > `TcpDiscoverySpi.localAddress`. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially. If addresses do not belong to assumed > node network, do not represent existing physical connection, processing them > is just waste of time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Description: We should document that TcpDiscoverySpi prolongs detection of node failure if node has several addresses. By default, all available addresses are assigned to node and node listens any address (0.0.0.0). Actual failure detection delay of this node is: `failureDetectionTimeout * addressesNumber + connRecoveryTimeout`. Often, middleware runs in environments with several IP addresses (virtualizations, containers, different networks). Node sends all obtained addresses with other node info to the cluster. Connection to node is established to first of its addresses. But if lost, other addresses are attempted to reconnect sequentially. If addresses do not belong to assumed node network, do not represent existing physical connection, processing them is just waste of time. was: We should emphasize in the documentation that TcpDiscoverySpi prolongs detection of node failure if several IP addresses are set. Actual failure detection delay is: failureDetectionTimeout * addressesNumber + connRecoveryTimeout. The problem appear in ability of node to run with several addresses. By default, all available addresses are assigned to node. Connection to a node is established to one of its address (first non-loopback). But if lost, other addresses are attempted to reconnect to sequentially. > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should document that TcpDiscoverySpi prolongs detection of node failure if > node has several addresses. By default, all available addresses are assigned > to node and node listens any address (0.0.0.0). Actual failure detection > delay of this node is: `failureDetectionTimeout * addressesNumber + > connRecoveryTimeout`. > Often, middleware runs in environments with several IP addresses > (virtualizations, containers, different networks). Node sends all obtained > addresses with other node info to the cluster. Connection to node is > established to first of its addresses. But if lost, other addresses are > attempted to reconnect sequentially. If addresses do not belong to assumed > node network, do not represent existing physical connection, processing them > is just waste of time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13694) Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch
[ https://issues.apache.org/jira/browse/IGNITE-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13694: -- Description: Latency drop(s) should be compared. (was: Latency drop(s) should be compated.) > Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch > --- > > Key: IGNITE-13694 > URL: https://issues.apache.org/jira/browse/IGNITE-13694 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: IEP-56, ducktape > > Latency drop(s) should be compared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13694) Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch
[ https://issues.apache.org/jira/browse/IGNITE-13694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13694: -- Description: Latency drop(s) should be compated. > Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch > --- > > Key: IGNITE-13694 > URL: https://issues.apache.org/jira/browse/IGNITE-13694 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: IEP-56, ducktape > > Latency drop(s) should be compated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13694) Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch
Anton Vinogradov created IGNITE-13694: - Summary: Check difference between SIGTERM, SIGKILL and Disconnect at Cellular switch Key: IGNITE-13694 URL: https://issues.apache.org/jira/browse/IGNITE-13694 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6642) [Umbrella] Model export/import to PMML and custom JSON format
[ https://issues.apache.org/jira/browse/IGNITE-6642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-6642: Labels: important (was: ) > [Umbrella] Model export/import to PMML and custom JSON format > - > > Key: IGNITE-6642 > URL: https://issues.apache.org/jira/browse/IGNITE-6642 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Alexey Zinoviev >Assignee: Alexey Zinoviev >Priority: Major > Labels: important > Fix For: 2.10 > > > > We need to be able to export/import Ignite model versions across clusters > with different versions and have exchangable & human-readable format for > inference with different systems like scikit-learn, Spark ML and etc > The PMML format is a good choice here: > PMML - Predictive Model Markup Language is XML based language which used in > SPARK MLlib and others platforms. > Here some additional info about PMML: > (i) [http://dmg.org/pmml/v4-3/GeneralStructure.html] > (i) [https://github.com/jpmml/jpmml-model] > > But PMML has limitation support for Ensembles like Random Forest, Gradient > Boosted Trees, Stacking, Bagging and so on. > These cases could be covered with our own JSON format which could be easily > parsed in another system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13581) CDC Application
[ https://issues.apache.org/jira/browse/IGNITE-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13581: - Fix Version/s: 2.10 > CDC Application > --- > > Key: IGNITE-13581 > URL: https://issues.apache.org/jira/browse/IGNITE-13581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59, important > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > As described in > [IEP-59|https://cwiki.apache.org/confluence/display/IGNITE/IEP-59+CDC+-+Capture+Data+Change] > we need to create IgniteCDC application that can notifies the consumer about > new WAL events. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13581) CDC Application
[ https://issues.apache.org/jira/browse/IGNITE-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13581: - Labels: IEP-59 important (was: IEP-59) > CDC Application > --- > > Key: IGNITE-13581 > URL: https://issues.apache.org/jira/browse/IGNITE-13581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59, important > Time Spent: 10m > Remaining Estimate: 0h > > As described in > [IEP-59|https://cwiki.apache.org/confluence/display/IGNITE/IEP-59+CDC+-+Capture+Data+Change] > we need to create IgniteCDC application that can notifies the consumer about > new WAL events. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13582) WAL force rollout timeout
[ https://issues.apache.org/jira/browse/IGNITE-13582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13582: - Fix Version/s: 2.10 > WAL force rollout timeout > - > > Key: IGNITE-13582 > URL: https://issues.apache.org/jira/browse/IGNITE-13582 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, Ignite doesn't have a timeout to force WAL segments to rollout. > We need to introduce one to be able to provide some lag guarantees for the > CDC application. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13596) Add flag to DataRecord to differentiate records on primary and backup nodes
[ https://issues.apache.org/jira/browse/IGNITE-13596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13596: - Fix Version/s: 2.10 > Add flag to DataRecord to differentiate records on primary and backup nodes > --- > > Key: IGNITE-13596 > URL: https://issues.apache.org/jira/browse/IGNITE-13596 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > To be able to minimize CDC processing volume we should be able to > differentiate DataRecords in WAL on primary and backup nodes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13143) Persistent store defragmentation
[ https://issues.apache.org/jira/browse/IGNITE-13143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13143: - Labels: IEP-47 important (was: IEP-47) > Persistent store defragmentation > > > Key: IGNITE-13143 > URL: https://issues.apache.org/jira/browse/IGNITE-13143 > Project: Ignite > Issue Type: New Feature > Components: persistence >Reporter: Sergey Chugunov >Priority: Major > Labels: IEP-47, important > > Persistent store enables users to store data of their caches in a durable > fashion on disk still benefiting from in-memory nature of Apache Ignite. Data > of caches is stored in files created for every primary or backup partition > assigned to that node and in an additional file for all user indexes. > Files in filesystem are allocated lazily (only if some data is actually > stored to particular partition) and grow automatically when more data is > added to the cache. But the problem is that files cannot shrink even if all > data is removed. > This umbrella ticket covers all other tasks needed to implement simple yet > effective approach to defragmentation. Detailed discussion could be found in > [IEP-47|https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation] > and in corresponding [dev-list > discussion|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-IEP-47-Native-persistence-defragmentation-td47717.html] > but core ideas are as follows: > # Defragmentation is performed in a special _maintenance_ mode when node > starts, provides access to some APIs like metrics or JMX management but > doesn't join the cluster. > # It is performed by copying all data from all partitions on node to new > files with automatic compaction. After successful copy old partition files > are deleted. > # Metrics on progress of the operation are provided to the user. > # Operation is fault-tolerant and in case of node failure proceeds after > node restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13681) Non markers checkpoint implementation
[ https://issues.apache.org/jira/browse/IGNITE-13681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229954#comment-17229954 ] Sergey Chugunov commented on IGNITE-13681: -- [~akalashnikov], Change looks reasonable to me, I merged it to master in commit *d8ffc2b2991e262b65dfb9ee32fd818852cd5aaf*. Thank you for contribution! > Non markers checkpoint implementation > - > > Key: IGNITE-13681 > URL: https://issues.apache.org/jira/browse/IGNITE-13681 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > It's needed to implement a new version of checkpoint which will be simpler > than the current one. The main differences compared to the current checkpoint: > * It doesn't contain any write operation to WAL. > * It doesn't create checkpoint markers. > * It should be possible to configure checkpoint listener only on the exact > data region > This checkpoint will be helpful for defragmentation and for recovery(it is > not possible to use the current checkpoint during recovery right now) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13608) .NET: Add Partitions and UpdateBatchSize to SqlFieldsQuery
[
https://issues.apache.org/jira/browse/IGNITE-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229950#comment-17229950
]
Ignite TC Bot commented on IGNITE-13608:
{panel:title=Branch: [pull/8445/head] Base: [master] : Possible Blockers
(42)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728863]]
* IgniteSpiTestSuite:
TcpDiscoveryNetworkIssuesTest.testServerGetsSegmentedOnBecomeDangling - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 TIMEOUT
|https://ci.ignite.apache.org/viewLog.html?buildId=5728919]]
{color:#d04437}Cache 8{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728901]]
* IgniteCacheTestSuite8:
Random2LruPageEvictionWithRebalanceTest.testEvictionWithRebalance - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 2{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5728912]]
{color:#d04437}MVCC PDS 2{color} [[tests 3 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5728939]]
* IgnitePdsMvccTestSuite2:
FullHistRebalanceOnClientStopTest.testFullRebalanceNotTriggeredWhenClientNodeStopsDuringPme
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
SlowHistoricalRebalanceSmallHistoryTest.testReservation - Test has low fail
rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
IgniteWalReaderTest.testArchiveIncompleteSegmentAfterInactivity - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 8{color} [[tests 6 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5728936]]
* IgniteCacheMvccTestSuite8: CleanupRestoredCachesSlowTest.testCleanupSlow -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite8:
ClientCreateCacheGroupOnJoinNodeMapsTest.testNodeMapsVolatile - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite8:
GridCacheRebalancingSyncSelfTest.testSimpleRebalancing - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite8:
GridCacheRebalancingCancelTest.testClientNodeJoinAtRebalancing - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite8:
GridCacheRebalancingAsyncSelfTest.testLoadRebalancing - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite8:
GridCacheRebalancingSyncCheckDataTest.testDataRebalancing - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC PDS 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728941]]
* IgnitePdsMvccTestSuite4:
IgniteClusterActivateDeactivateTestWithPersistenceAndMemoryReuse.testClientReconnectClusterDeactivated
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Queries{color} [[tests 20 TIMEOUT , Out Of Memory Error ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=5728879]]
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationInvoke - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadOperationsTest.testInvokeConsistency - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationSqlDml - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationMixedDml2 - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationMixedPut2 - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationSqlPut - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationMixedDml - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
CacheMvccSizeWithConcurrentJdbcTransactionTest.testSize - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadBulkOpsTest.testRepeatableReadIsolationMixedPut - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadOperationsTest.testRepeatableReadIsolationGetPut - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccSqlTestSuite:
MvccRepeatableReadOperationsTest.testRepeatableReadIsolationInvoke - Test has
low fail rate in base branch 0,0% and is not flaky
... and 9 tests blockers
[jira] [Updated] (IGNITE-13670) Upgrade nullmap to null-defaults map
[ https://issues.apache.org/jira/browse/IGNITE-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13670: -- Description: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). Also, need to add support for skipping writing nullmaps (use the flags bit). was: The nullmap is currently always written to the tuple layout for all columns (even if there are no nullable columns). This data structure can be further used to encode default values for non-nullable columns (either a user-specified value or 0 for primitives). The bits will still be left unused for non-null non-primitive types (UUID, String, byte[], etc). > Upgrade nullmap to null-defaults map > > > Key: IGNITE-13670 > URL: https://issues.apache.org/jira/browse/IGNITE-13670 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > The nullmap is currently always written to the tuple layout for all columns > (even if there are no nullable columns). This data structure can be further > used to encode default values for non-nullable columns (either a > user-specified value or 0 for primitives). > The bits will still be left unused for non-null non-primitive types (UUID, > String, byte[], etc). > Also, need to add support for skipping writing nullmaps (use the flags bit). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13693) Add flags field with tombstone support, update schema size to 2 bytes
[ https://issues.apache.org/jira/browse/IGNITE-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-13693: -- Description: After the IEP discussion, we agreed to extend the schema identifier size to 2 bytes and introduce flags byte to support tombstones. Need to implement these enhancements in the Tuple and TupleAssembler. > Add flags field with tombstone support, update schema size to 2 bytes > - > > Key: IGNITE-13693 > URL: https://issues.apache.org/jira/browse/IGNITE-13693 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Labels: iep-54, ignite-3 > > After the IEP discussion, we agreed to extend the schema identifier size to 2 > bytes and introduce flags byte to support tombstones. Need to implement these > enhancements in the Tuple and TupleAssembler. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13693) Add flags field with tombstone support, update schema size to 2 bytes
Alexey Goncharuk created IGNITE-13693: - Summary: Add flags field with tombstone support, update schema size to 2 bytes Key: IGNITE-13693 URL: https://issues.apache.org/jira/browse/IGNITE-13693 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13663: - Assignee: Vladimir Steshin (was: Denis A. Magda) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6, 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem appear in ability of node to run with several addresses. By > default, all available addresses are assigned to node. Connection to a node is > established to one of its address (first non-loopback). But if lost, other > addresses are attempted to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13663: -- Affects Version/s: (was: 2.6) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem appear in ability of node to run with several addresses. By > default, all available addresses are assigned to node. Connection to a node is > established to one of its address (first non-loopback). But if lost, other > addresses are attempted to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13206) Represent in the documenttion affection of several node addresses on failure detection.
[ https://issues.apache.org/jira/browse/IGNITE-13206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13206: - Assignee: Vladimir Steshin (was: Denis A. Magda) > Represent in the documenttion affection of several node addresses on failure > detection. > --- > > Key: IGNITE-13206 > URL: https://issues.apache.org/jira/browse/IGNITE-13206 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > > We should emphasize that TcpDiscoverySpi prolongs detection of node failure > if several IP addresses are set. Actual failure detection delay is: > _failureDetectionTimeout * addressesNumber_. > "You should assing multiple addresses to a node only if they represent some > real physical connections which can give more reliability. Several addresses > prolong failure detection of current node. The timeouts and settings on > network operations (_failureDetectionTimeout(), sockTimeout, ackTimeout, > maxAckTimeout, reconCnt_) work per connection/address. The exception is > _connRecoveryTimeout_. > Example: if you have 3 ip addresses configured for a node, Tcp Discovery > takes up to '_failureDetectionTimeout * 3 + connRecoveryTimeout' to detect > failure of this node_". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13662) Describe soLinger setting in TCP Discovery and SSL issues.
[ https://issues.apache.org/jira/browse/IGNITE-13662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-13662: - Assignee: Vladimir Steshin (was: Denis A. Magda) > Describe soLinger setting in TCP Discovery and SSL issues. > -- > > Key: IGNITE-13662 > URL: https://issues.apache.org/jira/browse/IGNITE-13662 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Fix For: 2.10 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Discribe soLinger setting in TCP Discovery and SSL issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12666) Provide cluster performance profiling tool
[ https://issues.apache.org/jira/browse/IGNITE-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12666: - Labels: IEP-35 important (was: IEP-35) > Provide cluster performance profiling tool > -- > > Key: IGNITE-12666 > URL: https://issues.apache.org/jira/browse/IGNITE-12666 > Project: Ignite > Issue Type: New Feature >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Critical > Labels: IEP-35, important > Fix For: 2.10 > > Time Spent: 29h > Remaining Estimate: 0h > > For now, Ignite has not build-in profiling tool for user's operations and > internal processes. Such a tool will be able to collect performance > statistics and create a human-readable report. It will help to analyze > workload and to tune configuration and applications. > Example of similar tools in other products: AWR > [[1]|https://docs.oracle.com/cd/E11882_01/server.112/e41573/autostat.htm#PFGRF94176] > [[2]|http://www.dba-oracle.com/t_sample_awr_report.htm] > [[3]|http://expertoracle.com/2018/02/06/performance-tuning-basics-15-awr-report-analysis/] > (Oracle) ; pgbadger [[4]|https://github.com/darold/pgbadger], pgmetrics > [[5]|https://pgmetrics.io/docs/index.html#example], powa > [[6]|https://powa.readthedocs.io/en/latest/] (PostgresSQL). Example of html > report: [powa|https://powa.readthedocs.io/en/latest/]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12666) Provide cluster performance profiling tool
[ https://issues.apache.org/jira/browse/IGNITE-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12666: - Fix Version/s: 2.10 > Provide cluster performance profiling tool > -- > > Key: IGNITE-12666 > URL: https://issues.apache.org/jira/browse/IGNITE-12666 > Project: Ignite > Issue Type: New Feature >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Labels: IEP-35 > Fix For: 2.10 > > Time Spent: 29h > Remaining Estimate: 0h > > For now, Ignite has not build-in profiling tool for user's operations and > internal processes. Such a tool will be able to collect performance > statistics and create a human-readable report. It will help to analyze > workload and to tune configuration and applications. > Example of similar tools in other products: AWR > [[1]|https://docs.oracle.com/cd/E11882_01/server.112/e41573/autostat.htm#PFGRF94176] > [[2]|http://www.dba-oracle.com/t_sample_awr_report.htm] > [[3]|http://expertoracle.com/2018/02/06/performance-tuning-basics-15-awr-report-analysis/] > (Oracle) ; pgbadger [[4]|https://github.com/darold/pgbadger], pgmetrics > [[5]|https://pgmetrics.io/docs/index.html#example], powa > [[6]|https://powa.readthedocs.io/en/latest/] (PostgresSQL). Example of html > report: [powa|https://powa.readthedocs.io/en/latest/]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12666) Provide cluster performance profiling tool
[ https://issues.apache.org/jira/browse/IGNITE-12666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-12666: - Priority: Critical (was: Major) > Provide cluster performance profiling tool > -- > > Key: IGNITE-12666 > URL: https://issues.apache.org/jira/browse/IGNITE-12666 > Project: Ignite > Issue Type: New Feature >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Critical > Labels: IEP-35 > Fix For: 2.10 > > Time Spent: 29h > Remaining Estimate: 0h > > For now, Ignite has not build-in profiling tool for user's operations and > internal processes. Such a tool will be able to collect performance > statistics and create a human-readable report. It will help to analyze > workload and to tune configuration and applications. > Example of similar tools in other products: AWR > [[1]|https://docs.oracle.com/cd/E11882_01/server.112/e41573/autostat.htm#PFGRF94176] > [[2]|http://www.dba-oracle.com/t_sample_awr_report.htm] > [[3]|http://expertoracle.com/2018/02/06/performance-tuning-basics-15-awr-report-analysis/] > (Oracle) ; pgbadger [[4]|https://github.com/darold/pgbadger], pgmetrics > [[5]|https://pgmetrics.io/docs/index.html#example], powa > [[6]|https://powa.readthedocs.io/en/latest/] (PostgresSQL). Example of html > report: [powa|https://powa.readthedocs.io/en/latest/]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11704) Write tombstones during rebalance to get rid of deferred delete buffer
[ https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229918#comment-17229918 ] Maxim Muzafarov commented on IGNITE-11704: -- [~ascherbakov] Hello, should we expect this issue to be included into 2.10 release? > Write tombstones during rebalance to get rid of deferred delete buffer > -- > > Key: IGNITE-11704 > URL: https://issues.apache.org/jira/browse/IGNITE-11704 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Alexey Scherbakov >Priority: Major > Labels: rebalance > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently Ignite relies on deferred delete buffer in order to handle > write-remove conflicts during rebalance. Given the limit size of the buffer, > this approach is fundamentally flawed, especially in case when persistence is > enabled. > I suggest to extend the logic of data storage to be able to store key > tombstones - to keep version for deleted entries. The tombstones will be > stored when rebalance is in progress and should be cleaned up when rebalance > is completed. > Later this approach may be used to implement fast partition rebalance based > on merkle trees (in this case, tombstones should be written on an incomplete > baseline). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13665) Useless failure trace "IgnitionEx$IgniteNamedInstance$2.apply"
[
https://issues.apache.org/jira/browse/IGNITE-13665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229916#comment-17229916
]
Ilya Kasnacheev commented on IGNITE-13665:
--
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BasicTestsWithPersistence/5727426
tests passed
> Useless failure trace "IgnitionEx$IgniteNamedInstance$2.apply"
> --
>
> Key: IGNITE-13665
> URL: https://issues.apache.org/jira/browse/IGNITE-13665
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Labels: 2.9.1-rc
> Fix For: 2.9.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When failure handler catches an issue in striped pool, maybe in some other
> cases, thread dump is as folows:
> {code}
> [2020-10-10T10:10:10,100][WARN ][grid-timeout-worker-#22%cluster%][] Possible
> failure suppressed accordingly to a configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class
> o.a.i.IgniteException: GridWorker [name=sys-stripe-0,
> igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]]]
> org.apache.ignite.IgniteException: GridWorker [name=sys-stripe-0,
> igniteInstanceName=instance, finished=false, heartbeatTs=1601234567890]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1859)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1854)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:296)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:265)
> [ignite-core.jar]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> [ignite-core.jar]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> when the actual stack trace from the relevant thread is hidden somewhere deep
> below. And may even be suppressed. This is a usability nightmare.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13663) Represent in the documenttion affection of several node addresses on failure detection v2.
[ https://issues.apache.org/jira/browse/IGNITE-13663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13663: - Priority: Major (was: Minor) > Represent in the documenttion affection of several node addresses on failure > detection v2. > -- > > Key: IGNITE-13663 > URL: https://issues.apache.org/jira/browse/IGNITE-13663 > Project: Ignite > Issue Type: Improvement > Components: documentation >Affects Versions: 2.6, 2.7.6, 2.9, 2.8.1 >Reporter: Vladimir Steshin >Assignee: Denis A. Magda >Priority: Major > Labels: iep-45 > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should emphasize in the documentation that TcpDiscoverySpi prolongs > detection of node failure if several IP addresses are set. Actual failure > detection delay is: failureDetectionTimeout * addressesNumber + > connRecoveryTimeout. > The problem appear in ability of node to run with several addresses. By > default, all available addresses are assigned to node. Connection to a node is > established to one of its address (first non-loopback). But if lost, other > addresses are attempted to reconnect to sequentially. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13385) Documentation of cache warm-up strategy
[ https://issues.apache.org/jira/browse/IGNITE-13385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13385: - Component/s: documentation > Documentation of cache warm-up strategy > --- > > Key: IGNITE-13385 > URL: https://issues.apache.org/jira/browse/IGNITE-13385 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Kirill Tkalenko >Priority: Blocker > Labels: IEP-40 > Fix For: 2.10 > > > Need to add documentation about the warm-up strategies that are implemented > for IEP-40, as well as about the possibility of stopping it via control.sh > and jmx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13385) Documentation of cache warm-up strategy
[ https://issues.apache.org/jira/browse/IGNITE-13385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13385: - Priority: Blocker (was: Minor) > Documentation of cache warm-up strategy > --- > > Key: IGNITE-13385 > URL: https://issues.apache.org/jira/browse/IGNITE-13385 > Project: Ignite > Issue Type: Test >Reporter: Kirill Tkalenko >Priority: Blocker > Labels: IEP-40 > Fix For: 2.10 > > > Need to add documentation about the warm-up strategies that are implemented > for IEP-40, as well as about the possibility of stopping it via control.sh > and jmx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13385) Documentation of cache warm-up strategy
[ https://issues.apache.org/jira/browse/IGNITE-13385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13385: - Issue Type: Task (was: Test) > Documentation of cache warm-up strategy > --- > > Key: IGNITE-13385 > URL: https://issues.apache.org/jira/browse/IGNITE-13385 > Project: Ignite > Issue Type: Task >Reporter: Kirill Tkalenko >Priority: Blocker > Labels: IEP-40 > Fix For: 2.10 > > > Need to add documentation about the warm-up strategies that are implemented > for IEP-40, as well as about the possibility of stopping it via control.sh > and jmx. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13648) Tests failing for extensions modules
[
https://issues.apache.org/jira/browse/IGNITE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13648:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Tests failing for extensions modules
>
>
> Key: IGNITE-13648
> URL: https://issues.apache.org/jira/browse/IGNITE-13648
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Saikat Maitra
>Assignee: Saikat Maitra
>Priority: Major
>
> Tests failing for extensions modules
>
> {code}
> org.apache.ignite.IgniteException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTestsStarted(IgniteSinkConnectorTest.java:136)
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTestsStarted(IgniteSinkConnectorTest.java:136)
> Caused by: org.apache.ignite.IgniteCheckedException: Remote node has peer
> class loading enabled flag different from local [locId8=dfc9ddaf,
> locPeerClassLoading=true, rmtId8=fee013c8, rmtPeerClassLoading=false,
> rmtAddrs=[9dc3d9f4b167/127.0.0.1, /172.17.0.6], rmtNode=ClusterNode
> [id=fee013c8-d398-4cdc-92f5-c368c5fc663a, order=1, addr=[127.0.0.1,
> 172.17.0.6], daemon=false]]
> at
> org.apache.ignite.stream.kafka.connect.IgniteSinkConnectorTest.beforeTestsStarted(IgniteSinkConnectorTest.java:136)
> {code}
>
>
> {code}
> org.apache.ignite.IgniteException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.stream.kafka.connect.IgniteSourceConnectorTest.beforeTestsStarted(IgniteSourceConnectorTest.java:96)
> Caused by: org.apache.ignite.IgniteCheckedException: Failed to start manager:
> GridManagerAdapter [enabled=true,
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at
> org.apache.ignite.stream.kafka.connect.IgniteSourceConnectorTest.beforeTestsStarted(IgniteSourceConnectorTest.java:96)
> Caused by: org.apache.ignite.IgniteCheckedException: Remote node has peer
> class loading enabled flag different from local [locId8=bbb64dda,
> locPeerClassLoading=true, rmtId8=fee013c8, rmtPeerClassLoading=false,
> rmtAddrs=[9dc3d9f4b167/127.0.0.1, /172.17.0.6], rmtNode=ClusterNode
> [id=fee013c8-d398-4cdc-92f5-c368c5fc663a, order=1, addr=[127.0.0.1,
> 172.17.0.6], daemon=false]]
> at
> org.apache.ignite.stream.kafka.connect.IgniteSourceConnectorTest.beforeTestsStarted(IgniteSourceConnectorTest.java:96)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13608) .NET: Add Partitions and UpdateBatchSize to SqlFieldsQuery
[
https://issues.apache.org/jira/browse/IGNITE-13608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229835#comment-17229835
]
Ignite TC Bot commented on IGNITE-13608:
{panel:title=Branch: [pull/8445/head] Base: [master] : Possible Blockers
(334)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 5 TIMEOUT , Out Of Memory Error ,
Exit Code |https://ci.ignite.apache.org/viewLog.html?buildId=5728811]]
* IgniteCacheMvccTestSuite7:
WalModeChangeAdvancedSelfTest.testConcurrentOperations - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite7: WalModeChangeAdvancedSelfTest.testClientReconnect
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite7: WalModeChangeAdvancedSelfTest.testCacheDestroy -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite7:
IgniteDynamicCacheStartFailWithPersistenceTest.testConcurrentClientNodeJoins -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheMvccTestSuite7: WalModeChangeAdvancedSelfTest.testJoin - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 9{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5728813]]
* IgniteCacheMvccTestSuite9:
IgniteTxCacheWriteSynchronizationModesMultithreadedTest.testMultithreadedFullAsyncRestart
- Test has low fail rate in base branch 1,3% and is not flaky
{color:#d04437}Examples{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5728721]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 3 TC_SERVICE_MESSAGE
|https://ci.ignite.apache.org/viewLog.html?buildId=5728792]]
* dll: CacheLinqTestSimpleName.TestIntrospection - Test has low fail rate in
base branch 0,0% and is not flaky
* dll: CacheLinqTestSqlEscapeAll.TestIntrospection - Test has low fail rate in
base branch 0,0% and is not flaky
* dll: CacheLinqTest.TestIntrospection - Test has low fail rate in base branch
0,0% and is not flaky
{color:#d04437}MVCC PDS 2{color} [[tests 46 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5728815]]
* IgnitePdsMvccTestSuite2:
IgniteWalReplayingAfterRestartTest.testWalRecordsAfterRestart - Test has low
fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
IgniteWalHistoryReservationsTest.testCheckpointsNotReserveWithWalModeNone -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2: FreeListCachingTest.testPageListCacheLimit - Test
has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
FullHistRebalanceOnClientStopTest.testFullRebalanceNotTriggeredWhenClientNodeStopsDuringPme
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2: CheckpointFreeListTest.testFreeListRestoredCorrectly
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
IgniteLocalWalSizeTest.testLocalSegmentSizesWithoutArchiveWithCompression -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
IgniteLocalWalSizeTest.testLocalSegmentSizesWithoutArchive - Test has low fail
rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
IgniteWalRecoverySeveralRestartsTest.testWalRecoverySeveralRestarts - Test has
low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2: CheckpointStartLoggingTest.testCheckpointLogging -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsMvccTestSuite2:
IgniteWalReaderTest.testIteratorWithCurrentKernelContext - Test has low fail
rate in base branch 1,3% and is not flaky
* IgnitePdsMvccTestSuite2: IgniteWalFlushFailoverTest.testErrorOnFlushByTimeout
- Test has low fail rate in base branch 0,0% and is not flaky
... and 35 tests blockers
{color:#d04437}Platform C++ (Win x64 / Release){color} [[tests 21
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=5728748]]
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryByteArrayInsertSelect -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCoreTest: BinaryIdentityResolverTestSuite: IdentityEquilityWithGuid -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCoreTest: BinaryIdentityResolverTestSuite: IdentityEquilityWithoutGuid
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCoreTest: CacheQueryTestSuite: TestSqlFieldsQueryBasic - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQuerySingle - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryExceptions - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryTwo - Test has low fail
