Alexey,
Yes, system view must be enabled by default and must not have any
enable/disable features. As I told early, system views is on demand
feature and views don't consume any resources while not requested.
On Wed, Sep 18, 2019 at 4:10 PM Alex Plehanov wrote:
>
> One more point to discuss:
Outstanding! Let's brag about this publicly :)
https://twitter.com/ApacheIgnite/status/1176280416627486720?s=20
-
Denis
On Mon, Sep 23, 2019 at 3:08 AM Nikolay Izhikov wrote:
> Hello, Team.
>
>
> System view engine is merged to the master.
>
> Thanks, everyone for the feeback and help with
Hello, Alex.
Good catch, thank you.
I will add enabling of JMX and SQL exporters for system views, by default.
В Ср, 18/09/2019 в 16:09 +0300, Alex Plehanov пишет:
> One more point to discuss: Wouldn't it be better to have enabled system
> views by default?
> To enable views admin must restart
One more point to discuss: Wouldn't it be better to have enabled system
views by default?
To enable views admin must restart the node, sometimes it's an issue.
Views cost almost nothing in terms of performance until they are explicitly
requested, so is their a reason to disable views by default?
Folks,
I honestly tried to follow the discussion, but I think that I lost the
point of the debate. Should we try to exploit the newly introduced slack to
discuss the change and then send a follow-up here?
--AG
> From my point of view is still task of current issue
What is exactly the task of current issue?
We have fully ready `Walkers` for current system views.
They are correct and easy to use and maintain.
The current PR is already relatively big.
I don't think we should overcomplicate it with the
> I think, we should improve Ignite step by step.
>From my point of view is still task of current issue - system views,
that is exactly one step.
>> What is part of exported data?
> Some SPI implementation(JMX, SQL view) exports both metrics and views.
> Some exports only metrics.
> It's fine
> Why? It is still part of the same task. Master branch should not see
> intermediate changes.
I don't propose any "intermediate" feature.
We would have full feature of "system views" after merge.
I think, we should improve Ignite step by step.
Why we should postpone merge of "system views"
>> Views have wider meaning than metrics.
> Yes! I agree, that's why I wrote 'extension' :)
No, no, no. Wider meaning isn't equal to extension :)
>> IMO using the same code at
>> runtime for view generation is better approach.
> OK for me.
> Let's do it in another ticket?
> I will create one.
> Views have wider meaning than metrics.
Yes! I agree, that's why I wrote 'extension' :)
> IMO using the same code at
> runtime for view generation is better approach.
OK for me.
Let's do it in another ticket?
I will create one.
> What is the reaal life uses cases for exporting views?
> Is
Hi,
>> I think akso that GridMetricManager is bad candidate for lists (system
>> views) management.
>For me, it seems that views and metrics is extension of one another.
>If the user want to know some instant values(cache put count, cahe get
>latency) he use metrics
>and one want to know list
Hello, Andrey.
> I really don't like name MonitoringList. First of all because it isn't
> about monitoring at all while can be useful for monitoring purposes.
> We already have SQL system views and I think that system view is good
> candidate for naming of new entity.
SystemView is OK for me.
I
Nikolay,
thanks a lot for clarification! I added some comments to Upsource review [1].
Here I want to discuss some high-level issues.
1. Naming
"There are only two hard things in Computer Science: cache
invalidation and naming things."
-- Phil Karlton
I really don't like name MonitoringList.
Hello, Andrey.
Thanks, for joining the review.
Basic interface for objects list is `MonitoringList`. It provides the following
features:
* name.
* description.
* row class.
* size.
* iterator for the list content.
* attribute walker (described
Nikolai,
I'm trying to review this PR but it is too large.
Could you please describe problem and design of implemented solution?
Also javadocs for base interfaces aren't clear, too brief and doesn't
give any imagine about whole picture.
At present it is very hard to understand the purposes of
Hello, Igniters.
IEP-35. Monitoring Phase2 is ready [1]
Please, join to the review!
I've implemented:
* Monitoring list engine.
* Following list implemented:
* Cache list
* Cache group list
* Compute task list
* Service list.
Engine details:
* `MonitoringList` added to store
Sorry for the duplicate - apparently, Maksim also spotted this regression.
Let's continue the discussion in the separate thread.
пт, 28 июн. 2019 г. в 19:04, Alexey Goncharuk :
> Hello Nikolay,
>
> From the latest TC runs I can see a sporadic regression
> in testParallelStartAndStop and
Hello, Alex.
I will fix it shortly.
Ticket - https://issues.apache.org/jira/browse/IGNITE-11945
В Пт, 28/06/2019 в 19:04 +0300, Alexey Goncharuk пишет:
> Hello Nikolay,
>
> From the latest TC runs I can see a sporadic regression in
> testParallelStartAndStop and testStartManyCaches tests.
Hello Nikolay,
>From the latest TC runs I can see a sporadic regression
in testParallelStartAndStop and testStartManyCaches tests. Digging deeper,
I see that stopping a single cache when there are many other started caches
now takes a significant amount of time.
Current suspect is
Hello, Igniters.
Since Phase 1 will be merged in master soon I've created the ticket [1] for
Phase 2.
Scope of Phase 2(copy-paste from the ticket)
Ability to collect lists of some internal object Ignite manage.
Examples of such objects:
* Caches
* Queries (including continuous queries)
20 matches
Mail list logo
