[
https://issues.apache.org/jira/browse/IGNITE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15281470#comment-15281470
]
Vladimir Ozerov commented on IGNITE-2744:
-----------------------------------------
Looked at implementation again. I can neither accept, not reject it. My
concerns:
1) I can say nothing about changes to {{IgniteTxHandler}} as I am not familiar
with this piece of code.
2) {{IgniteTxRemoteStateImpl}} - looks readMap is always empty and is never
filled with any data. Is it true?
3) {{IgniteTxRemoteStateImpl}} - having separate concurrent HM seems too heavy
for me. Normally user will have 1 cache, rarely 2, very rare - more than 2.
Wrapped CHM looks like an overkill for me. We already produce too much garbage
and I do not want to add more. Can we do something like this (pseudocode)?
{code}
public void unwindEvicts(GridCacheSharedContext cctx) {
assert readMap == null || readMap.isEmpty();
int singleCacheId = -1;
Set<Integer> cacheIds = null;
for (IgniteTxKey writeKey : writeMap.keySet()) {
int cacheId = writeKey.cacheId();
// Have we already notified this cache?
if (cacheId == singleCacheId || cacheIds != null &&
!cacheIds.add(writeCacheId))
continue;
if (singleCacheId == -1)
singleCacheId = cacheId;
if (cacheIds == null) {
cacheIds = new HashSet<>(2);
cacheIds.add(cacheId);
}
GridCacheContext ctx = cctx.cacheContext(cacheId);
if (ctx != null)
CU.unwindEvicts(ctx);
}
}
{code}
> Optimize "unwindEvict" call in GridCacheIoManager.processMessage().
> -------------------------------------------------------------------
>
> Key: IGNITE-2744
> URL: https://issues.apache.org/jira/browse/IGNITE-2744
> Project: Ignite
> Issue Type: Task
> Components: cache
> Affects Versions: 1.5.0.final
> Reporter: Vladimir Ozerov
> Assignee: Vladimir Ozerov
> Priority: Critical
> Labels: performance
> Fix For: 1.6
>
>
> We call this method on every (!!!) received cache message. This call is
> pretty heavy as it iterates over all caches.
> We need to optimize it. E.g., check evicts only for the cache to which
> received message belongs. And iterate over the whole set only if we know for
> sure that several caches are affected (e.g. due to cross-cache TX).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
