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

add check for timeout exception #76

Merged
merged 2 commits into from
Oct 2, 2020
Merged

add check for timeout exception #76

merged 2 commits into from
Oct 2, 2020

Conversation

gfuller1
Copy link
Contributor

@gfuller1 gfuller1 commented Oct 2, 2020

Also manually tested and works.

Copy link
Contributor

@breedx-nr breedx-nr left a comment

Choose a reason for hiding this comment

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

Why do we want to special case this? I fully grok what it's doing, but I don't immediately see why this is desirable.

I also asked for a small/nitpicky change.

/**
* Detects if the error received was a connection timeout exception. This can happen if the agent hasn't sent any spans for more than 15 seconds.
*/
protected boolean isConnectionTimeoutException(Throwable t) {
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is protected only for the test to have access, let's make it package-private and add a comment or annotation saying that it's available just for testing.

disconnectionHandler, shouldRecreateCall);

Throwable exception = new StatusRuntimeException(Status.fromCode(Status.Code.INTERNAL).withDescription("No error: A GRPC status of OK should have been sent\nRst Stream"));
assertTrue(target.isConnectionTimeoutException(exception));
Copy link
Contributor

Choose a reason for hiding this comment

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

There are a few permutations that are missing from the test suite:

  • type is not a StatusRuntimeException (tho it might be tested above/below, I didn't check)
  • type IS StatusRuntimeException but the message doesn't match.
    Would be nice to have proper coverage of the new behavior.

@gfuller1
Copy link
Contributor Author

gfuller1 commented Oct 2, 2020

Why do we want to special case this? I fully grok what it's doing, but I don't immediately see why this is desirable.

I also asked for a small/nitpicky change.

What happens is after 15 seconds if we don't send anything to infinite tracing it closes the channel and sends us an ugly exception that we print to the logs as a WARNING. The agent simply reconnect after that and there's nothing wrong with that, that's just how it is handled.

We don't want to scare customers with this log message when nothing is actually wrong. So far it has scared customers into filing tickets with us.

We special case this error because we don't want to avoid printing other errors that may occur which are actually serious.

@breedx-nr
Copy link
Contributor

Ok cool, thanks for the clarification.

@gfuller1 gfuller1 merged commit 7fe46a2 into main Oct 2, 2020
@gfuller1 gfuller1 deleted the avoid-timeout-logging branch October 2, 2020 18:01
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.

2 participants