EmbeddedSolr class from Wiki

[Daniel Einspanjer <de...@gmail.com>]

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?
   - How stable is trunk right now?
   - Is 1.2 due out soon?
   - Is this approach significantly better than the one roughly outlined
   in
   http://www.mail-archive.com/solr-user@lucene.apache.org/msg03137.html?

Re: EmbeddedSolr class from Wiki

[Ryan McKinley <ry...@gmail.com>]

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

[Fuad Efendi <fu...@efendi.ca>]

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)

RE: EmbeddedSolr class from Wiki

[Chris Hostetter <ho...@fucit.org>]

: :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

[Fuad Efendi <fu...@efendi.ca>]

: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

[Chris Hostetter <ho...@fucit.org>]

: - 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

[Fuad Efendi <fu...@rbc.com>]

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.