falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srikanth Sundarrajan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FALCON-1476) Maintaining threshold on monitoring entities for SLA service
Date Mon, 28 Sep 2015 15:27:04 GMT

    [ https://issues.apache.org/jira/browse/FALCON-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933441#comment-14933441
] 

Srikanth Sundarrajan commented on FALCON-1476:
----------------------------------------------

{noformat}
-    private static Map<Pair<String, String>, Set<Date>> pendingInstances;
+    private static Map<Pair<String, String>, BlockingQueue<Date>> pendingInstances;
{noformat}

One of the things with Set is that there is a guarantee of uniqueness. Haven't checked for
scenarios where duplicates are possible, and dont recall seeing any explicit checks for this
in the new patch where Set isn't used. Is this a concern ?

Instead of removing head of the queue (based on insertion order), would it be more useful
to remove older entries ? Or is the insertion order already chronologically sequenced ?

> Maintaining threshold on monitoring entities for SLA service
> ------------------------------------------------------------
>
>                 Key: FALCON-1476
>                 URL: https://issues.apache.org/jira/browse/FALCON-1476
>             Project: Falcon
>          Issue Type: Sub-task
>         Environment: QA
>            Reporter: Pragya Mittal
>            Assignee: Ajay Yadava
>             Fix For: 0.8
>
>         Attachments: FALCON-1476.patch
>
>
> Currently SLA Monitoring service keeps on logging indefinitely for a given entity until
it gets data for that entity. In case user gives wrong data path, monitoring service will
look for the entity infinitely as data path will never be there for it. It is better to introduce
a threshold which user can use to define how long he wants the service to run (with a default
value set to a long interval).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message