if your primary motivation for whating to use Solr is the replication of index data vs JMS messages and seperate INdexWriters on each node, you may just want to use the Solr replication scripts -- they should work with any Lucene index regardless of wether or not you are using SOlr, you just need to make sure you use them with the same semantics (ie: run snapshooter after closing the IndexWriter on your master, reopen the INdexReaders on your slaves after runing snapinstaller, etc...)
: Hi everyone, : I have a open source app under development called "authsum" which is a sso/identity/authorization server that supports user registration, openid,sso. It's a "search engine for authorizations" because the authorizations are stored in a lucene index accessible via xfire. There will be a dotnet and ruby client. http://www.authsum.org/overview/index.html : : I am using JMS to keep my lucene indexes in sync. : : My applications (admin application,registration,login applications) publish messages (i.e. userid, group addition, etc) onto a JMS topic. : There are other running applications that subscribes to the topic and processes the index changes. : : I am trying to "cut down" on the engineering and was wondering if solr would be a better fit for my needs. : : As I see it, my custom JMS solution means that there are potentially many IndexWriters out there (and more processing) since the same processing work needs to be performed on all indexes. This could also be a problem since there is more of a possibility that indexes could get out of sync with one another. For these reasons, I am thinking that solr would be better for me than JMS. : : The drawbacks: : 1) I would need to write my application to post xml documents to lucene vs. my lucene programming that I do now. : 2) Do I have direct access to the lucene index to do queries? Or do I need to rewrite my app for that also? : : -Hoss
