[
https://issues.apache.org/jira/browse/IGNITE-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16729346#comment-16729346
]
Ivan Fedotov edited comment on IGNITE-10376 at 12/27/18 6:30 AM:
-----------------------------------------------------------------
[~sergey-chugunov],
Now It seems that problem really relates with
[IGNITE-9830|https://issues.apache.org/jira/browse/IGNITE-9830]. This ticker
solves the next problem: we have a huge cluster and updating metadata process
on this. At some moment on the node, which already has the newest metadata
version, starts the transaction that wants to update the same metadata. It goes
inside {{CacheObjectBinaryProcessorImpl#addMeta}} and completes the method
because of {{(mergedMeta == oldMeta)}} condition. As a result, the transaction
maps on nodes which do not have the latest metadata version. In the ticket the
condition {{metaHolder.pendingVersion() == metaHolder.acceptedVersion()}} was
added.
But now duplicate requests on updating metadata are not filtered: if n threads
ask for metadata updates than n requests will be sent. And each next thread
that wants to add the same metadata during this process will launch the
metadata update.
It is necessary here to wait until the first metadata finishes update in case
of duplicate metadata.
was (Author: ivanan.fed):
[~sergey-chugunov], Now It seems that problem really relates with
[IGNITE-9830|https://issues.apache.org/jira/browse/IGNITE-9830]. This ticker
solves the next problem: we have a huge cluster and updating metadata process
on this. At some moment on the node, which already has the newest metadata
version, starts the transaction that wants to update the same metadata. It goes
inside {{CacheObjectBinaryProcessorImpl#addMeta}} and completes the method
because of {{(mergedMeta == oldMeta)}} condition. As a result, the transaction
maps on nodes which do not have the latest metadata version. In the ticket the
condition {{metaHolder.pendingVersion() == metaHolder.acceptedVersion()}} was
added.
But now duplicate requests on updating metadata are not filtered: if n threads
ask for metadata updates than n requests will be sent. And each next thread
that wants to add the same metadata during this process will launch the
metadata update.
It is necessary here to wait until the first metadata finishes update in case
of duplicate metadata.
> Fail to update metadata during invocation on cache
> ---------------------------------------------------
>
> Key: IGNITE-10376
> URL: https://issues.apache.org/jira/browse/IGNITE-10376
> Project: Ignite
> Issue Type: Task
> Reporter: Ivan Fedotov
> Assignee: Ivan Fedotov
> Priority: Major
> Labels: MakeTeamcityGreenAgain, stability, test-fail
> Fix For: 2.8
>
> Attachments: IGNITE-10376 log.txt
>
>
> BinaryObjectException exception sometimes appears in
> [testAtomicOnheapTwoBackupAsyncFullSync|https://ci.ignite.apache.org/viewLog.html?buildId=2398013&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ContinuousQuery4#testNameId3300126853696550025]
> at the
> [moment|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/query/continuous/CacheContinuousQueryOrderingEventTest.java#L371]
> of CacheEntryProcessor invocation.
> {code}class org.apache.ignite.binary.BinaryObjectException: Failed to update
> meta data for type:
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$QueryTestValue
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:516)
> at
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:194)
> at
> org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1332)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1815)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1150)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke0(GridDhtAtomicCache.java:831)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.invoke(GridDhtAtomicCache.java:787)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1438)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.invoke(IgniteCacheProxyImpl.java:1482)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.invoke(GatewayProtectedCacheProxy.java:1228)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryOrderingEventTest$1.run(CacheContinuousQueryOrderingEventTest.java:373)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1300)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){code}
> It can be because of absence of locks in
> GridCacheMapEntry#touch(GridCacheMapEntry.java:5063).
> It seems that test does not work after integration MVCC in Continuous Query.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
