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

integrating with logging framework for better understanding of the issues #1266

Open
mrpenchalaiah opened this issue Jan 8, 2025 · 3 comments
Labels
proposal Enhancement idea or proposal

Comments

@mrpenchalaiah
Copy link

mrpenchalaiah commented Jan 8, 2025

Proposed change

I am seeing the code in NatsConnection class. when any exception occured we are simply returning null and not printing the logs. Due to that People don't know what happened when. It is a black box for every one who is using and who is supporting.
I would be great if we print any exception occured in the logs. Depending the Log level people can trace what happened in the Nats client.

Message requestInternal(String subject, Headers headers, byte[] data, Duration timeout, NatsRequestCompletableFuture.CancelAction cancelAction, boolean validateSubRep) throws InterruptedException {
        CompletableFuture<Message> incoming = this.requestFutureInternal(subject, headers, data, timeout, cancelAction, validateSubRep);
        try {
            return (Message)incoming.get(timeout.toNanos(), TimeUnit.NANOSECONDS);
        } catch (ExecutionException | CancellationException | TimeoutException var9) {
            return null;
        }
    }

### Use case

It is easy to debug the issues.

### Contribution

Yes, I am ready to contribe for this, Is there any document to understand how this client interact with Nats server. 
@mrpenchalaiah mrpenchalaiah added the proposal Enhancement idea or proposal label Jan 8, 2025
@scottf
Copy link
Contributor

scottf commented Jan 8, 2025

I suppose we could add a call to the error listener, maybe a new method with a default implementation. The problem here is the client really doesn't care why there is an error, it's a failure and it needs to move forward. And I wonder if it will actually be more confusing, like why am I getting this error. I'll think on it.

@mrpenchalaiah
Copy link
Author

@scottf In my opinion, Client should move forward if any failure at server but we should intimate as warning or info regarding that failure. This issue I have raised because there is connect timeout or unable to connect issue is happening only certain pods we want to debug why only certain pods were getting. Due to no logging we were not able to understand anything what is the issue.

@scottf
Copy link
Contributor

scottf commented Jan 10, 2025

I think the best I can do is add some sort of callback for this.

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

No branches or pull requests

2 participants