[jira] [Commented] (IGNITE-11824) Integrate diagnostic PageLockTracker to DataStructure
[ https://issues.apache.org/jira/browse/IGNITE-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835632#comment-16835632 ] Anton Kalashnikov commented on IGNITE-11824: [~DmitriyGovorukhin] Looks good to me. > Integrate diagnostic PageLockTracker to DataStructure > -- > > Key: IGNITE-11824 > URL: https://issues.apache.org/jira/browse/IGNITE-11824 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > After [IGNITE-11786] will be completed, we will have a structure for tracking > page locks per-thread. The next step, need to integrate it into diagnostic > API and implements a component for creating this structure per-thread. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11841) Dump page history info in FailureHandler on CorruptedTreeException
[ https://issues.apache.org/jira/browse/IGNITE-11841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11841: Fix Version/s: 2.8 > Dump page history info in FailureHandler on CorruptedTreeException > -- > > Key: IGNITE-11841 > URL: https://issues.apache.org/jira/browse/IGNITE-11841 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835627#comment-16835627
]
Roman Kondakov commented on IGNITE-11756:
-
[~amashenkov], [~tledkov-gridgain], [~taras.ledkov], patch is ready for review.
Tests look good.
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835625#comment-16835625
]
Roman Kondakov commented on IGNITE-11756:
-
Local statistics was implemented by overriding method
{{GridH2IndexBase#getRowCountApproximation}} which is used by H2 optimizer in
order to estimate plan cost.
Row count statistics is cached to avoid recalculation on each method
invocation. This cache is invalidated on each table size changes.
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11816) Diagnostic processor for dump page history info
[ https://issues.apache.org/jira/browse/IGNITE-11816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-11816: --- Issue Type: Sub-task (was: Improvement) Parent: IGNITE-11749 > Diagnostic processor for dump page history info > --- > > Key: IGNITE-11816 > URL: https://issues.apache.org/jira/browse/IGNITE-11816 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Diagnostic processor for dump page history info -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11818) Support JMX/control.sh for debug page info
[
https://issues.apache.org/jira/browse/IGNITE-11818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-11818:
---
Issue Type: Sub-task (was: Improvement)
Parent: IGNITE-11749
> Support JMX/control.sh for debug page info
> --
>
> Key: IGNITE-11818
> URL: https://issues.apache.org/jira/browse/IGNITE-11818
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Support JMX/control.sh for debug page info
> JMX
> {code}
> public interface DiagnosticMXBean {
> @MXBeanDescription("Dump page history to custom path.")
> void dumpPageHistory(boolean dumpToFile, boolean dumpToLog, String
> filePath, long... pageIds);
> @MXBeanDescription("Dump page history.")
> void dumpPageHistory(boolean dumpToFile, boolean dumpToLog, long...
> pageIds);
> }
> {code}
> console.sh command:
> {noformat}
> control.sh --diagnostic page_history print_to_log print_to_file [page_ids
> ] [dump_path ] [--yes]
> --diagnostic - command for dumping some diagnostic info
> page_history - subcommand for dumping only page_history. Required.
> page_ids {list_of_page_ids} - list of page ids for dumping
> print_to_log, print_to_file - place for dumping(file or log or both). At
> least one of them is required.
> dump_path - custom path to folder(absolute or
> relative of work_dir).
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11782) WAL iterator for collect per-pageId info
[ https://issues.apache.org/jira/browse/IGNITE-11782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11782: Issue Type: Sub-task (was: Improvement) Parent: IGNITE-11749 > WAL iterator for collect per-pageId info > > > Key: IGNITE-11782 > URL: https://issues.apache.org/jira/browse/IGNITE-11782 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Implement WAL iterator for collect per-pageId info (page is root) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11841) Dump page history info in FailureHandler on CorruptedTreeException
Ivan Bessonov created IGNITE-11841: -- Summary: Dump page history info in FailureHandler on CorruptedTreeException Key: IGNITE-11841 URL: https://issues.apache.org/jira/browse/IGNITE-11841 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-640) Implement IgniteMultimap data structures
[
https://issues.apache.org/jira/browse/IGNITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835610#comment-16835610
]
Vishal Patel commented on IGNITE-640:
-
Is this issue still in progress, can I checkout source for this requirement,
and I can fix whatever is left, can anyone provide more details on this.
> Implement IgniteMultimap data structures
>
>
> Key: IGNITE-640
> URL: https://issues.apache.org/jira/browse/IGNITE-640
> Project: Ignite
> Issue Type: Sub-task
> Components: data structures
>Reporter: Dmitriy Setrakyan
>Assignee: Amir Akhmedov
>Priority: Major
> Fix For: 2.8
>
>
> We need to add {{IgniteMultimap}} data structure in addition to other data
> structures provided by Ignite. {{IgniteMultiMap}} should have similar API to
> {{java.util.Map}} class in JDK, but support the semantics of multiple values
> per key, similar to [Guava
> Multimap|http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html].
>
> However, unlike in Guava, our multi-map should work with Lists, not
> Collections. Lists should make it possible to support the following methods:
> {code}
> // Gets value at a certain index for a key.
> V get(K, index);
> // Gets all values for a collection of keys at a certain index.
> Map getAll(Collection, index);
> // Gets values for specified indexes for a key.
> List get(K, Iterable indexes);
> // Gets all values for a collection of keys at specified indexes.
> Map> getAll(Collection, Iterable indexes);
> // Gets values for specified range of indexes, between min and max.
> List get(K, int min, int max);
> // Gets all values for a collection of keys for a specified index range,
> between min and max.
> Map> getAll(Collection, int min, int max);
> // Gets all values for a specific key.
> List get(K);
> // Gets all values for a collection of keys.
> Map> getAll(Collection);
> // Iterate through all elements with a certain index.
> Iterator> iterate(int idx);
> // Do we need this?
> Collection> get(K, IgniteBiPredicate)
> {code}
> Multimap should also support colocated and non-colocated modes, similar to
> [IgniteQueue|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/IgniteQueue.java]
> and its implementation,
> [GridAtomicCacheQueueImpl|https://github.com/apache/incubator-ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/datastructures/GridAtomicCacheQueueImpl.java].
> h2. Design Details
> The most natural way to implement such map, would be to store every value
> under a separate key in an Ignite cache. For example, let's say that we have
> a key {{K}} with multiple values: {{V0, V1, V2, ...}}. Then the cache should
> end up with the following values {{K0, V0}}, {{K1, V1}}, {{K2, V2}}, etc.
> This means that we need to wrap user key into our own, internal key, which
> will also have {{index}} field.
> Also note that we need to collocate all the values for the same key on the
> same node, which means that we need to define user key K as the affinity key,
> like so:
> {code}
> class MultiKey {
> @CacheAffinityMapped
> private K key;
> int index;
> }
> {code}
> Look ups of values at specific indexes becomes very simple. Just attach a
> specific index to a key and do a cache lookup. Look ups for all values for a
> key should work as following:
> {code}
> MultiKey key;
> V v = null;
> int index = 0;
> List res = new LinkedList<>();
> do {
> v = cache.get(MultiKey(K, index));
> if (v != null)
> res.add(v);
> index++;
> }
> while (v != null);
> return res;
> {code}
> We could also use batching for performance reason. In this case the batch
> size should be configurable.
> {code}
> int index = 0;
> List res = new LinkedList<>();
> while (true) {
> List batch = new ArrayList<>(batchSize);
> // Populate batch.
> for (; index < batchSize; index++)
> batch.add(new MultiKey(K, index % batchSize);
> Map batchRes = cache.getAll(batch);
> // Potentially need to properly sort values, based on the key order,
> // if the returning map does not do it automatically.
> res.addAll(batchRes.values());
> if (res.size() < batch.size())
> break;
> }
> return res;
> {code}
> h2. Evictions
> Evictions in the {{IgniteMultiMap}} should have 2 levels: maximum number of
> keys, and maximum number of values for a key. The maximum number of keys
> should be controlled by Ignite standard eviction policy. The maximum number
> of values for a key should be controlled by the implementation of the
> multi-map. Either eviction parameter should be configurable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835605#comment-16835605
]
Ignite TC Bot commented on IGNITE-11756:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3779047buildTypeId=IgniteTests24Java8_RunAll]
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[
https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835577#comment-16835577
]
Alexei Scherbakov commented on IGNITE-11256:
[~antonovsergey93]
I reviewed your contribution. My comments:
1. No need to implement metrics aggregation for readOnlyMode and
readOnlyModeDuration_._ They will be almost same for all nodes. __ Better move
them to IgniteMXBean and in addition implement readOnly(boolean) method to
allow read-only mode switching from JMX. Look for
{{org.apache.ignite.mxbean.IgniteMXBean#active(boolean)}}
2. It might be good to have a way to activate grid in read-only state. This
could be achieved by adding new configuration property like
readOnlyAfterActivation and something like --activate read-only in control.sh
3. Fix logging like: log("Cluster is active" + (readOnly ? " (read-only)" :
""));
4. Fix logging like: log("Read-only mode is " + (readOnly ? "enabled" :
"disabled"));
5. Fix message like: Failed to perform cache operation (cluster is in read-only
mode)
6. U.hasCause is redundant and should be erased. We already have
{{org.apache.ignite.internal.util.typedef.X#hasCause(java.lang.Throwable,
java.lang.String, java.lang.Class...)}}
7. Documentation on new public methods {{IgniteCluster.readOnly*}} could be
improved.
8. You should create a ticket for missing bindings in .NET module.
Otherwise looks good. [~tledkov-gridgain] could your review SQL related changes
?
> Implement read-only mode for grid
> -
>
> Key: IGNITE-11256
> URL: https://issues.apache.org/jira/browse/IGNITE-11256
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Should be triggered from control.sh utility.
> Useful for maintenance work, for example checking partition consistency
> (idle_verify)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11824) Integrate diagnostic PageLockTracker to DataStructure
[
https://issues.apache.org/jira/browse/IGNITE-11824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835533#comment-16835533
]
Ignite TC Bot commented on IGNITE-11824:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3777909buildTypeId=IgniteTests24Java8_RunAll]
> Integrate diagnostic PageLockTracker to DataStructure
> --
>
> Key: IGNITE-11824
> URL: https://issues.apache.org/jira/browse/IGNITE-11824
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Govorukhin
>Assignee: Dmitriy Govorukhin
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After [IGNITE-11786] will be completed, we will have a structure for tracking
> page locks per-thread. The next step, need to integrate it into diagnostic
> API and implements a component for creating this structure per-thread.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-11705) Jdbc Thin: add ability to control affinity cache size.
[ https://issues.apache.org/jira/browse/IGNITE-11705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-11705: - Comment: was deleted (was: Was implemented within https://issues.apache.org/jira/browse/IGNITE-10308) > Jdbc Thin: add ability to control affinity cache size. > -- > > Key: IGNITE-11705 > URL: https://issues.apache.org/jira/browse/IGNITE-11705 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Priority: Major > Labels: iep-24 > Fix For: 2.8 > > > Within AffinityCache there are two properties DISTRIBUTIONS_CACHE_LIMIT and > SQL_CACHE_LIMIT that are hard coded. We should add an ability to control > given parameters within some sort of configuration. IgniteSystemProperties is > not an option however. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (IGNITE-11705) Jdbc Thin: add ability to control affinity cache size.
[ https://issues.apache.org/jira/browse/IGNITE-11705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reopened IGNITE-11705: -- > Jdbc Thin: add ability to control affinity cache size. > -- > > Key: IGNITE-11705 > URL: https://issues.apache.org/jira/browse/IGNITE-11705 > Project: Ignite > Issue Type: Task > Components: jdbc >Reporter: Alexander Lapin >Priority: Major > Labels: iep-24 > Fix For: 2.8 > > > Within AffinityCache there are two properties DISTRIBUTIONS_CACHE_LIMIT and > SQL_CACHE_LIMIT that are hard coded. We should add an ability to control > given parameters within some sort of configuration. IgniteSystemProperties is > not an option however. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11470) Views don't show in Dbeaver
[
https://issues.apache.org/jira/browse/IGNITE-11470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835335#comment-16835335
]
Ignite TC Bot commented on IGNITE-11470:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}JDBC Driver{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3781208]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3764112buildTypeId=IgniteTests24Java8_RunAll]
> Views don't show in Dbeaver
> ---
>
> Key: IGNITE-11470
> URL: https://issues.apache.org/jira/browse/IGNITE-11470
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: iep-29
> Fix For: 2.8
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> At Database navigator tab we can see no a views. As of now we should see at
> least SQL system views.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
