Hey Christos,
Sorry for the delay - I don't know the logging functionality all that
well and had to do some digging before I could reply. Replies below
inline:
> Let me know if I should create individual threads for such grouped questions
If I put myself in the shoes of someone coming to this thread to
understand the v2 API design and progress as a whole, then a lot of
this discussion would be "noise" to them. So +1 to using a different
thread next time. But let's continue discussion here to minimize
overhead - if you have any followups, we can break into a separate
thread at that point.
> I assume they are specific to the node currently connected, since we have
> "/node" in the URL path.
This has historically been true, but apparently it changed several
years back as a part of SOLR-15011, which has led to a gap between
what the v1 and v2 APIs support. In terms of changing log values, the
v1 API can update the log-level either globally or "just" on the
receiving node based on the value of a "nodes" flag param. (This
behavior only works in SolrCloud mode - the "nodes" parameter is
ignored when running in standalone mode) To be more explicit:
Update all nodes
- v1: GET /solr/admin/info/logging?set=className:LEVEL&nodes=all
- v2: (Unsupported)
Update Single Node
- v1: GET /solr/admin/info/logging?set=className:LEVEL
- v2: PUT /api/node/logging/levels [{"className": "LEVEL"}]
We should remedy this functionality gap, and probably change the v2
API path to reflect the changed behavior.
> Can each node configure only one log watcher (like Log4j2) at a time, or ...
Yep, Solr currently only supports a single watcher at a time. Solr
creates a single "LogWatcher" instance (for either JUL or Log4j) at
boot time, and then reuses that for the life of the process afaict.
> The class LogLevelInfo does not provide much information about the fields
You're right - it could really be better documented.
The "name" parameter represents the name of the logger in question, so
I suspect it will always be non-null and non-empty. Looking at a few
of the LogWatcher implementations, it looks like "level" can be null
when set=false. These would be great things to document in
@JsonProperty and OpenAPI annotations, if anyone reading is interested
in helping fill in that gap?
> In LogMessagesResponse, the "docs" field is currently just an object and has
> an open TODO. Who is currently defining the object of "docs"?
Gah - I forgot about this. The "docs" field is a "SolrDocumentList" -
the same type that Solr uses to return search results. But
SolrDocumentList as a Java class lives in a different gradle module
and itself relies on other utilities/types that we don't want to pull
into the 'api' module where LogMessageResponse lives. It's a solvable
problem with some refactoring, just not one that I (or anyone else)
has gotten to yet. Again - a great place to jump in if any interested
readers want to get their feet wet in the v2 API code!
In the code, the "docs" field gets populated by the retval of
"LogWatcher.getHistory(...)"
Hope that helps clear up some of your questions. Happy to clarify if
you have any followups (but let's move that to a separate thread).
Best,
Jason
On Tue, Feb 11, 2025 at 4:30 AM Colvin Cowie <colvin.cowie....@gmail.com> wrote:
>
> Just to say, I've been writing a smoke test for the v2 APIs when I've had a
> spare hour, I've done about half of it
> https://github.com/apache/solr/pull/3023/files
> <https://github.com/apache/solr/pull/3023/files#diff-549531110b26fa08a870f1853351abad4808116ff4258b5226358d6a5073dadb>
> I've found three broken endpoints so far; hopefully I'll finish writing the
> test this weekend and see if there's any more.
>
> From a consumer POV what I have noticed is that the validation of the
> requests is slightly brutal, in that invalid input (missing fields, object
> instead of an array etc) leads to a 500 response rather than a 400.
> It would be good to distinguish bad request errors from backend errors. A
> *nice
> to have*, would be to return the error in the response (e.g. using RFC 7807
> / RFC 9457 error responses), so that the client author doesn't have to go
> to the server log when they get it wrong.
>
>
> On Tue, 11 Feb 2025 at 02:13, David Smiley <dsmiley....@gmail.com> wrote:
>
> > (An aside: discussion around a particular endpoint or even category of
> > endpoints deserves its own thread IMO)
> >
> > > On Feb 10, 2025, at 4:40 PM, Christos Malliaridis <
> > malliari...@apache.org> wrote:
> > > - If this assumption is correct, can one update the log level of all
> > nodes with a single request?
> >
> > I can say Solr supports this, _at least_ in the V1 API, as I was involved
> > as a reviewer.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
