[jira] [Updated] (IGNITE-14919) [ML] issus for BostonHousePricesPredictionExample
[
https://issues.apache.org/jira/browse/IGNITE-14919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
zhujiebing updated IGNITE-14919:
Description:
The version I use is 2.9.1 .
When I run this example，returns as follows. When I put the
boston_housing_dataset.txt's first sample data into the formula（Fitting
equation ？），I got a negative number （-68.2154436）。I want to know the reason for
the negative number。 thanks very much.Thanks for answering。
The first sample data is as follows。
0.02731,0.00,7.070,0,0.4690,6.4210,78.90,4.9671,2,242.0,17.80,396.90,9.14,21.60
Output
>>> Model: 0.04*f0 - 0.05*f1 - 0.79*f2 - 10.01*f3 + 0.28*f4 + 0.01*f5 - 0.89*f6
>>> + 0.54*f7 - 0.00*f8 - 0.18*f9 - 0.01*f10 + 0.09*f11 - 0.15*f12 + 14.10
>>> R^2 score: 0.5871216903877478
@org.junit.Test
public void test222()
{ System.out.println(0.04*0.02731 - 0.05*0.00 - 0.79*7.070 - 10.01*0 +
0.28*0.4690 + 0.01*6.4210 - 0.89*78.90 + 0.54*4.9671 - 0.00*2 - 0.18*242.0 -
0.01*17.80 + 0.09*396.90 - 0.15*9.14 + 14.10); // -68.2154436 }
very thankful。
was:
The version I use is 2.9.1 .
When I run this example，returns as follows. When I put the
boston_housing_dataset.txt's first sample data into the formula，I got a
negative number （-68.2154436）。I want to know the reason for the negative
number。 thanks very much.Thanks for answering。
The first sample data is as follows。
0.02731,0.00,7.070,0,0.4690,6.4210,78.90,4.9671,2,242.0,17.80,396.90,9.14,21.60
Output
>>> Model: 0.04*f0 - 0.05*f1 - 0.79*f2 - 10.01*f3 + 0.28*f4 + 0.01*f5 - 0.89*f6
>>> + 0.54*f7 - 0.00*f8 - 0.18*f9 - 0.01*f10 + 0.09*f11 - 0.15*f12 + 14.10
>>> R^2 score: 0.5871216903877478
@org.junit.Test
public void test222() {
System.out.println(0.04*0.02731 - 0.05*0.00 - 0.79*7.070 - 10.01*0 +
0.28*0.4690 + 0.01*6.4210 - 0.89*78.90 + 0.54*4.9671 - 0.00*2 - 0.18*242.0 -
0.01*17.80 + 0.09*396.90 - 0.15*9.14 + 14.10);
// -68.2154436
}
very thankful。
> [ML] issus for BostonHousePricesPredictionExample
> --
>
> Key: IGNITE-14919
> URL: https://issues.apache.org/jira/browse/IGNITE-14919
> Project: Ignite
> Issue Type: Test
> Components: examples
> Environment: BostonHousePricesPredictionExample
>
> >>> Perform scoring.
> >>> Model: 0.04*f0 - 0.05*f1 - 0.79*f2 - 10.01*f3 + 0.28*f4 + 0.01*f5 -
> >>> 0.89*f6 + 0.54*f7 - 0.00*f8 - 0.18*f9 - 0.01*f10 + 0.09*f11 - 0.15*f12 +
> >>> 14.10
> >>> R^2 score: 0.5871216903877478
> [23:16:23] Ignite node stopped OK [uptime=00:00:00.817]
>Reporter: zhujiebing
>Priority: Major
>
> The version I use is 2.9.1 .
>
> When I run this example，returns as follows. When I put the
> boston_housing_dataset.txt's first sample data into the formula（Fitting
> equation ？），I got a negative number （-68.2154436）。I want to know the reason
> for the negative number。 thanks very much.Thanks for answering。
>
> The first sample data is as follows。
> 0.02731,0.00,7.070,0,0.4690,6.4210,78.90,4.9671,2,242.0,17.80,396.90,9.14,21.60
>
>
> Output
> >>> Model: 0.04*f0 - 0.05*f1 - 0.79*f2 - 10.01*f3 + 0.28*f4 + 0.01*f5 -
> >>> 0.89*f6 + 0.54*f7 - 0.00*f8 - 0.18*f9 - 0.01*f10 + 0.09*f11 - 0.15*f12 +
> >>> 14.10
> >>> R^2 score: 0.5871216903877478
>
> @org.junit.Test
> public void test222()
> { System.out.println(0.04*0.02731 - 0.05*0.00 - 0.79*7.070 - 10.01*0 +
> 0.28*0.4690 + 0.01*6.4210 - 0.89*78.90 + 0.54*4.9671 - 0.00*2 - 0.18*242.0 -
> 0.01*17.80 + 0.09*396.90 - 0.15*9.14 + 14.10); // -68.2154436 }
>
> very thankful。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14919) [ML] issus for BostonHousePricesPredictionExample
zhujiebing created IGNITE-14919:
---
Summary: [ML] issus for BostonHousePricesPredictionExample
Key: IGNITE-14919
URL: https://issues.apache.org/jira/browse/IGNITE-14919
Project: Ignite
Issue Type: Test
Components: examples
Environment: BostonHousePricesPredictionExample
>>> Perform scoring.
>>> Model: 0.04*f0 - 0.05*f1 - 0.79*f2 - 10.01*f3 + 0.28*f4 + 0.01*f5 - 0.89*f6
>>> + 0.54*f7 - 0.00*f8 - 0.18*f9 - 0.01*f10 + 0.09*f11 - 0.15*f12 + 14.10
>>> R^2 score: 0.5871216903877478
[23:16:23] Ignite node stopped OK [uptime=00:00:00.817]
Reporter: zhujiebing
The version I use is 2.9.1 .
When I run this example，returns as follows. When I put the
boston_housing_dataset.txt's first sample data into the formula，I got a
negative number （-68.2154436）。I want to know the reason for the negative
number。 thanks very much.Thanks for answering。
The first sample data is as follows。
0.02731,0.00,7.070,0,0.4690,6.4210,78.90,4.9671,2,242.0,17.80,396.90,9.14,21.60
Output
>>> Model: 0.04*f0 - 0.05*f1 - 0.79*f2 - 10.01*f3 + 0.28*f4 + 0.01*f5 - 0.89*f6
>>> + 0.54*f7 - 0.00*f8 - 0.18*f9 - 0.01*f10 + 0.09*f11 - 0.15*f12 + 14.10
>>> R^2 score: 0.5871216903877478
@org.junit.Test
public void test222() {
System.out.println(0.04*0.02731 - 0.05*0.00 - 0.79*7.070 - 10.01*0 +
0.28*0.4690 + 0.01*6.4210 - 0.89*78.90 + 0.54*4.9671 - 0.00*2 - 0.18*242.0 -
0.01*17.80 + 0.09*396.90 - 0.15*9.14 + 14.10);
// -68.2154436
}
very thankful。
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14844) ignite-examples run error ignite-examples [KMeansClusterizationExample]
[ https://issues.apache.org/jira/browse/IGNITE-14844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhujiebing resolved IGNITE-14844. - Resolution: Not A Problem I have solved this problem。 > ignite-examples run error ignite-examples [KMeansClusterizationExample] > - > > Key: IGNITE-14844 > URL: https://issues.apache.org/jira/browse/IGNITE-14844 > Project: Ignite > Issue Type: Bug > Components: examples >Affects Versions: 2.9.1 >Reporter: zhujiebing >Priority: Major > > when i run example KMeansClusterizationExample. This exception occurred。 > > ```java > D:\software\dbfff\Java\java\jdk1.8.0_31\bin\java.exe > "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA > 2020.3.1\lib\idea_rt.jar=63937:C:\Program Files\JetBrains\IntelliJ IDEA > 2020.3.1\bin" -Dfile.encoding=UTF-8 -classpath >
[jira] [Updated] (IGNITE-14826) .NET: Thin client fails to compute hash code for string and array keys
[
https://issues.apache.org/jira/browse/IGNITE-14826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14826:
Release Note: .NET: Fixed string and array cache keys handling when
partition awareness is enabled (was: .NET: Fix string and array cache keys
handling when partition awareness is enabled)
> .NET: Thin client fails to compute hash code for string and array keys
> --
>
> Key: IGNITE-14826
> URL: https://issues.apache.org/jira/browse/IGNITE-14826
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET
> Fix For: 2.11
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> String keys are not supported in BinaryHashCodeUtils. The following code
> throws "Failed to compute hash code for object" exception:
> {code}
> var server = Ignition.Start();
> var client = Ignition.StartClient(new IgniteClientConfiguration
> {
> Endpoints = new[] {"127.0.0.1"},
> EnablePartitionAwareness = true
> });
> var cache = client.CreateCache("c");
> cache.Put("hello", "world");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14782) .NET: If bash not installed on pod, ignite fails to start
[
https://issues.apache.org/jira/browse/IGNITE-14782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14782:
Ignite Flags: Release Notes Required
Release Note: .NET: Removed the requirement to have bash installed on Linux
and macOS systems
> .NET: If bash not installed on pod, ignite fails to start
> -
>
> Key: IGNITE-14782
> URL: https://issues.apache.org/jira/browse/IGNITE-14782
> Project: Ignite
> Issue Type: Bug
> Components: clients, platforms
>Affects Versions: 2.10
>Reporter: Robert May
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If bash is not installed, you get the following exception on startup:
> {code:c#}
> System.TypeInitializationException: The type initializer for
> 'Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll' threw an exception.
> ---> System.TypeInitializationException: The type initializer for
> 'Apache.Ignite.Core.Impl.Unmanaged.Os' threw an exception.
> ---> System.ComponentModel.Win32Exception (2): No such file or directory
>at System.Diagnostics.Process.ForkAndExecProcess(String filename, String[]
> argv, String[] envp, String cwd, Boolean redirectStdin, Boolean
> redirectStdout, Boolean redirectStderr, Boolean setCredentials, UInt32
> userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd,
> Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
>at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
>at System.Diagnostics.Process.Start()
>at Apache.Ignite.Core.Impl.Shell.Execute(String file, String args)
>at Apache.Ignite.Core.Impl.Shell.BashExecute(String args)
>at Apache.Ignite.Core.Impl.Unmanaged.Os..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.Os.get_IsWindows()
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll..cctor()
>--- End of inner exception stack trace ---
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14702) Inconsistency of the new index when the node falls / deactivates
[
https://issues.apache.org/jira/browse/IGNITE-14702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364436#comment-17364436
]
Ignite TC Bot commented on IGNITE-14702:
{panel:title=Branch: [pull/9150/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9150/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6050268]]
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ResumeCreateIndexTest.testGeneralFlow - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ResumeCreateIndexTest.testErrorFlow - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ResumeCreateIndexTest.testConcurrentBuildNewIndexAndRebuildIndexes0 -
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ResumeCreateIndexTest.testConcurrentBuildNewIndexAndRebuildIndexes1 -
PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ResumeCreateIndexTest.testNoCheckpointAfterIndexCreation - PASSED{color}
* {color:#013220}IgnitePdsWithIndexingTestSuite:
ResumeCreateIndexTest.testPartialCheckpointNewIndexRows - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6049873buildTypeId=IgniteTests24Java8_RunAll]
> Inconsistency of the new index when the node falls / deactivates
>
>
> Key: IGNITE-14702
> URL: https://issues.apache.org/jira/browse/IGNITE-14702
> Project: Ignite
> Issue Type: Bug
> Components: persistence, sql
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> At the moment, if we add a new index and in the middle of its construction we
> fall / deactivate a node, then it will be inconsistent and may create errors.
> Need to either add a new index to DurableBackgroundTask, or add / modify a
> separate mechanism that allows to resume the creation of a new index.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14918) "java.util.concurrent.RejectedExecutionException: event executor terminated" in test logs
[
https://issues.apache.org/jira/browse/IGNITE-14918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14918:
-
Priority: Minor (was: Major)
> "java.util.concurrent.RejectedExecutionException: event executor terminated"
> in test logs
> -
>
> Key: IGNITE-14918
> URL: https://issues.apache.org/jira/browse/IGNITE-14918
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> Sometimes when running tests (particularly tests related to JRaft, e.g.
> {{ITCliServiceTest}}{color:#00})), {color}the following message can be
> seen in logs. This can probably happen due to an invalid shutdown order - we
> are closing the Netty event loop and are trying to send a message afterwards.
> {code:java}
> 2021-06-16 18:47:09:864 +0300 [main] WARN AbstractChannel - Force-closing a
> channel whose registration task was not accepted by an event loop: [id:
> 0x74fc195f]
> java.util.concurrent.RejectedExecutionException: event executor terminated
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:471)
> at
> io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:87)
> at
> io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:81)
> at
> io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:86)
> at
> io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:323)
> at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:155)
> at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:139)
> at
> org.apache.ignite.internal.network.netty.NettyClient.start(NettyClient.java:119)
> at
> org.apache.ignite.internal.network.netty.ConnectionManager.connect(ConnectionManager.java:210)
> at
> org.apache.ignite.internal.network.netty.ConnectionManager.lambda$channel$1(ConnectionManager.java:167)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1932)
> at
> org.apache.ignite.internal.network.netty.ConnectionManager.channel(ConnectionManager.java:165)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$send$4(ScaleCubeDirectMarshallerTransport.java:171)
> at reactor.core.publisher.Mono.lambda$fromFuture$1(Mono.java:508)
> at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:44)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
> at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4190)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4126)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4098)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$requestResponse$8(ScaleCubeDirectMarshallerTransport.java:255)
> at reactor.core.publisher.MonoCreate.subscribe(MonoCreate.java:57)
> at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
> at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
> at reactor.core.publisher.Mono.toFuture(Mono.java:4664)
> at
> org.apache.ignite.network.scalecube.ScaleCubeMessagingService.invoke(ScaleCubeMessagingService.java:125)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.send(IgniteRpcClient.java:165)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.invokeAsync(IgniteRpcClient.java:161)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:182)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:156)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:150)
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.DefaultRaftClientService.timeoutNow(DefaultRaftClientService.java:118)
> at
>
[jira] [Updated] (IGNITE-14918) "java.util.concurrent.RejectedExecutionException: event executor terminated" in test logs
[
https://issues.apache.org/jira/browse/IGNITE-14918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14918:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> "java.util.concurrent.RejectedExecutionException: event executor terminated"
> in test logs
> -
>
> Key: IGNITE-14918
> URL: https://issues.apache.org/jira/browse/IGNITE-14918
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> Sometimes when running tests (particularly tests related to JRaft, e.g.
> {{ITCliServiceTest}}{color:#00})), {color}the following message can be
> seen in logs. This can probably happen due to an invalid shutdown order - we
> are closing the Netty event loop and are trying to send a message afterwards.
> {code:java}
> 2021-06-16 18:47:09:864 +0300 [main] WARN AbstractChannel - Force-closing a
> channel whose registration task was not accepted by an event loop: [id:
> 0x74fc195f]
> java.util.concurrent.RejectedExecutionException: event executor terminated
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
> at
> io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:471)
> at
> io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:87)
> at
> io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:81)
> at
> io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:86)
> at
> io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:323)
> at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:155)
> at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:139)
> at
> org.apache.ignite.internal.network.netty.NettyClient.start(NettyClient.java:119)
> at
> org.apache.ignite.internal.network.netty.ConnectionManager.connect(ConnectionManager.java:210)
> at
> org.apache.ignite.internal.network.netty.ConnectionManager.lambda$channel$1(ConnectionManager.java:167)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1932)
> at
> org.apache.ignite.internal.network.netty.ConnectionManager.channel(ConnectionManager.java:165)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$send$4(ScaleCubeDirectMarshallerTransport.java:171)
> at reactor.core.publisher.Mono.lambda$fromFuture$1(Mono.java:508)
> at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:44)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
> at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4190)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4126)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4098)
> at
> org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$requestResponse$8(ScaleCubeDirectMarshallerTransport.java:255)
> at reactor.core.publisher.MonoCreate.subscribe(MonoCreate.java:57)
> at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
> at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
> at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
> at reactor.core.publisher.Mono.toFuture(Mono.java:4664)
> at
> org.apache.ignite.network.scalecube.ScaleCubeMessagingService.invoke(ScaleCubeMessagingService.java:125)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.send(IgniteRpcClient.java:165)
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.invokeAsync(IgniteRpcClient.java:161)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:182)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:156)
> at
> org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:150)
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.DefaultRaftClientService.timeoutNow(DefaultRaftClientService.java:118)
> at
>
[jira] [Updated] (IGNITE-14918) "java.util.concurrent.RejectedExecutionException: event executor terminated" in test logs
[
https://issues.apache.org/jira/browse/IGNITE-14918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14918:
-
Description:
Sometimes when running tests (particularly tests related to JRaft, e.g.
{{ITCliServiceTest}}{color:#00})), {color}the following message can be seen
in logs. This can probably happen due to an invalid shutdown order - we are
closing the Netty event loop and are trying to send a message afterwards.
{code:java}
2021-06-16 18:47:09:864 +0300 [main] WARN AbstractChannel - Force-closing a
channel whose registration task was not accepted by an event loop: [id:
0x74fc195f]
java.util.concurrent.RejectedExecutionException: event executor terminated
at
io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
at
io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
at
io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:471)
at
io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:87)
at
io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:81)
at
io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:86)
at
io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:323)
at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:155)
at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:139)
at
org.apache.ignite.internal.network.netty.NettyClient.start(NettyClient.java:119)
at
org.apache.ignite.internal.network.netty.ConnectionManager.connect(ConnectionManager.java:210)
at
org.apache.ignite.internal.network.netty.ConnectionManager.lambda$channel$1(ConnectionManager.java:167)
at
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1932)
at
org.apache.ignite.internal.network.netty.ConnectionManager.channel(ConnectionManager.java:165)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$send$4(ScaleCubeDirectMarshallerTransport.java:171)
at reactor.core.publisher.Mono.lambda$fromFuture$1(Mono.java:508)
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:44)
at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
at reactor.core.publisher.Mono.subscribe(Mono.java:4190)
at reactor.core.publisher.Mono.subscribe(Mono.java:4126)
at reactor.core.publisher.Mono.subscribe(Mono.java:4098)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$requestResponse$8(ScaleCubeDirectMarshallerTransport.java:255)
at reactor.core.publisher.MonoCreate.subscribe(MonoCreate.java:57)
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
at reactor.core.publisher.Mono.toFuture(Mono.java:4664)
at
org.apache.ignite.network.scalecube.ScaleCubeMessagingService.invoke(ScaleCubeMessagingService.java:125)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.send(IgniteRpcClient.java:165)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.invokeAsync(IgniteRpcClient.java:161)
at
org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:182)
at
org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:156)
at
org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:150)
at
org.apache.ignite.raft.jraft.rpc.impl.core.DefaultRaftClientService.timeoutNow(DefaultRaftClientService.java:118)
at
org.apache.ignite.raft.jraft.core.Replicator.timeoutNow(Replicator.java:1667)
at
org.apache.ignite.raft.jraft.core.Replicator.sendTimeoutNow(Replicator.java:1653)
at
org.apache.ignite.raft.jraft.core.Replicator.sendTimeoutNowAndStop(Replicator.java:1789)
at
org.apache.ignite.raft.jraft.core.NodeImpl.stepDown(NodeImpl.java:1276)
at
org.apache.ignite.raft.jraft.core.NodeImpl.shutdown(NodeImpl.java:2749)
at
org.apache.ignite.raft.jraft.core.NodeImpl.shutdown(NodeImpl.java:2428)
at
[jira] [Created] (IGNITE-14918) "java.util.concurrent.RejectedExecutionException: event executor terminated" in test logs
Aleksandr Polovtcev created IGNITE-14918:
Summary: "java.util.concurrent.RejectedExecutionException: event
executor terminated" in test logs
Key: IGNITE-14918
URL: https://issues.apache.org/jira/browse/IGNITE-14918
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Sometimes when running tests (particularly tests related to JRaft, e.g.
{{ITCliServiceTest{color:#00}}})), {color}the following message can be seen
in logs:{color:#00}
{color}
{code:java}
2021-06-16 18:47:09:864 +0300 [main] WARN AbstractChannel - Force-closing a
channel whose registration task was not accepted by an event loop: [id:
0x74fc195f]
java.util.concurrent.RejectedExecutionException: event executor terminated
at
io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:926)
at
io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:353)
at
io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:346)
at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:828)
at
io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:818)
at
io.netty.channel.AbstractChannel$AbstractUnsafe.register(AbstractChannel.java:471)
at
io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:87)
at
io.netty.channel.SingleThreadEventLoop.register(SingleThreadEventLoop.java:81)
at
io.netty.channel.MultithreadEventLoopGroup.register(MultithreadEventLoopGroup.java:86)
at
io.netty.bootstrap.AbstractBootstrap.initAndRegister(AbstractBootstrap.java:323)
at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:155)
at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:139)
at
org.apache.ignite.internal.network.netty.NettyClient.start(NettyClient.java:119)
at
org.apache.ignite.internal.network.netty.ConnectionManager.connect(ConnectionManager.java:210)
at
org.apache.ignite.internal.network.netty.ConnectionManager.lambda$channel$1(ConnectionManager.java:167)
at
java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1932)
at
org.apache.ignite.internal.network.netty.ConnectionManager.channel(ConnectionManager.java:165)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$send$4(ScaleCubeDirectMarshallerTransport.java:171)
at reactor.core.publisher.Mono.lambda$fromFuture$1(Mono.java:508)
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:44)
at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
at reactor.core.publisher.Mono.subscribe(Mono.java:4190)
at reactor.core.publisher.Mono.subscribe(Mono.java:4126)
at reactor.core.publisher.Mono.subscribe(Mono.java:4098)
at
org.apache.ignite.network.scalecube.ScaleCubeDirectMarshallerTransport.lambda$requestResponse$8(ScaleCubeDirectMarshallerTransport.java:255)
at reactor.core.publisher.MonoCreate.subscribe(MonoCreate.java:57)
at reactor.core.publisher.MonoDefer.subscribe(MonoDefer.java:52)
at reactor.core.publisher.Mono.subscribe(Mono.java:4219)
at reactor.core.publisher.Mono.subscribeWith(Mono.java:4330)
at reactor.core.publisher.Mono.toFuture(Mono.java:4664)
at
org.apache.ignite.network.scalecube.ScaleCubeMessagingService.invoke(ScaleCubeMessagingService.java:125)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.send(IgniteRpcClient.java:165)
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcClient.invokeAsync(IgniteRpcClient.java:161)
at
org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:182)
at
org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:156)
at
org.apache.ignite.raft.jraft.rpc.impl.AbstractClientService.invokeWithDone(AbstractClientService.java:150)
at
org.apache.ignite.raft.jraft.rpc.impl.core.DefaultRaftClientService.timeoutNow(DefaultRaftClientService.java:118)
at
org.apache.ignite.raft.jraft.core.Replicator.timeoutNow(Replicator.java:1667)
at
org.apache.ignite.raft.jraft.core.Replicator.sendTimeoutNow(Replicator.java:1653)
at
org.apache.ignite.raft.jraft.core.Replicator.sendTimeoutNowAndStop(Replicator.java:1789)
at
org.apache.ignite.raft.jraft.core.NodeImpl.stepDown(NodeImpl.java:1276)
at
org.apache.ignite.raft.jraft.core.NodeImpl.shutdown(NodeImpl.java:2749)
at
org.apache.ignite.raft.jraft.core.NodeImpl.shutdown(NodeImpl.java:2428)
at
[jira] [Comment Edited] (IGNITE-14917) Fix internal packages naming in configuration modules
[
https://issues.apache.org/jira/browse/IGNITE-14917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364350#comment-17364350
]
Andrey N. Gura edited comment on IGNITE-14917 at 6/16/21, 3:38 PM:
---
[~ibessonov] LGTM. Thanks for contribution! Please, proceed with merge.
was (Author: agura):
[~ibessonov] LGTM. Thanks for contribution!
> Fix internal packages naming in configuration modules
> -
>
> Key: IGNITE-14917
> URL: https://issues.apache.org/jira/browse/IGNITE-14917
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {{org.apache.ignite.internal.}} should be a continuous prefix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14917) Fix internal packages naming in configuration modules
[
https://issues.apache.org/jira/browse/IGNITE-14917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14917:
---
Description:
{{org.apache.ignite.internal.}} should be a continuous prefix.
Current packages ...configuration.internal.* and
...configuration.processor.internal.* break this rule. There's also package
collision in configuration module that can be avoided.
was:{{org.apache.ignite.internal.}} should be a continuous prefix.
> Fix internal packages naming in configuration modules
> -
>
> Key: IGNITE-14917
> URL: https://issues.apache.org/jira/browse/IGNITE-14917
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {{org.apache.ignite.internal.}} should be a continuous prefix.
> Current packages ...configuration.internal.* and
> ...configuration.processor.internal.* break this rule. There's also package
> collision in configuration module that can be avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14849) Calcite engine. Support '%' operator as alias for 'mod' function
[
https://issues.apache.org/jira/browse/IGNITE-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364351#comment-17364351
]
Stanilovsky Evgeny commented on IGNITE-14849:
-
looks good !
> Calcite engine. Support '%' operator as alias for 'mod' function
>
>
> Key: IGNITE-14849
> URL: https://issues.apache.org/jira/browse/IGNITE-14849
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, the H2-based SQL engine supports both {{a % b}} and {{mod(a, b)}}
> syntax for the modulo operation. But calcite-based engine supports only
> {{mod(a, b)}} syntax. Support for {{%}} operator should be added to minimize
> compatibility issues.
> Affected tests:
> {{src/test/sql/aggregate/group/test_group_by.test}}
> And many other.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-14912) AssertionError in ITJRaftCounterServerTest
[
https://issues.apache.org/jira/browse/IGNITE-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev resolved IGNITE-14912.
--
Resolution: Cannot Reproduce
> AssertionError in ITJRaftCounterServerTest
> --
>
> Key: IGNITE-14912
> URL: https://issues.apache.org/jira/browse/IGNITE-14912
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: _Test_-_Run_Integration_Tests_708.log
>
>
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.startServer(ITJRaftCounterServerTest.java:161)
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.doTestFollowerCatchUp(ITJRaftCounterServerTest.java:503)
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromLog2(ITJRaftCounterServerTest.java:431){noformat}
> Full log from TC is attached.
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6048662?expandedTest=build%3A%28id%3A6048660%29%2Cid%3A5313
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14917) Fix internal packages naming in configuration modules
Ivan Bessonov created IGNITE-14917:
--
Summary: Fix internal packages naming in configuration modules
Key: IGNITE-14917
URL: https://issues.apache.org/jira/browse/IGNITE-14917
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha2
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
Fix For: 3.0.0-alpha3
{{org.apache.ignite.internal.}} should be a continuous prefix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14899) PagesWriteSpeedBasedThrottle wrong appliance
[ https://issues.apache.org/jira/browse/IGNITE-14899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364327#comment-17364327 ] Ivan Bessonov commented on IGNITE-14899: [~sdanilov] thank you for the fix, code looks good! > PagesWriteSpeedBasedThrottle wrong appliance > > > Key: IGNITE-14899 > URL: https://issues.apache.org/jira/browse/IGNITE-14899 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > > During the investigation of the throttling algorithm I found out that it > doesn’t exactly match the description provided in readme > ([https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/README.md]). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14910) ITJRaftCounterServerTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364324#comment-17364324 ] Ivan Bessonov commented on IGNITE-14910: [~apolovtcev] thank you for another fix, I'll merge it > ITJRaftCounterServerTest fails locally > -- > > Key: IGNITE-14910 > URL: https://issues.apache.org/jira/browse/IGNITE-14910 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: ITJRaftCounterServerTest.log > > Time Spent: 10m > Remaining Estimate: 0h > > See attached logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14911) Inconsistent and confusing timeout properties in python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14911: - Summary: Inconsistent and confusing timeout properties in python thin client (was: Inconsistent and confused timeout properties in python thin client) > Inconsistent and confusing timeout properties in python thin client > --- > > Key: IGNITE-14911 > URL: https://issues.apache.org/jira/browse/IGNITE-14911 > Project: Ignite > Issue Type: Task > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Blocker > Labels: python, thin > Fix For: python-0.5.0 > > > Currently, in python thin client timeout values can be set in int and float. > 1. Timeouts for sql and cache properties are set using int as milliseconds > 2. Timeouts for tx and expiry policy can be set either in float (as seconds) > and in int as milliseconds (not released yet) > But in python traditionally all timeouts are set using float and int as > *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms > are set as 0.12) > We can solve this issue in many ways > 1. Completely change to traditional way (and probably broke backward > compatibility) > 2. Change logic as for transactions for all timeouts with deprecation warning > and with advice using only float. > 3. Change logic for transaction or expiry_policy traditionally, for all > others timeouts as in point 2. (This is not consitent) > 4. Set all timeouts in ints and milliseconds (except for socket timeout in > `Connection`) and optionally for ExpiryPolicy accept also > `datetime.timedelta`. > I suppose, that forth variant is the best option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14916) Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered.
[ https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-14916: --- Assignee: Taras Ledkov (was: Stanilovsky Evgeny) > Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if > all conditions are covered. > --- > > Key: IGNITE-14916 > URL: https://issues.apache.org/jira/browse/IGNITE-14916 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Taras Ledkov >Priority: Major > Labels: calcite > > FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it > takes into account only _searchRow_ which can be partial representation of > _condition_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14916) Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered.
[ https://issues.apache.org/jira/browse/IGNITE-14916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-14916: --- Assignee: Stanilovsky Evgeny > Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if > all conditions are covered. > --- > > Key: IGNITE-14916 > URL: https://issues.apache.org/jira/browse/IGNITE-14916 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite > > FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it > takes into account only _searchRow_ which can be partial representation of > _condition_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14916) Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered.
Stanilovsky Evgeny created IGNITE-14916: --- Summary: Calcite. FilterSpoolMergeToHashIndexSpoolRule need to be applicable only if all conditions are covered. Key: IGNITE-14916 URL: https://issues.apache.org/jira/browse/IGNITE-14916 Project: Ignite Issue Type: Improvement Components: sql Reporter: Stanilovsky Evgeny FilterSpoolMergeToHashIndexSpoolRule can return erroneous results cause it takes into account only _searchRow_ which can be partial representation of _condition_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14915) Fix packet structure in network and network-processor modules
[
https://issues.apache.org/jira/browse/IGNITE-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14915:
Labels: ignite-3 (was: )
> Fix packet structure in network and network-processor modules
> -
>
> Key: IGNITE-14915
> URL: https://issues.apache.org/jira/browse/IGNITE-14915
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-alpha2
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> {{network}} and {{network-processor}} modules violate the packet structure,
> defined in the Ignite project.
> Expected: {{org.apache.ignite.internal.}}
> Actual: {{org.apache.ignite..internal}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14915) Fix packet structure in network and network-processor modules
[
https://issues.apache.org/jira/browse/IGNITE-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14915:
Fix Version/s: 3.0.0-alpha3
> Fix packet structure in network and network-processor modules
> -
>
> Key: IGNITE-14915
> URL: https://issues.apache.org/jira/browse/IGNITE-14915
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-alpha2
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 3.0.0-alpha3
>
>
> {{network}} and {{network-processor}} modules violate the packet structure,
> defined in the Ignite project.
> Expected: {{org.apache.ignite.internal.}}
> Actual: {{org.apache.ignite..internal}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14915) Fix packet structure in network and network-processor modules
[
https://issues.apache.org/jira/browse/IGNITE-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-14915:
Affects Version/s: (was: 3.0.0-alpha3)
3.0.0-alpha2
> Fix packet structure in network and network-processor modules
> -
>
> Key: IGNITE-14915
> URL: https://issues.apache.org/jira/browse/IGNITE-14915
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-alpha2
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> {{network}} and {{network-processor}} modules violate the packet structure,
> defined in the Ignite project.
> Expected: {{org.apache.ignite.internal.}}
> Actual: {{org.apache.ignite..internal}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364281#comment-17364281 ] Aleksandr Polovtcev commented on IGNITE-14909: -- ??I confirm I've got the second issue again, using Inet4Address.getLocalHost().getHostAddress()?? Looks like this is a separate issue, I'll create a ticket for that > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > Time Spent: 20m > Remaining Estimate: 0h > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14120) select count * returns multiple rows
[ https://issues.apache.org/jira/browse/IGNITE-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-14120: - Assignee: Vladimir Ermakov (was: Peter Ivanov) > select count * returns multiple rows > > > Key: IGNITE-14120 > URL: https://issues.apache.org/jira/browse/IGNITE-14120 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8.1 >Reporter: Isaac Zhu >Assignee: Vladimir Ermakov >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > I have a partitioned table which has 1 backup, the *queryParallelism* is set > to 4. > The table primary key is column "ID", > If I do this query: > select count( * ) from my_table where ID = 1000; > It will return 4 rows: > 1 > 0 > 0 > 0 > > If I query by other not primary-key columns of this table, the result is > good, like: > select count( *) from my_table where name = 'abcd' > result is: > 0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14120) select count * returns multiple rows
[ https://issues.apache.org/jira/browse/IGNITE-14120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-14120: - Assignee: Peter Ivanov (was: Vladimir Ermakov) > select count * returns multiple rows > > > Key: IGNITE-14120 > URL: https://issues.apache.org/jira/browse/IGNITE-14120 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8.1 >Reporter: Isaac Zhu >Assignee: Peter Ivanov >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > I have a partitioned table which has 1 backup, the *queryParallelism* is set > to 4. > The table primary key is column "ID", > If I do this query: > select count( * ) from my_table where ID = 1000; > It will return 4 rows: > 1 > 0 > 0 > 0 > > If I query by other not primary-key columns of this table, the result is > good, like: > select count( *) from my_table where name = 'abcd' > result is: > 0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14913) Add cache statistics switch to control script
[
https://issues.apache.org/jira/browse/IGNITE-14913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14913:
---
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Add cache statistics switch to control script
> -
>
> Key: IGNITE-14913
> URL: https://issues.apache.org/jira/browse/IGNITE-14913
> Project: Ignite
> Issue Type: New Feature
> Components: control.sh
>Reporter: Ilya Shishkov
>Priority: Minor
>
> Currently, enabling or disabling of cache statistics is available only via
> ignitevisorcmd and JMX. Because it seems that ignitevisorcmd is no longer
> being developed, it would be helpful to add a cache statistics switch into
> control script, moreover we already have classes for this purpose:
> {code}
> VisorCacheToggleStatisticsTask
> VisorCacheToggleStatisticsTaskArg
> {code}
> Suggested syntax for command:
> {code}
> --cache statistics enable|disable [cacheName1,...,cacheNameN]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14724) Calcite engine. Create table with DATE column creates INTEGER column
[
https://issues.apache.org/jira/browse/IGNITE-14724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364259#comment-17364259
]
Konstantin Orlov commented on IGNITE-14724:
---
[~alex_pl], LGTM!
> Calcite engine. Create table with DATE column creates INTEGER column
>
>
> Key: IGNITE-14724
> URL: https://issues.apache.org/jira/browse/IGNITE-14724
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> sql("CREATE TABLE t(d DATE)", true);
> sql("INSERT INTO t VALUES (date '2021-01-01')", true);
> {code}
> Fails with:
> {noformat}
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Cannot assign to target field 'D' of type INTEGER from source field 'DATE
> '2021-01-01'' of type DATE{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14912) AssertionError in ITJRaftCounterServerTest
[
https://issues.apache.org/jira/browse/IGNITE-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364258#comment-17364258
]
Aleksandr Polovtcev commented on IGNITE-14912:
--
I've tried running this test for 500 times, but after introducing the fix from
https://issues.apache.org/jira/browse/IGNITE-14910 I wasn't able to reproduce
this issue.
> AssertionError in ITJRaftCounterServerTest
> --
>
> Key: IGNITE-14912
> URL: https://issues.apache.org/jira/browse/IGNITE-14912
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: _Test_-_Run_Integration_Tests_708.log
>
>
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.startServer(ITJRaftCounterServerTest.java:161)
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.doTestFollowerCatchUp(ITJRaftCounterServerTest.java:503)
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromLog2(ITJRaftCounterServerTest.java:431){noformat}
> Full log from TC is attached.
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6048662?expandedTest=build%3A%28id%3A6048660%29%2Cid%3A5313
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364248#comment-17364248 ] Alexey Scherbakov commented on IGNITE-14909: I confirm I've got the second issue again, using Inet4Address.getLocalHost().getHostAddress() > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > Time Spent: 20m > Remaining Estimate: 0h > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364244#comment-17364244 ] Alexey Scherbakov commented on IGNITE-14909: [~apolovtcev] It seems we have two issues here. 1) Mismatch in scalecube cluster node binding address and raft rpc node endpoint configuration, caused by some specific network configuration. My local pc and TC doesn't suffer from this. Looks like you have fixed this problem, but I'm not 100% sure. The correct fix probably should check all possible addresses in org.apache.ignite.network.TopologyService#getByAddress, because scalecube node can bind to multiple addresses. 2) The very rare issue with "Address already in use", caused by quick node restarts. I've just got it in my test running in the endless loop. Seems it's not fixed yet. Adding a small delay between tests can help to mitigate this problem. You can try to reproduce it by running IgniteRpcTest many times on TC. So, I'm ok with the current fix for local failures. > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > Time Spent: 20m > Remaining Estimate: 0h > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14915) Fix packet structure in network and network-processor modules
[
https://issues.apache.org/jira/browse/IGNITE-14915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14915:
-
Summary: Fix packet structure in network and network-processor modules
(was: Fix packaet structure in network and network-processor modules)
> Fix packet structure in network and network-processor modules
> -
>
> Key: IGNITE-14915
> URL: https://issues.apache.org/jira/browse/IGNITE-14915
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-alpha3
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> {{network}} and {{network-processor}} modules violate the packet structure,
> defined in the Ignite project.
> Expected: {{org.apache.ignite.internal.}}
> Actual: {{org.apache.ignite..internal}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14911) Inconsistent and confused timeout properties in python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14911: - Description: Currently, in python thin client timeout values can be set in int and float. 1. Timeouts for sql and cache properties are set using int as milliseconds 2. Timeouts for tx and expiry policy can be set either in float (as seconds) and in int as milliseconds (not released yet) But in python traditionally all timeouts are set using float and int as *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms are set as 0.12) We can solve this issue in many ways 1. Completely change to traditional way (and probably broke backward compatibility) 2. Change logic as for transactions for all timeouts with deprecation warning and with advice using only float. 3. Change logic for transaction or expiry_policy traditionally, for all others timeouts as in point 2. (This is not consitent) 4. Set all timeouts in ints and milliseconds (except for socket timeout in `Connection`) and optionally for ExpiryPolicy accept also `datetime.timedelta`. I suppose, that forth variant is the best option. was: Currently, in python thin client timeout values can be set in int and float. 1. Timeouts for sql and cache properties are set using int as milliseconds 2. Timeouts for tx and expiry policy can be set either in float (as seconds) and in int as milliseconds (not released yet) But in python traditionally all timeouts are set using float and int as *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms are set as 0.12) We can solve this issue in 2 ways 1. Completely change to traditional way (and probably broke backward compatibility) 2. Change logic as for transactions for all timeouts with deprecation warning and with advice using only float. 3. Change logic for transaction or expiry_policy traditionally, for all others timeouts as in point 2. (This is not consitent) > Inconsistent and confused timeout properties in python thin client > -- > > Key: IGNITE-14911 > URL: https://issues.apache.org/jira/browse/IGNITE-14911 > Project: Ignite > Issue Type: Task > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Blocker > Labels: python, thin > Fix For: python-0.5.0 > > > Currently, in python thin client timeout values can be set in int and float. > 1. Timeouts for sql and cache properties are set using int as milliseconds > 2. Timeouts for tx and expiry policy can be set either in float (as seconds) > and in int as milliseconds (not released yet) > But in python traditionally all timeouts are set using float and int as > *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms > are set as 0.12) > We can solve this issue in many ways > 1. Completely change to traditional way (and probably broke backward > compatibility) > 2. Change logic as for transactions for all timeouts with deprecation warning > and with advice using only float. > 3. Change logic for transaction or expiry_policy traditionally, for all > others timeouts as in point 2. (This is not consitent) > 4. Set all timeouts in ints and milliseconds (except for socket timeout in > `Connection`) and optionally for ExpiryPolicy accept also > `datetime.timedelta`. > I suppose, that forth variant is the best option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14899) PagesWriteSpeedBasedThrottle wrong appliance
[
https://issues.apache.org/jira/browse/IGNITE-14899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364230#comment-17364230
]
Ignite TC Bot commented on IGNITE-14899:
{panel:title=Branch: [pull/9172/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6045551]]
* exe: CacheTest.TestCacheWithExpiryPolicyOnAccess - Test has low fail rate in
base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/9172/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Unit Tests){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6045546]]
* {color:#013220}IgnitePdsUnitTestSuite:
IgniteThrottlingUnitTest.testCorrectTimeToPark - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6045577buildTypeId=IgniteTests24Java8_RunAll]
> PagesWriteSpeedBasedThrottle wrong appliance
>
>
> Key: IGNITE-14899
> URL: https://issues.apache.org/jira/browse/IGNITE-14899
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Semyon Danilov
>Assignee: Semyon Danilov
>Priority: Major
>
> During the investigation of the throttling algorithm I found out that it
> doesn’t exactly match the description provided in readme
> ([https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/README.md]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14591:
--
Description:
h3. Motivation.
For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
done for releases for javadoc generation purposes.
Using this tool helps us to detect a markup error in the resulting HTML code at
the early stage.
However, it treats style violations as just a WARNING which never make the TC
task failed.
We tried to use an additional check (actually a log parsing) to fail the TC
task, but now it is disabled because we can't perform the same checks on the
user side.
Also, style checks are not configurable, so using the {{javadoc}} tool for that
purpose looks useless.
h3. Descrition.
Checkstyle plugin has a module that performs style checks for javadocs and its
configuration looks flexible enough.
In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in case
of style violation as on TC as on user side.
Let's
* leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
styles warnings.
* add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
was:
h3. Motivation.
For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
done for releases for javadoc generation purposes.
Using this tool helps us to detect a markup error in the resulting HTML code at
the early stage.
However, it treats style violations as just a WARNING which never make the TC
task failed.
We tried to use an additional check (actually a log parsing) to fail the TC
task, but now it is disabled because we can't perform the same checks on the
user side.
Also, style checks are not configurable, so using the {{javadoc}} tool for that
purpose looks useless.
h3. Descrition.
Checkstyle plugin has a module that performs style checks for javadocs and its
configuration looks flexible enough.
In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in case
of style violation as on TC as on user side.
Let's
* leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
styles warnings.
* add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
Dev-list thread on the topic.
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Javadoc-style-requirements-and-checks-in-Ignite-3-td52400.html
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14591:
--
Description:
h3. Motivation.
For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
done for releases for javadoc generation purposes.
Using this tool helps us to detect a markup error in the resulting HTML code at
the early stage.
However, it treats style violations as just a WARNING which never make the TC
task failed.
We tried to use an additional check (actually a log parsing) to fail the TC
task, but now it is disabled because we can't perform the same checks on the
user side.
Also, style checks are not configurable, so using the {{javadoc}} tool for that
purpose looks useless.
h3. Descrition.
Checkstyle plugin has a module that performs style checks for javadocs and its
configuration looks flexible enough.
In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in case
of style violation as on TC as on user side.
Let's
* leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
styles warnings.
* add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
Dev-list thread on the topic.
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Javadoc-style-requirements-and-checks-in-Ignite-3-td52400.html
was:
h3. Motivation.
For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
done for releases for javadoc generation purposes.
Using this tool helps us to detect a markup error in the resulting HTML code at
the early stage.
However, it treats style violations as just a WARNING which never make the TC
task failed.
We tried to use an additional check (actually a log parsing) to fail the TC
task, but now it is disabled because we can't perform the same checks on the
user side.
Also, style checks are not configurable, so using the {{javadoc}} tool for that
purpose looks useless.
h3. Descrition.
Checkstyle plugin has a module that performs style checks for javadocs and its
configuration looks flexible enough.
In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in case
of style violation as on TC as on user side.
Let's
* leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
styles warnings.
* add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
> Dev-list thread on the topic.
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Javadoc-style-requirements-and-checks-in-Ignite-3-td52400.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14591) Add Javadoc rules to maven checkstyle plugin.
[
https://issues.apache.org/jira/browse/IGNITE-14591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-14591:
--
Description:
h3. Motivation.
For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
done for releases for javadoc generation purposes.
Using this tool helps us to detect a markup error in the resulting HTML code at
the early stage.
However, it treats style violations as just a WARNING which never make the TC
task failed.
We tried to use an additional check (actually a log parsing) to fail the TC
task, but now it is disabled because we can't perform the same checks on the
user side.
Also, style checks are not configurable, so using the {{javadoc}} tool for that
purpose looks useless.
h3. Descrition.
Checkstyle plugin has a module that performs style checks for javadocs and its
configuration looks flexible enough.
In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in case
of style violation as on TC as on user side.
Let's
* leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
styles warnings.
* add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
was:Let's add javadoc rules to maven-checkstyle-plugin and update the
Codestyle guide.
> Add Javadoc rules to maven checkstyle plugin.
> -
>
> Key: IGNITE-14591
> URL: https://issues.apache.org/jira/browse/IGNITE-14591
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> h3. Motivation.
> For now, we have a Javadoc suite on TC which runs {{javadoc}} tool as it is
> done for releases for javadoc generation purposes.
> Using this tool helps us to detect a markup error in the resulting HTML code
> at the early stage.
> However, it treats style violations as just a WARNING which never make the TC
> task failed.
> We tried to use an additional check (actually a log parsing) to fail the TC
> task, but now it is disabled because we can't perform the same checks on the
> user side.
> Also, style checks are not configurable, so using the {{javadoc}} tool for
> that purpose looks useless.
> h3. Descrition.
> Checkstyle plugin has a module that performs style checks for javadocs and
> its configuration looks flexible enough.
> In opposite to {{javadoc}} tool, checkstyle plugin fails the maven task in
> case of style violation as on TC as on user side.
> Let's
> * leave current Javadoc TC suite ({{javadoc}} tool) as is with suppressing
> styles warnings.
> * add javadoc rules to maven-checkstyle-plugin and update the Codestyle guide.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14909) IgniteRpcTest fails locally
[
https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364189#comment-17364189
]
Aleksandr Polovtcev edited comment on IGNITE-14909 at 6/16/21, 10:16 AM:
-
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
??what wrong in binding to real addr??
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
was (Author: apolovtcev):
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
what wrong in binding to real addr ???
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
> IgniteRpcTest fails locally
> ---
>
> Key: IGNITE-14909
> URL: https://issues.apache.org/jira/browse/IGNITE-14909
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: IgniteRpcTest.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See attached log file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14909) IgniteRpcTest fails locally
[
https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364189#comment-17364189
]
Aleksandr Polovtcev edited comment on IGNITE-14909 at 6/16/21, 10:16 AM:
-
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
what wrong in binding to real addr ???
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
was (Author: apolovtcev):
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
??what wrong in binding to real addr ???
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
> IgniteRpcTest fails locally
> ---
>
> Key: IGNITE-14909
> URL: https://issues.apache.org/jira/browse/IGNITE-14909
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: IgniteRpcTest.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See attached log file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14909) IgniteRpcTest fails locally
[
https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364189#comment-17364189
]
Aleksandr Polovtcev commented on IGNITE-14909:
--
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
??what wrong in binding to real addr ???
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
> IgniteRpcTest fails locally
> ---
>
> Key: IGNITE-14909
> URL: https://issues.apache.org/jira/browse/IGNITE-14909
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: IgniteRpcTest.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See attached log file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14909) IgniteRpcTest fails locally
[
https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364189#comment-17364189
]
Aleksandr Polovtcev edited comment on IGNITE-14909 at 6/16/21, 10:15 AM:
-
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
??what wrong in binding to real addr ???
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
was (Author: apolovtcev):
??changing server name to local address doesn't really changes anything,
because scalecube cluster node uses it only for server name and not actually do
any binding to local addr.??
Yes, but the test in question also uses this external address to retrieve the
cluster members, which are bound to the local address.
??what wrong in binding to real addr ???
The problem is that the member map inside the Topology Service gets filled with
addresses like "127.0.0.1:5003", while {{getMyIp}} returns addresses like
"192.168.45.94:5003". Therefore these tests fail 100% of the time on my local
machine. I don't know why these tests pass on TC, though...
??all client nodes seem to correctly shutdown if test is finished without any
error.??
Can you clarify, please, I don't understand how is this related to the fix?
> IgniteRpcTest fails locally
> ---
>
> Key: IGNITE-14909
> URL: https://issues.apache.org/jira/browse/IGNITE-14909
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: IgniteRpcTest.log
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> See attached log file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14912) AssertionError in ITJRaftCounterServerTest
[
https://issues.apache.org/jira/browse/IGNITE-14912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-14912:
Assignee: Aleksandr Polovtcev
> AssertionError in ITJRaftCounterServerTest
> --
>
> Key: IGNITE-14912
> URL: https://issues.apache.org/jira/browse/IGNITE-14912
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Attachments: _Test_-_Run_Integration_Tests_708.log
>
>
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.startServer(ITJRaftCounterServerTest.java:161)
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.doTestFollowerCatchUp(ITJRaftCounterServerTest.java:503)
> at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromLog2(ITJRaftCounterServerTest.java:431){noformat}
> Full log from TC is attached.
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6048662?expandedTest=build%3A%28id%3A6048660%29%2Cid%3A5313
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14911) Inconsistent and confused timeout properties in python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14911: - Fix Version/s: python-0.5.0 > Inconsistent and confused timeout properties in python thin client > -- > > Key: IGNITE-14911 > URL: https://issues.apache.org/jira/browse/IGNITE-14911 > Project: Ignite > Issue Type: Task > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinsky >Priority: Blocker > Labels: python, thin > Fix For: python-0.5.0 > > > Currently, in python thin client timeout values can be set in int and float. > 1. Timeouts for sql and cache properties are set using int as milliseconds > 2. Timeouts for tx and expiry policy can be set either in float (as seconds) > and in int as milliseconds (not released yet) > But in python traditionally all timeouts are set using float and int as > *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms > are set as 0.12) > We can solve this issue in 2 ways > 1. Completely change to traditional way (and probably broke backward > compatibility) > 2. Change logic as for transactions for all timeouts with deprecation warning > and with advice using only float. > 3. Change logic for transaction or expiry_policy traditionally, for all > others timeouts as in point 2. (This is not consitent) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14911) Inconsistent and confused timeout properties in python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-14911: Assignee: Ivan Daschinsky > Inconsistent and confused timeout properties in python thin client > -- > > Key: IGNITE-14911 > URL: https://issues.apache.org/jira/browse/IGNITE-14911 > Project: Ignite > Issue Type: Task > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Blocker > Labels: python, thin > Fix For: python-0.5.0 > > > Currently, in python thin client timeout values can be set in int and float. > 1. Timeouts for sql and cache properties are set using int as milliseconds > 2. Timeouts for tx and expiry policy can be set either in float (as seconds) > and in int as milliseconds (not released yet) > But in python traditionally all timeouts are set using float and int as > *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms > are set as 0.12) > We can solve this issue in 2 ways > 1. Completely change to traditional way (and probably broke backward > compatibility) > 2. Change logic as for transactions for all timeouts with deprecation warning > and with advice using only float. > 3. Change logic for transaction or expiry_policy traditionally, for all > others timeouts as in point 2. (This is not consitent) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14911) Inconsistent and confused timeout properties in python thin client
[ https://issues.apache.org/jira/browse/IGNITE-14911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-14911: - Priority: Blocker (was: Major) > Inconsistent and confused timeout properties in python thin client > -- > > Key: IGNITE-14911 > URL: https://issues.apache.org/jira/browse/IGNITE-14911 > Project: Ignite > Issue Type: Task > Components: python, thin client >Affects Versions: python-0.4.0 >Reporter: Ivan Daschinsky >Priority: Blocker > Labels: python, thin > > Currently, in python thin client timeout values can be set in int and float. > 1. Timeouts for sql and cache properties are set using int as milliseconds > 2. Timeouts for tx and expiry policy can be set either in float (as seconds) > and in int as milliseconds (not released yet) > But in python traditionally all timeouts are set using float and int as > *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms > are set as 0.12) > We can solve this issue in 2 ways > 1. Completely change to traditional way (and probably broke backward > compatibility) > 2. Change logic as for transactions for all timeouts with deprecation warning > and with advice using only float. > 3. Change logic for transaction or expiry_policy traditionally, for all > others timeouts as in point 2. (This is not consitent) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364180#comment-17364180 ] Alexey Scherbakov edited comment on IGNITE-14909 at 6/16/21, 9:56 AM: -- [~apolovtcev] [~ibessonov] This fix looks suspicious to me, because 1) changing server name to local address doesn't really changes anything, because scalecube cluster node uses it only for server name and not actually do any binding to local addr. 2) what wrong in binding to real addr ? 3) all client nodes seem to correctly shutdown if test is finished without any error. was (Author: ascherbakov): [~apolovtcev] [~ibessonov] This fix looks suspicious to me, because 1) changing server name to local address doesn't really changes anything, because scalecube cluster node uses it only for server name and not actually do any binding to local addr. 2) what wrong in binding to real addr ? 3) all client nodes seem to correctly shutdown if test is finished without an error. > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > Time Spent: 20m > Remaining Estimate: 0h > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364180#comment-17364180 ] Alexey Scherbakov commented on IGNITE-14909: [~apolovtcev] [~ibessonov] This fix looks suspicious to me, because 1) changing server name to local address doesn't really changes anything, because scalecube cluster node uses it only for server name and not actually do any binding to local addr. 2) what wrong in binding to real addr ? 3) all client nodes seem to correctly shutdown if test is finished without an error. > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > Time Spent: 20m > Remaining Estimate: 0h > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14914) Support in() clause in IndexQuery.
Maksim Timonin created IGNITE-14914: --- Summary: Support in() clause in IndexQuery. Key: IGNITE-14914 URL: https://issues.apache.org/jira/browse/IGNITE-14914 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin Assignee: Maksim Timonin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14913) Add cache statistics switch to control script
Ilya Shishkov created IGNITE-14913:
--
Summary: Add cache statistics switch to control script
Key: IGNITE-14913
URL: https://issues.apache.org/jira/browse/IGNITE-14913
Project: Ignite
Issue Type: New Feature
Components: control.sh
Reporter: Ilya Shishkov
Currently, enabling or disabling of cache statistics is available only via
ignitevisorcmd and JMX. Because it seems that ignitevisorcmd is no longer being
developed, it would be helpful to add a cache statistics switch into control
script, moreover we already have classes for this purpose:
{code}
VisorCacheToggleStatisticsTask
VisorCacheToggleStatisticsTaskArg
{code}
Suggested syntax for command:
{code}
--cache statistics enable|disable [cacheName1,...,cacheNameN]
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364160#comment-17364160 ] Ivan Bessonov commented on IGNITE-14909: [~apolovtcev] thank you for the fix, I confirm that these tests pass now. > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > Time Spent: 10m > Remaining Estimate: 0h > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14910) ITJRaftCounterServerTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-14910: Assignee: Aleksandr Polovtcev (was: Alexey Scherbakov) > ITJRaftCounterServerTest fails locally > -- > > Key: IGNITE-14910 > URL: https://issues.apache.org/jira/browse/IGNITE-14910 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: ITJRaftCounterServerTest.log > > > See attached logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14910) ITJRaftCounterServerTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov reassigned IGNITE-14910: -- Assignee: Alexey Scherbakov > ITJRaftCounterServerTest fails locally > -- > > Key: IGNITE-14910 > URL: https://issues.apache.org/jira/browse/IGNITE-14910 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: ITJRaftCounterServerTest.log > > > See attached logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14912) AssertionError in ITJRaftCounterServerTest
Ivan Bessonov created IGNITE-14912:
--
Summary: AssertionError in ITJRaftCounterServerTest
Key: IGNITE-14912
URL: https://issues.apache.org/jira/browse/IGNITE-14912
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
Fix For: 3.0.0-alpha3
Attachments: _Test_-_Run_Integration_Tests_708.log
{noformat}
java.lang.AssertionError
at
org.apache.ignite.raft.server.ITJRaftCounterServerTest.startServer(ITJRaftCounterServerTest.java:161)
at
org.apache.ignite.raft.server.ITJRaftCounterServerTest.doTestFollowerCatchUp(ITJRaftCounterServerTest.java:503)
at
org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromLog2(ITJRaftCounterServerTest.java:431){noformat}
Full log from TC is attached.
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6048662?expandedTest=build%3A%28id%3A6048660%29%2Cid%3A5313
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14890) Unify a log string with placeholders for various log-library implementation
[
https://issues.apache.org/jira/browse/IGNITE-14890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-14890:
---
Description:
After the fix, we would use Ignite own specific logger pattern format.
This format is based by widely know SLF4J:
1. We would pass several parameters after a pattern.
2. The last one parameter might be exception.
3. `{}` is used as a formatting anchor.
> Unify a log string with placeholders for various log-library implementation
> ---
>
> Key: IGNITE-14890
> URL: https://issues.apache.org/jira/browse/IGNITE-14890
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> After the fix, we would use Ignite own specific logger pattern format.
> This format is based by widely know SLF4J:
> 1. We would pass several parameters after a pattern.
> 2. The last one parameter might be exception.
> 3. `{}` is used as a formatting anchor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-14909: Assignee: Aleksandr Polovtcev > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14911) Inconsistent and confused timeout properties in python thin client
Ivan Daschinsky created IGNITE-14911: Summary: Inconsistent and confused timeout properties in python thin client Key: IGNITE-14911 URL: https://issues.apache.org/jira/browse/IGNITE-14911 Project: Ignite Issue Type: Task Components: python, thin client Affects Versions: python-0.4.0 Reporter: Ivan Daschinsky Currently, in python thin client timeout values can be set in int and float. 1. Timeouts for sql and cache properties are set using int as milliseconds 2. Timeouts for tx and expiry policy can be set either in float (as seconds) and in int as milliseconds (not released yet) But in python traditionally all timeouts are set using float and int as *seconds*. Milliseconds precision are achieved using fractions (f.e. 120 ms are set as 0.12) We can solve this issue in 2 ways 1. Completely change to traditional way (and probably broke backward compatibility) 2. Change logic as for transactions for all timeouts with deprecation warning and with advice using only float. 3. Change logic for transaction or expiry_policy traditionally, for all others timeouts as in point 2. (This is not consitent) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14910) ITJRaftCounterServerTest fails locally
Ivan Bessonov created IGNITE-14910: -- Summary: ITJRaftCounterServerTest fails locally Key: IGNITE-14910 URL: https://issues.apache.org/jira/browse/IGNITE-14910 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Fix For: 3.0.0-alpha3 Attachments: ITJRaftCounterServerTest.log See attached logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14910) ITJRaftCounterServerTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14910: --- Ignite Flags: (was: Docs Required,Release Notes Required) > ITJRaftCounterServerTest fails locally > -- > > Key: IGNITE-14910 > URL: https://issues.apache.org/jira/browse/IGNITE-14910 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: ITJRaftCounterServerTest.log > > > See attached logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14909) IgniteRpcTest fails locally
[ https://issues.apache.org/jira/browse/IGNITE-14909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14909: --- Ignite Flags: (was: Docs Required,Release Notes Required) > IgniteRpcTest fails locally > --- > > Key: IGNITE-14909 > URL: https://issues.apache.org/jira/browse/IGNITE-14909 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Attachments: IgniteRpcTest.log > > > See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14909) IgniteRpcTest fails locally
Ivan Bessonov created IGNITE-14909: -- Summary: IgniteRpcTest fails locally Key: IGNITE-14909 URL: https://issues.apache.org/jira/browse/IGNITE-14909 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Fix For: 3.0.0-alpha3 Attachments: IgniteRpcTest.log See attached log file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14853: --- Description: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] A similar issue with [testInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] [https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] was: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] A similar issue with [estInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] [https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] > A similar issue with > [testInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] > > [https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14853: --- Description: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] A similar issue with [estInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] [https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] was: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] A similar issue with [estInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] > A similar issue with > [estInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] > > [https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14853: --- Description: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] A similar issue with [estInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests was: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > [https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests] > A similar issue with > [estInstallLargeSnapshotWithThrottle|https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests#testNameId1454989063795674956] > > https://ci.ignite.apache.org/viewLog.html?buildId=6044871=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14908) Remove non-inclusive terms in Ignite
[
https://issues.apache.org/jira/browse/IGNITE-14908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishwas updated IGNITE-14908:
-
Description:
Ignite has non inclusive words like blacklist/whitelist.
{code:java}
public static final String IGNITE_MARSHALLER_WHITELIST =
"IGNITE_MARSHALLER_WHITELIST";
public static final String IGNITE_MARSHALLER_BLACKLIST =
"IGNITE_MARSHALLER_BLACKLIST";
{code}
All these references needs to be removed from ignite and needs to be replaced
with more inclusive terms.
was:
Ignite has non inclusive words like blacklist/whitelist.
{code:java}
public static final String IGNITE_MARSHALLER_WHITELIST =
"IGNITE_MARSHALLER_WHITELIST";
public static final String IGNITE_MARSHALLER_BLACKLIST =
"IGNITE_MARSHALLER_BLACKLIST";
{code}
All these references needs to be removed from ignite and needs to be replaced
with more inclusive terms.
> Remove non-inclusive terms in Ignite
>
>
> Key: IGNITE-14908
> URL: https://issues.apache.org/jira/browse/IGNITE-14908
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Vishwas
>Priority: Major
>
> Ignite has non inclusive words like blacklist/whitelist.
> {code:java}
> public static final String IGNITE_MARSHALLER_WHITELIST =
> "IGNITE_MARSHALLER_WHITELIST";
> public static final String IGNITE_MARSHALLER_BLACKLIST =
> "IGNITE_MARSHALLER_BLACKLIST";
> {code}
> All these references needs to be removed from ignite and needs to be replaced
> with more inclusive terms.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14908) Remove non-inclusive terms in Ignite
Vishwas created IGNITE-14908:
Summary: Remove non-inclusive terms in Ignite
Key: IGNITE-14908
URL: https://issues.apache.org/jira/browse/IGNITE-14908
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.10
Reporter: Vishwas
Ignite has non inclusive words like blacklist/whitelist.
{code:java}
public static final String IGNITE_MARSHALLER_WHITELIST =
"IGNITE_MARSHALLER_WHITELIST";
public static final String IGNITE_MARSHALLER_BLACKLIST =
"IGNITE_MARSHALLER_BLACKLIST";
{code}
All these references needs to be removed from ignite and needs to be replaced
with more inclusive terms.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14853) testInstallSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-14853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-14853: --- Description: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests was: Sometimes the joining node does not respond to install snapshot message. Due to big timeout on install snapshot request retry is not happening. > testInstallSnapshot is flaky > > > Key: IGNITE-14853 > URL: https://issues.apache.org/jira/browse/IGNITE-14853 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Sometimes the joining node does not respond to install snapshot message. > Due to big timeout on install snapshot request retry is not happening. > https://ci.ignite.apache.org/viewLog.html?buildId=6041204=buildResultsDiv=ignite3_Test_IntegrationTests_IntegrationTests > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14907) testLearnerServices is flaky
Alexey Scherbakov created IGNITE-14907: -- Summary: testLearnerServices is flaky Key: IGNITE-14907 URL: https://issues.apache.org/jira/browse/IGNITE-14907 Project: Ignite Issue Type: Task Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 3.0.0-alpha3 https://ci.ignite.apache.org/viewLog.html?buildId=6049184=ignite3_Test_IntegrationTests_IntegrationTests -- This message was sent by Atlassian Jira (v8.3.4#803005)
