-
Notifications
You must be signed in to change notification settings - Fork 700
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
What's up with the logging? #1196
Comments
Hey @radistmorse. Yes, there is a logger which is not used much if I recall. But something to think about is what would it be used for? If it's for debugging of the library itself then that could be helpful. But if it's to serve user application code, usually applications do their own logging in their endpoint callbacks. If you'd like to propose something, feel free to though. We're open minded and always happy to review PRs. |
I meant for the library itself. To see what happens with the requests, how the routes are matched, and whether someone tries to screw us up with malformed http. I assume there is a lot of http-magic going on under the hood, like keep-alives or chunkings, so it might be helpful to see if something is up. I'd look into it myself, but I don't know which functions are actually doing the "interesting" stuff, and which are just a boilerplate. |
Hi @radistmorse. There is significant additional logging in the branch/PR "macosSupport". Much of that logging is general purpose i.e. not macOS specific. That PR may show up in "master" in May I would think. That said, the new logging is debug-mode only and more focussed with lower level operations (at the socket/epoll level) vs. higher level HTTP parsing etc. But of course it could be extended as you + @kiplingw commented. |
Pistache has a whole logging system set up, with macros and levels and all the fancy stuff, which is totally not used. The only place where the logging is present is
listener.cc
, and it's just 6 occasions: 4 are about SSL, and 2 about socket errors. And the best part: it doesn't even work, because when the listener is initialized inEndpoint::init
the logger is not passed and is thus alwaysPISTACHE_NULL_STRING_LOGGER
.Could there maybe be more logging overall? I looked at it myself, but I'm not that familiar with pistache to understand where the main codepaths lie. The stacktraces that I usually see in debugger do not even include the endpoint or the listener.
The text was updated successfully, but these errors were encountered: