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

Merged data source displays wrong origin. #154

Closed
oleg-abr opened this issue Dec 20, 2017 · 5 comments
Closed

Merged data source displays wrong origin. #154

oleg-abr opened this issue Dec 20, 2017 · 5 comments
Assignees
Labels
Projects

Comments

@oleg-abr
Copy link
Contributor

Current behaviour

Wrong origin is displayed in the second column of the megred data source row. See yellow marked areas.

wrongdatasource

Expected behaviour

In the first marked area Nestor.log is expected.
In the second marked area Tsma.log is expected.

Steps to reproduce the problem

Not sure. Maybe need a log with a long stack trace?

@Kittyfisto Kittyfisto added the bug label Dec 20, 2017
@Kittyfisto Kittyfisto added this to To Do in v0.7.2 via automation Dec 20, 2017
@Kittyfisto
Copy link
Owner

Kittyfisto commented Dec 20, 2017

@oleg-abr I'd guess that this is caused due to having a multiline entry.
Can you do me a favour and confirm if this problem vanishes when you enable singleline (View => Single line)

Either way I'll have this fixed in the next patch.

@oleg-abr
Copy link
Contributor Author

yepp, it vanishes all right.

@Kittyfisto Kittyfisto self-assigned this Dec 20, 2017
Kittyfisto added a commit that referenced this issue May 27, 2019
The current MergedLogFile implementation is too slow because it generates far too many invalidations in between insertions.
The rewrite processes batches in ONE operation and thus is able to achieve the same with fewer invalidations (but it is not quite done).
Kittyfisto added a commit that referenced this issue May 27, 2019
Added first tests to verify index access
Kittyfisto added a commit that referenced this issue May 28, 2019
The new implementation performs much faster than the previous one, however currently processes too much at once, causing tailviewer to freeze for a few hundred ms when merging 25MB of log files in my tests => Will be addressed in next commit
Kittyfisto added a commit that referenced this issue May 28, 2019
Rewrote FindInsertionIndexNoLock() hotspot to use a binary search instead
of linear one, yielded ~3x speed-up
Kittyfisto added a commit that referenced this issue May 28, 2019
…#154

Also removed unnecessary debug logs and fixed slightly indeterministic test
Kittyfisto added a commit that referenced this issue May 28, 2019
…identical timestamps compared to their original order

This occured due to the re-write sorting indices (using an unstable sort) before inserting them => Replaced with stable sort #154
@Kittyfisto
Copy link
Owner

Fixed with v0.8.0

v0.7.2 automation moved this from To Do to Done May 28, 2019
@Kittyfisto
Copy link
Owner

This issue re-appeared in v0.9.

@Kittyfisto
Copy link
Owner

@oleg-abr Fixed with v0.9.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
v0.7.2
  
Done
Development

No branches or pull requests

2 participants