Page History

...

File Manager clients send product archiving requests to the File Manager (typically running as a local service on default port 9000).
This communication is carried over HTTP through XML-RPC encoded request/response pairs.
As part of the archiving process, the File Manager transforms the available product metadata
(either generated on the client side and sent as part of the archiving request, or generated by metadata extractors on the server side)
into Solr documents, which are sent to the Solr server for indexing. The Solr server must be deployed as an external service, running
within Tomcat (default ports: 80 or 8080) or Jetty (default port: 8983), and configured with a metadata schema that defines
the project specific fields to be indexed. The File Manager sends documents to Solr as payloads of HTTP/POST requests.
Product  Product metadata can be queried either by the standard File Manager clients, but more efficiently by clients that interact directly
with directly with the Solr web services (as Solr is optimized for querying).

In conclusion, in this architecture the OODT File Manager provides the data archiving functionality, while Solr is responsible for
providing metadata querying services.

Release Notes and Limitations

-----------------------------The OODT File Manager is only compatible with a Solr version of 4.X or above - i.e. no support is provided for interacting with pre-existing Solr
installations Solr installations of 3.X or below. The technical motivation is that the Solr implementation of the OODT Catalog interface relies heavily on the
the "atomic update" functionality that was introduced in Solr 4 - i.e. the ability to update single parts of Solr document without the need to re-index the whole
documentwhole document. The logical rationale behind this decision is that this is a new functionality provided to the OODT framework, and consequently there is
no is no need to support legacy deployments: a project that wishes to leverage this architecture might as well start anew with the most up to date version of Solr,
instead  instead of installing an older version.

Furthermore, in order to leverage the out-of-the-box "atomic update" functionality, ALL fields to be indexed must be declared in the Solr schema.xml
with xml with "stored=true". This requirement comes with the price of a larger index, but will allow documents to be updated in place, as opposed to be fully replaced.

CurrentlyFinally, currently, multiple Solr cores are NOT supported: all documents sent by the File Manager are indexed and retrieved from the default Solr core.

...