[jira] [Commented] (IGNITE-11620) GridDhtInvalidPartitionException stops the cluster
[
https://issues.apache.org/jira/browse/IGNITE-11620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800418#comment-16800418
]
Roman Shtykh commented on IGNITE-11620:
---
{noformat}
[ERROR][ttl-cleanup-worker-#39][] Critical system error detected. Will be
handled accordingly to configured handler [hnd=class
o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=class
o.a.i.i.processors.cache.distributed.dht.GridDhtInvalidPartitionException
[part=814, msg=Adding entry to partition that is concurrently evicted
[grp=OrderLog1, part=814, shouldBeMoving=, belongs=false,
topVer=AffinityTopologyVersion [topVer=579, minorTopVer=0],
curTopVer=AffinityTopologyVersion [topVer=579, minorTopVer=0]
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException:
Adding entry to partition that is concurrently evicted [grp=OrderLog1,
part=814, shouldBeMoving=, belongs=false, topVer=AffinityTopologyVersion
[topVer=579, minorTopVer=0], curTopVer=AffinityTopologyVersion [topVer=579,
minorTopVer=0]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:909)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:784)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:955)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:525)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:946)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1049)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:197)
~[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:137)
[ignite-core-2.6.0.jar:2.6.0]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
[ignite-core-2.6.0.jar:2.6.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
[ERROR][ttl-cleanup-worker-#39][] JVM will be halted immediately due to the
failure: [failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION, err=class
o.a.i.i.processors.cache.distributed.dht.GridDhtInvalidPartitionException
[part=814, msg=Adding entry to partition that is concurrently evicted
[grp=OrderLog1, part=814, shouldBeMoving=, belongs=false,
topVer=AffinityTopologyVersion [topVer=579, minorTopVer=0],
curTopVer=AffinityTopologyVersion [topVer=579, minorTopVer=0]
{noformat}
> GridDhtInvalidPartitionException stops the cluster
> --
>
> Key: IGNITE-11620
> URL: https://issues.apache.org/jira/browse/IGNITE-11620
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.6, 2.7
>Reporter: Roman Shtykh
>Priority: Critical
>
> When injecting data and having it expired at the same time rebalancing occurs,
> *GridDhtInvalidPartitionException* triggers *SYSTEM_WORKER_TERMINATION*.
> This can cause cascading failures in the cluster and take the whole cluster
> down.
> Simple test case:
> {noformat}
> import org.apache.ignite.IgniteCache;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import javax.cache.expiry.CreatedExpiryPolicy;
> import javax.cache.expiry.Duration;
> import java.util.concurrent.CountDownLatch;
> import java.util.concurrent.TimeUnit;
> import static org.apache.ignite.cache.CacheAtomicityMode.ATOMIC;
> import static
[jira] [Created] (IGNITE-11620) GridDhtInvalidPartitionException stops the cluster
Roman Shtykh created IGNITE-11620:
-
Summary: GridDhtInvalidPartitionException stops the cluster
Key: IGNITE-11620
URL: https://issues.apache.org/jira/browse/IGNITE-11620
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7, 2.6
Reporter: Roman Shtykh
When injecting data and having it expired at the same time rebalancing occurs,
*GridDhtInvalidPartitionException* triggers *SYSTEM_WORKER_TERMINATION*.
This can cause cascading failures in the cluster and take the whole cluster
down.
Simple test case:
{noformat}
import org.apache.ignite.IgniteCache;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.TcpDiscoveryIpFinder;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import javax.cache.expiry.CreatedExpiryPolicy;
import javax.cache.expiry.Duration;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import static org.apache.ignite.cache.CacheAtomicityMode.ATOMIC;
import static org.apache.ignite.cache.CacheMode.PARTITIONED;
/**
*
*/
public class ExpireWhileRebalanceTest extends GridCommonAbstractTest {
private static final int ENTRIES = 50;
/**
*
*/
protected static final TcpDiscoveryIpFinder IP_FINDER = new
TcpDiscoveryVmIpFinder(true);
/**
* {@inheritDoc}
*/
@Override
protected IgniteConfiguration getConfiguration(String gridName) throws
Exception {
IgniteConfiguration cfg = super.getConfiguration(gridName);
((TcpDiscoverySpi) cfg.getDiscoverySpi()).setIpFinder(IP_FINDER);
cfg.setFailureHandler(new StopNodeOrHaltFailureHandler());
CacheConfiguration ccfg = new
CacheConfiguration<>(DEFAULT_CACHE_NAME);
ccfg.setAtomicityMode(ATOMIC);
ccfg.setCacheMode(PARTITIONED);
ccfg.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(new
Duration(TimeUnit.SECONDS, 1)));
cfg.setCacheConfiguration(ccfg);
return cfg;
}
/**
* @throws Exception If failed.
*/
public void testExpireWhileRebalancing() throws Exception {
startGridsMultiThreaded(4);
IgniteCache cache = ignite(0).cache(DEFAULT_CACHE_NAME);
CountDownLatch latch = new CountDownLatch(1);
new Thread(() -> {
for (int i = 1; i <= ENTRIES; i++) {
cache.put(i, i);
if (i % (ENTRIES / 10) == 0)
System.out.println(">>> Entries put: " + i);
}
latch.countDown();
}).start();
// stopping 0 has no effect
stopGrid(3);
awaitPartitionMapExchange();
startGrid(3);
latch.await(10, TimeUnit.SECONDS);
}
/**
* {@inheritDoc}
*/
@Override
protected void afterTest() throws Exception {
stopAllGrids();
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11535) AtomicLong cannot be found after creation
[
https://issues.apache.org/jira/browse/IGNITE-11535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800178#comment-16800178
]
Ivan Rakov commented on IGNITE-11535:
-
[~slava.koptilin], merged to master.
> AtomicLong cannot be found after creation
> -
>
> Key: IGNITE-11535
> URL: https://issues.apache.org/jira/browse/IGNITE-11535
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For now, IgniteAtomics use {{PartitionLossPolicy.IGNORE}}, which is the
> default value for all caches, (see
> {{DataStructuresProcessor#cacheConfiguration}}). Therefore, partition loss
> leads to the fact that information about IgniteAtomic may be lost as well. In
> that case, any operation with IgniteAtomic results in the following exception:
> {code}
> javax.cache.processor.EntryProcessorException: Failed to find atomic long:
> atomicLong
> {code}
> {code:java}
> Value: An error occurred while calling o2248.incrementAndGet.
> : class org.apache.ignite.IgniteException: Failed to find atomic long:
> nodeIdFilter_7
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl.incrementAndGet(GridCacheAtomicLongImpl.java:105)
> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at py4j.reflection.MethodInvoker.invoke(MethodInvoker.java:244)
> at py4j.reflection.ReflectionEngine.invoke(ReflectionEngine.java:357)
> at py4j.Gateway.invoke(Gateway.java:282)
> at py4j.commands.AbstractCommand.invokeMethod(AbstractCommand.java:132)
> at py4j.commands.CallCommand.execute(CallCommand.java:79)
> at py4j.GatewayConnection.run(GatewayConnection.java:238)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.cache.processor.EntryProcessorException: Failed to find
> atomic long: nodeIdFilter_7
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:525)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheAtomicLongImpl$IncrementAndGetProcessor.process(GridCacheAtomicLongImpl.java:512)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:424)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1237)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:677)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1054)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:396)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:519)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:150)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:97)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:177)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
> at
>
[jira] [Comment Edited] (IGNITE-11536) Add information about possible long GC pause to checkpoint started message.
[
https://issues.apache.org/jira/browse/IGNITE-11536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800177#comment-16800177
]
Ivan Rakov edited comment on IGNITE-11536 at 3/24/19 9:35 PM:
--
[~antonovsergey93], your PR has conflicts with master. Also a few comments:
1. GridCacheDatabaseSharedManager: new field lacks javadoc
{code:java}
private final LongJVMPauseDetector pauseDetector;
{code}
2. Do we really need to explicitly pass instance of LongJVMPauseDetector to
every needed grid component? There's only one instance per node anyway - we can
obtain it via getter from kernal context instead.
was (Author: ivan.glukos):
[~antonovsergey93], your PR has conflicts with master. Also a few comments:
1. GridCacheDatabaseSharedManager: new field
{code:java}
private final LongJVMPauseDetector pauseDetector;
{code}
2. Do we really need to explicitly pass instance of LongJVMPauseDetector to
every needed grid component? There's only one instance per node anyway - we can
obtain it via getter from kernal context instead.
> Add information about possible long GC pause to checkpoint started message.
> ---
>
> Key: IGNITE-11536
> URL: https://issues.apache.org/jira/browse/IGNITE-11536
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One of possible reasons long hold of write lock on checkpoint is GC pause.
> Now you must check logs around on {{Possible too long JVM pause}} message. We
> should print possible long GC pause time in {{Checkpoint started}} message,
> if threshold was passed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11536) Add information about possible long GC pause to checkpoint started message.
[
https://issues.apache.org/jira/browse/IGNITE-11536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800177#comment-16800177
]
Ivan Rakov commented on IGNITE-11536:
-
[~antonovsergey93], your PR has conflicts with master. Also a few comments:
1. GridCacheDatabaseSharedManager: new field
{code:java}
private final LongJVMPauseDetector pauseDetector;
{code}
2. Do we really need to explicitly pass instance of LongJVMPauseDetector to
every needed grid component? There's only one instance per node anyway - we can
obtain it via getter from kernal context instead.
> Add information about possible long GC pause to checkpoint started message.
> ---
>
> Key: IGNITE-11536
> URL: https://issues.apache.org/jira/browse/IGNITE-11536
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One of possible reasons long hold of write lock on checkpoint is GC pause.
> Now you must check logs around on {{Possible too long JVM pause}} message. We
> should print possible long GC pause time in {{Checkpoint started}} message,
> if threshold was passed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800174#comment-16800174
]
Ivan Rakov commented on IGNITE-11617:
-
TC looks good:
https://ci.ignite.apache.org/viewLog.html?buildId=3402534=buildResultsDiv=IgniteTests24Java8_RunAll
Can't get TC bot visa, the fetaure is not working at the moment.
[~agoncharuk], please review.
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: ClientFastReplyCoordinatorFailureTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[
https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-11618:
-
Assignee: Alexey Goncharuk
> Assertion got removed exception on entry with dht local candidate on
> transaction timeout
>
>
> Key: IGNITE-11618
> URL: https://issues.apache.org/jira/browse/IGNITE-11618
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: TxOptimisticSerializableTest.java
>
>
> IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}}
> method is called right before {{onEntriesLocked}} and contains the same
> assertion which may cause node failure.
> Attached test reproduces the problem if the following code is added to the
> very beginning of the {{checkReadConflict}} method:
> {code}
> U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11484) Get rid of ForkJoinPool#commonPool usage for system critical tasks
[ https://issues.apache.org/jira/browse/IGNITE-11484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800099#comment-16800099 ] Ivan Rakov commented on IGNITE-11484: - Merged to master. > Get rid of ForkJoinPool#commonPool usage for system critical tasks > -- > > Key: IGNITE-11484 > URL: https://issues.apache.org/jira/browse/IGNITE-11484 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Rakov >Assignee: Ivan Rakov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > We use ForkJoinPool#commonPool for sorting checkpoint pages. > This may backfire if common pool is already utilized in current JVM: > checkpoint may wait for sorting for a long time, which in turn will cause > user load dropdown. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072 ] Ivan Fedotov edited comment on IGNITE-11411 at 3/24/19 1:53 PM: [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2] https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 was (Author: ivanan.fed): [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2]https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072 ] Ivan Fedotov edited comment on IGNITE-11411 at 3/24/19 1:53 PM: [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2]https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 was (Author: ivanan.fed): [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2]https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072 ] Ivan Fedotov edited comment on IGNITE-11411 at 3/24/19 1:52 PM: [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2]https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 was (Author: ivanan.fed): [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2]https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800072#comment-16800072 ] Ivan Fedotov commented on IGNITE-11411: --- [~Pavlukhin] , Thank you for your attention. I fixed merge conflicts and re-run TC nightly[1]. According to this, there are no blockers related to this ticket. I guess that now ticket is ready for the review again. By the way, I noticed that your changes in the ticket [2] have an influence on beforeTestsStarted(), afterTestsStarted() methods. I guess that now when we decided to leave the support of such methods in the context of JUnit rules, my ticket about removing of them [3] becomes not actual. If you do not mind, I will comment it with a link on your ticket and close as "Not a problem". [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6227/head=Latest] [2]https://issues.apache.org/jira/browse/IGNITE-11356 [3] https://issues.apache.org/jira/browse/IGNITE-11413 > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Time Spent: 10m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11471) JDBC: Thin driver should start with a random server to connect
[
https://issues.apache.org/jira/browse/IGNITE-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16800030#comment-16800030
]
Ivan Pavlukhin commented on IGNITE-11471:
-
[~ibelyakov], [~vozerov], please pay attention that line (from patch) in method
{{JdbcThinTcpIo#nextServerIndex}}
{code}
return (int)(abs(nextIdx) % len);
{code}
can still return negative number because {{Math.abs}} returns
{{Long.MIN_VALUE}} if {{Long.MIN_VALUE}} is passed as argument and {{%}}
operators preserves a sign of a _dividend_ ({{-1 % 2 == -1}}).
> JDBC: Thin driver should start with a random server to connect
> --
>
> Key: IGNITE-11471
> URL: https://issues.apache.org/jira/browse/IGNITE-11471
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Reporter: Stanislav Lukyanov
>Assignee: Igor Belyakov
>Priority: Major
> Labels: newbie
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Thin JDBC driver uses a list of server addresses to connect to. Connections
> created in a single JVM will use round-robin to choose the server to connect,
> yielding a uniform distribution. However, the round-robin always starts from
> the first server in the list. It means that multiple JVMs with the same JDBC
> connection URL and one connection each will all connect to the same server.
> Need to choose the first server randomly to have a better distribution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11619) Misleading Javadoc for IgniteConfiguration.setMetricsExpireTime
Moti Nisenson-Ken created IGNITE-11619:
--
Summary: Misleading Javadoc for
IgniteConfiguration.setMetricsExpireTime
Key: IGNITE-11619
URL: https://issues.apache.org/jira/browse/IGNITE-11619
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7, 2.4
Reporter: Moti Nisenson-Ken
The javadoc reads:
* Sets time in milliseconds after which a certain metric value is considered
expired.
* If not set explicitly, then default value is \{@code 600,000}
milliseconds (10 minutes).
*
* @param metricsExpTime The metricsExpTime to set.
* @see #DFLT_METRICS_EXPIRE_TIME
* @return \{@code this} for chaining.
Note that DFLT_METRICS_EXPIRE_TIME is:
/**
* Default metrics expire time. The value is {@link Long#MAX_VALUE} which
* means that metrics never expire.
*/
I haven't verified which versions are impacted - it has likely been present for
a very long time (at least since 2.4, perhaps much longer)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Rakov reassigned IGNITE-11617:
---
Assignee: Ivan Rakov
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Assignee: Ivan Rakov
>Priority: Critical
> Fix For: 2.8
>
> Attachments: ClientFastReplyCoordinatorFailureTest.java
>
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest
[ https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799979#comment-16799979 ] Eduard Shangareev commented on IGNITE-11568: Looks good. Thank you for contribution. > Change afterTest() annotation in TcpDiscoveryFailedJoinTest > --- > > Key: IGNITE-11568 > URL: https://issues.apache.org/jira/browse/IGNITE-11568 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated > by after. Meanwhile, it is under prohibition because afterTest will be > executed after test anyway (see JUnit3TestLegacySupport and > beforeTest/afterTest usage in GridAbstractTest for more details). > > So, it is necessary to change after annotation on override. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
