The results using image vector model are barely able to keep up with the expectations.
After all "image speaks louder than words" :)

Documentation 'First Kata: Lets Optimize a Query' instructs to set scorer to nDCG@5, but that option is not available in the scorers drop down.
Further in the document nDCG@4 (and the available option nDCG@10) is also referred to.
The available options are:

• nDCG@10 (Communal)
• DCG@10 (Communal)
• CG@10 (Communal)
• P@10 (Communal)
• AP@10 (Communal)

Documentation:

• Chorus kata 000
• Solr Configsets API

My example with POST (failed):
curl —user solr:SolrRocks -X POST —header “Content-Type:application/octet-stream” —data-binary @./solr/configsets/ecommerce.zip “http://localhost:8983/api/cluster/configs/ecommerce”
{
“responseHeader”:{
“status”:0,
“QTime”:0},
“availableSubPaths”:{“/cluster/configs/ecommerce/*”:[“PUT”]}}

My example with PUT (success):
curl —user solr:SolrRocks -X PUT —header “Content-Type:application/octet-stream” —data-binary @./solr/configsets/ecommerce.zip “http://localhost:8983/api/cluster/configs/ecommerce”
{
“responseHeader”:{
“status”:0,
“QTime”:27}}

Noticed on chorus.dev.o19s.com, mysql died... did a docker-compose start mysql, and we ened up with a new databas setup and no "quepid" database!

curl http://chorus.dev.o19s.com/healthcheck produced

curl "http://chorus.dev.o19s.com:3000/healthcheck"
{"code":503,"errors":[{"name":"database","exception":"ActiveRecord::NoDatabaseError","message":"Unknown database 'quepid'"},{"name":"migrations","exception":"ActiveRecord::NoDatabaseError","message":"Unknown database 'quepid'"}]}%    

Chorus still uses Querqy for Solr 4.9, which has the issue described in querqy/querqy#153. Querqy v. 4.11 solves this.

Response times are high (in the 30-50 ms range) at Solr level regardless of which query parser we use (querqy or edismax). ms should be in the slow single digits, even on a not-so-fast machine.

Query: http://localhost:8983/solr/ecommerce/select?q=laptop&defType=edismax

Guess: JVM heap (500m) looks a bit small to me.

RRE - No evaluation data has been generated - no reports will be produced.

katas/000_setting_up_chorus.md and katas/001_optimize_a_query.md both have a section on using RRE to evaluate search results, but it looks to fail silently. Issue #92 I think shows a symptom of this failure as well

docker-compose run rre mvn rre-report:report
[+] Running 5/0
 ⠿ Container keycloak  Running                                                          0.0s
 ⠿ Container zoo3      Running                                                          0.0s
 ⠿ Container zoo2      Running                                                          0.0s
 ⠿ Container zoo1      Running                                                          0.0s
 ⠿ Container solr1     Running                                                          0.0s
[INFO] Scanning for projects...
[INFO]
[INFO] --------------< org.querqy.chorus:chorus-rre-regression >---------------
[INFO] Building chorus-rre-regression 1.0
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- rre-maven-report-plugin:1.1:report (default-cli) @ chorus-rre-regression ---
[INFO] No evaluation data has been generated - no reports will be produced.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.665 s
[INFO] Finished at: 2022-01-24T18:59:21Z
[INFO] ------------------------------------------------------------------------

this doesn't seem to change even if the evaluation is run in the same docker-compose run:

docker-compose exec rre mvn rre:evaluate rre-report:report

The same error occurs even though RRE looks like it ran correctly in the evaluate stage.

Potentially relates to SeaseLtd/rated-ranking-evaluator#140

After cloning the repo and running docker-compose up --build on a MacBook with a M1 chip there is a quepid Error stating docker-compose up --build.

zoo1 might not start on macOS (Monterey) as port 7000 is already in use. The application that uses this port seems to be Mac's AirPlay. Disabling 'AirPlay Receiver' has worked for me (https://developer.apple.com/forums/thread/682332) - but I assume we should change the ZK port?!

• Upgrade to latest Querqy when it is released (probably 4.10)
• Bump Solr
• Bump to latest SMUI
• Run through the scripts to verify things still work.

The 2 curl commands in kata 6 (https://github.com/querqy/chorus/blob/master/katas/006_adding_custom_query_rules.md#sixth-kata-lets-understand-how-to-consume-some-common-query-patterns-with-regex) that illustrate the results from querqy use the parameter qt (qt=querqy) instead of defType (defType=querqy). This results in error message returned:

  "error":{
    "metadata":[
      "error-class","org.apache.solr.common.SolrException",
      "root-error-class","org.apache.solr.common.SolrException"],
    "msg":"invalid query parser 'qt' for query '16:9 K58357WW'",
    "code":400}}

Command that misses ending curly brackets:

curl --user solr:SolrRocks -X POST http://localhost:8983/api/collections -H 'Content-Type: application/json' -d'
  {
    "create": {
      "name": "ecommerce",
      "config": "ecommerce",
      "numShards": 2,
      "replicationFactor": 1,
      "waitForFinalState": true
    }
'

Hey @renekrie can you make the date_released field be in the proper full format that Solr wants by default?

I don't see a good reason to have to demonstrate converting date time stamps since we control the source file!

date_released'='2009-12-10' should be '2009-12-10T00:00:00Z`

Thanks!

I'm opening up this issue to ask a question: Should the default data quality related filters live in the Solr Request Handler?

We've added two filters to the Blacklight front end, one to ensure we only show products with prices, the other for images:

      fq: '-img_500x500:""',
      fq: 'price:*'

I then was poking around with the data, and was getting conflicting results between Quepid and Blacklight, and my python script and Blacklight, which I finally realized was because I wasn't keeping those parameters in Solr!

Maybe on a larger point, should all data filters like this always live in the search layer? Since we don't have a "Search API" that is seperate, then that makes the Solr /select basically our API.

I love advertising the power of https://solr.apache.org/guide/7_5/request-parameters-api.html, and yet we have all the params for our three algo's hard coded in the Blacklight ui, instead of doing a useParams=querqy or useParams=mustmatchall.

Time to walk the walk!

Following the steps for the setup of chorus as described in :
https://github.com/querqy/chorus/blob/master/katas/000_setting_up_chorus.md

as the security.json was added at step :

docker cp ./solr/security.json solr1:/security.json
docker exec solr1 solr zk cp /security.json zk:security.json -z zoo1:2181
after this setup solr becomes inaccessible as below :

Create a Docker image for a service that makes available embeddings via HTTP so that the Solr/Blacklight demo app can use embeddings from models available in Python when querying. Start with SBERT sentence-transformers.

Great initiative to provide an OSS stack for e-commerce search!

So far I haven't taken a closer look at the components and the integration yet. But I would be interested in which ones you would describe yourself as ready for production and which you would rather not use in production yourself. This could also be added to the README if this is possible.

I would also be interested in which components you would like to get contributions / in which parts would you say things should be improved (thinking about it, maybe this is just a different way to ask the same thing as before ;-)). Maybe you could create issues for things where you'd like to receive contributions...?

Often I'll fire up Chorus and discover that port 3000 was already taken by my Quepid. Or a Solr is running on 8983 already...

can we prefix everything with a number like 10, and then keep them on the well known port number.

Kata 007 introduces paramsets, but they are used in 000 now? It might help to add a link to expand on why paramsets. Introduced in PR #89

I like the call to action that this project https://github.com/simonw/datasette

Kata 6 (https://github.com/querqy/chorus/blob/master/katas/006_adding_custom_query_rules.md#sixth-kata-lets-understand-how-to-consume-some-common-query-patterns-with-regex) says that query q=16:9%20K58357WW returns only 1 result (numFound=1). However, the result from executing the query returns 13 results (numFound=13).
Only after setting mm=100% or q.op=AND, numFound is 1.

We are home rolling what we should do via "profiles": https://docs.docker.com/compose/profiles/

Over time blacklight appears to leak memory, I see this on our demo site.

https://github.com/schneems/puma_worker_killer

Currently have a volumes/preliveCore/conf/rules.txt file that appears to be needed to allow Querqy to start up. With out it, I think Querqy blows up, or maybe SMUI does.

This file gets edited, which means when you do git status you constantly see it! We really want to have it be in the .gitignore.

I thought about creative Git techniques like in this post: https://stackoverflow.com/questions/3319479/can-i-git-commit-a-file-and-ignore-its-content-changes but that looks very error prone!

A new pattern is to use the same Production Solr setup, but to first test your rules out in a prelive environment, and then once you are happy, push to live. We could demonstrate that in Chorus, and maybe even have a button in Blacklight to swap between "LIVE" view and "PRELIVE" to try out the rules.

Once Solr 8.7 is cut, use the new SOLR-14907 v2 Configset API to update rules.txt in zookeeper, which lets us remove our jackhanna.jar file that directly inserts rules.txt into ZooKeeper.

We may be able to avoid doing a manual reload on the collection as well, not sure on that ;-)

Thanks @HoustonPutman for adding this to Solr!

Following the setup instructions it seems like on the step :

Now, let's go ahead and make sure we publish the results of our evaluation:
docker-compose run rre mvn rre-report:report
You can now see a Excel spreadsheet saved to ./rre/target/site/rre-report.xlsx.

The file instead is called ./rre/target/site/rre-report.html.

When going through the Katas after setting up the lab with ./quickstart.sh -with-offline-lab, adding the "Notebook Computers" case in quepid, and entering "notebook" and "laptop" into the query, the UI spins until a message appears at the bottom:

"One or more of your Solr queries failed to return results, please access your Solr instance directly to confirm Solr is accessible and to inspect the error. If Solr responds, check if you have an ad blocker blocking your queries. With Solr 8.4.1 and later you need to allow Quepid access to Solr. Learn more on the troubleshooting Solr wiki page."

The query responds with:

"responseHeader": {
"zkConnected": true,
"status": 400,
"QTime": 0,
"params": {
"df": "id",
"debug": "true",
"hl": "false",
"echoParams": [
"all",
"all)"
],
"indent": "true",
"fl": "id title img_500x500 name brand product_type",
"rows": "10",
"debug.explain.structured": "true",
"q": "laptop",
"tie": "1.0",
"defType": "edismax",
"qf": "text_all",
"wt": "json",
"rid": "-148"
}
},
"error": {
"metadata": [
"error-class",
"org.apache.solr.common.SolrException",
"root-error-class",
"org.apache.solr.common.SolrException"
],
"msg": "org.apache.solr.search.SyntaxError: Query Field 'text_all' is not a valid field name",
"code": 400
}
}

The text_all field used in the query filter is missing from the index.

I'm not quite sure where the query is generated in the code and was just going to add a field to the index to make it work. If I can get pointed in the right direction and this is not a config issue on my end, I'd be happy to investigate a possible fix. If it is something I missed in the kata or something missing in the kata, I could take a look there too.

Kata 000 step:

docker exec solr1 solr zk cp /security.json zk:security.json -z zoo1:2181

Keycloak doesn't load the configuration from zookeeper, due to a missing udp service:

solr1 | 2022-06-24 17:15:29.285 ERROR (zkCallback-12-thread-2) [ ] o.a.s.c.c.ZkStateReader Error running collections node listener => org.apache.solr.common.SolrException: Well-known config could not be read from url http://keycloak:9080/auth/realms/chorus/.well-known/openid-configuration
...
keycloak | ("subsystem" => "jgroups"),
keycloak | ("channel" => "ee")
keycloak | ]) - failure description: {"WFLYCTL0080: Failed services" => {"org
.wildfly.clustering.jgroups.channel.ee" => "java.lang.IllegalStateException: jav
a.net.SocketException: Protocol not available
keycloak | Caused by: java.lang.IllegalStateException: java.net.SocketExc
eption: Protocol not available
keycloak | Caused by: java.net.SocketException: Protocol not available"}}
keycloak | ESC[0mESC[0m01:08:24,414 INFO [org.jboss.as.server] (ServerServic
e Thread Pool -- 45) WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name :
"keycloak-server.war")

Updating docker-compose.yml to use version 17.0.1-legacy (wildfly support variant, see ):
diff --git a/docker-compose.yml b/docker-compose.yml
index fd7a096..40c3144 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -239,7 +239,7 @@ services:
- prometheus

keycloak:

• image: quay.io/keycloak/keycloak:16.1.0

• image: quay.io/keycloak/keycloak:17.0.1-legacy
  container_name: keycloak
  hostname: keycloak
  command: ["-b", "0.0.0.0", "-Dkeycloak.migration.action=import", "-Dkeycloak.migration.provider=dir", "-Dkeycloak.migration.dir=/opt/jboss/keycloak/realm-config", "-Dkeycloak.migration.strategy=OVERWRITE_EXISTING", "-Djboss.socket.binding.port-offset=1000", "-Dkeycloak.profile.feature.upload_scripts=enabled"]

resolves the issue.

Image update referenced in keycloak/keycloak#8846 (comment) and the surrounding thread.

As the error came from wildfly, I used the wildfly version, but I do not know if that is necessary.

Relates to #91, #93, #110

katas/001_optimize_a_query.md hints at making laptop and notebook act similarly, but doesn't go into any detail about actually making that happen.

Make 'brand' field use type 'text_general' instead of 'text_stemmed_en' as we must not stem names.

Ugh, the assumption that http://keycloak:9080 will work both inside the Docker Environment and Externally to the end user works fine in dev, but breaks in the hosted version! This impacts Solr and Quepid authing against Keycloak.

I received the following error on a fresh install (Docker for desktop, 2.2.0.0, Engine 19.03.05, Compose 1.25.2):

 docker-compose up --build
Building smui
Step 1/3 : FROM querqy/smui:3.6.1
 ---> af725f077730
Step 2/3 : USER root
 ---> Running in a08229712345
Removing intermediate container a08229712345
 ---> 22b38a8b0273
Step 3/3 : RUN chmod -R 0777 /usr
 ---> Running in 814917c9a27c
Removing intermediate container 814917c9a27c
 ---> 725804306aa7
Successfully built 725804306aa7
Successfully tagged chorus_smui:latest
Building solr
Step 1/2 : FROM solr:8.5.2
8.5.2: Pulling from library/solr
e9afc4f90ab0: Pull complete
989e6b19a265: Pull complete
af14b6c2f878: Pull complete
68a79816c3e1: Pull complete
e440f69a0a76: Pull complete
837b533a935d: Pull complete
2df9b8b5d142: Pull complete
0eb4ef5b01ad: Pull complete
2a223a8f7eac: Pull complete
b09044e85a86: Pull complete
d2db09755929: Pull complete
Digest: sha256:671d11bda54007aeb05fefae80f201156b14f2a6bc173fec9daecfc0a60d081b
Status: Downloaded newer image for solr:8.5.2
 ---> 7d9cd085372d
Step 2/2 : COPY ./lib/querqy-solr-4.9.lucene810.0-jar-with-dependencies.jar /opt/querqy/lib/
 ---> 9e7c428c8a56
Successfully built 9e7c428c8a56
Successfully tagged chorus_solr:latest
Building blacklight
Step 1/12 : FROM ruby:2.6.5
 ---> ad10dfbc638b
Step 2/12 : RUN apt-get update -qq     && apt-get install -y build-essential                           nodejs                           vim                           libxml2-dev                           libxslt-dev                           sqlite
 ---> Using cache
 ---> 842aae469f15
Step 3/12 : RUN mkdir -p /app
 ---> Using cache
 ---> 475f1a2c0586
Step 4/12 : WORKDIR /app
 ---> Using cache
 ---> cfca241b18c0
Step 5/12 : COPY Gemfile /app
 ---> Using cache
 ---> fb695f28ed43
Step 6/12 : COPY Gemfile.lock /app
 ---> Using cache
 ---> 776cdc4d476a
Step 7/12 : RUN gem install bundler && bundle install --jobs 20 --retry 5
 ---> Using cache
 ---> cbc73a22d382
Step 8/12 : COPY . /app
 ---> 58e10408fbfb
Step 9/12 : RUN rake db:migrate
 ---> Running in ce01f1fd68d6
== 20200604111513 CreateSearches: migrating ===================================
-- create_table(:searches, {:id=>:integer})
   -> 0.0014s
== 20200604111513 CreateSearches: migrated (0.0015s) ==========================

== 20200604111514 CreateBookmarks: migrating ==================================
-- create_table(:bookmarks, {:id=>:integer})
   -> 0.0023s
== 20200604111514 CreateBookmarks: migrated (0.0023s) =========================

== 20200604111515 AddPolymorphicTypeToBookmarks: migrating ====================
== 20200604111515 AddPolymorphicTypeToBookmarks: migrated (0.0065s) ===========

Removing intermediate container ce01f1fd68d6
 ---> d3dd3f3c6798
Step 10/12 : RUN apt-get clean all
 ---> Running in 794151761d3e
Removing intermediate container 794151761d3e
 ---> ec6b912f0bb5
Step 11/12 : EXPOSE 3000
 ---> Running in 22fbefd8e682
Removing intermediate container 22fbefd8e682
 ---> 8267be6d80da
Step 12/12 : CMD bundle exec puma -C config/puma.rb
 ---> Running in d18822ba60ca
Removing intermediate container d18822ba60ca
 ---> fac3080c3210
Successfully built fac3080c3210
Successfully tagged chorus_blacklight:latest
Pulling redis (redis:6.0.5)...
6.0.5: Pulling from library/redis
8559a31e96f4: Pull complete
85a6a5c53ff0: Pull complete
b69876b7abed: Pull complete
a72d84b9df6a: Pull complete
5ce7b314b19c: Pull complete
04c4bfb0b023: Pull complete
Digest: sha256:800f2587bf3376cb01e6307afe599ddce9439deafbd4fb8562829da96085c9c5
Status: Downloaded newer image for redis:6.0.5
Pulling quepid (o19s/quepid:6.2.0)...
6.2.0: Pulling from o19s/quepid
7568c21980bd: Already exists
4a9f2207c812: Already exists
6fe350d2b140: Already exists
d95a2fdc8b3d: Already exists
760eb225f9e8: Extracting [==================================================>]  214.9MB/214.9MBBwnload complete
ce86e3018f7e: Download complete
 20.73MB/20.88MBwnload complete
5cac564727b9: Download complete
 38.61MB/38.8MBownload complete
4624a69c038b: Download complete
1341f98f0ab5: Download complete
13905178c107: Download complete
 26.45MB/26.45MBwnload complete
1c80938cbaca: Download complete
36af165e7a5e: Download complete
 76.71MB/76.79MBwnload complete
a218fa4bde1c: Download complete
   235MB/235.2MBwnload complete
ERROR: failed to register layer: error creating overlay mount to /var/lib/docker/overlay2/d6dc824ab096477706bd4e8a4d67ca4c39caf69097ad3a1f55a6f11225f1744a/merged: no such file or directory```

When I fire up Docker on a fresh git clone and follow the README, SMUI reports a successful push to Solr but the rules.txt file in the conf folder of the Solr core is not modified. It turns out that SMUI does not push to the conf folder but to a different path.

We should fix this so that SMUI Solr work together out-of-the-box under Chorus.

Hi, the demo "Chorus Electronics" link (http://chorus.dev.o19s.com:4000/) isn't working. Rest of the applications are runnning and are accessible through their respective ports. Please take a look.

Cheers !

Awesome feature, where is it in demo.

In response to #11, we should add CI testing so that we can guarantee that Chorus components do work together.

HTTP ERROR 404 javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down.

Caused by:

javax.servlet.ServletException: javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down.

LOGS:

solr1 | 2022-04-04T11:19:55.968916581Z 2022-04-04 11:19:55.968 INFO (main) [ ] o.a.s.c.ZkController Register node as live in ZooKeeper:/live_nodes/172.31.0.9:8983_solr
solr1 | 2022-04-04T11:19:56.048754867Z 2022-04-04 11:19:56.047 INFO (zkCallback-12-thread-1) [ ] o.a.s.c.c.ZkStateReader Updated live nodes from ZooKeeper... (2) -> (3)
solr1 | 2022-04-04T11:19:56.189361493Z 2022-04-04 11:19:56.188 INFO (main) [ ] o.a.s.p.PackageLoader /packages.json updated to version -1
solr1 | 2022-04-04T11:19:56.247212248Z 2022-04-04 11:19:56.246 INFO (main) [ ] o.a.s.c.CoreContainer Initializing authorization plugin: solr.MultiAuthRuleBasedAuthorizationPlugin
solr1 | 2022-04-04T11:19:56.314005852Z 2022-04-04 11:19:56.313 INFO (main) [ ] o.a.s.c.CoreContainer Initializing authentication plugin: solr.MultiAuthPlugin
solr1 | 2022-04-04T11:19:56.349467571Z 2022-04-04 11:19:56.348 ERROR (main) [ ] o.a.s.s.SolrDispatchFilter Could not start Solr. Check solr/home property and the logs
solr1 | 2022-04-04T11:19:56.421782378Z 2022-04-04 11:19:56.377 ERROR (main) [ ] o.a.s.c.SolrCore null => org.apache.solr.common.SolrException: Well-known config could not be read from url http://keycloak:9080/auth/realms/chorus/.well-known/openid-configuration
solr1 | 2022-04-04T11:19:56.421837225Z at org.apache.solr.security.JWTIssuerConfig$WellKnownDiscoveryConfig.parse(JWTIssuerConfig.java:402)
solr1 | 2022-04-04T11:19:56.421922679Z org.apache.solr.common.SolrException: Well-known config could not be read from url http://keycloak:9080/auth/realms/chorus/.well-known/openid-configuration
solr1 | 2022-04-04T11:19:56.422210140Z at org.apache.solr.security.JWTIssuerConfig$WellKnownDiscoveryConfig.parse(JWTIssuerConfig.java:402) ~[?:?]
solr1 | 2022-04-04T11:19:56.422263421Z at org.apache.solr.security.JWTIssuerConfig.fetchWellKnown(JWTIssuerConfig.java:184) ~[?:?]
solr1 | 2022-04-04T11:19:56.422277001Z at org.apache.solr.security.JWTIssuerConfig.init(JWTIssuerConfig.java:104) ~[?:?]
solr1 | 2022-04-04T11:19:56.422286342Z at org.apache.solr.security.JWTAuthPlugin.lambda$parseIssuers$2(JWTAuthPlugin.java:259) ~[?:?]
solr1 | 2022-04-04T11:19:56.422293296Z at java.util.ArrayList.forEach(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422298976Z at org.apache.solr.security.JWTAuthPlugin.parseIssuers(JWTAuthPlugin.java:257) ~[?:?]
solr1 | 2022-04-04T11:19:56.422303955Z at org.apache.solr.security.JWTAuthPlugin.init(JWTAuthPlugin.java:174) ~[?:?]
solr1 | 2022-04-04T11:19:56.422309692Z at org.apache.solr.security.MultiAuthPlugin.initPluginForScheme(MultiAuthPlugin.java:147) ~[?:?]
solr1 | 2022-04-04T11:19:56.422314501Z at org.apache.solr.security.MultiAuthPlugin.init(MultiAuthPlugin.java:129) ~[?:?]
solr1 | 2022-04-04T11:19:56.422319708Z at org.apache.solr.core.CoreContainer.initializeAuthenticationPlugin(CoreContainer.java:500) ~[?:?]
solr1 | 2022-04-04T11:19:56.422324982Z at org.apache.solr.core.CoreContainer.reloadSecurityProperties(CoreContainer.java:987) ~[?:?]
solr1 | 2022-04-04T11:19:56.422330295Z at org.apache.solr.core.CoreContainer.load(CoreContainer.java:735) ~[?:?]
solr1 | 2022-04-04T11:19:56.422335976Z at org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:287) ~[?:?]
solr1 | 2022-04-04T11:19:56.422341294Z at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:184) ~[?:?]
solr1 | 2022-04-04T11:19:56.422346522Z at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:140) ~[jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422351804Z at org.eclipse.jetty.servlet.ServletHandler.lambda$initialize$0(ServletHandler.java:731) ~[jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422362559Z at java.util.Spliterators$ArraySpliterator.forEachRemaining(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422368213Z at java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422373783Z at java.util.stream.ReferencePipeline$Head.forEach(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422379105Z at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:755) ~[jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422401953Z at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:379) ~[jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422408900Z at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1449) ~[jetty-webapp-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422429698Z at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1414) ~[jetty-webapp-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422434818Z at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:910) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422459973Z at org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:288) ~[jetty-servlet-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422465806Z at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:524) ~[jetty-webapp-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422470895Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422476296Z at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422481475Z at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422487274Z at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422492695Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422497996Z at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422503508Z at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422527623Z at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422533001Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422538231Z at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422543308Z at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:117) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422548668Z at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422553978Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422565182Z at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422570957Z at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422576186Z at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422581520Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422586901Z at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422592165Z at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422597666Z at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422605304Z at org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:426) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422610937Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422616204Z at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:169) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422621304Z at org.eclipse.jetty.server.Server.start(Server.java:423) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422626402Z at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:110) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422631713Z at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:97) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422636955Z at org.eclipse.jetty.server.Server.doStart(Server.java:387) ~[jetty-server-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422641856Z at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:73) ~[jetty-util-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422647395Z at org.eclipse.jetty.xml.XmlConfiguration.lambda$main$3(XmlConfiguration.java:1907) ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422652783Z at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
solr1 | 2022-04-04T11:19:56.422657863Z at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1857) ~[jetty-xml-9.4.44.v20210927.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422663085Z at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
solr1 | 2022-04-04T11:19:56.422668042Z at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422677763Z at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422683041Z at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422688213Z at org.eclipse.jetty.start.Main.invokeMain(Main.java:218) ~[start.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422693607Z at org.eclipse.jetty.start.Main.start(Main.java:491) ~[start.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422699566Z at org.eclipse.jetty.start.Main.main(Main.java:77) ~[start.jar:9.4.44.v20210927]
solr1 | 2022-04-04T11:19:56.422704803Z Caused by: java.net.ConnectException: Connection refused (Connection refused)
solr1 | 2022-04-04T11:19:56.422710126Z at java.net.PlainSocketImpl.socketConnect(Native Method) ~[?:?]
solr1 | 2022-04-04T11:19:56.422716700Z at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422722227Z at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422727177Z at java.net.AbstractPlainSocketImpl.connect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422732328Z at java.net.Socket.connect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422737222Z at java.net.Socket.connect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422742340Z at sun.net.NetworkClient.doConnect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422747387Z at sun.net.www.http.HttpClient.openServer(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422752551Z at sun.net.www.http.HttpClient.openServer(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422757785Z at sun.net.www.http.HttpClient.(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422763239Z at sun.net.www.http.HttpClient.New(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422768165Z at sun.net.www.http.HttpClient.New(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422773164Z at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422778227Z at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422783390Z at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422788382Z at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422793368Z at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422798631Z at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422803794Z at java.net.URL.openStream(Unknown Source) ~[?:?]
solr1 | 2022-04-04T11:19:56.422808817Z at org.apache.solr.security.JWTIssuerConfig$WellKnownDiscoveryConfig.parse(JWTIssuerConfig.java:398) ~[?:?]
solr1 | 2022-04-04T11:19:56.422814448Z ... 63 more
solr1 | 2022-04-04T11:19:56.443173250Z 2022-04-04 11:19:56.442 INFO (main) [ ] o.e.j.s.h.ContextHandler Started o.e.j.w.WebAppContext@3276732{/solr,file:///opt/solr-8.11.1/server/solr-webapp/webapp/,AVAILABLE}{/opt/solr-8.11.1/server/solr-webapp/webapp}
solr1 | 2022-04-04T11:19:56.484608032Z 2022-04-04 11:19:56.483 INFO (main) [ ] o.e.j.s.AbstractConnector Started ServerConnector@18c5069b{HTTP/1.1, (http/1.1, h2c)}{0.0.0.0:8983}
solr1 | 2022-04-04T11:19:56.488124641Z 2022-04-04 11:19:56.487 INFO (main) [ ] o.e.j.s.Server Started @46186ms

A nice feature ;-)

007 is both paramsets and security?

katas/007_security_in_chorus.md and katas/007_organize_algorithms_using_paramsets.md

I think the security kata should be moved to a later number since it doesn't look fleshed out yet.

Now that we create a baseline relevance Quepid Case in quickstart.sh, lets have a kata!

Per this thread: https://groups.google.com/forum/#!topic/blacklight-development/9TX0QO04BsU

recommended by Trey, Max, Doug in AI Powered search ;-)

.. in README

Change this line from:

curl 'http://localhost:8983/solr/ecommerce/update?processor=formatDateUpdateProcessor&commit=true' --data-binary @icecat-products-150k-20200607.tar.gz -H 'Content-type:application/json'

to

curl 'http://localhost:8983/solr/ecommerce/update?processor=formatDateUpdateProcessor&commit=true' --data-binary @icecat-products-150k-20200607.json -H 'Content-type:application/json'

Change meaninfully to meaningfully in the That all folks! paragraph

• Use smaller product dataset with prices for all products (ca. 20k) in quickstart.sh.
• Remove price filter appended in solrconfig.xml
• Change README to use smaller dataset. Large dataset still available for download and to be mentioned in README