[jira] [Comment Edited] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042164#comment-17042164
]
kartheek b edited comment on IGNITE-12508 at 2/21/20 10:01 PM:
---
Hi Ivan,
I would like to work on this issue. Hence assigning to myself. Could you
please let me know how to proceed further with the issue?
Thanks.
was (Author: kark):
Hi Ivan,
I would like to work on this issue. Hence assigning to myself. Could you
please let me know how to reproduce the issue?
Thanks.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042164#comment-17042164
]
kartheek b edited comment on IGNITE-12508 at 2/21/20 10:00 PM:
---
Hi Ivan,
I would like to work on this issue. Hence assigning to myself. Could you
please let me know how to reproduce the issue?
Thanks.
was (Author: kark):
Hi Ivan,
I would like to work on this issue. Could you please let me know the initial
details which I might need to proceed on this issue.
Thanks.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kartheek b reassigned IGNITE-12508:
---
Assignee: kartheek b
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12508) GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
[
https://issues.apache.org/jira/browse/IGNITE-12508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042164#comment-17042164
]
kartheek b commented on IGNITE-12508:
-
Hi Ivan,
I would like to work on this issue. Could you please let me know the initial
details which I might need to proceed on this issue.
Thanks.
> GridCacheProcessor#cacheDescriptor(int) has O(N) complexity
> ---
>
> Key: IGNITE-12508
> URL: https://issues.apache.org/jira/browse/IGNITE-12508
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Rakov
>Assignee: kartheek b
>Priority: Major
> Labels: newbie
> Fix For: 2.9
>
>
> See the method code:
> {code}
> @Nullable public DynamicCacheDescriptor cacheDescriptor(int cacheId) {
> for (DynamicCacheDescriptor cacheDesc : cacheDescriptors().values()) {
> CacheConfiguration ccfg = cacheDesc.cacheConfiguration();
> assert ccfg != null : cacheDesc;
> if (CU.cacheId(ccfg.getName()) == cacheId)
> return cacheDesc;
> }
> return null;
> }
> {code}
> This method is invoked in several hot paths which causes significant
> performance regression when the number of caches is large, for example,
> logical recovery and security check for indexing.
> The method should be improved to use a hash map or similar data structure to
> get a better complexity
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042042#comment-17042042 ] Vladimir Steshin edited comment on IGNITE-12464 at 2/21/20 5:13 PM: Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 3) Fixed failed tests which used service class directly instead of its interface. was (Author: vladsz83): Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 4) Fixed failed tests which used service class directly instead of its interface. > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 1h > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042041#comment-17042041
]
Vladimir Steshin edited comment on IGNITE-12701 at 2/21/20 5:11 PM:
Major changes:
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
was (Author: vladsz83):
Major changes:
# Added IgniteCluster#state(ClusterState newState, boolean force).
# Deprecated IgniteCluster#state(ClusterState newState).
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042042#comment-17042042 ] Vladimir Steshin commented on IGNITE-12464: --- Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 4) Fixed failed tests which used service class directly instead of its interface. > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 1h > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042041#comment-17042041
]
Vladimir Steshin commented on IGNITE-12701:
---
Major changes:
# Added IgniteCluster#state(ClusterState newState, boolean force).
# Deprecated IgniteCluster#state(ClusterState newState).
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12715) Calcite integration. Secondary indexes support.
[ https://issues.apache.org/jira/browse/IGNITE-12715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042009#comment-17042009 ] Ivan Pavlukhin commented on IGNITE-12715: - [~rkondakov], out of curiosity, are you going to use Calcite materialized views here? > Calcite integration. Secondary indexes support. > --- > > Key: IGNITE-12715 > URL: https://issues.apache.org/jira/browse/IGNITE-12715 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > > Secondary indexes should be supported by Calcite-based engine as well as they > supported by the legacy H2 engine. At first we can use the old engine for > indexes maintenance (building, updating, etc). In this case Calcite engine > will only use indexes metadata for query planning and index scans for query > execution. On the next iteration we need to eliminate the old engine usage. > Approximate plan for indexes support implementation: > # Add indexes to schema and set up all schema listeners. > # Add Collation to planner's output trait set and check if generated plan is > properly chosen in accordance to index sort direction. > # Implement index scans with filtering > # Add Sort node to exec. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
[ https://issues.apache.org/jira/browse/IGNITE-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042000#comment-17042000 ] Ivan Pavlukhin commented on IGNITE-12549: - [~macrergate], approach with topology read lock looks fine to me. I left some comments on GitHub. > Scan query/iterator on a replicated cache may get wrong results > --- > > Key: IGNITE-12549 > URL: https://issues.apache.org/jira/browse/IGNITE-12549 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.7.6 >Reporter: Sergey Kosarev >Assignee: Sergey Kosarev >Priority: Critical > Fix For: 2.8 > > Time Spent: 2h > Remaining Estimate: 0h > > Case 1 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start servr node 2 > 4. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the node 2 > It can get empty or partial results. (if rebalance on node 2 is finished) > Case 2 > 1. start server node 1 > 2. create and fill replicated cache with RebalanceMode.Async (as by default) > 3. start client node 2 > 4. start server node 3 > 5. immediately execute scan query on the replicated cache((or just iterate > the cache)) on the client node 2 > It can get empty or partial results. (if rebalance on node 2 is not finished > and query is mapped on the node 2) > It looks like problem in the > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() > case REPLICATED: > if (prj != null || part != null) > return nodes(cctx, prj, part); > if (cctx.affinityNode()) > return *Collections.singletonList(cctx.localNode())*; > Collection affNodes = nodes(cctx, null, null); > return affNodes.isEmpty() ? affNodes : > *Collections.singletonList(F.rand(affNodes))*; > case PARTITIONED: > return nodes(cctx, prj, part); > which is executed in > org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#executeScanQuery. > If executed on a just started node it obviously returns the local node > disregarding was it rebalanced or not. > If executed on a client it returns a random affinity node, so it also can be > not yet rebalanced node. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12715) Calcite integration. Secondary indexes support.
[ https://issues.apache.org/jira/browse/IGNITE-12715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Kondakov reassigned IGNITE-12715: --- Assignee: Roman Kondakov > Calcite integration. Secondary indexes support. > --- > > Key: IGNITE-12715 > URL: https://issues.apache.org/jira/browse/IGNITE-12715 > Project: Ignite > Issue Type: New Feature > Components: sql >Reporter: Roman Kondakov >Assignee: Roman Kondakov >Priority: Major > > Secondary indexes should be supported by Calcite-based engine as well as they > supported by the legacy H2 engine. At first we can use the old engine for > indexes maintenance (building, updating, etc). In this case Calcite engine > will only use indexes metadata for query planning and index scans for query > execution. On the next iteration we need to eliminate the old engine usage. > Approximate plan for indexes support implementation: > # Add indexes to schema and set up all schema listeners. > # Add Collation to planner's output trait set and check if generated plan is > properly chosen in accordance to index sort direction. > # Implement index scans with filtering > # Add Sort node to exec. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12715) Calcite integration. Secondary indexes support.
Roman Kondakov created IGNITE-12715: --- Summary: Calcite integration. Secondary indexes support. Key: IGNITE-12715 URL: https://issues.apache.org/jira/browse/IGNITE-12715 Project: Ignite Issue Type: New Feature Components: sql Reporter: Roman Kondakov Secondary indexes should be supported by Calcite-based engine as well as they supported by the legacy H2 engine. At first we can use the old engine for indexes maintenance (building, updating, etc). In this case Calcite engine will only use indexes metadata for query planning and index scans for query execution. On the next iteration we need to eliminate the old engine usage. Approximate plan for indexes support implementation: # Add indexes to schema and set up all schema listeners. # Add Collation to planner's output trait set and check if generated plan is properly chosen in accordance to index sort direction. # Implement index scans with filtering # Add Sort node to exec. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12707) Update release branch version for 2.8
[ https://issues.apache.org/jira/browse/IGNITE-12707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-12707. -- Resolution: Fixed > Update release branch version for 2.8 > -- > > Key: IGNITE-12707 > URL: https://issues.apache.org/jira/browse/IGNITE-12707 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > The following need to be done: > 1. Update pom.xml version to 2.8.0 > 2. Update Linux package version to 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12712) NPE in checkpoint thread
[
https://issues.apache.org/jira/browse/IGNITE-12712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041893#comment-17041893
]
Ignite TC Bot commented on IGNITE-12712:
{panel:title=Branch: [pull/7463/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=5069465&buildTypeId=IgniteTests24Java8_RunAll]
> NPE in checkpoint thread
>
>
> Key: IGNITE-12712
> URL: https://issues.apache.org/jira/browse/IGNITE-12712
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NPE occured in checkpoint thread (rare reproducing):
> {noformat}
> [2019-11-04 20:54:58,018][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
> Received full message, will finish exchange
> [node=1784645d-3bef-44fe-8288-e0c16202f5e3, resVer=AffinityTopologyVersion
> [topVer=4, minorTopVer=9]]
> [2019-11-04 20:54:58,023][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
> Finish exchange future [startVer=AffinityTopologyVersion [topVer=4,
> minorTopVer=9], resVer=AffinityTopologyVersion [topVer=4, minorTopVer=9],
> err=null]
> [2019-11-04 20:54:58,029][INFO ][sys-#50][GridCacheProcessor] Finish proxy
> initialization, cacheName=SQL_PUBLIC_T8,
> localNodeId=5b153e14-70f2-4408-a125-584752532ebd
> [2019-11-04 20:54:58,030][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
> Completed partition exchange [localNode=5b153e14-70f2-4408-a125-584752532ebd,
> exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion
> [topVer=4, minorTopVer=9], evt=DISCOVERY_CUSTOM_EVT, evtNode=TcpDiscoveryNode
> [id=1784645d-3bef-44fe-8288-e0c16202f5e3, consistentId=1, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1572890071469, loc=false,
> ver=8.7.8#20191101-sha1:e344ed04, isClient=false], done=true,
> newCrdFut=null], topVer=AffinityTopologyVersion [topVer=4, minorTopVer=9]]
> [2019-11-04 20:54:58,030][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
> Exchange timings [startVer=AffinityTopologyVersion [topVer=4, minorTopVer=9],
> resVer=AffinityTopologyVersion [topVer=4, minorTopVer=9], stage="Waiting in
> exchange queue" (0 ms), stage="Exchange parameters initialization" (0 ms),
> stage="Update caches registry" (0 ms), stage="Start caches" (52 ms),
> stage="Affinity initialization on cache group start" (1 ms), stage="Determine
> exchange type" (0 ms), stage="Preloading notification" (0 ms), stage="WAL
> history reservation" (0 ms), stage="Wait partitions release" (1 ms),
> stage="Wait partitions release latch" (5 ms), stage="Wait partitions release"
> (0 ms), stage="Restore partition states" (7 ms), stage="After states restored
> callback" (10 ms), stage="Waiting for Full message" (59 ms), stage="Affinity
> recalculation" (0 ms), stage="Full map updating" (4 ms), stage="Exchange
> done" (7 ms), stage="Total time" (146 ms)]
> [2019-11-04 20:54:58,030][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
> Exchange longest local stages [startVer=AffinityTopologyVersion [topVer=4,
> minorTopVer=9], resVer=AffinityTopologyVersion [topVer=4, minorTopVer=9],
> stage="Affinity initialization on cache group start [grp=SQL_PUBLIC_T8]" (1
> ms) (parent=Affinity initialization on cache group start), stage="Restore
> partition states [grp=SQL_PUBLIC_T8]" (6 ms) (parent=Restore partition
> states), stage="Restore partition states [grp=ignite-sys-cache]" (3 ms)
> (parent=Restore partition states), stage="Restore partition states
> [grp=cache_group_3]" (0 ms) (parent=Restore partition states)]
> [2019-11-04 20:54:58,037][INFO
> ][exchange-worker-#45][GridCachePartitionExchangeManager] Skipping
> rebalancing (nothing scheduled) [top=AffinityTopologyVersion [topVer=4,
> minorTopVer=9], force=false, evt=DISCOVERY_CUSTOM_EVT,
> node=1784645d-3bef-44fe-8288-e0c16202f5e3]
> [2019-11-04 20:54:58,713][INFO
> ][db-checkpoint-thread-#53][GridCacheDatabaseSharedManager] Checkpoint
> started [checkpointId=82969270-b1a5-4480-9513-3af65bab0e17,
> startPtr=FileWALPointer [idx=0, fileOff=3550077, len=12350],
> checkpointBeforeLockTime=8ms, checkpointLockWait=4ms,
> checkpointListenersExecuteTime=56ms, checkpointLockHoldTime=61ms,
> walCpRecordFsyncDuration=4ms, writeCheckpointEntryDuration=8ms,
> splitAndSortCpPagesDuration=1ms, pages=178, reason='timeout']
> [2019-11-04 20:54:58,914][INFO ][exchange-worker-#45][time] Started exchange
> init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=10], crd=false,
> evt=DISCOVERY_CUSTOM_EVT, evtNode=1784645d-3bef-44fe-8288-e0c16202f5e3,
> customEvt=DynamicCacheChang
[jira] [Updated] (IGNITE-12714) Absence of default value of IGNITE_SYSTEM_WORKER_BLOCKED TIMEOUT
[
https://issues.apache.org/jira/browse/IGNITE-12714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Kalashnikov updated IGNITE-12714:
---
Description:
Scenario:
1. Start 3 data nodes
2. Start load with a streamer on 6 clients
3. Start data nodes restarter
Result:
Keys weren't loaded in all (1000) caches.
In the server node log I see:
{noformat}
[2019-07-17 16:52:36,881][ERROR][tcp-disco-msg-worker-#2] Blocked
system-critical thread has been detected. This can lead to cluster-wide
undefined behaviour [threadName=data-streamer-stripe-7, blockedFor=16s]
[2019-07-17 16:52:36,883][WARN ][tcp-disco-msg-worker-#2] Thread
[name="data-streamer-stripe-7-#24", id=43, state=WAITING, blockCnt=111,
waitCnt=169964]
[2019-07-17 16:52:36,885][ERROR][tcp-disco-msg-worker-#2] 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=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=data-streamer-stripe-7,
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]]]
org.apache.ignite.IgniteException: GridWorker [name=data-streamer-stripe-7,
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1838)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1833)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:230)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2804)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7568)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2866)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7506)
[ignite-core-2.5.9.jar:2.5.9]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-2.5.9.jar:2.5.9]
{noformat}
*Solution:*
Increase timeout to 2 min
org.apache.ignite.IgniteSystemProperties#IGNITE_SYSTEM_WORKER_BLOCKED_TIMEOUT
was:
Scenario:
1. Start 3 data nodes
2. Start load with a streamer on 6 clients
3. Start data nodes restarter
Result:
Keys weren't loaded in all (1000) caches.
In the server node log I see:
{noformat}
[2019-07-17 16:52:36,881][ERROR][tcp-disco-msg-worker-#2] Blocked
system-critical thread has been detected. This can lead to cluster-wide
undefined behaviour [threadName=data-streamer-stripe-7, blockedFor=16s]
[2019-07-17 16:52:36,883][WARN ][tcp-disco-msg-worker-#2] Thread
[name="data-streamer-stripe-7-#24", id=43, state=WAITING, blockCnt=111,
waitCnt=169964]
[2019-07-17 16:52:36,885][ERROR][tcp-disco-msg-worker-#2] 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=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=data-streamer-stripe-7,
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]]]
org.apache.ignite.IgniteException: GridWorker [name=data-streamer-stripe-7,
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1838)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1833)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:230)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2804)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7568)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2866)
[ignite-core-2.5.9.jar:2.5.9]
[jira] [Created] (IGNITE-12714) Absence of default value of IGNITE_SYSTEM_WORKER_BLOCKED TIMEOUT
Anton Kalashnikov created IGNITE-12714:
--
Summary: Absence of default value of IGNITE_SYSTEM_WORKER_BLOCKED
TIMEOUT
Key: IGNITE-12714
URL: https://issues.apache.org/jira/browse/IGNITE-12714
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
Scenario:
1. Start 3 data nodes
2. Start load with a streamer on 6 clients
3. Start data nodes restarter
Result:
Keys weren't loaded in all (1000) caches.
In the server node log I see:
{noformat}
[2019-07-17 16:52:36,881][ERROR][tcp-disco-msg-worker-#2] Blocked
system-critical thread has been detected. This can lead to cluster-wide
undefined behaviour [threadName=data-streamer-stripe-7, blockedFor=16s]
[2019-07-17 16:52:36,883][WARN ][tcp-disco-msg-worker-#2] Thread
[name="data-streamer-stripe-7-#24", id=43, state=WAITING, blockCnt=111,
waitCnt=169964]
[2019-07-17 16:52:36,885][ERROR][tcp-disco-msg-worker-#2] 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=SYSTEM_WORKER_BLOCKED, err=class
o.a.i.IgniteException: GridWorker [name=data-streamer-stripe-7,
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]]]
org.apache.ignite.IgniteException: GridWorker [name=data-streamer-stripe-7,
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1838)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1833)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:230)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2804)
~[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7568)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2866)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
[ignite-core-2.5.9.jar:2.5.9]
at
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7506)
[ignite-core-2.5.9.jar:2.5.9]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
[ignite-core-2.5.9.jar:2.5.9]
{noformat}
Logs: ftp://gg@172.25.2.50/poc-tester-logs/1723/log-2019-07-17-17-33-23
Log with dumps:
ftp://gg@172.25.2.50/poc-tester-logs/1723/log-2019-07-17-17-33-23/servers/172.25.1.12/poc-tester-server-172.25.1.12-id-0-2019-07-17-16-46-58.log-1-2019-07-17.log.gz
*Solution:*
Increase timeout to 2 min
org.apache.ignite.IgniteSystemProperties#IGNITE_SYSTEM_WORKER_BLOCKED_TIMEOUT
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12713) [Suite] PDS 1 flaky failed on TC
Anton Kalashnikov created IGNITE-12713: -- Summary: [Suite] PDS 1 flaky failed on TC Key: IGNITE-12713 URL: https://issues.apache.org/jira/browse/IGNITE-12713 Project: Ignite Issue Type: Bug Reporter: Anton Kalashnikov Assignee: Anton Kalashnikov IgnitePdsTestSuite: BPlusTreeReuseListPageMemoryImplTest.testIterateConcurrentPutRemove_2 ⚂IgnitePdsTestSuite: BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12712) NPE in checkpoint thread
Anton Kalashnikov created IGNITE-12712:
--
Summary: NPE in checkpoint thread
Key: IGNITE-12712
URL: https://issues.apache.org/jira/browse/IGNITE-12712
Project: Ignite
Issue Type: Bug
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov
NPE occured in checkpoint thread (rare reproducing):
{noformat}
[2019-11-04 20:54:58,018][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
Received full message, will finish exchange
[node=1784645d-3bef-44fe-8288-e0c16202f5e3, resVer=AffinityTopologyVersion
[topVer=4, minorTopVer=9]]
[2019-11-04 20:54:58,023][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
Finish exchange future [startVer=AffinityTopologyVersion [topVer=4,
minorTopVer=9], resVer=AffinityTopologyVersion [topVer=4, minorTopVer=9],
err=null]
[2019-11-04 20:54:58,029][INFO ][sys-#50][GridCacheProcessor] Finish proxy
initialization, cacheName=SQL_PUBLIC_T8,
localNodeId=5b153e14-70f2-4408-a125-584752532ebd
[2019-11-04 20:54:58,030][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
Completed partition exchange [localNode=5b153e14-70f2-4408-a125-584752532ebd,
exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion
[topVer=4, minorTopVer=9], evt=DISCOVERY_CUSTOM_EVT, evtNode=TcpDiscoveryNode
[id=1784645d-3bef-44fe-8288-e0c16202f5e3, consistentId=1, addrs=ArrayList
[127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
intOrder=1, lastExchangeTime=1572890071469, loc=false,
ver=8.7.8#20191101-sha1:e344ed04, isClient=false], done=true, newCrdFut=null],
topVer=AffinityTopologyVersion [topVer=4, minorTopVer=9]]
[2019-11-04 20:54:58,030][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
Exchange timings [startVer=AffinityTopologyVersion [topVer=4, minorTopVer=9],
resVer=AffinityTopologyVersion [topVer=4, minorTopVer=9], stage="Waiting in
exchange queue" (0 ms), stage="Exchange parameters initialization" (0 ms),
stage="Update caches registry" (0 ms), stage="Start caches" (52 ms),
stage="Affinity initialization on cache group start" (1 ms), stage="Determine
exchange type" (0 ms), stage="Preloading notification" (0 ms), stage="WAL
history reservation" (0 ms), stage="Wait partitions release" (1 ms),
stage="Wait partitions release latch" (5 ms), stage="Wait partitions release"
(0 ms), stage="Restore partition states" (7 ms), stage="After states restored
callback" (10 ms), stage="Waiting for Full message" (59 ms), stage="Affinity
recalculation" (0 ms), stage="Full map updating" (4 ms), stage="Exchange done"
(7 ms), stage="Total time" (146 ms)]
[2019-11-04 20:54:58,030][INFO ][sys-#50][GridDhtPartitionsExchangeFuture]
Exchange longest local stages [startVer=AffinityTopologyVersion [topVer=4,
minorTopVer=9], resVer=AffinityTopologyVersion [topVer=4, minorTopVer=9],
stage="Affinity initialization on cache group start [grp=SQL_PUBLIC_T8]" (1 ms)
(parent=Affinity initialization on cache group start), stage="Restore partition
states [grp=SQL_PUBLIC_T8]" (6 ms) (parent=Restore partition states),
stage="Restore partition states [grp=ignite-sys-cache]" (3 ms) (parent=Restore
partition states), stage="Restore partition states [grp=cache_group_3]" (0 ms)
(parent=Restore partition states)]
[2019-11-04 20:54:58,037][INFO
][exchange-worker-#45][GridCachePartitionExchangeManager] Skipping rebalancing
(nothing scheduled) [top=AffinityTopologyVersion [topVer=4, minorTopVer=9],
force=false, evt=DISCOVERY_CUSTOM_EVT,
node=1784645d-3bef-44fe-8288-e0c16202f5e3]
[2019-11-04 20:54:58,713][INFO
][db-checkpoint-thread-#53][GridCacheDatabaseSharedManager] Checkpoint started
[checkpointId=82969270-b1a5-4480-9513-3af65bab0e17, startPtr=FileWALPointer
[idx=0, fileOff=3550077, len=12350], checkpointBeforeLockTime=8ms,
checkpointLockWait=4ms, checkpointListenersExecuteTime=56ms,
checkpointLockHoldTime=61ms, walCpRecordFsyncDuration=4ms,
writeCheckpointEntryDuration=8ms, splitAndSortCpPagesDuration=1ms, pages=178,
reason='timeout']
[2019-11-04 20:54:58,914][INFO ][exchange-worker-#45][time] Started exchange
init [topVer=AffinityTopologyVersion [topVer=4, minorTopVer=10], crd=false,
evt=DISCOVERY_CUSTOM_EVT, evtNode=1784645d-3bef-44fe-8288-e0c16202f5e3,
customEvt=DynamicCacheChangeBatch
[id=8b06d873e61-af9e27a6-8fe9-4da1-bc0a-d19cd0eabd36, reqs=ArrayList
[DynamicCacheChangeRequest [cacheName=SQL_PUBLIC_T9, hasCfg=true,
nodeId=1784645d-3bef-44fe-8288-e0c16202f5e3, clientStartOnly=false, stop=false,
destroy=false, disabledAfterStartfalse]], exchangeActions=ExchangeActions
[startCaches=[SQL_PUBLIC_T9], stopCaches=null, startGrps=[cache_group_4],
stopGrps=[], resetParts=null, stateChangeRequest=null], startCaches=false],
allowMerge=false]
[2019-11-04 20:54:58,930][INFO ][exchange-worker-#45][PageMemoryImpl] Started
page memory [memoryAllocated=200.0 MiB, pages=49630, tableSize=3.9 MiB,
checkpointBuffer=200.0 MiB]
[2019-11-04 20:54:5
[jira] [Created] (IGNITE-12711) Change dataRegion max size for preventing possible test fail.
Stanilovsky Evgeny created IGNITE-12711: --- Summary: Change dataRegion max size for preventing possible test fail. Key: IGNITE-12711 URL: https://issues.apache.org/jira/browse/IGNITE-12711 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.7.6 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Fix For: 2.9 Limit max region size for preventing possible tests failure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12696) Remove deprecated @MXBeanParametersNames and @MXBeanParametersDescriptions annotations
[
https://issues.apache.org/jira/browse/IGNITE-12696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Vysotin reassigned IGNITE-12696:
Assignee: (was: Aleksey Vysotin)
> Remove deprecated @MXBeanParametersNames and @MXBeanParametersDescriptions
> annotations
> --
>
> Key: IGNITE-12696
> URL: https://issues.apache.org/jira/browse/IGNITE-12696
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey N. Gura
>Priority: Major
> Labels: newbie
> Fix For: 3.0
>
>
> {{@MXBeanParametersNames}} and {{@MXBeanParametersDescriptions}} annotations
> are deprecated due to the change IGNITE-10698.
> Mentioned annotations must be removed in Apache Ignite 3.0 release, **but not
> earlier**.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12684) Optimize count of threads for rebuild indexes
[
https://issues.apache.org/jira/browse/IGNITE-12684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041679#comment-17041679
]
Alexey Scherbakov commented on IGNITE-12684:
[~ktkale...@gridgain.com]
Looks good.
Merged to master f52350c552f957e4c867bab9431b45ea1f16dc62.
Thanks for the contribution.
> Optimize count of threads for rebuild indexes
> -
>
> Key: IGNITE-12684
> URL: https://issues.apache.org/jira/browse/IGNITE-12684
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We were recently implemented the new property
> {{INDEX_REBUILDING_PARALLELISM}} (by issue IGNITE-11979).
> That fix do possible to rebuild indexes, after restart without index.bin or
> restore from snapshot to another topology, in parallel threads.
> But now the process of rebuild can to consume a lot of threads, which limited
> on INDEX_REBUILDING_PARALLELISM * AVAILABLE_PROC_CNT (count of thread in
> public pool).
> For example in case of INDEX_REBUILDING_PARALLELISM = 28 and 64 CPU it will
> be more then 1.5К threads.
> Look at the method, it will create dedicate thread on each invocation
> `org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl#processPartitionsAsync`
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[ https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17041675#comment-17041675 ] Andrey Mashenkov commented on IGNITE-12710: --- [~antonovsergey93], I've reviewed a PR and found code looks like a mess. SchemaIndexCacheStat violates all principles of OOP and it's logic resides outside of class. Is it possible to extend (or may be wrap) SchemaIndexCacheVisitorClosure implementations with statistics logic? > Extension log in rebuild indexes to search problems > --- > > Key: IGNITE-12710 > URL: https://issues.apache.org/jira/browse/IGNITE-12710 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have the ability to get extended information about rebuild indexes: > cache, cache id, cache group, cache group id, index name, index type, index > size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
