Hey Colvin,
Awesome to hear you're making progress on the v2 API integration
test(s). Thanks again for taking that up - it'll be a huge
improvement! Feel free to be aggressive about tagging me on the PR
when it's ready for review, if it seems like I missed it.
> 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
That's definitely not the intention - can you file a JIRA describing a
particular case, and we can continue the discussion there?
Best,
Jason
On Fri, Feb 14, 2025 at 10:14 AM Jason Gerlowski <gerlowsk...@gmail.com> wrote:
>
> 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
