-
Notifications
You must be signed in to change notification settings - Fork 65
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
Remove the logs printed from the listeners #2040
Comments
Please note that in the case of an error, error logs will be printed. |
@shafreenAnfar I hope the reason behind the change is to hide the internal protocol details when we using the dependent modules such as WebSub and GraphQL. But this change can reduce some important info such as host and port which provided implicitly. Also the end user also does not receive a strong signal saying the listener is ready to serve request. If the issue is with the prefix of
|
Well, when it comes to listeners, we don't use implicit host and port. This is similar to Java server socket. Because, if you use an implicit port, you don't know which port to send request to.
It is not the prefix but the entire log is the problem. We can not just get rid of the prefix as it is a key part of the any log entry. Users need to know who printed this log. IMO, Ballerina is a programming language and it gives enough room to let users print what they want. We as standard library developers should not have an opinionated stand on this. |
I must have missed the log part, in-fact I meant the implicit log which provided stating the user provided host port.
Yeah agree. User can go ahead with some logs based on their requirement |
Quick question: To make it consistent, we have to remove the listener stop log as well right? But user does not have proper way to log that if needed when the service declaration is used. But they can used lifecycle method(GracefulStop()) |
This is a major usability issue. As a Ballerina user I am writing a service and running it. I expect to see a message saying my service is ready. But all I see now is "Running executable". This is very confusing. What is "executable"? Is it still compiling? How am I supposed to know my service is ready to receive requests? |
As mentioned in the description if an explicit log is expected to be printed, service init can be used. But that is a choice of the developer. One might expect a log but the other might not. Of-course there can be a millisecond difference between the log and the actual binding but it is not a major problem. Because this log is merely printed for a human to read. Systems don't use logs to know if the service is ready. For instance in k8s you can do a readiness probe to determine if the pod is ready to serve traffic. Even go lang standard library has high level abstractions [1] for writing services and they don't print a log either. I guess for the same reasons. P.S. |
I don't think it's right to compare Ballerina with Go. Unlike Go, the concept of services is fundamental to Ballerina. The problem is that as a developer if I implement a service in Ballerina and run it, I see no indication it started. The printed message is confusing and doesn't tell me its ready. It is the first user experience that is at stake here. Of course we can argue saying the developer can print a log if he/she wants to, and yes we can use probes and stuff in production to determine readiness. But at the end of the day if the first user experience is bad, none of that would matter. |
Interesting, I thought for a human Maybe I am missing out something :). If the Ballerina community also thinks the same, we can certainly consider another alternative for the original problem. Yes, one to one comparison with go is not right. That is why it is not there in the original description. However, it is not that far away either in terms of starting a HTTP service. But the point is none of the standard libraries I know of print @sanjiva @sameerajayasoma if you all have any opinion on this, do let us know. |
Printing the host and port are good to have, not mandatory. The issue with The issue with |
Usually, programming languages and standard library packages do not emit logs. Standard library packages are typically composed to build other packages, and such logs can be a nuisance for libraries built on top of standard libraries. I agree with @shafreenAnfar decision to remove logs emitted by the HTTP logs. This was discussed before as well. There are three ways to run a compiled Ballerina program.
Most use the 1st or 2nd option during the development time and the 3rd in production. I understand the usability issue here during the development time. |
I've watched quite a few first time users start a Ballerina program and say "It's stuck". That clearly shows there's a usability issue. Whether/How the same is done in other places is of lesser concern to me. Printing an ambiguous message that doesn't indicate the state of a process (but is supposed to) is very confusing, especially when it is used within platforms like Choreo (https://wso2.com/choreo). |
Even though in the case of listeners there is no way to add logs when the biding happens, etc, users still can add a log in the service init. It is not the same but good enough. Eg,
On the other side, these logs gets in the way when developing other libraries (which is a common usecase for standard libraries). For instance, GraphQL and WebSub both use HTTP library. They have no way to suppress or customize the HTTP log printed from the listener.
Eg -
[ballerina/http] started HTTP/WS listener 0.0.0.0:9090
The text was updated successfully, but these errors were encountered: