Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PrintMessageByQueueCommand may not print the right msgs #903

Closed
pigpdong opened this issue Feb 26, 2019 · 2 comments
Closed

PrintMessageByQueueCommand may not print the right msgs #903

pigpdong opened this issue Feb 26, 2019 · 2 comments

Comments

@pigpdong
Copy link

BUG REPORT

  1. Please describe the issue you observed:
  • What did you do (The steps to reproduce)?
    PrintMessageByQueueCommand with the option -d -e
  • What did you expect to see?
    print the right msglist
  • What did you see instead?
    the -e may get a max offset,but consumer.pull(mq, subExpression, offset, 32); this code may return the msg which bigger than the maxoffset

and the option -d -d describe as a string like End timestamp[currentTimeMillis|yyyy-MM-dd#HH:mm:ss:SSS] but acturally it need a long
timestamp = Long.parseLong(value);

  1. Please tell us about your environment:
    None.
  2. Other information (e.g. detailed explanation, logs, related issues, suggestions how to fix, etc):
    None
@ymwneu
Copy link
Contributor

ymwneu commented Feb 26, 2019

A good ISSUE.
Two problems:

  1. -d can accept both "yyyy-MM-dd#HH:mm:ss:SSS" or long style timestamp. Look PrintMessageByQueueCommand#timestampFormat for more detail.
  2. Your PR have a bug, i have already given my comment.

@ymwneu
Copy link
Contributor

ymwneu commented Feb 26, 2019

The max offset problem, i suggest you optimize method "PrintMessageByQueueCommand#calculateByTag" and "PrintMessageByQueueCommand#printMessage" to filter the messages which exceed the max offset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants