ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-8570) Create lighter version of GridStringLogger
Date Thu, 18 Oct 2018 16:16:00 GMT

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

ASF GitHub Bot commented on IGNITE-8570:
----------------------------------------

Github user asfgit closed the pull request at:

    https://github.com/apache/ignite/pull/4786


> Create lighter version of GridStringLogger
> ------------------------------------------
>
>                 Key: IGNITE-8570
>                 URL: https://issues.apache.org/jira/browse/IGNITE-8570
>             Project: Ignite
>          Issue Type: Improvement
>    Affects Versions: 2.4
>            Reporter: Andrey Kuznetsov
>            Assignee: Pavel Pereslegin
>            Priority: Major
>             Fix For: 2.8
>
>
> _+Problem with current GridStringLogger implementation+_: 
>  Most usages of {{GridStringLogger}} in test assumes the following scenario. First, it
is set as a logger for some Ignite node. 
>  Then, after some activity on that node, log content is searched for some predefined
strings. 
>  {{GridStringLogger}} uses {{StringBuilder}} of bounded size internally to store log
contents, older contents gets dropped on exaustion. 
>  Thus, changes that add more logging may damage some independent tests that use {{GridStringLogger}}.
>  
> +_The suggestion for new implementation:_+
>  The suggestion is to implement and use another test logger conforming to these requirements:
>  * It does not accumulate any logs(actually, it will print no logs to anywhere)
>  * It allows to set the listener that fires when log message matches certain condition,
> _+Proposed design+_, pseudocode:
> {code:java}
>  public class ListeningTestLogger implements IgniteLogger {
>     public void registerListener(Consumer<String> lsnr);
>     public void unregisterListener(Consumer<String> lsnr);
>     
>     public void clearListeners();
>  }
> {code}
> In 99.9% cases at some point we should validate listener precondition. For example, default
precondition for {{substring listener}} - "_Is there any message in the log with such substring?_".
So, listener should support validation. 
> {code:java}
> interface LogListener extends Consumer<String> {
>     void check() throws AssertionError;
> }
> {code}
> To simplify creation of common case listeners (substring, regular expression and predicate)
special listener builder should be introduced.
> +_Sample logger usage_+:
> {code:java}
> ListeningTestLogger log = new ListeningTestLogger(false, super.log);
> // Create listener that should match "hello" (2 times) and "Ignite" (case insensitive,
once at least)
> LogListener lsnr = LogListener.matches("hello").times(2).andMatches(Pattern.compile(""(?i)ignite")).build();
> log.registerListener(lsnr);
> // ...
> // ...
> // ...
> lsnr.check(); // throws AssertionError if precodition is not met.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message