ignite-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [ignite] nizhikov commented on a change in pull request #6845: IGNITE-12145: Monitoring list engine.
Date Thu, 12 Sep 2019 07:24:20 GMT
nizhikov commented on a change in pull request #6845: IGNITE-12145: Monitoring list engine.
URL: https://github.com/apache/ignite/pull/6845#discussion_r323591133

 File path: modules/core/src/main/java/org/apache/ignite/internal/processors/metric/GridMetricManager.java
 @@ -265,45 +378,116 @@ public MetricRegistry registry(String name) {
         return registries.computeIfAbsent(name, n -> {
             MetricRegistry mreg = new MetricRegistry(name, log);
-            notifyListeners(mreg, metricRegCreationLsnrs);
+            notifyListeners(mreg, metricRegCreationLsnrs, log);
             return mreg;
-    /** {@inheritDoc} */
-    @NotNull @Override public Iterator<MetricRegistry> iterator() {
-        return registries.values().iterator();
+    public <R extends MonitoringRow, D> void list(String name, String description,
+        Class<R> rowClazz, Supplier<ConcurrentMap<?, D>> data, Function<D,
R> rowFunc, Consumer<D> clearer) {
+        Supplier<MonitoringList<R>> listCreator = () -> list(name, () ->
new MonitoringListAdapter<>(name,
+            description,
+            rowClazz,
+            (MonitoringRowAttributeWalker<R>)walkers.get(rowClazz),
+            data.get(),
+            rowFunc));
+        //Create new instance of the list.
+        listCreator.get();
+        ctx.metric().addEnableListListener(listenOnlyEqual(name, identity(), n -> listCreator.get()));
 Review comment:
   > Create maps for list creators and removers (name -> closure) instead of lists for
   Yes, we can do it.
   1. This will require one more additional listener map because we already have 'List' of
the listeners that comes from `MonitoringExporterSpi`. Please, see `ReadOnlyMonitoringListRegistry#addListRemoveListener`.
   2. I expect very few enable/disable events, and from 10 to 20 lists over Ignite, so we
shouldn't observe performance issues because of name check in `listenOnlyEqual`.
   So I prefer to keep it as is.
   What do you think?
   > Get rid of as most nested lambdas as possible
   Seems, I'm already did it. Can you see, how lambdas can be reduced?
   What is the issue with the lambdas count, in the first place? 
   Do you see some issues with code readability, understandability?

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message