Guest Blog Post: Solr in a multi-instance setup

This post is more than 2 years old.

Michael Dawson sent this to me and asked if I could help let others know. I rarely use multi-instances myself so I haven't run into this, but hopefully this will help others. (And if Michael is wrong, let us know!)

From Michael:

This is just an observation that you might already know, but it may be worth blogging about since your site usually tops the list in search engine results.

I have two CF 10 instances running on a Windows 2008 (IIS) web server. I have confirmed the two instances are separate.

I created a Solr collection in "one" of the CF instances. However, the collection appears in "both" of the CF instances.

I originally wanted to refer to one collection name, "maincontent", when moving from test to production, however, this doesn't appear possible without installing separate instances of the Solr engine.

That was too much work, so my workaround was to prepend the instance name to the name of the collection: wwwdevmaincontent, for example.

There is very little documentation about this particular issue other than one page I found that suggested installing multiple instances of Solr and using its web services.

I hope this can be helpful to you.

Raymond Camden's Picture

About Raymond Camden

Raymond is a senior developer evangelist for Adobe. He focuses on document services, JavaScript, and enterprise cat demos. If you like this article, please consider visiting my Amazon Wishlist or donating via PayPal to show your support. You can even buy me a coffee!

Lafayette, LA

Archived Comments

Comment 1 by Tom Jenkins posted on 7/18/2012 at 3:04 PM

Hi Ray

I can confirm this is correct and certainly in our server setup, is the correct way to work.

We have a clustered multi instance server, with 3 instances all set to round robin each request (with sticky sessions). Because of this, each instance would need to access a certain applications SOLR collection when required, so of course it would need to be setup on each instances for this to happen.

Setting it up in literally one place and having it automatically add it to each instance is a time saving ... something I wish would be an option when setting up datasources, as to get around this, we had to write a custom admin menu option to allow adding a datasource to each instance, instead of logging in manually each time.

Tom Jenkins

Comment 2 by Michael Dawson posted on 7/18/2012 at 7:35 PM

Tom, thanks for confirming this. Since many people use load-balancing systems, it makes sense to share a repository. Also, since CFINDEX/CFSEARCH allow me to specify an dynamically-named collection, my solution works just fine. I can live with this without feeling icky about it.


Comment 3 by JC posted on 7/24/2012 at 5:16 PM

Doesn't seem too terrible for SOLR, unless of course you're running a shared hosting environment. Can you at least restrict access to the individual repositories through CFAdmin or something? (I haven't worked with SOLR yet, just Verity).

If DSNs acted like that as Tom would like, good god, what a mess. Security headache! You can always export your DSNs to a .car and import them to another CF instance if you don't want to bother setting them up manually. Or, as Tom did, write a script to do it. I suppose it might be a nice addition to the master CF instance (Copy DSN between instances/deploy DSNs to instances/etc), but I wouldn't want to see it in any of the other ones, and certainly not by default.