testPutMessagePositionInfo_buildCQRepeatedly method run error

[sunheyi6]

The issue tracker is used for bug reporting purposes ONLY whereas feature request needs to follow the RIP process. To avoid unnecessary duplication, please check whether there is a previous issue before filing a new one.

It is recommended to start a discussion thread in the mailing lists in cases of discussing your deployment plan, API clarification, and other non-bug-reporting issues.
We welcome any friendly suggestions, bug fixes, collaboration, and other improvements.

Please ensure that your bug report is clear and self-contained. Otherwise, it would take additional rounds of communication, thus more time, to understand the problem itself.

Generally, fixing an issue goes through the following steps:

1. Understand the issue reported;
2. Reproduce the unexpected behavior locally;
3. Perform root cause analysis to identify the underlying problem;
4. Create test cases to cover the identified problem;
5. Work out a solution to rectify the behavior and make the newly created test cases pass;
6. Make a pull request and go through peer review;

As a result, it would be very helpful yet challenging if you could provide an isolated project reproducing your reported issue. Anyway, please ensure your issue report is informative enough for the community to pick up. At a minimum, include the following hints:

BUG REPORT

1. Please describe the issue you observed:
   

• What did you do (The steps to reproduce)?
  run directly

• What is expected to see?

• What did you see instead?

2. Please tell us about your environment:

3. Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):

FEATURE REQUEST

1. Please describe the feature you are requesting.

2. Provide any additional detail on your proposed use case for this feature.

3. Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?

4. If there are some sub-tasks involved, use -[] for each sub-task and create a corresponding issue to map to the sub-task:

• sub-task1-issue-number: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

[ShadowySpirits]

In my test, the error you describe is caused by the introduction of the following dependency:

<!-- store/pom.xml -->
<!-- Required by DLedger -->
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <scope>test</scope>
</dependency>

And shaded log dependency rocketmq-logback-classic woks well.

[ShadowySpirits]

IMO, deleting slf4j-api is more reasonable.

[sunheyi6]

IMO, deleting slf4j-api is more reasonable.

11:20:45,597 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.3.4-rocketmq
11:20:45,611 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.classic.LoggerContext[default] - Found resource [rmq.logback-test.xml] at [file:/D:/java/rocketmq/store/target/test-classes/rmq.logback-test.xml]
11:20:45,773 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [CONSOLE]
11:20:45,773 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [org.apache.rocketmq.logging.ch.qos.logback.core.ConsoleAppender]
11:20:45,831 |-WARN in org.apache.rocketmq.logging.ch.qos.logback.core.ConsoleAppender[CONSOLE] - This appender no longer admits a layout as a sub-component, set an encoder instead.
11:20:45,831 |-WARN in org.apache.rocketmq.logging.ch.qos.logback.core.ConsoleAppender[CONSOLE] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
11:20:45,831 |-WARN in org.apache.rocketmq.logging.ch.qos.logback.core.ConsoleAppender[CONSOLE] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
11:20:45,831 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting level of logger [org.apache.rocketmq] to ERROR
11:20:45,832 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.classic.model.processor.LoggerModelHandler - Setting additivity of logger [org.apache.rocketmq] to false
11:20:45,832 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [CONSOLE] to Logger[org.apache.rocketmq]
11:20:45,832 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.classic.model.processor.RootLoggerModelHandler - Setting level of ROOT logger to ERROR
11:20:45,832 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [CONSOLE] to Logger[ROOT]
11:20:45,832 |-INFO in org.apache.rocketmq.logging.ch.qos.logback.core.model.processor.DefaultProcessor@646007f4 - End of configuration.
11:20:45,833 |-INFO in org.apache.rocketmq.common.logging.JoranConfiguratorExt@481a15ff - Registering current configuration as safe fallback point

@ShadowySpirits The above is the result after removing the dependencies. does not appear to be the result of normal operation

[ShadowySpirits]

There is indeed a problem if we delete sl4j-api. And this problem not only happened in the test but also happened in the production environment.

We should discuss this in dledeger community to change sl4j-api to rocketmq-logback-classic.

cc @aaron-ai

[aaron-ai]

@shy-share I will fix it.

We will add a bridge to take over the logging of SLF4j by the shaded SLF4j, then slf4j-api could be easily introduced.

[mxsm]

IMO, deleting slf4j-api is more reasonable.

DLedger needs slf4j-api, should fix it in DLedger project