Re: [DISCUSS] Standardizing sysprop naming

[David Smiley]

Thanks for working on this and raising the topic of config naming
standardization!

Using this one as an example; what would you propose?:
* solr.shardSplit.checkDiskSpace.enabled

Thankfully, it already uses two best practices (A) starting with "solr."
and (B) a module/category "shardSplit".  What follows is
"checkDiskSpace.enabled.  I dislike ".enabled" in general but not a big
deal.  Are you saying the camel case is a problem?  Is it a problem in the
module part "shardSplit"?  The current structure is clear (separation of
the module/category from the individual toggle name); disallowing camel
case in a system property and converting to periods would look worse, but
alas, I guess we can't have everything.

On a related note, I've been thinking it'd be wonderful if Solr
automatically had sys-prop/env-var overrides for any configuration element
without requiring a dollar-curley-bracket use.  This would result in
standardization and more easily allow near empty configurations by default;
something we don't quite have.  An example:
in solrconfig.xml,  parent element, we have this today:
 
Imagine instead not specifying this at all.  The default logic would
instead read the class from the sys prop: "solr.config.directoryFactory".
The "config" part is because that's the root element of this file.

Here's another example:
  

  ${solr.commitwithin.softcommit:true}

  

Again, imagine not specifying this at all.  Instead, the default would be
read from "solr.config.updateHandler.commitWithin.softCommit".


On Fri, Jan 5, 2024 at 11:15 AM Jan Høydahl  wrote:

> Hi,
>
> Happy New Year to all!
>
> Finally https://issues.apache.org/jira/browse/SOLR-15960 Unified use of
> system properties and environment variables is now merged!
> It exports all SOLR_FOO and ZK_FOO env.vars to be available to the Solr
> Java process and maps them to sys.prop without need for explicit maping in
> bin/solr[.cmd].
>
> Please take it for a spin, and if you find simplifications that can be
> done in bin/solr[.cmd] scripts or docs, feel free to grab those.
>
>
> I'm planning a followup related to sysprop naming convention in
> https://issues.apache.org/jira/browse/SOLR-17111
> Proposing a strict solr.foo.bar naming, aligning with env name
> SOLR_FOO_BAR instead of our current solr.fooBar camelCase props.
> The plan is to support both old and new keys in in 9.x (e.g. both
> "disableAdminUI" and "solr.admin.ui.disabled") and only new from 10.0.
> Q: Wil this be such a big change that both variants should work throughout
> the 10.x series as well?
>
>
> Next, I'd love to consider semantic property names. Now we have a mix of
> randomly chosen property names. Some examples:
> metricsEnabled
> solr.enableStreamBody
> enable.packages
> solr.clustering.enabled
> solr.shardSplit.checkDiskSpace.enabled
> solr.log.requestlog.enabled
> I'd love for us to qualify these with module/submodule, so we get some
> semantic naming structure like
>
> solr...=foo
> E.g. enable.packages would then be solr.packages.enabled (instead of
> simply solr.enable.packages)
>
> To do this across the entire set of solr properties is a much bigger
> change than SOLR-17111. So I propose to tackle only the non-standard ones
> first, and select new names case by case.
>
> If you like the proposal of some standardized naming hierarchy across all
> properties, that is probably something that deserves a design document or a
> SIP..
>
> -Jan

Re: Solr 9.4.1

[Jan Høydahl]

Done

Jan

> 7. jan. 2024 kl. 07:03 skrev David Smiley :
> 
> Sure; thanks.
> 
>> On Fri, Jan 5, 2024 at 3:29 PM Jan Høydahl  wrote:
>> 
>> Should we include this bugfix?
>> https://issues.apache.org/jira/browse/SOLR-16203
>> I'm merging to branch_9x now...
>> 
>> Jan
>> 
 5. jan. 2024 kl. 17:14 skrev David Smiley :
>>> 
>>> 9.4.1 is unblocked; bug fixes are now on the release branch.  I plan to
>>> pursue a RC soon (today/tomorrow).  This is my first time.
>>> 
>>> On Fri, Dec 8, 2023 at 9:53 AM Jan Høydahl 
>> wrote:
>>> 
 SolrBot had been failing for a long time (>1month), but I got it on
>> track
 again. Normally it only files new PRs on Sundays, but I'm triggering
>> that
 manually now to consider what other upgrades from the past month that we
 should put into 9.4.1.
 
 Please have a look at https://github.com/apache/solr/pulls/solrbot and
 consider which ones should be merged and backported.
 
 Jan
 
> 8. des. 2023 kl. 14:59 skrev David Smiley :
> 
> I renamed that job to add "(Crave)"
> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x%20(Crave)/
>> and
> disabled it.  I then I created a new job copied from the
 "Solr-check-main"
> but branch_9x.  Builds are hourly so we'll see how it goes.
> 
> ~ David
> 
> 
> On Thu, Dec 7, 2023 at 10:08 AM Jan Høydahl 
 wrote:
> 
>> PS: https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/ is also
 not
>> running since 25 days as it was converted to Crave..
>> 
>> Jan
>> 
>>> 7. des. 2023 kl. 15:06 skrev David Smiley >> :
>>> 
>>> I've been working with Uv on these glitches.
>>> ~ David
>>> 
>>> 
>>> On Thu, Dec 7, 2023 at 2:47 AM Jan Høydahl 
>> wrote:
>>> 
 I backported ALL SolrBot PRs to branch_9_4, which brings the number
>> of
 known CVEs down.
 
 I also have a few other dependency upgrades baking in PRs but
 unfortunately Crave has died so no PRs pass tests:
 
> Run cd
 
>> 
 
>> /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
> Selecting project Solr (id:39)
> Error: Process completed with exit code 1.
 
 Jan
 
> 7. des. 2023 kl. 02:44 skrev David Smiley <
>> david.w.smi...@gmail.com
> :
> 
> Sounds good Eric.  It's not clear when exactly a 9.4.1 RC will
>> happen
>> as
> there are a couple security matters we're looking at.
> ~ David
> 
> 
> On Wed, Dec 6, 2023 at 12:31 PM Eric Pugh <
 ep...@opensourceconnections.com>
> wrote:
> 
>> Something that I’d like to get released ASAP is a fix to the
 bin/solr
 post
>> command.
>> 
>> Our Ref Guide has a lot of mentions of using “bin/solr post -c
>> tech
>> products”, however I removed the -c parameter in favour of -url
 parameter.
>> I think that was a mistake, and would like to restore the old -c
 parameter,
>> and then make sure the Ref Guide is up to date.
>> 
>> This could be a 9.4.1 or 9.5 change.
>> 
>>> On Dec 6, 2023, at 10:31 AM, Jason Gerlowski <
 gerlowsk...@gmail.com>
>> wrote:
>>> 
>>> Good question - I'm still thinking through what makes the most
 sense
>>> there.  Let's continue discussion on SOLR-17100 if you've got
>> thoughts!
>>> 
>>> On Wed, Dec 6, 2023 at 9:58 AM Jan Høydahl <
>> jan@cominvent.com>
>> wrote:
>>> 
 Jason, what do you mean by "publishing" the clients?
 I suppose you don't mean pip and npm, but including them in the
>> binary
 tarball for users to consume? Or can we perhaps keep them
 "internal"
>> only
 for a few releases with no docs and no guarantees, only
 dog-fooding?
 
 Jan
 
> 6. des. 2023 kl. 15:38 skrev Jason Gerlowski <
>> gerlowsk...@gmail.com
> :
> 
> I'd love to see a 9.5 go out sometime in January to get our new
 Python
 and
> Javascript clients in front of users.  I'm willing to RM the
>> release,
>> or
> share duties with you if you're interested David?  Publishing
>> the
>> new
> clients will require some changes to the release process, and
>> I'd
 hate
>> to
> saddle someone else with ironing out whatever hiccups are
>> likely
 to
>> crop
 up.
> 
> What do you guys think about doing 9.5 on a January-ish
 timeframe?
> 
> That said, if someone else wants a 9.4.1 I don't want to get in
 the
 way
 of
> that either. 

Nifi error after Solrj Upgrade

[Subhasis Patra]

Hi Everyone,

Appreciate any help on following.

I am using nifi-1.23.2 and Solr version is 9.2.0.
In my nifi processor I have logic to create Solr client. It was working as 
expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After that I 
started getting following error while creating Solr client in my nifi processor.

java.lang.IncompatibleClassChangeError: class 
org.eclipse.jetty.http.HttpFields$Mutable can not implement 
org.eclipse.jetty.http.HttpFields, because it is not an interface 
(org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
org.apache.nifi.nar.NarClassLoader @4a8df3e2)
at java.base/java.lang.ClassLoader.defineClass1(Native Method)
at 
java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
at 
java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
at 
java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
at 
java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
at 
java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at 
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
at 
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
at 
org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(Http2SolrClient.java:1066)
at 
org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(CloudHttp2SolrClient.java:61)
at 
org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)

I am using following method to create solr Client.

CloudSolrClient.Builder(urlList, Optional.empty()).withZkConnectTimeout(1, 
TimeUnit.MILLISECONDS)
 .withZkClientTimeout(6, 
TimeUnit.MILLISECONDS).build()

Thanks
Subhasis Patra
240-755-2601
subhasis.pa...@e2open.com