[
https://issues.apache.org/jira/browse/SOLR-16347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642687#comment-17642687
]
Jason Gerlowski commented on SOLR-16347:
----------------------------------------
bq. node startup is 33% slower because of this commit
There's at least a little truth in that old quote about "lies, damn lies, and
statistics". :P
I really wish you'd include full context around claims like "33% slower". Node
startup isn't 33% slower in *all*, or even in *most* cases. It's 33% slower
only in a very particular deployment scenario that involves packing very very
large number of cores onto each node (700? 750?). "33%" isn't wrong per se,
but the picture it paints bears little relation to what an average Solr user
would experience.
This is why I advocated in Slack to keep all of the discussion about this in
one place - context is super important in all of this stuff, and it's easy to
mislead folks by innocuous, accidental omission. Let's make this discussion as
easy to follow as possible.
bq. I don't think we have made progress in reversing the degradation. On the
other hand, we are continuing to make changes to the codebase that likely
depend on this commit
I understand and appreciate your anxiety that this won't get fixed "in time".
But I'd ask for a bit more patience on your part.
We're coming off a holiday week here in the U.S, and I was afk with the flu
some time before that - so granted, there hasn't been much visible progress -
but much of that is extenuating circumstances. This is absolutely at the top
of my list. Even the recent commit you referenced on SOLR-16392 is being
misread a bit I'd argue. Merging that was an attempt on my part to clear my
plate so that I can focus on the perf regression more fully, not an attempt to
further entrench things.
If entrenchment is a big part of your concern, would you feel better about
things if I held off on subsequent branch_9x JAX-RS backports until more
progress has been made on the underlying regression? Maybe that's a compromise
we can all be happy with here? The branch_9x revert wouldn't get any harder or
more entrenched (by and large), and we'd be able to defer the decision (of
whether or not to revert 9x) until we know much more (LoE on the perf fix, 9.2
timeline, etc.)
> Add JAX-RS integration for defining v2 APIs
> -------------------------------------------
>
> Key: SOLR-16347
> URL: https://issues.apache.org/jira/browse/SOLR-16347
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> SOLR-15182 rewrote our v2 APIs to use annotations using an existing
> (in-house) framework. But continuing to use a homegrown framework is less
> than ideal for a few reasons:
> # Our in-house framework doesn't integrate with 3rd-party tooling like
> OpenAPI.
> # It gives us less functionality than many off-the-shelf frameworks, at a
> higher maintenance cost.
> # The current framework is less explicit about API inputs and outputs than
> many off-the-shelf alternatives, making code less clear and readable for
> developers.
> (For more on the pros/cons and for different evaluations on the tradeoff
> here, see
> [this|https://lists.apache.org/thread/6wx2vzfnmfgkw03b7s450zfp7yhrlz8f]
> long-running dev@ thread.)
> The work done by SOLR-15182 makes the jump to JAX-RS reasonably
> straightforward on an individual API basis: once the framework is in place
> switching a given API to JAX-RS is mostly a matter of swapping out our
> homegrown annotations for those recognized by JAX-RS and changing API method
> signatures to better represent the API inputs/outputs.
> We should integrate Jersey or a similar JAX-RS implementation and start
> cutting over v2 APIs to this new mode of definition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
