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

[Spark EF][Enhancement]Adding De-Deuplication logic for Spark Exception Fingerprinting results #679

Open
wants to merge 1 commit into
base: tuning_20190221
Choose a base branch
from

Conversation

ShubhamGupta29
Copy link
Contributor

WHAT CHANGES ARE PROPOSED IN THIS PR
This PR is aimed to add deDup logic before saving the EF results to the DB. Currently, there is no dedup is done in case of SparkExceptionFingerprinting, so the changes are done in this PR to look for the same Exception Stacktraces and remove the duplicate one from the result before saving them to the database. The problem with the result duplication is implicitly the memory resource wastage, no extra information for the end-user, some overhead while fetching the results for the API call.

How these changes are Tested
Testing it on the EI machine. The current Unit tests are rigid in terms of flexibility to test new changes made, finding a way out to make them more structured and add tests for the done changes.

@ShubhamGupta29 ShubhamGupta29 self-assigned this Apr 13, 2020
@ShubhamGupta29 ShubhamGupta29 requested review from pralabhkumar and removed request for pralabhkumar April 13, 2020 02:57
@pralabhkumar
Copy link
Contributor

@ShubhamGupta29 This is only removing duplicate and not similar exceptions . We should have logic to remove simillar exceptions also

@ShubhamGupta29
Copy link
Contributor Author

These changes are made in accordance with DSS-24596.
Also just an observation, in Spark there are not many similar exceptions as in TonY. In Spark, most of the exceptions will be having format of JavaExceptions, so huge chances are there for two exceptions to be the same. In Tony, most of the time exception stack traces did have only different container_id else whole so there was a lot of similarity between the logs.
For Spark also I will add similarity logic but in different future PR.

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

Successfully merging this pull request may close these issues.

2 participants