SolrConnectionValidator SolrInitializationException
I'm trying to startup a particular service and running into:
com.broadleafcommerce.search.provider.solr.SolrConnectionValidator$SolrInitializationException: Failed to execute query on collection XXXXX_alias_1.
You may disable this validation by setting broadleaf.solr.startup-validation to false
If you ever run into this error during startup of a pod (e.g. processing, supporting, core, search, or indexer) , it's helpful to understand what's going on "underneath the hood" to help diagnose and remedy this particular exception.
System Expectations
When using Broadleaf's Search Service SOLR implementation, the system expects certain Broadleaf specific collections and aliases to exist in SOLR before being able to successfully start up. This validation is gated by the property broadleaf.solr.startup-validation. This is defaulted to true and it is good practice to keep this enabled unless there's a specific implementation reason for not having the default Broadleaf configuration in SOLR. During the startup and the initialization process, if a service requires a connection to the SOLR-backed search service, it will attempt to connect to query SOLR and verify that these Broadleaf specific configurations exist, otherwise it will fail with the above exception.
How do you create the Broadleaf-specific SOLR configuration?
Broadleaf ships with several starter projects one of which is a is a project that produces a "Broadleaf Flavored" Docker Solr Image based on the standard solr:8.2-slim image. It contains default Broadleaf specific schema files and various initialization shell scripts for uploading those schema files to zookeeper and Solr Cloud. Below is a high level look at the composition of the Broadleaf Solr Image project.
Solr Image/ ├── configurations/ <------- need to be upconfig to ZK │ ├── catalog/conf | | ├── schema.xml | | └── other config... │ ├── customer/conf | | └── schema.xml | | └── other config... │ ├── order/conf | | └── schema.xml | | └── other config... │ └── order_fulfillment/conf | └── schema.xml | └── other config... ├── solr-config.sh <--------- main entry script ├── other supporting init scripts... └── Dockerfile
Option 1: Automatic SOLR setup on Kubernetes using Helm
If you are setting up Broadleaf on a Kubernetes cluster, we recommend using the provided starter Helm scripts. The Helm starter project contains an installation script that automates uploading the Broadleaf SOLR schema to Zookeeper as well as creating the appropriate collection aliases in SOLR. The installation script deploys the needed resources in a specific order to support the full Broadleaf microservices stack and utilizes Helm pre and post-install hooks ( https://helm.sh/docs/topics/charts_hooks) to load specific configurations needed by other resources in the stack. In general, the helm chart installation goes like this:
1. Install zookeeper and solr via the blc-supporting-stack helm charts
2. Once Zookeeper is running, the blc-supporting-stack contains several post-install resources that will upload several schema.xml and other broadleaf specific configuration directly to Zookeeper (from the Broadleaf Solr Docker Image). These resources are configured as a Kubernetes Job (https://kubernetes.io/docs/concepts/workloads/controllers/job/) as they only ever need to be executed once during the initial installation of the full stack.
3. In a later stage of the Helm installation when you are about to deploy one of the Flex Packages (either balanced, granular, or min), there are pre-install hooks to create the appropriate SOLR collection aliases needed by the system. For example, the system by default requires that there be an alias named catalog_alias_1 and catalog_alias_2 for catalog collection 1 and 2 (see here for more details: https://developer.broadleafcommerce.com/utility-services/solr#aliases)
4. When one of the services in the Flex Package starts up, the SolrConnectionValidator will attempt to query Zookeeper and SOLR to ensure that everything has been setup and configured properly.
If any step in the above process fails, the system expectations have not been met and a closer inspection as to why the configurations were not uploaded or aliases created would be needed.
Some common failure reasons may include:
- not providing a big enough Kubernetes cluster to support a large initial resource grab and initialization process.
- misconfiguration of zookeeper and solr so that they are unable to communicate with each other or to other services (e.g. if they are being installed on separate Kubernetes namespaces than the rest of the resources, you need to ensure all the connection strings are properly configured) See https://developer.broadleafcommerce.com/tutorials/devops/deploy-to-cloud#additional_configuration for more details.
Option 2: Manual Setup
If you wish to manually setup this configuration outside the Helm and Kubernetes installation scripts, it is also possible to upconfig the Broadleaf SOLR schemas and create the SOLR aliases yourself.
At this point, it would be good to familiarize yourself with what the solr-config.sh script does in the provided Solr Image Starter Project and follow the same manual steps in your environment. This script makes use of some default Solr command line utilities (included in the default solr image - https://solr.apache.org/guide/8_2/command-line-utilities.html) to perform these initialization steps. In general the steps include:
1. creating the CHROOT in Zookeeper (defaults to /broadleaf/solr)
2. "upconfig" all the broadleaf collections to Zookeeper (i.e. all the configuration for catalog, customer, order, and order fulfillments)
3. create all the aliases for these collections in Solr