date:20210226

[MTCGA]: new failures in builds [5889007] needs to be handled

2021-02-26 Thread dpavlov . tasks

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 *Test with high flaky rate in master-nightly 
IgnitePdsRebalancingOnNotStableTopologyTest.test 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=8039258633878980719&branch=%3Cdefault%3E&tab=testDetails

 *Test with high flaky rate in master-nightly 
IgniteUidAsConsistentIdMigrationTest.testRestartOnExistingOldStyleId 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-7060607268758670123&branch=%3Cdefault%3E&tab=testDetails

 *Test with high flaky rate in master-nightly 
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyCachesAbruptlyWithoutCheckpoints
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5180582589037958306&branch=%3Cdefault%3E&tab=testDetails

 *Test with high flaky rate in master-nightly 
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyGroupCachesAbruptlyWithoutCheckpoints
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=7041034747489803654&branch=%3Cdefault%3E&tab=testDetails

 *Test with high flaky rate in master-nightly 
IgniteUidAsConsistentIdMigrationTest.testStartTwoOldStyleNodes 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5447578554431548633&branch=%3Cdefault%3E&tab=testDetails
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 02:51:54 27-02-2021

[MTCGA]: new failures in builds [5892258] needs to be handled

2021-02-26 Thread dpavlov . tasks

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 *New Critical Failure in master Control Utility 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtility?branch=%3Cdefault%3E
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 21:06:54 26-02-2021

[jira] [Created] (IGNITE-14254) Graceful stop rebuilding indexes when deactivating a cluster

2021-02-26 Thread Kirill Tkalenko (Jira)

Kirill Tkalenko created IGNITE-14254:


 Summary: Graceful stop rebuilding indexes when deactivating a 
cluster
 Key: IGNITE-14254
 URL: https://issues.apache.org/jira/browse/IGNITE-14254
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
 Fix For: 2.11


If in the process of rebuilding the indexes to deactivate the cluster, then a 
number of errors may appear, including a node fail. It is necessary to stop 
index rebuilding before stopping the cache.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14253) .Net: Failed to acquire lock within provided timeout for transaction

2021-02-26 Thread Fedor Malchikov (Jira)

Fedor Malchikov  created IGNITE-14253:
-

 Summary: .Net: Failed to acquire lock within provided timeout for 
transaction 
 Key: IGNITE-14253
 URL: https://issues.apache.org/jira/browse/IGNITE-14253
 Project: Ignite
  Issue Type: Bug
  Components: examples, platforms
Affects Versions: 2.9.1
Reporter: Fedor Malchikov 
 Attachments: example_node_1.log

See Thick/Cache/TransactionDeadlockDetection example: 


{code:java}

>>> Update failed in thread 1: 
>>> Apache.Ignite.Core.Transactions.TransactionTimeoutException: Failed to 
>>> acquire lock within provided timeout for transaction [timeout=2000, 
>>> tx=GridNearTxLocal[xid=7d0bd2fd771--0d75-fffc--0001, 
>>> xidVersion=GridCacheVersion [topVer=225837052, order=1614357049559, 
>>> nodeOrder=1], nearXidVersion=GridCacheVersion [topVer=225837052, 
>>> order=1614357049559, nodeOrder=1], concurrency=PESSIMISTIC, 
>>> isolation=READ_COMMITTED, state=MARKED_ROLLBACK, 
>>> topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], invalidate=false, 
>>> rollbackOnly=true, nodeId=f9df2d5d-1f47-4980-ae27-7684f761048f, 
>>> timeout=2000, startTime=1614357051532, duration=2045, label=null]] ---> 
>>> Apache.Ignite.Core.Common.JavaException: class 
>>> org.apache.ignite.transactions.TransactionTimeoutException: Failed to 
>>> acquire lock within provided timeout for transaction [timeout=2000, 
>>> tx=GridNearTxLocal[xid=7d0bd2fd771--0d75-fffc--0001, 
>>> xidVersion=GridCacheVersion [topVer=225837052, order=1614357049559, 
>>> nodeOrder=1], nearXidVersion=GridCacheVersion [topVer=225837052, 
>>> order=1614357049559, nodeOrder=1], concurrency=PESSIMISTIC, 
>>> isolation=READ_COMMITTED, state=MARKED_ROLLBACK, 
>>> topVer=AffinityTopologyVersion [topVer=1, minorTopVer=1], invalidate=false, 
>>> rollbackOnly=true, nodeId=f9df2d5d-1f47-4980-ae27-7684f761048f, 
>>> timeout=2000, startTime=1614357051532, duration=2045, label=null]]
at 
org.apache.ignite.internal.util.IgniteUtils$13.apply(IgniteUtils.java:986)
at 
org.apache.ignite.internal.util.IgniteUtils$13.apply(IgniteUtils.java:981)
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1265)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2077)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1313)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:817)
at 
org.apache.ignite.internal.processors.platform.cache.PlatformCache.processInStreamOutLong(PlatformCache.java:839)
at 
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:66)
Caused by: class 
org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException: Failed 
to acquire lock within provided timeout for transaction [timeout=2000, 
tx=GridNearTxLocal[xid=7d0bd2fd771--0d75-fffc--0001, 
xidVersion=GridCacheVersion [topVer=225837052, order=1614357049559, 
nodeOrder=1], nearXidVersion=GridCacheVersion [topVer=225837052, 
order=1614357049559, nodeOrder=1], concurrency=PESSIMISTIC, 
isolation=READ_COMMITTED, state=MARKED_ROLLBACK, topVer=AffinityTopologyVersion 
[topVer=1, minorTopVer=1], invalidate=false, rollbackOnly=true, 
nodeId=f9df2d5d-1f47-4980-ae27-7684f761048f, timeout=2000, 
startTime=1614357051532, duration=2045, label=null]]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$LockTimeoutObject$1.apply(GridDhtColocatedLockFuture.java:1536)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$LockTimeoutObject$1.apply(GridDhtColocatedLockFuture.java:1529)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:407)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.listen(GridFutureAdapter.java:362)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$LockTimeoutObject.onTimeout(GridDhtColocatedLockFuture.java:1529)
at 
org.apache.ignite.internal.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:278)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.base/java.lang.Thread.run(Thread.java:834)

   --- End of inner exception stack trace ---
   at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutLong[TR](Int32 type, 
Func`2 outAction, Func`3 inAction, Func`2 readErrorAction)
   at Apache.Ignite.Core.Impl.Cache.CacheImpl`2.Put(TK key, TV val)
   at 
Apache.Ignite.Examples.Thick.Cache.Transact

[MEETUP] March 2: Moving from Postgres to Apache Ignite to boost Jira cloud app development

2021-02-26 Thread Kseniya Romanova

Hi Igniters!
Join Virtual Apache Ignite Meetup on March 2nd[1]. Peter Gagarinov from
Alliedium will share his experience of moving to Ignite from Postgres and
integrating Ignite with Atlassian Connect Spring Boot. In this
presentation, Peter will speak about Apache Ignite features such as SQL and
NoSQL queries, thin and thick clients, caching, distributed messaging and
events, distributed computations, database-schema change tracking,
Kubernetes deployment.

[1] https://www.meetup.com/Apache-Ignite-Virtual-Meetup/events/276416802/

-- 
Cheers,
Kseniya

Devrel at GridGain
Don't miss upcoming community events, join
https://www.meetup.com/Apache-Ignite-Virtual-Meetup/

[jira] [Created] (IGNITE-14252) CorruptedTreeException for persistence 2.7.5 running on 2.9.1 version

2021-02-26 Thread Maxim Muzafarov (Jira)

Maxim Muzafarov created IGNITE-14252:


 Summary: CorruptedTreeException for persistence 2.7.5 running on 
2.9.1 version
 Key: IGNITE-14252
 URL: https://issues.apache.org/jira/browse/IGNITE-14252
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov


PDS Version - 2.7.5
Ignite node verision - 2.9.1

h3. Cache configuration
{code}
DataRegionConfiguration dataRegionCfg = new DataRegionConfiguration();
dataRegionCfg.setName(DATA_REGION_NAME)
  .setInitialSize(200_000_000)
  .setMaxSize(200_000_000)
  .setPersistenceEnabled(true)
  .setMetricsEnabled(true);

DataStorageConfiguration storageCfg = new DataStorageConfiguration();
storageCfg.setDataRegionConfigurations(dataRegionCfg)
 .setWriteThrottlingEnabled(true)
 .setMetricsEnabled(true);

IgniteConfiguration ignCfg = new IgniteConfiguration();
ignCfg.setWorkDirectory(workDirectory)
  .setDataStorageConfiguration(storageCfg)
  .setIgniteInstanceName("instanceName")
  .setSystemWorkerBlockedTimeout(1)
  .setFailureDetectionTimeout(1)
{code}

h3. Exception
{code}
2021-02-19 13:30:38,175 ERROR STDIO [pool-32-thread-5] {} Feb 19, 2021 1:30:38 
PM org.apache.ignite.logger.java.JavaLogger error
SEVERE: Critical system error detected. Will be handled accordingly to 
configured handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, 
super=AbstractFailureHandler 
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=CRITICAL_ERROR, err=class 
o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is 
corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-128547534, 
val2=281474976721835]], msg=Runtime failure on lookup row: SearchRow 
[key=com.bloomberg.aim.wingman.cachemgr.Ts3DataCache$Ts3SecurityCacheKey 
[idHash=1436767547, hash=-931214342, 
accountCusip=com.bloomberg.aim.wingman.common.dto.submgr.AccountCusip 
[idHash=316813954, hash=343304888, accountId=0, 
cusip=com.bloomberg.aim.wingman.common.dto.Cusip [idHash=1325824124, 
hash=2123451959, cusip1=136125, cusip2=9001, cusip3=541401120, dept=2, 
subflag=2]]], hash=-931214342, cacheId=0
class 
org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
 B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=-128547534, 
val2=281474976721835]], msg=Runtime failure on lookup row: SearchRow 
[key=com.bloomberg.aim.wingman.cachemgr.Ts3DataCache$Ts3SecurityCacheKey 
[idHash=1436767547, hash=-931214342, accountCusip=
com.bloomberg.aim.wingman.common.dto.submgr.AccountCusip [idHash=316813954, 
hash=343304888, accountId=0, cusip=com.bloomberg.aim.wingman.common.dto.Cusip 
[idHash=1325824124, hash=2123451959, cusip1=136125, cusip2=9001, 
cusip3=541401120, dept=2, subflag=2]]], hash=-931214342, cacheId=0]]
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6106)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1367)
at 
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1344)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.find(IgniteCacheOffheapManagerImpl.java:2755)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.find(GridCacheOffheapManager.java:2469)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.read(IgniteCacheOffheapManagerImpl.java:637)
at 
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.getAllInternal(GridLocalAtomicCache.java:410)
at 
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.getAll(GridLocalAtomicCache.java:323)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.repairableGetAll(GridCacheAdapter.java:4907)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAll(GridCacheAdapter.java:1617)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAll(IgniteCacheProxyImpl.java:1157)
at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAll(GatewayProtectedCacheProxy.java:724)
at 
com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.fetchCalcrtDataByKeySync(Ts3DataCache.java:1535)
at 
com.bloomberg.aim.wingman.cachemgr.Ts3DataCache.lambda$fetchCalcrtDataBySecurityKeyAccountAsync$11(Ts3DataCache.java:895)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.c

[jira] [Created] (IGNITE-14251) Ignite extension: refactor usage of proxy classes and their names

2021-02-26 Thread Mikhail Petrov (Jira)

Mikhail Petrov created IGNITE-14251:
---

 Summary: Ignite extension: refactor usage of proxy classes and 
their names
 Key: IGNITE-14251
 URL: https://issues.apache.org/jira/browse/IGNITE-14251
 Project: Ignite
  Issue Type: Improvement
Reporter: Mikhail Petrov
Assignee: Mikhail Petrov


It's proposed to change names of the following proxy classes to make them more 
consistent:

IgniteProxyImpl -> IgniteNodeProxy 
ClosableIgniteProxyImpl -> ClosableIgniteNodeProxy

IgniteCacheClientProxy -> IgniteClientCacheProxu

 

It's also proposed to reuse ignite-spring-data-commons module in 
ignite-spring-tx-ext tests as ClientCacheProxy and IgniteCacheProxy duplicate 
existing IgniteCacheProxy functionality.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Trying to get some response

2021-02-26 Thread Pavel Tupitsyn

Hi,

u...@ignite.apache.org address is reachable.

However, it looks like you have an http address instead of the email
address, which probably does not work:
"https://lists.apache.org/list.html?u...@ignite.apache.org";

On Fri, Feb 26, 2021 at 5:28 PM Sean Chen  wrote:

> Hi team,
>
> Is "u...@ignite.apache.org
> " still
> reachable?
>
> Sean
>

Trying to get some response

2021-02-26 Thread Sean Chen

Hi team,

Is "u...@ignite.apache.org
" still
reachable?

Sean

[jira] [Created] (IGNITE-14250) .NET Examples: Race condition - the TASK_REDUCE, TASK_FINISHED events arrive after the end of GetСomputer().Execute

2021-02-26 Thread Fedor Malchikov (Jira)

Fedor Malchikov  created IGNITE-14250:
-

 Summary: .NET Examples: Race condition - the TASK_REDUCE, 
TASK_FINISHED events arrive after the end of GetСomputer().Execute
 Key: IGNITE-14250
 URL: https://issues.apache.org/jira/browse/IGNITE-14250
 Project: Ignite
  Issue Type: Bug
  Components: examples, platforms
Affects Versions: 2.9.1
Reporter: Fedor Malchikov 
 Attachments: example_node_1.log, server_node_1.log, server_node_2.log

{code:java}
[16:20:20]   ^-- Baseline [id=0, size=3, online=3, offline=0]>>> Events example 
started.
>>> Listening for a local event...Local listener received an event 
>>> [evt=TASK_STARTED]Service initialized: default-map-serviceService started: 
>>> default-map-service
>>> Executing salary job for 7 employee(s) ...
>>> Received events count: 1
Service cancelled: default-map-service
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-14249) Ignite extensions: Flaky IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter test

2021-02-26 Thread Mikhail Petrov (Jira)

Mikhail Petrov created IGNITE-14249:
---

 Summary: Ignite extensions: Flaky 
IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter test
 Key: IGNITE-14249
 URL: https://issues.apache.org/jira/browse/IGNITE-14249
 Project: Ignite
  Issue Type: Test
Reporter: Mikhail Petrov


IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter is flaky. 
See [TC 
build|https://ci.ignite.apache.org/viewLog.html?buildId=5892624&tab=buildResultsDiv&buildTypeId=IgniteExtensions_Tests_Kafka#testNameId788555262623894619]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

IGNITE-14225 -- New Helper Method For Tests

2021-02-26 Thread Atri Sharma

Hi,

I have raised a new PR for IGNITE-14225:

https://github.com/apache/ignite/pull/8833

Please help in reviewing.

Regards,

Atri

-- 
Regards,

Atri
Apache Concerted

Re: [DISCCUSS] Ignite 2.9.2. Index compatibility issue 2.x -> 2.9

2021-02-26 Thread Ilya Kasnacheev

Hello!

I don't think we should fix it in 2.9.2 if the fix will already be
available in 2.10.

Anyone who sees this bug is welcome to upgrade to 2.10.

Regards,
-- 
Ilya Kasnacheev


пт, 26 февр. 2021 г. в 11:32, Max Timonin :

> Hi, Igniters!
>
> There was a compatibility issue [1] with upgrading an old version of Ignite
> to 2.9. Inlined JavaObjects just are skipped and then it leads to undefined
> behavior:
> 1. In best case it just fails with BPlusTreeCorruptedException;
> 2. But in some cases Ignite may *silently* make a wrong decision while
> comparing, then results of queries will be invalid.
>
> Workaround is to rebuild indexes.
>
> For the new release 2.10 this bug was fixed today (commits are [2], [3]).
>
> WDYT, is it worth to backport those commits to the previous Ignite version?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-14206
> [2]
>
> https://github.com/apache/ignite/commit/851f650ba03e0b6c081cfe23f411fd2bf6be0228
> [3]
>
> https://github.com/apache/ignite/commit/93b74922bd04b164301d7bc5a2788b9693d4a8a4
>

[jira] [Created] (IGNITE-14248) Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock properly

2021-02-26 Thread Vladimir Pligin (Jira)

Vladimir Pligin created IGNITE-14248:


 Summary: Handle exceptions in 
PartitionReservationManager.onDoneAfterTopologyUnlock properly
 Key: IGNITE-14248
 URL: https://issues.apache.org/jira/browse/IGNITE-14248
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.9.1
Reporter: Vladimir Pligin


If an exception (or even Error) is thrown inside of the method then the node 
turns into some unrecoverable state. Here's an example.
 # an exchange is about to finish, it's time to invalidate partition 
reservations.
 # exchange thread delegates it to a thread in the management pool
 # management pool tries to allocate a new thread (maybe it's idle and 
therefore empty)
 # for example ulimit is reached, the error is 
java.lang.OutOfMemoryError: unable to create native thread: possibly out of 
memory or process/resource limits reached
 # It's being logged, no further action is taken
 # partitions are reserved forever

Message:
2021-02-25 05:52:03.242 [exchange-worker-#182] ERROR 
o.a.i.i.p.q.h.t.PartitionReservationManager - Unexpected exception on start 
reservations cleanup
java.lang.OutOfMemoryError: unable to create native thread: possibly out of 
memory or process/resource limits reached
at java.base/java.lang.Thread.start0(Native Method)
at java.base/java.lang.Thread.start(Thread.java:803)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor.runLocal(GridClosureProcessor.java:847)
at 
org.apache.ignite.internal.processors.query.h2.twostep.PartitionReservationManager.onDoneAfterTopologyUnlock(PartitionReservationManager.java:323)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:2617)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onDone(GridDhtPartitionsExchangeFuture.java:159)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:1064)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3375)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3194)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.base/java.lang.Thread.run(Thread.java:834)
 

Code of PartitionReservationManager.onDoneAfterTopologyUnlock:

 
{code:java}
@Override public void onDoneAfterTopologyUnlock(final 
GridDhtPartitionsExchangeFuture fut) {
try {
// Must not do anything at the exchange thread. Dispatch to the 
management thread pool.
ctx.closure().runLocal(() -> {
AffinityTopologyVersion topVer = 
ctx.cache().context().exchange()

.lastAffinityChangedTopologyVersion(fut.topologyVersion());
reservations.forEach((key, r) -> {
if (r != REPLICATED_RESERVABLE && 
!F.eq(key.topologyVersion(), topVer)) {
assert r instanceof GridDhtPartitionsReservation;   
 ((GridDhtPartitionsReservation)r).invalidate();
}
});
},
GridIoPolicy.MANAGEMENT_POOL);
}
catch (Throwable e) {
log.error("Unexpected exception on start reservations cleanup", e);
}
}
{code}
 

 

My vision is there are two basic approaches:
 * to kill the node (it's already non-functional at this point)
 * try to recover somehow (to be honest it's not clear how exactly)

This particular OOM situation seems unrecoverable in fact. It's a environment 
misconfiguration. It would be great to investigate if potentially recoverable 
exceptions are possible to be raised inside this block. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[DISCCUSS] Ignite 2.9.2. Index compatibility issue 2.x -> 2.9

2021-02-26 Thread Max Timonin

Hi, Igniters!

There was a compatibility issue [1] with upgrading an old version of Ignite
to 2.9. Inlined JavaObjects just are skipped and then it leads to undefined
behavior:
1. In best case it just fails with BPlusTreeCorruptedException;
2. But in some cases Ignite may *silently* make a wrong decision while
comparing, then results of queries will be invalid.

Workaround is to rebuild indexes.

For the new release 2.10 this bug was fixed today (commits are [2], [3]).

WDYT, is it worth to backport those commits to the previous Ignite version?


[1] https://issues.apache.org/jira/browse/IGNITE-14206
[2]
https://github.com/apache/ignite/commit/851f650ba03e0b6c081cfe23f411fd2bf6be0228
[3]
https://github.com/apache/ignite/commit/93b74922bd04b164301d7bc5a2788b9693d4a8a4

[jira] [Created] (IGNITE-14247) Add documentation pages for snapshot check command

2021-02-26 Thread Maxim Muzafarov (Jira)

Maxim Muzafarov created IGNITE-14247:


 Summary: Add documentation pages for snapshot check command
 Key: IGNITE-14247
 URL: https://issues.apache.org/jira/browse/IGNITE-14247
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
 Fix For: 2.11


The snapshot check command must be properly documented.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

2021-02-26 Thread Max Timonin

Hi, Maxim!

The bug IGNITE-14206 [1] fixed. There are 2 commits to cherry-pick

1.
https://github.com/apache/ignite/commit/851f650ba03e0b6c081cfe23f411fd2bf6be0228
2.
https://github.com/apache/ignite/commit/93b74922bd04b164301d7bc5a2788b9693d4a8a4


https://issues.apache.org/jira/browse/IGNITE-14206

On Wed, Feb 24, 2021 at 5:47 PM Maxim Muzafarov  wrote:

> Anton,
>
> Your improvement is very important, for sure, but it's almost 2 months
> have passed since the initiation of the release branch. I think we
> should prepare the changes as fast as possible for now and initiate
> with the next one release. In general, it would be nice to have a
> release plan for the year ahead so each developer will understand on
> which release his changes can get into.
>
> That's why I'm going to prepare an RC-build on Monday 1-st March.
>
> On Wed, 24 Feb 2021 at 11:13, Anton Vinogradov  wrote:
> >
> > Maxim,
> >
> > https://issues.apache.org/jira/browse/IGNITE-13873
> > Is ready for review, is it possible to wait for it?
> >
> > On Wed, Feb 24, 2021 at 12:01 AM Maxim Muzafarov 
> wrote:
> >
> > > Folks,
> > >
> > >
> > > I'd like to cherry-pick to the release branch the following fixes:
> > >
> > > Fix security context for JDBC bulk-load operations
> > > https://issues.apache.org/jira/browse/IGNITE-13472
> > >
> > > Fixed an issue that caused a deadlock when user cache was created in
> > > parallel with TTL worker was in progress.
> > > https://issues.apache.org/jira/browse/IGNITE-14078
> > >
> > > On Thu, 18 Feb 2021 at 20:26, Maxim Muzafarov 
> wrote:
> > > >
> > > > Maxim, Igor,
> > > >
> > > > Thanks for sharing details.
> > > > Let's wait for these fixes.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-14206
> > > > [2] https://issues.apache.org/jira/browse/IGNITE-14204
> > > >
> > > > On Thu, 18 Feb 2021 at 18:35, Igor Sapego 
> wrote:
> > > > >
> > > > > Maxim,
> > > > >
> > > > > I believe I could fix the ticket [1] by the end of the next week.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14204
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Thu, Feb 18, 2021 at 6:30 PM Max Timonin <
> timonin.ma...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hi! I've today found an issue [1], there is wrong handling of
> > > inlined POJO.
> > > > > > This bug appeared in 2.9.0 and makes it impossible to work with
> > > > > > multi-column indexes created on old AI versions that contain
> inlined
> > > POJO
> > > > > > keys in the middle.
> > > > > >
> > > > > > I'm working on the fix and asked Konstantin Orlov to review it. I
> > > think
> > > > > > that it will take only a couple of days to fix this issue. From
> my
> > > side, it
> > > > > > looks like a release blocker, but we've been living with that
> since
> > > 2.9.0.
> > > > > > WDYT if the release can wait for the fix?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14206
> > > > > >
> > > > > > On Thu, Feb 18, 2021 at 5:38 PM Maxim Muzafarov <
> mmu...@apache.org>
> > > wrote:
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > >
> > > > > > > Do we have any estimations of how long does it take to fix the
> > > issue
> > > > > > > [1] in C++ thin client? The bug must be fixed for sure,
> however, I
> > > > > > > tend to continue with the release (if fixing the bug require a
> few
> > > > > > > weeks) and prepare a batch of fixes for the 2.10.1.
> > > > > > >
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-14204
> > > > > > >
> > > > > > > On Thu, 18 Feb 2021 at 13:22, Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > There was a ticket filed about the new feature, transactions
> in
> > > C++
> > > > > > thin
> > > > > > > > client, making this feature unusable if there's more than one
> > > > > > connection
> > > > > > > > endpoint:
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-14204
> > > > > > > >
> > > > > > > > I don't think this is a genuine blocker for 2.10, since
> there is
> > > a
> > > > > > > > workaround (use just one endpoint), nevertheless it is a
> critical
> > > > > > crasher
> > > > > > > > bug, so I wonder if Igor could take a look at it promptly,
> > > include the
> > > > > > > fix
> > > > > > > > in 2.10.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > >
> > > > > > > > чт, 18 февр. 2021 г. в 09:03, Zhenya Stanilovsky
> > > > > > >  > > > > > > > >:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I fill the ticket with drop problem, plz take a look [1]
> > > > > > > > >
> > > > > > > > > [1]  https://issues.apache.org/jira/browse/IGNITE-14205
> > > > > > > > >
> > > > > > > > > >Ilya,
> > > > > > > > > >
> > > > > > > > > >Thanks!
> > > > > > > > > >I've added this step to the Release Process wiki page

[MTCGA]: new failures in builds [5889007] needs to be handled

[MTCGA]: new failures in builds [5892258] needs to be handled

[jira] [Created] (IGNITE-14254) Graceful stop rebuilding indexes when deactivating a cluster

[jira] [Created] (IGNITE-14253) .Net: Failed to acquire lock within provided timeout for transaction

[MEETUP] March 2: Moving from Postgres to Apache Ignite to boost Jira cloud app development

[jira] [Created] (IGNITE-14252) CorruptedTreeException for persistence 2.7.5 running on 2.9.1 version

[jira] [Created] (IGNITE-14251) Ignite extension: refactor usage of proxy classes and their names

Re: Trying to get some response

Trying to get some response

[jira] [Created] (IGNITE-14250) .NET Examples: Race condition - the TASK_REDUCE, TASK_FINISHED events arrive after the end of GetСomputer().Execute

[jira] [Created] (IGNITE-14249) Ignite extensions: Flaky IgniteSourceConnectorTest.testEventsInjectedIntoKafkaWithoutFilter test

IGNITE-14225 -- New Helper Method For Tests

Re: [DISCCUSS] Ignite 2.9.2. Index compatibility issue 2.x -> 2.9

[jira] [Created] (IGNITE-14248) Handle exceptions in PartitionReservationManager.onDoneAfterTopologyUnlock properly

[DISCCUSS] Ignite 2.9.2. Index compatibility issue 2.x -> 2.9

[jira] [Created] (IGNITE-14247) Add documentation pages for snapshot check command

Re: Re[2]: [DISCUSSION] Apache Ignite Release 2.10 (time, scope, manager)

17 matches

Site Navigation

Mail list logo

Footer information