Re: EmbeddedSolr class from Wiki
Daniel Einspanjer wrote: The example EmbeddedSolr class on the wiki makes use of getUpdateHandler which was added after 1.1 (so it seems to be available only on trunk). I'd really like to move to an embedded Solr sooner rather than later. My questions are: - Would it be easy/possible to work around the lack of getUpdateHandler in 1.1 or would it completely change the implementation of EmbeddedSolr? If you need to update, it will be difficult ;) - How stable is trunk right now? There is nothing we know that is not stable. - Is 1.2 due out soon? Hopefully soon. I hope within a week or two. - Is this approach significantly better than the one roughly outlined in http://www.mail-archive.com/solr-user@lucene.apache.org/msg03137.html? The wiki page gives an example of how you can internally access most things you would need to try. It is a superset of what I suggesed in the email. Check the printDocs(DocList docs) code. Another approach is: https://issues.apache.org/jira/browse/SOLR-212 In this case you don't get access to the lucene Document, you just the the output text without an HTTP connection. Your specific approach will depend on what you need. ryan
Re: EmbeddedSolr class from Wiki
Additional questions regarding EmbeddedSolr (for using the Solr API directly without HTTP): - Can I use separate JVMs for same Directory object? One process will create/update/delete, and another search. - Can I use separate JEE contexts inside same JVM? Looks like "singleton" is a must, but separate "search" should be possible... Thanks, Fuad -- View this message in context: http://www.nabble.com/EmbeddedSolr-class-from-Wiki-tf3659379.html#a10225263 Sent from the Solr - User mailing list archive at Nabble.com.
Re: EmbeddedSolr class from Wiki
: - Can I use separate JVMs for same Directory object? One process will : create/update/delete, and another search. : - Can I use separate JEE contexts inside same JVM? : : Looks like "singleton" is a must, but separate "search" should be : possible... in theory it should work, Solr doens't do any additional locking on top of Lucene, so having multiple Solr instances acting as a reader and a single Solr instance acting as a writer should work (but i've never tried it) you could even have the postCommit hook of your writer trigger a commit call on your readers so they reopen the newly updated index. -Hoss
RE: EmbeddedSolr class from Wiki
:you could even have the postCommit hook of your writer trigger a commit :call on your readers so they reopen the newly updated index. Thanks, I need "separate JVMs" so "writer triggers a commit call on readers" is slightly unclear... I want to use separate applications, webmodule with reader, and standalone writer (it could be webmodule too, but with different JEE context; similar to separate JVMs). As I understand, we need some some kind of trigger refreshing our readers. Probably I can add some code to refresh readers hourly, for instance...
RE: EmbeddedSolr class from Wiki
: :you could even have the postCommit hook of your writer trigger a commit : :call on your readers so they reopen the newly updated index. : : Thanks, I need "separate JVMs" so "writer triggers a commit call on readers" : is slightly unclear... I want to use separate applications, webmodule with : reader, and standalone writer (it could be webmodule too, but with different : JEE context; similar to separate JVMs). postCommit and postOptimize hooks can be subclass of SolrEventListener so you can trigger arbitrary jva code if you want to write your own (use JMS, or make an HTTP call, whatever) the RunExecutableListener that ships with Solr would be the easiest thing to do ... just have it execute the "commit" command line script on your slave (which will make it reopen the index you just modified) -Hoss
RE: EmbeddedSolr class from Wiki
Thank you Hoss, this is exactly what I need! Currently I perform reindexing once a month, and it takes few days... Very slow... Over 2 millions documents (not too much; 300Mb in files), database & SOLR on a same box, and SOLR uses about 60-80% CPU. I will implement real-time updates, via direct Java calls (as soon as data gets changed). About Compass, I noticed some messages. I tried to use it (before SOLR) because of advertised "transactional" Lucene updates; that is not true, and performance was really bad. -Original Message- From: Chris Hostetter postCommit and postOptimize hooks can be subclass of SolrEventListener so you can trigger arbitrary jva code if you want to write your own (use JMS, or make an HTTP call, whatever) the RunExecutableListener that ships with Solr would be the easiest thing to do ... just have it execute the "commit" command line script on your slave (which will make it reopen the index you just modified)