Skip to content

Conversation

@sk0x50
Copy link
Contributor

@sk0x50 sk0x50 commented Aug 9, 2023

https://issues.apache.org/jira/browse/IGNITE-19148

Thank you for submitting the pull request.

To streamline the review process of the patch and ensure better code quality
we ask both an author and a reviewer to verify the following:

The Review Checklist

  • Formal criteria: TC status, codestyle, mandatory documentation. Also make sure to complete the following:
    - There is a single JIRA ticket related to the pull request.
    - The web-link to the pull request is attached to the JIRA ticket.
    - The JIRA ticket has the Patch Available state.
    - The description of the JIRA ticket explains WHAT was made, WHY and HOW.
    - The pull request title is treated as the final commit message. The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • Design: new code conforms with the design principles of the components it is added to.
  • Patch quality: patch cannot be split into smaller pieces, its size must be reasonable.
  • Code quality: code is clean and readable, necessary developer documentation is added if needed.
  • Tests code quality: test set covers positive/negative scenarios, happy/edge cases. Tests are effective in terms of execution time and resources.

Notes

@sk0x50 sk0x50 force-pushed the ignite-19148 branch 2 times, most recently from 6d8d434 to 3a1c282 Compare August 14, 2023 11:34

lock.writeLock().lock();
try {
for (Handler handler : handlers) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Collections.addAll(this.handlers, handlers);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Fixed

Copy link
Contributor

@rpuch rpuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason to change from JUL to log4j2? The JIRA only says about logging to stderr, but JUL can be configured to use any appenders (or how are they called there?) we want. So why?


Handler physicalTopologyWaiter = physicalTopologyWaiter(allNodesAreInPhysicalTopology);
topologyLogger.addHandler(physicalTopologyWaiter);
TestLogChecker topologyLogger = new TestLogChecker(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a logger, this is a checker. I suggest to rename this accordingly

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are absolutely right. Will fix it here and in other places.

import org.apache.logging.log4j.core.config.Property;

/**
* Test log checker.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's expand the documentation with an explanation of what this checker does, what checks it performs, how it can be used

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Javadoc was added.

* @param loggerName Logger name.
* @param predicate Predicate to check log messages.
*/
public TestLogChecker(String loggerName, Predicate<String> predicate) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the predicate returns true or false?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, in some cases it is required to verify other message attributes, not only its text (for instance, we might want to verify that a message is logged as a WARN). Let's make the predicate accept the whole message, not just its text.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the predicate returns true or false?
updated javadoc in the following way:

    /**
     * Creates a new instance of {@link TestLogChecker} with the given {@code predicate}.
     * In order to check that the required log event was logged, use {@link #isMatched()} method.
     *
     * @param loggerName Logger name.
     * @param predicate Predicate to check log messages.
     */

Also, in some cases it is required to verify other message attributes, not only its text
It makes sense to me. Predicate should accept LogEvent instead of String

}

/**
* Creates a new instance of {@link TestLogChecker} with the given {@code predicate} and {@code action}.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no predicate among parameters, probably this needs to be adjusted

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Fixed.

public Handler addHandler(Predicate<String> predicate, Runnable action) {
Handler handler = new Handler(predicate, action);

lock.writeLock().lock();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems we can just invoke addHandler(handler) here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Fixed.

private final TestMessagesFactory messageFactory = new TestMessagesFactory();

/** List of test loggers. */
private final List<TestLogChecker> loggers = new ArrayList<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those are not loggers, they are checkers

private Cluster cluster;

private Logger replicatorLogger;
private TestLogChecker replicatorLogger;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a logger anymore, the field probably needs to be renamed

AtomicBoolean snapshotInstallFailedDueToIdenticalRetry = new AtomicBoolean(false);

Logger snapshotExecutorLogger = Logger.getLogger(SnapshotExecutorImpl.class.getName());
TestLogChecker snapshotExecutorLogger = TestLogChecker.create(SnapshotExecutorImpl.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a logger

/**
* Test log checker.
*/
public class TestLogChecker {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name does not seem perfect. 'Check' is too abstract; also this class not just 'checks' incoming log messages, but it also reacts to them somehow. Maybe a better name should be devised (but I cannot come up with anything good now)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to LogInspector

Copy link
Contributor Author

@sk0x50 sk0x50 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @rpuch,

I agree that this is my fault and I had to describe the motivation in the ticket.

IMHO

  • It would be better to use a well-known and widely-used logging framework instead of JUL, which should not require any additional code like a custom appender, etc. I don't think that JUL is used in real-life solutions, so this patch can be considered a test scenario to use 3rd party implementation of the logging framework (For example, scalecube, which is an internal thing, uses slf4j and so we need to provide a bridge from slf4j to log4j2/logback. this step is not so obvious and has to be described in our documentation).
  • log4j2 provides a color schema for the logs, which is a nice feature :)

By the way, I don't like our approach of using logs to check something like cluster initialization, snapshots, etc. It should be done via special lifecycle events, callbacks, whatever... but using logs for this looks weird to me.

sk0x50 and others added 2 commits August 21, 2023 12:44
…testframework/log4j2/TestLogChecker.java

Co-authored-by: Roman Puchkovskiy <roman.puchkovskiy@gmail.com>
@sk0x50 sk0x50 merged commit e32fd8d into apache:main Aug 21, 2023
@sk0x50 sk0x50 deleted the ignite-19148 branch September 1, 2023 11:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants