[jira] Created: (SOLR-255) RemoteSearchable for Solr(use RMI)

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

[jira] Created: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
RemoteSearchable for Solr(use RMI)
----------------------------------

                 Key: SOLR-255
                 URL: https://issues.apache.org/jira/browse/SOLR-255
             Project: Solr
          Issue Type: Improvement
          Components: search
            Reporter: Toru Matsuzawa


I experimentally implemented RemoteSearchable of Lucene for Solr.
I referred to "FederatedSearch" and used RMI.

Two or more Searchers can be referred to with SolrIndexSearcher.
These query-only indexes can be specified in solrconfig.xml,
enumerating the list under a <searchIndex> tag.

  <searchIndex>
    <lst>E:\sample\data1</lst>
    <lst>E:\sample\data2</lst>
    <lst>rmi://localhost</lst>
  </searchIndex>

The index in the dataDir is also used as the default index of solr
to update and query.

When data of a document in a index specified under the <searchIndex> is
updated,
that document data in the index will be deleted and data of the updated document will be stored
in the index in the dataDir.

SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
("-Djava.security.policy" should be set when you start VM. )

Not all of the operational cases are tested
because Solr has so many features.

Moreover, TestUnit has not been made
because I made this through a trial and error process.
Some changes are required in Lucene to execute this.

I need your comments on this although it might be hard without TestUnit.
I especially worry about the followings:
- Am I on the right truck about this issue?
- Is the extent of modifying Lucene tolerable?
- Are there any ideas to implement this feature without modifying Lucene?
- Does this idea contribute for improving Solr?
- This implementation may partially overlap with "Multiple Solr Cores".
  What should be done?
- Are there any other considerations about this issue, which I have overlooked?


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toru Matsuzawa updated SOLR-255:
--------------------------------

    Attachment: solr-multi20070606.zip

I attached the patch for Lucene, the patch for Solr
and solrconfig.xml to execute this.

My response could be very slow because of my poor English ability.

> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504740 ]

Otis Gospodnetic commented on SOLR-255:
---------------------------------------

I took only a very quick look at this and noticed changes are done in Lucene.  Any such changes should be brought up on the java-dev@lucene.... mailing list and posted as a patch in Lucene's JIRA.  You can explain why you need to make those changes.

I didn't take a closer look at your Solr changes, but from your description above, my guess is that this will clash, at least somewhat, with SOLR-215.

Is this what you implemented?
                                                   remote lucene index (not Solr?)
                                                  /
                                               RMI
client -----> solr instance /
                                             \
                                               RMI
                                                  \
                                                   remote lucene index (not Solr?)

Thanks.

> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505078 ]

Toru Matsuzawa commented on SOLR-255:
-------------------------------------

My implementation is as follows.

client --> Solr instance  +/data/index
                                           +/local/other/solr1/data/index
                                           +/local/other/solr2/data/index
                                           +/local/other/solr3/data/index
                                            |
                                           +--- RMI <--- Remote Solr index(/data/index)
                                            |
                                           +--- RMI <--- Remote Solr index(/data/index)

First of all, I'd like to get your comments whether my modification is beneficial for Solr.
If it is helpful, is it possible to implement this changes without modifying Lucene?
I need your comments on this point.(If you have any other ideas for the implementation, please let me know.)

After it becomes clear the necessity of modifying Lucene, I'd like to post it to Lucene's JIRA.

I understand there are some overlaps with SOLR-215.
However, I think this modification can coexist with SOLR-215.

Thank you.



> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506716 ]

Otis Gospodnetic commented on SOLR-255:
---------------------------------------

That looks good.  So with your patch one can search any *one* of those indices, or any *group* of those indices, correct?  In the case where a *group* of indices is searched, do you search them in parallel and merge the results?

I'll add a note about this work to SOLR-215.  It sounds like you and Henri (the author of SOLR-215) really need to work together, otherwise applying both his and your patch will be very difficult.


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507326 ]

Henri Biestro commented on SOLR-255:
------------------------------------

Toru,
I've been looking quickly at your patch and kinda understands why Otis is pushing for a merge. :-)
I dont know how this is usually done; should we merge the 2 issues and merge our patches?
I can try & see how this goes if you want.

One thing that worries me though is the Lucene patch dependency; any way to only have a Solr patch?
I would suspect that Lucene committers are as busy as Solr 's so the review process might take sometime.
Although from far, it does look like pretty harmless changes so there is hope...

As a side note, I was wondering if we could extend you patch's functionality and get read/write capability per index (as in http://hellonline.com/blog/?p=55 ,document indexing load balancing could be performed on hashing unique key % number of indexes for instance or by some configurable class). The current functionality would be retained by specificying 'read-only' versus 'read-write' for each index.

Nice job btw.
Henri


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Mike Klaas
On 22-Jun-07, at 6:53 AM, Henri Biestro (JIRA) wrote:

>
>     [ https://issues.apache.org/jira/browse/SOLR-255?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#action_12507326 ]
>
> Henri Biestro commented on SOLR-255:
> ------------------------------------
>
> Toru,
> I've been looking quickly at your patch and kinda understands why  
> Otis is pushing for a merge. :-)
> I dont know how this is usually done; should we merge the 2 issues  
> and merge our patches?
> I can try & see how this goes if you want.
>
> One thing that worries me though is the Lucene patch dependency;  
> any way to only have a Solr patch?
> I would suspect that Lucene committers are as busy as Solr 's so  
> the review process might take sometime.
> Although from far, it does look like pretty harmless changes so  
> there is hope...
>
> As a side note, I was wondering if we could extend you patch's  
> functionality and get read/write capability per index (as in http://
> hellonline.com/blog/?p=55 ,document indexing load balancing could  
> be performed on hashing unique key % number of indexes for instance  
> or by some configurable class). The current functionality would be  
> retained by specificying 'read-only' versus 'read-write' for each  
> index.

I just wanted to note (in midst of all this talk of merging patches  
and adding functionality), that the larger a patch becomes, the  
harder it is to evaluate and maintain.  It might be better to split  
it up in terms of dependencies: one patch depends on the other.  Or,  
if the core infrastructure is similar/highly dependent, split it up  
into a core patch and outward-facing-feature patch.

-Mike
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Otis Gospodnetic-2
In reply to this post by Tim Allison (Jira)
Yes, I think I mentioned the same thing in one of my comments, I think in SOLR-255.  Smaller ==> easier to understand ==> less potential breakage ==> less risk to commit ==> commit! :)

Otis
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/  -  Tag  -  Search  -  Share

----- Original Message ----
From: Mike Klaas <[hidden email]>
To: [hidden email]
Sent: Saturday, June 23, 2007 1:45:13 AM
Subject: Re: [jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

On 22-Jun-07, at 6:53 AM, Henri Biestro (JIRA) wrote:

>
>     [ https://issues.apache.org/jira/browse/SOLR-255?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#action_12507326 ]
>
> Henri Biestro commented on SOLR-255:
> ------------------------------------
>
> Toru,
> I've been looking quickly at your patch and kinda understands why  
> Otis is pushing for a merge. :-)
> I dont know how this is usually done; should we merge the 2 issues  
> and merge our patches?
> I can try & see how this goes if you want.
>
> One thing that worries me though is the Lucene patch dependency;  
> any way to only have a Solr patch?
> I would suspect that Lucene committers are as busy as Solr 's so  
> the review process might take sometime.
> Although from far, it does look like pretty harmless changes so  
> there is hope...
>
> As a side note, I was wondering if we could extend you patch's  
> functionality and get read/write capability per index (as in http://
> hellonline.com/blog/?p=55 ,document indexing load balancing could  
> be performed on hashing unique key % number of indexes for instance  
> or by some configurable class). The current functionality would be  
> retained by specificying 'read-only' versus 'read-write' for each  
> index.

I just wanted to note (in midst of all this talk of merging patches  
and adding functionality), that the larger a patch becomes, the  
harder it is to evaluate and maintain.  It might be better to split  
it up in terms of dependencies: one patch depends on the other.  Or,  
if the core infrastructure is similar/highly dependent, split it up  
into a core patch and outward-facing-feature patch.

-Mike



Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508380 ]

Toru Matsuzawa commented on SOLR-255:
-------------------------------------

Hi Otis & Henri,

Otis Gospodnetic wrote:
> So with your patch one can search any *one* of those indices,
> or any *group* of those indices,
> correct?  In the case where a *group* of indices is searched,
> do you search them in parallel and merge the results?

With my patch one can search a group of these indeces.
Each index in the group is searched in sequence,
and then each result is merged.

Henri Biestro wrote:
> I've been looking quickly at your patch and
> kinda understands why Otis is pushing for a merge. :-)
> I dont know how this is usually done;
> should we merge the 2 issues and merge our patches?
> I can try & see how this goes if you want.

I inspected the patch of SOLR-215.
The overlaps between SOLR-215 and SOLR255 are
in the constructor of SolrIndexSearcher and SolrCore.
Each modification should be committed sequentially.
After that, there are not many additional modifications.

The commitment should be done through some stages.
(It might be acceptable Step1 and Step2 is in reverse order. Or, simultaneous? )
Step1) MultiCore (SOLR-215)
Step2) The functionality of MultiSearcher, exclude modification of RMI and Lucene.
       (SolrMultiSearcher and SolrIndexSearchable)
Step3) The modification of Lucene
Step4) The functional addition to the RMI (SolrRemoteSearcher)
       (When it becomes MultiCore, additional modification, in which
        the remote object of RMI should be created dynamically, will be needed.)

> One thing that worries me though is the Lucene patch dependency;
> any way to only have a Solr patch?
> I would suspect that Lucene committers are as busy as Solr 's
> so the review process might take sometime.
> Although from far, it does look like pretty harmless changes so there is hope...

The RMI (SolrRemoteSearcher) causes the Lucene patch dependency.
There will be no impact on SOLR-215 by the above-mentioned procedure.

> As a side note, I was wondering if we could extend
> you patch's functionality and get read/write capability per index
> (as in http://hellonline.com/blog/?p=55 ,
> document indexing load balancing could be performed
> on hashing unique key % number of indexes for instance
> or by some configurable class).
> The current functionality would be retained
> by specificying 'read-only' versus 'read-write' for each index.

I also have ideas about this but those are not concrete enough.
Anyway, that will be done through Step5 and later.

Thanks.


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508385 ]

Yonik Seeley commented on SOLR-255:
-----------------------------------

Toru, could you give an overview of how this solution works, what data is passed over the network, and how well you think it scales?  What is done on the shards, and what is done on the "combiner" to sort hits by a certain field?  to facet by a certain field?  Some of the methods on SolrSearchable make me nervous about scalability (like getInts(field), getFloats(field)) but it's not easy to tell if/when those are used.



> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508394 ]

Yonik Seeley commented on SOLR-255:
-----------------------------------

A few other considerations for good scalability:
 - shards should be searched in parallel
 - there needs to be multiple copies of each shard (esp for HA), with failover, otherwise splitting and distributing the index will lead to higher failure rates.


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510631 ]

Toru Matsuzawa commented on SOLR-255:
-------------------------------------

Hi Yonik,

SolrMultiSearcher execute searches in each index file.
Index files to be searched is as follows:
 - /data/index (default index files, read/write)
 - local index files (read only)
 - remote index files through RMI (read only)

SolrIndexSearchable performs searches in local indexes,
which originally SolrIndexSearcher performs.
SolrClientSearchable is executed as the wrapper instance
which gets a RMI object and performs searches

In SolrMultiSearcher, SolrFieldSortedHitQueue merged search results
from all searched indexes.
(FieldSortedHitQueue cannot use here
because it requires using FieldCache.)

When RMI is valid, the following data are transferred through the network.
1) Weight, DocSet, Sort and so on, for search requests to remote indexes
2) DocListAndSet , DocList or DocSet as these search results
3) FieldCache of each field from remote indexes

With getInts(field), getFloats(field) and so on,
SolrMultiSearcher merges all these data,
which SolrIndexSearchable or SolrClientSearchable for each index gets
with getInts(field), getFloats(field) and so on.
There will be certain problems on scalability unless something should be done for this point.(Please teach if there is something a good idea. )

Each index is searched sequentially in my present implementation.
This process should be in parallel in future implementation. (It must be hard to implement.)

My implementation is mainly in order to search indexes on remote nodes through RMI.
Without RMI (i.e., local index searches only), my implementation can be more simple.
(I have originally implemented this for its remote index use in my project.
 However, I use Solr with local indexes only because of complex operations of remote index version.)

Thanks,

> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510637 ]

Sharad Agarwal commented on SOLR-255:
-------------------------------------

Toru, Along with the query processing, RequestHandlers also add more info to response, like 'highlighting' and 'moreLikeThis' information. I am not clear how this get accomplished in the distributed environment?

Collecting Highlighting info for all top N records from all shards could be quite expensive. How about first combining the results from shards and then gathering Highlighting info?


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toru Matsuzawa updated SOLR-255:
--------------------------------

    Attachment: solr-multi20070724..zip

Pache Updated.

The following changes.
1) Addition of easy TestUnit.
2) search for shards in parallel.
3) Cash(like FieldCache) is added to getInts(filed),getStringIndex(filed) etc.
4) Bug fix of "sort asc".

Standalone/solr-multi20070724-NoRMI.patch is a patch for local index searches only.
Please use the patch of RMI/lucene4solr-multi.patch and RMI/solr-multi20070724.patch when you use RMI.
(lucene4solr-multi.patch is patch for lucene. )


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Issue Comment Edited: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516107 ]

Stu Hood edited comment on SOLR-255 at 7/27/07 3:17 PM:
--------------------------------------------------------

Everyone working on this patch should check out
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/search/ParallelMultiSearcher.html
and make sure no work is being duplicated. My company is using 'ParallelMultiSearcher' in a production environment with great success, so I wanted to make sure it is on everyone's radar.

Thanks!


 was:
Everyone working on this patch should check out
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/search/ParallelMultiSearcher.html
and make sure no work is being duplicated. My company is using 'ParallelMultiSearcher' in a production environment with great success, so I wanted to make it is on everyone's radar.

Thanks!

> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

    [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516107 ]

Stu Hood commented on SOLR-255:
-------------------------------

Everyone working on this patch should check out
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/search/ParallelMultiSearcher.html
and make sure no work is being duplicated. My company is using 'ParallelMultiSearcher' in a production environment with great success, so I wanted to make it is on everyone's radar.

Thanks!

> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>         Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Otis Gospodnetic updated SOLR-255:
----------------------------------

    Assignee: Otis Gospodnetic

I re-read all the comments here and from what I understand, this patch doesn't really add anything that SOLR-303 hasn't already given us.

Is that correct?  If that's correct, I'll close this issue.


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>            Assignee: Otis Gospodnetic
>         Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Resolved: (SOLR-255) RemoteSearchable for Solr(use RMI)

Tim Allison (Jira)
In reply to this post by Tim Allison (Jira)

     [ https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Otis Gospodnetic resolved SOLR-255.
-----------------------------------

    Resolution: Won't Fix

One month no follow-up makes me think there is no real interest in this any more, now that we have Distributed Search functionality.  If there is still something of value in this issue/patch, we can reopen.


> RemoteSearchable for Solr(use RMI)
> ----------------------------------
>
>                 Key: SOLR-255
>                 URL: https://issues.apache.org/jira/browse/SOLR-255
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Toru Matsuzawa
>            Assignee: Otis Gospodnetic
>         Attachments: solr-multi20070606.zip, solr-multi20070724..zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a <searchIndex> tag.
>   <searchIndex>
>     <lst>E:\sample\data1</lst>
>     <lst>E:\sample\data2</lst>
>     <lst>rmi://localhost</lst>
>   </searchIndex>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the <searchIndex> is
> updated,
> that document data in the index will be deleted and data of the updated document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from SolrCore
> by specifying "< remoteSearcher>true</remoteSearcher >" in solrconfig.xml.(It is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
>   What should be done?
> - Are there any other considerations about this issue, which I have overlooked?

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.