solr vs custom JMS for replication?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

solr vs custom JMS for replication?

rhodebump
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?


Reply | Threaded
Open this post in threaded view
|

Re: solr vs custom JMS for replication?

Chris Hostetter-3

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