[jira] [Created] (IGNITE-13047) Ignite node must return Ignition#KILL_EXIT_CODE exit code, if node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHandler
Sergey Antonov created IGNITE-13047: --- Summary: Ignite node must return Ignition#KILL_EXIT_CODE exit code, if node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHandler Key: IGNITE-13047 URL: https://issues.apache.org/jira/browse/IGNITE-13047 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Ignite process must be finished with exit code 130 [1] if the node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHanlder. [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-7153) Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for values > 8kb
[
https://issues.apache.org/jira/browse/IGNITE-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112625#comment-17112625
]
Denis A. Magda commented on IGNITE-7153:
Thanks for your contribution! I left minor suggestions in the GitHub. Please
take them into consideration.
Also, assign the ticket on yourself and move it to the patch available state.
Pay attention to the checklist added in the very first message of the
pull-request.
> Redis: BufferUnderflowException at GridRedisProtocolParser.readBulkStr for
> values > 8kb
> ---
>
> Key: IGNITE-7153
> URL: https://issues.apache.org/jira/browse/IGNITE-7153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.3
> Environment: Win, PHP 7, php_redis-3.1.1-7.0
>Reporter: Alexey Popov
>Assignee: Michael Fong
>Priority: Major
> Labels: redis
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Exception:
> {noformat}
> [15:03:23,690][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=28
> lim=8192 cap=8192], super=AbstractNioClientWorker [idx=0, bytesRcvd=0,
> bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=true, super=GridWorker
> [name=grid-nio-worker-tcp-rest-0, igniteInstanceName=null, finished=false,
> hashCode=396395638, interrupted=false,
> runner=grid-nio-worker-tcp-rest-0-#36]]], writeBuf=null, readBuf=null,
> inRecovery=null, outRecovery=null, super=GridNioSessionImpl
> [locAddr=/127.0.0.1:6380, rmtAddr=/127.0.0.1:51794, createTime=1512734602674,
> closeTime=0, bytesSent=0, bytesRcvd=8192, bytesSent0=0, bytesRcvd0=8192,
> sndSchedTime=1512734602674, lastSndTime=1512734602674,
> lastRcvTime=1512734602674, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter [parser=GridTcpRestParser
> [jdkMarshaller=JdkMarshaller [], routerClient=false], directMode=false]],
> accepted=true]]]
> java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readBulkStr(GridRedisProtocolParser.java:107)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.redis.GridRedisProtocolParser.readArray(GridRedisProtocolParser.java:86)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:150)
> at
> org.apache.ignite.internal.processors.rest.protocols.tcp.GridTcpRestParser.decode(GridTcpRestParser.java:70)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onMessageReceived(GridNioCodecFilter.java:114)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$HeadFilter.onMessageReceived(GridNioServer.java:3392)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain.onMessageReceived(GridNioFilterChain.java:175)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$ByteBufferNioClientWorker.processRead(GridNioServer.java:1096)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2272)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> [15:03:23,691][SEVERE][grid-nio-worker-tcp-rest-0-#36][GridTcpRestProtocol]
> Closing NIO session because of unhandled exception.
> class org.apache.ignite.internal.util.nio.GridNioException: null
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2296)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2048)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1717)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.nio.BufferUnderflowException
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:151)
> at
>
[jira] [Commented] (IGNITE-12085) ThreadPool metrics register after all components start
[
https://issues.apache.org/jira/browse/IGNITE-12085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112589#comment-17112589
]
Amelchev Nikita commented on IGNITE-12085:
--
[~PetrovMikhail], LGTM.
> ThreadPool metrics register after all components start
> --
>
> Key: IGNITE-12085
> URL: https://issues.apache.org/jira/browse/IGNITE-12085
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: IEP-35, await
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For now, thread pool metrics register after all {{GridComponent}} starts.
> But there are specific scenarios when some component blocks {{onKernalStart}}
> execution for a long time. {{GridCacheProcessor}} can be taken as an example.
> This leads to the situation when some metric info is lost.
> Seems, we can register thread pool metrics right after only **required**
> components are started and don't wait for all components.
> {code:java}
> // Callbacks.
> for (GridComponent comp : ctx) {
> comp.onKernalStart(active);
> }
> // Start plugins.
> for (PluginProvider provider : ctx.plugins().allProviders())
> provider.onIgniteStart();
> ctx.metric().registerThreadPools(utilityCachePool, execSvc,
> svcExecSvc, sysExecSvc, stripedExecSvc,
> p2pExecSvc, mgmtExecSvc, igfsExecSvc, dataStreamExecSvc,
> restExecSvc, affExecSvc, idxExecSvc,
> callbackExecSvc, qryExecSvc, schemaExecSvc, rebalanceExecSvc,
> rebalanceStripedExecSvc, customExecSvcs);
> // Register MBeans.
> mBeansMgr.registerAllMBeans(utilityCachePool, execSvc,
> svcExecSvc, sysExecSvc, stripedExecSvc, p2pExecSvc,
> mgmtExecSvc, igfsExecSvc, dataStreamExecSvc, restExecSvc,
> affExecSvc, idxExecSvc, callbackExecSvc,
> qryExecSvc, schemaExecSvc, rebalanceExecSvc,
> rebalanceStripedExecSvc, customExecSvcs, ctx.workersRegistry());
> {code}
> {code:java}
> public class GridCacheProcessor {
> @Override public void onKernalStart(boolean active) throws
> IgniteCheckedException {
> //.
> final List syncFuts = new
> ArrayList<>(caches.size());
> sharedCtx.forAllCaches(new CIX1() {
> @Override public void applyx(GridCacheContext cctx) {
> CacheConfiguration cfg = cctx.config();
> if (cctx.affinityNode() &&
> cfg.getRebalanceMode() == SYNC &&
> startTopVer.equals(cctx.startTopologyVersion())) {
> CacheMode cacheMode = cfg.getCacheMode();
> if (cacheMode == REPLICATED || (cacheMode == PARTITIONED
> && cfg.getRebalanceDelay() >= 0))
> // Need to wait outside to avoid a deadlock
> syncFuts.add(cctx.preloader().syncFuture());
> }
> }
> });
> for (int i = 0, size = syncFuts.size(); i < size; i++)
> syncFuts.get(i).get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13046) Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
[
https://issues.apache.org/jira/browse/IGNITE-13046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-13046:
Fix Version/s: 2.9
> Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
> ---
>
> Key: IGNITE-13046
> URL: https://issues.apache.org/jira/browse/IGNITE-13046
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
>
> Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
> sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
> There is race between runner thread and thread which completes future in
> {{IgniteH2Indexing#rebuildIndexesFromHash()}} method. Runner thread is
> unblocked due to the future completion and it tries to assert conditions
> while thread which completed the future changes state of index rebuild
> process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13046) Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
[
https://issues.apache.org/jira/browse/IGNITE-13046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-13046:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
> ---
>
> Key: IGNITE-13046
> URL: https://issues.apache.org/jira/browse/IGNITE-13046
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
> Fix For: 2.9
>
>
> Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
> sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
> There is race between runner thread and thread which completes future in
> {{IgniteH2Indexing#rebuildIndexesFromHash()}} method. Runner thread is
> unblocked due to the future completion and it tries to assert conditions
> while thread which completed the future changes state of index rebuild
> process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13046) Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
[
https://issues.apache.org/jira/browse/IGNITE-13046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura reassigned IGNITE-13046:
---
Assignee: Andrey N. Gura
> Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
> ---
>
> Key: IGNITE-13046
> URL: https://issues.apache.org/jira/browse/IGNITE-13046
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Assignee: Andrey N. Gura
>Priority: Major
>
> Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
> sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
> There is race between runner thread and thread which completes future in
> {{IgniteH2Indexing#rebuildIndexesFromHash()}} method. Runner thread is
> unblocked due to the future completion and it tries to assert conditions
> while thread which completed the future changes state of index rebuild
> process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13046) Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
[
https://issues.apache.org/jira/browse/IGNITE-13046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-13046:
Description:
Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
There is race between runner thread and thread which completes future in
{{IgniteH2Indexing#rebuildIndexesFromHash()}} method. Runner thread is
unblocked due to the future completion and it tries to assert conditions while
thread which completed the future changes state of index rebuild process.
was:Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
> Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
> ---
>
> Key: IGNITE-13046
> URL: https://issues.apache.org/jira/browse/IGNITE-13046
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey N. Gura
>Priority: Major
>
> Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
> sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
> There is race between runner thread and thread which completes future in
> {{IgniteH2Indexing#rebuildIndexesFromHash()}} method. Runner thread is
> unblocked due to the future completion and it tries to assert conditions
> while thread which completed the future changes state of index rebuild
> process.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13046) Flaky test SqlSystemViewsSelfTest.testTableViewDuringRebuilding
Andrey N. Gura created IGNITE-13046:
---
Summary: Flaky test
SqlSystemViewsSelfTest.testTableViewDuringRebuilding
Key: IGNITE-13046
URL: https://issues.apache.org/jira/browse/IGNITE-13046
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
Test {{SqlSystemViewsSelfTest.testTableViewDuringRebuilding}} fails
sporadically. The reason is changes introduced due to the IGNITE-12684 issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13045) SystemWorkersBlockingTest may fail NullPointerException if MXBean not found
[
https://issues.apache.org/jira/browse/IGNITE-13045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13045:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> SystemWorkersBlockingTest may fail NullPointerException if MXBean not found
> ---
>
> Key: IGNITE-13045
> URL: https://issues.apache.org/jira/browse/IGNITE-13045
> Project: Ignite
> Issue Type: Test
>Reporter: Maxim Muzafarov
>Priority: Major
>
> The test may fail with NullPointerException during a stop.
> Investigation and reproducer required.
> {code}
> [17:12:56] : [org.apache.ignite:ignite-core] [2020-05-20
> 17:12:56,374][INFO ][main][root] >>> Stopping test:
> SystemWorkersBlockingTest#testBlockingWorker in 5910 ms <<<
> [17:12:56]W: [org.apache.ignite:ignite-core] [2020-05-20
> 17:12:56,374][ERROR][tcp-disco-msg-worker-[crd]-#186%failure.SystemWorkersBlockingTest0%-#1778%failure.SystemWorkersBlockingTest0%][TestTcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> [17:12:56]W: [org.apache.ignite:ignite-core]
> java.lang.NullPointerException
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.IgniteUtils.dumpThread(IgniteUtils.java:1501)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:232)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2881)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7738)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2969)
> [17:12:56] : [org.apache.ignite:ignite-core] [2020-05-20
> 17:12:56,374][INFO ][main][root] >>> Stopping grid
> [name=failure.SystemWorkersBlockingTest0,
> id=6a13078b-0050-48bd-91e1-f201e1b0]
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7676)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> [17:12:56]W: [org.apache.ignite:ignite-core] [2020-05-20
> 17:12:56,378][ERROR][tcp-disco-msg-worker-[crd]-#186%failure.SystemWorkersBlockingTest0%-#1778%failure.SystemWorkersBlockingTest0%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_CRITICAL_OPERATION_TIMEOUT]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
> [17:12:56]W: [org.apache.ignite:ignite-core]
> java.lang.NullPointerException
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.IgniteUtils.dumpThread(IgniteUtils.java:1501)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:232)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2881)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7738)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2969)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7676)
> [17:12:56]W: [org.apache.ignite:ignite-core]at
>
[jira] [Created] (IGNITE-13045) SystemWorkersBlockingTest may fail NullPointerException if MXBean not found
Maxim Muzafarov created IGNITE-13045:
Summary: SystemWorkersBlockingTest may fail NullPointerException
if MXBean not found
Key: IGNITE-13045
URL: https://issues.apache.org/jira/browse/IGNITE-13045
Project: Ignite
Issue Type: Test
Reporter: Maxim Muzafarov
The test may fail with NullPointerException during a stop.
Investigation and reproducer required.
{code}
[17:12:56] : [org.apache.ignite:ignite-core] [2020-05-20
17:12:56,374][INFO ][main][root] >>> Stopping test:
SystemWorkersBlockingTest#testBlockingWorker in 5910 ms <<<
[17:12:56]W: [org.apache.ignite:ignite-core] [2020-05-20
17:12:56,374][ERROR][tcp-disco-msg-worker-[crd]-#186%failure.SystemWorkersBlockingTest0%-#1778%failure.SystemWorkersBlockingTest0%][TestTcpDiscoverySpi]
TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in
order to prevent cluster wide instability.
[17:12:56]W: [org.apache.ignite:ignite-core]
java.lang.NullPointerException
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.IgniteUtils.dumpThread(IgniteUtils.java:1501)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:232)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2881)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7738)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2969)
[17:12:56] : [org.apache.ignite:ignite-core] [2020-05-20
17:12:56,374][INFO ][main][root] >>> Stopping grid
[name=failure.SystemWorkersBlockingTest0,
id=6a13078b-0050-48bd-91e1-f201e1b0]
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7676)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
[17:12:56]W: [org.apache.ignite:ignite-core] [2020-05-20
17:12:56,378][ERROR][tcp-disco-msg-worker-[crd]-#186%failure.SystemWorkersBlockingTest0%-#1778%failure.SystemWorkersBlockingTest0%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_CRITICAL_OPERATION_TIMEOUT]], failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.NullPointerException]]
[17:12:56]W: [org.apache.ignite:ignite-core]
java.lang.NullPointerException
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.IgniteUtils.dumpThread(IgniteUtils.java:1501)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:232)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2881)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7738)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2969)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7676)
[17:12:56]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13043) Fix compilation error in Ignite C++, when boost version is greater than 1.70
[ https://issues.apache.org/jira/browse/IGNITE-13043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112419#comment-17112419 ] Ivan Daschinskiy commented on IGNITE-13043: --- TC builds [Linux clang|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPLinuxClang?branch=pull%2F7823%2Fhead] [Linux |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCLinux?branch=pull%2F7823%2Fhead] [Win 64|https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCWinX64Release?branch=pull%2F7823%2Fhead] [~isapego] Could you please merge this little patch? > Fix compilation error in Ignite C++, when boost version is greater than 1.70 > - > > Key: IGNITE-13043 > URL: https://issues.apache.org/jira/browse/IGNITE-13043 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > Fix compilation issue when libboost greater than 1.71 in > TeamcityBoostLogFormatter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13044) Additional possibility to check for high contending keys generated by the transaction payload.
[ https://issues.apache.org/jira/browse/IGNITE-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13044: Summary: Additional possibility to check for high contending keys generated by the transaction payload. (was: Additional possibility to check for high contending keys through transactional payload.) > Additional possibility to check for high contending keys generated by the > transaction payload. > -- > > Key: IGNITE-13044 > URL: https://issues.apache.org/jira/browse/IGNITE-13044 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > > In process of limited keys highload updates there are possible to obtain high > queue of locking candidates. Want to be able for monitoring such situations, > jmx seems to be correct place for it. Any additional info would be append > here after pr approval and resolution also appropriate documentation ticket, > of course, need to be linked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13044) Additional possibility to check for high contending keys through transactional payload.
Stanilovsky Evgeny created IGNITE-13044: --- Summary: Additional possibility to check for high contending keys through transactional payload. Key: IGNITE-13044 URL: https://issues.apache.org/jira/browse/IGNITE-13044 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.8 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny In process of limited keys highload updates there are possible to obtain high queue of locking candidates. Want to be able for monitoring such situations, jmx seems to be correct place for it. Any additional info would be append here after pr approval and resolution also appropriate documentation ticket, of course, need to be linked. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13043) Fix compilation error in Ignite C++, when boost version is greater than 1.70
[ https://issues.apache.org/jira/browse/IGNITE-13043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-13043: -- Component/s: platforms Priority: Trivial (was: Major) > Fix compilation error in Ignite C++, when boost version is greater than 1.70 > - > > Key: IGNITE-13043 > URL: https://issues.apache.org/jira/browse/IGNITE-13043 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Trivial > > Fix compilation issue when libboost greater than 1.71 in > TeamcityBoostLogFormatter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13043) Fix compilation error in Ignite C++, when boost version is greater than 1.70
Ivan Daschinskiy created IGNITE-13043: - Summary: Fix compilation error in Ignite C++, when boost version is greater than 1.70 Key: IGNITE-13043 URL: https://issues.apache.org/jira/browse/IGNITE-13043 Project: Ignite Issue Type: Bug Reporter: Ivan Daschinskiy Assignee: Ivan Daschinskiy Fix compilation issue when libboost greater than 1.71 in TeamcityBoostLogFormatter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13042:
--
Description:
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because
Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
Affected ignite-odbc-tests and ignite-thin-client-tests
was:
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because use
Sha1WithRSAEncryption signature, that is widely considered flaw. So
certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
Affected ignite-odbc-tests and ignite-thin-client-tests
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because
> Sha1WithRSAEncryption signature is used, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13042:
--
Description:
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because use
Sha1WithRSAEncryption signature, that is widely considered flaw. So
certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
Affected ignite-odbc-tests and ignite-thin-client-tests
was:
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because use
Sha1WithRSAEncryption signature, that is widely considered flaw. So
certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because use
> Sha1WithRSAEncryption signature, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
> Affected ignite-odbc-tests and ignite-thin-client-tests
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13042:
--
Description:
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because use
Sha1WithRSAEncryption signature, that is widely considered flaw. So
certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
was:
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because use
sha1withRsaEncription signature, that is widely considered flaw. So
certificates needs to be renewed.
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Priority: Minor
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because use
> Sha1WithRSAEncryption signature, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
[
https://issues.apache.org/jira/browse/IGNITE-13042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-13042:
-
Assignee: Igor Sapego
> Update SSL certificates in C++ test suites to more secure signature
> ---
>
> Key: IGNITE-13042
> URL: https://issues.apache.org/jira/browse/IGNITE-13042
> Project: Ignite
> Issue Type: Test
> Components: platforms
>Reporter: Ivan Daschinskiy
>Assignee: Igor Sapego
>Priority: Minor
>
> When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
> 20.04, for example), provided certificates are not accepted, because use
> Sha1WithRSAEncryption signature, that is widely considered flaw. So
> certificates needs to be renewed (i.e. with sha256WithRSAEncryption signature)
> Example error:
> {code}
> Connecting to 127.0.0.1:0
> 140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
> weak:../ssl/ssl_rsa.c:310:
> Failed to connect :Can not set client certificate file for secure connection:
> path
> /home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13042) Update SSL certificates in C++ test suites to more secure signature
Ivan Daschinskiy created IGNITE-13042:
-
Summary: Update SSL certificates in C++ test suites to more secure
signature
Key: IGNITE-13042
URL: https://issues.apache.org/jira/browse/IGNITE-13042
Project: Ignite
Issue Type: Test
Components: platforms
Reporter: Ivan Daschinskiy
When modern openssl is used (i.e OpenSSL 1.1.1f, which is default for ubuntu
20.04, for example), provided certificates are not accepted, because use
sha1withRsaEncription signature, that is widely considered flaw. So
certificates needs to be renewed.
Example error:
{code}
Connecting to 127.0.0.1:0
140246535644992:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too
weak:../ssl/ssl_rsa.c:310:
Failed to connect :Can not set client certificate file for secure connection:
path
/home/ivandasch/ignite/modules/platforms/cpp/thin-client-test/config/ssl/client_full.pem
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13041) PDS (Indexing) is failed with 137 code
Anton Kalashnikov created IGNITE-13041: -- Summary: PDS (Indexing) is failed with 137 code Key: IGNITE-13041 URL: https://issues.apache.org/jira/browse/IGNITE-13041 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov Process exited with code 137 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PdsIndexing?branch=%3Cdefault%3E=overview=builds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13040:
--
Description:
Unused parameter
{code:java}
TcpDiscoveryAbstractMessage msg{code}
should be removed from
{code:java}
TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg, byte[]
data, long timeout){code}
This method seems to send raw data, not a message.
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Task
> Environment:
>Reporter: Vladimir Steshin
>Priority: Trivial
>
> Unused parameter
> {code:java}
> TcpDiscoveryAbstractMessage msg{code}
> should be removed from
> {code:java}
> TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg,
> byte[] data, long timeout){code}
> This method seems to send raw data, not a message.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
[
https://issues.apache.org/jira/browse/IGNITE-13040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13040:
--
Environment: (was: Unused parameter
{code:java}TcpDiscoveryAbstractMessage msg{code} should be removed from
{code:java}
TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg, byte[]
data, long timeout){code}
This method seems to send raw data, not a message.
)
> Remove unused parameter from TcpDiscoverySpi.writeToSocket()
>
>
> Key: IGNITE-13040
> URL: https://issues.apache.org/jira/browse/IGNITE-13040
> Project: Ignite
> Issue Type: Task
> Environment:
>Reporter: Vladimir Steshin
>Priority: Trivial
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13040) Remove unused parameter from TcpDiscoverySpi.writeToSocket()
Vladimir Steshin created IGNITE-13040:
-
Summary: Remove unused parameter from
TcpDiscoverySpi.writeToSocket()
Key: IGNITE-13040
URL: https://issues.apache.org/jira/browse/IGNITE-13040
Project: Ignite
Issue Type: Task
Environment: Unused parameter {code:java}TcpDiscoveryAbstractMessage
msg{code} should be removed from
{code:java}
TcpDiscovery.writeToSocket(Socket sock, TcpDiscoveryAbstractMessage msg, byte[]
data, long timeout){code}
This method seems to send raw data, not a message.
Reporter: Vladimir Steshin
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13039) Get rid of possibility to change final static fields through reflection for test purpose.
Stanilovsky Evgeny created IGNITE-13039: --- Summary: Get rid of possibility to change final static fields through reflection for test purpose. Key: IGNITE-13039 URL: https://issues.apache.org/jira/browse/IGNITE-13039 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.8 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Rare for tests purpose there is a need for changing some private fields through reflection. Changing *static final* fields in this manner could bring more tears, check for example [1] and [2]. [1] https://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection [2] http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.28 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13036) Add event triggered while page replacement start.
[ https://issues.apache.org/jira/browse/IGNITE-13036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112018#comment-17112018 ] Stanilovsky Evgeny commented on IGNITE-13036: - seems alll ok here, [~agoncharuk] who can review ? thanks ! > Add event triggered while page replacement start. > - > > Key: IGNITE-13036 > URL: https://issues.apache.org/jira/browse/IGNITE-13036 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Page replacement between in memory pages and disk stored pages will be > triggered if no DataRegion free space available for the new payload. There is > a need for checking such events. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13036) Add event triggered while page replacement start.
[
https://issues.apache.org/jira/browse/IGNITE-13036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112016#comment-17112016
]
Ignite TC Bot commented on IGNITE-13036:
{panel:title=Branch: [pull/7815/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5319540buildTypeId=IgniteTests24Java8_RunAll]
> Add event triggered while page replacement start.
> -
>
> Key: IGNITE-13036
> URL: https://issues.apache.org/jira/browse/IGNITE-13036
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.8
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Page replacement between in memory pages and disk stored pages will be
> triggered if no DataRegion free space available for the new payload. There is
> a need for checking such events.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112001#comment-17112001
]
Nikolay Izhikov commented on IGNITE-12905:
--
It seems, that fix doesn't have a chance to squeeze into 2.8.1 scope so I moved
it to 2.9
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12905:
-
Fix Version/s: (was: 2.8.1)
2.9
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.9
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112000#comment-17112000
]
Nikolay Izhikov commented on IGNITE-12905:
--
[~bleedah] Please, see my comments in PR.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12801) Possible extra page release when throttling and checkpoint thread store its concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12801:
-
Fix Version/s: 2.9
> Possible extra page release when throttling and checkpoint thread store its
> concurrently
>
>
> Key: IGNITE-12801
> URL: https://issues.apache.org/jira/browse/IGNITE-12801
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * User thread acquire page on write release
> * Checkpoint thread sees that page was acquired
> * Throttling thread sees that page was acquired
> * Checkpoint thread saves page to disk and releases the page
> * Throttling thread understand that the page was already saved but
> nonetheless release this page again. - this is not ok.
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1181)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1160)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4868)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:4792)
> ... 3 common frames omitted
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12801) Possible extra page release when throttling and checkpoint thread store its concurrently
[
https://issues.apache.org/jira/browse/IGNITE-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111957#comment-17111957
]
Nikolay Izhikov commented on IGNITE-12801:
--
Cherry-picked to 2.8.1
> Possible extra page release when throttling and checkpoint thread store its
> concurrently
>
>
> Key: IGNITE-12801
> URL: https://issues.apache.org/jira/browse/IGNITE-12801
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> * User thread acquire page on write release
> * Checkpoint thread sees that page was acquired
> * Throttling thread sees that page was acquired
> * Checkpoint thread saves page to disk and releases the page
> * Throttling thread understand that the page was already saved but
> nonetheless release this page again. - this is not ok.
> {noformat}
> java.lang.AssertionError: null
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1181)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.checkpointWritePage(PageMemoryImpl.java:1160)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.writePages(GridCacheDatabaseSharedManager.java:4868)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:4792)
> ... 3 common frames omitted
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111942#comment-17111942
]
Nikolay Izhikov commented on IGNITE-12794:
--
I moved this fix to the 2.9 scope.
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111940#comment-17111940 ] YuJue Li commented on IGNITE-12852: --- OK > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-12794:
-
Fix Version/s: (was: 2.8.1)
2.9
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111938#comment-17111938 ] Nikolay Izhikov commented on IGNITE-10417: -- I moved this fix to the 2.9 scope. > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.9 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-10417: - Fix Version/s: (was: 2.8.1) > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.9 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111936#comment-17111936 ] Nikolay Izhikov commented on IGNITE-12852: -- Hello, [~liyuj] It seems there is no chance for this fix to squeeze into 2.8.1 scope. So I moved it into 2.9. > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12852: - Fix Version/s: (was: 2.8.1) 2.9 > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.9 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13001) .NET: Thin Client Compute
[ https://issues.apache.org/jira/browse/IGNITE-13001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111911#comment-17111911 ] Pavel Tupitsyn commented on IGNITE-13001: - Merged to master: a75c2f4ff21e1aa06558282c9965ab076b512cc8 > .NET: Thin Client Compute > - > > Key: IGNITE-13001 > URL: https://issues.apache.org/jira/browse/IGNITE-13001 > Project: Ignite > Issue Type: New Feature > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-42 > Fix For: 2.9 > > Original Estimate: 72h > Time Spent: 1h 40m > Remaining Estimate: 70h 20m > > Add Compute to .NET Thin Client. See IGNITE-12853. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-13001) .NET: Thin Client Compute
[
https://issues.apache.org/jira/browse/IGNITE-13001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13001:
Comment: was deleted
(was: {panel:title=Branch: [pull/7811/head] Base: [master] : Possible Blockers
(101)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5321252]]
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5321215]]
* IgniteCacheTestSuite5:
ClusterStateThinClientReplicatedSelfTest.testDisablingReadOnly - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 4{color} [[tests 17 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5321231]]
* IgnitePdsTestSuite4:
NotOptimizedRebalanceTest.testRebalanceWithoutPersistenceAndClient - Test has
low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
NotOptimizedRebalanceTest.testRebalanceWithPersistenceAndClient - Test has low
fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4: NotOptimizedRebalanceTest.testRebalanceWithPersistence -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
NotOptimizedRebalanceTest.testRebalanceWithoutPersistence - Test has low fail
rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceFilteredNodeOnOnlyInMemoryCluster - Test
has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceNoneBltNodeFailedOnMixedCluster - Test
has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceNoneBltNodeLeftOnOnlyPersistenceCluster
- Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceFilteredNodeOnMixedCluster - Test has
low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceNoneBltNodeFailedOnOnlyInMemoryCluster -
Test has low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceNoneBltNodeLeftOnMixedCluster - Test has
low fail rate in base branch 0,0% and is not flaky
* IgnitePdsTestSuite4:
RebalanceCancellationTest.testRebalanceNoneBltNodeFailedOnOnlyPersistenceCluster
- Test has low fail rate in base branch 0,0% and is not flaky
... and 6 tests blockers
{color:#d04437}Scala (Visor Console){color} [[tests 1 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5321184]]
* VisorConsoleSelfTestSuite: testsuites.VisorConsoleSelfTestSuite - History for
base branch is absent.
{color:#d04437}Web Sessions{color} [[tests 40 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5321180]]
* IgniteWebSessionSelfTestSuite:
WebSessionV1SelfTest.testClientReconnectRequest - Test has low fail rate in
base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionSelfTest.testRestarts - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite:
WebSessionSelfTest.testImplicitlyAttributeModification - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionV1SelfTest.testSingleRequest - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite:
WebSessionTransactionalV1SelfTest.testChangeSessionId - Test has low fail rate
in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionSelfTest.testSingleRequestMetaInf -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionSelfTest.testSingleRequest - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionSelfTest.testClientReconnectRequest
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionSelfTest.testSessionCookie - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite:
WebSessionTransactionalSelfTest.testSessionCookie - Test has low fail rate in
base branch 0,0% and is not flaky
* IgniteWebSessionSelfTestSuite: WebSessionReplicatedSelfTest.testSessionCookie
- Test has low fail rate in base branch 0,0% and is not flaky
... and 29 tests blockers
{color:#d04437}Cache (Restarts) 2{color} [[tests 37 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5321209]]
* IgniteCacheRestartTestSuite2:
GridCachePutAllFailoverSelfTest.testPutAllFailoverNearDisabledTwoBackups - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheRestartTestSuite2:
GridCachePutAllFailoverSelfTest.testPutAllFailoverColocatedNearEnabledTwoBackups
- Test has low
[jira] [Commented] (IGNITE-13001) .NET: Thin Client Compute
[
https://issues.apache.org/jira/browse/IGNITE-13001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111898#comment-17111898
]
Ignite TC Bot commented on IGNITE-13001:
{panel:title=Branch: [pull/7811/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5321907]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5321934buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Thin Client Compute
> -
>
> Key: IGNITE-13001
> URL: https://issues.apache.org/jira/browse/IGNITE-13001
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, iep-42
> Fix For: 2.9
>
> Original Estimate: 72h
> Time Spent: 1.5h
> Remaining Estimate: 70.5h
>
> Add Compute to .NET Thin Client. See IGNITE-12853.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12509) CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified RebalanceDelay
[ https://issues.apache.org/jira/browse/IGNITE-12509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov reassigned IGNITE-12509: --- Assignee: Yaroslav Molochkov > CACHE_REBALANCE_STOPPED event raises for wrong caches in case of specified > RebalanceDelay > - > > Key: IGNITE-12509 > URL: https://issues.apache.org/jira/browse/IGNITE-12509 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Yaroslav Molochkov >Priority: Major > Labels: newbie > Fix For: 2.9 > > Attachments: RebalanceDelayTest.java > > > Steps to reproduce: > 1. Start in-memory cluster with 2 server nodes > 2. Start 3 caches with different rebalance delays (e.g. 5, 10 and 15 seconds) > and upload some data > 3. Start localListener for EVT_CACHE_REBALANCE_STOPPED event on one of the > nodes. > 4. Start one more server node. > 5. Wait for 5 seconds, till rebalance delay is reached. > 6. EVT_CACHE_REBALANCE_STOPPED event received 3 times (1 for each cache), but > in fact only 1 cache was rebalanced. The same happens for the rest of the > caches. > As result on rebalance finish we're getting event for each cache > [CACHE_COUNT] times, instead of 1. > Reproducer attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111835#comment-17111835
]
Maksim Timonin edited comment on IGNITE-10970 at 5/20/20, 7:02 AM:
---
[~ilyak] hi! I'm working on this task and have a question about introducing
alias (you mention in the comment above).
Looks like introducing the alias should be a separate activity and discussed
more carefully. As I understand there are 2 places where the mode is set from
String:
* *spring configuration* injects the value by field name of the enum
_CacheAtomicityMode_;
* in method *GridSqlQueryParser.processExtraParam* where ** we set the value
manually.
If it's required to support MVCC alias in Spring Configuration out of the box
then CacheAtomicityMode class should have a line:
{code:java}
/**
* An alias for TRANSACTIONAL_SNAPSHOT mode.
*/
public static final CacheAtomicityMode MVCC = TRANSACTIONAL_SNAPSHOT;
{code}
In that case it will be correctly parsed by Spring, also there will be
interchangeability of this modes out of the box. But it breaks common enum
functionality (valueOf(), values()).
Should we continue discussing that within this task?
was (Author: timonin.maksim):
[~ilyak] hi! I'm working on this task and have a question about introducing
alias (you mention in the comment above).
Looks like introducing the alias should be a separate activity and discussed
more carefully. As I understand there are 2 places where the mode is set from
String:
* *spring configuration* injects the value by field name of the enum
_CacheAtomicityMode_;
* in method *GridSqlQueryParser.processExtraParam* where ** we set the value
manually.
If it's required to support MVCC alias in Spring Configuration out of the box
then CacheAtomicityMode class should a line:
{code:java}
/**
* An alias for TRANSACTIONAL_SNAPSHOT mode.
*/
public static final CacheAtomicityMode MVCC = TRANSACTIONAL_SNAPSHOT;
{code}
In that case it will be correctly parsed by Spring, also there will be
interchangeability of this modes out of the box. But it breaks common enum
functionality (valueOf(), values()).
Should we continue discussing that within this task?
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: newbie, usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111835#comment-17111835
]
Maksim Timonin edited comment on IGNITE-10970 at 5/20/20, 7:02 AM:
---
[~ilyak] hi! I'm working on this task and have a question about introducing
alias (you mention in the comment above).
Looks like introducing the alias should be a separate activity and discussed
more carefully. As I understand there are 2 places where the mode is set from
String:
* *spring configuration* injects the value by field name of the enum
_CacheAtomicityMode_;
* in method *GridSqlQueryParser.processExtraParam* where we set the value
manually.
If it's required to support MVCC alias in Spring Configuration out of the box
then CacheAtomicityMode class should have a line:
{code:java}
/**
* An alias for TRANSACTIONAL_SNAPSHOT mode.
*/
public static final CacheAtomicityMode MVCC = TRANSACTIONAL_SNAPSHOT;
{code}
In that case it will be correctly parsed by Spring, also there will be
interchangeability of this modes out of the box. But it breaks common enum
functionality (valueOf(), values()).
Should we continue discussing that within this task?
was (Author: timonin.maksim):
[~ilyak] hi! I'm working on this task and have a question about introducing
alias (you mention in the comment above).
Looks like introducing the alias should be a separate activity and discussed
more carefully. As I understand there are 2 places where the mode is set from
String:
* *spring configuration* injects the value by field name of the enum
_CacheAtomicityMode_;
* in method *GridSqlQueryParser.processExtraParam* where ** we set the value
manually.
If it's required to support MVCC alias in Spring Configuration out of the box
then CacheAtomicityMode class should have a line:
{code:java}
/**
* An alias for TRANSACTIONAL_SNAPSHOT mode.
*/
public static final CacheAtomicityMode MVCC = TRANSACTIONAL_SNAPSHOT;
{code}
In that case it will be correctly parsed by Spring, also there will be
interchangeability of this modes out of the box. But it breaks common enum
functionality (valueOf(), values()).
Should we continue discussing that within this task?
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: newbie, usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10970) ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
[
https://issues.apache.org/jira/browse/IGNITE-10970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111835#comment-17111835
]
Maksim Timonin commented on IGNITE-10970:
-
[~ilyak] hi! I'm working on this task and have a question about introducing
alias (you mention in the comment above).
Looks like introducing the alias should be a separate activity and discussed
more carefully. As I understand there are 2 places where the mode is set from
String:
* *spring configuration* injects the value by field name of the enum
_CacheAtomicityMode_;
* in method *GridSqlQueryParser.processExtraParam* where ** we set the value
manually.
If it's required to support MVCC alias in Spring Configuration out of the box
then CacheAtomicityMode class should a line:
{code:java}
/**
* An alias for TRANSACTIONAL_SNAPSHOT mode.
*/
public static final CacheAtomicityMode MVCC = TRANSACTIONAL_SNAPSHOT;
{code}
In that case it will be correctly parsed by Spring, also there will be
interchangeability of this modes out of the box. But it breaks common enum
functionality (valueOf(), values()).
Should we continue discussing that within this task?
> ATOMICITY table creation error message should include TRANSACTIONAL_SNAPSHOT
>
>
> Key: IGNITE-10970
> URL: https://issues.apache.org/jira/browse/IGNITE-10970
> Project: Ignite
> Issue Type: Task
> Components: mvcc, sql
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: newbie, usability
>
> {code}
> 0: jdbc:ignite:thin://localhost> CREATE TABLE city2(id LONG PRIMARY KEY, name
> VARCHAR,name1 VARCHAR) WITH "atomicity=mvcc";
> Error: Invalid value of "ATOMICITY" parameter (should be either TRANSACTIONAL
> or ATOMIC): mvcc (state=42000,code=1001)
> {code}
> This error message should also suggest TRANSACTIONAL_SNAPSHOT to activate
> MVCC, which totally works.
> Docs update request sent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
