Multicore - Unload / Reload

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

Multicore - Unload / Reload

Andy Olliver-2
Hi
I've been playing with Multicore and MultiCoreHandler, and have got Unload &
Reload working nicely.
This was very little code, since all the basic mechanisms were already in
place.
I'd still need to get multi-core config persistence working to make the
solution complete.
This now gives me a great basis for getting index replication working
nicely in a cross platform manner.
Let me know if patches for this would be handy, and I'll email them
across, with an explanation of what decisions I made on the way.
Is there a std code formatting eclipse config for this project, so that my
diffs look less crazy than they do now?

Andy

Reply | Threaded
Open this post in threaded view
|

Re: Multicore - Unload / Reload

Ryan McKinley
Have you checked the latest patch from SOLR-350?
https://issues.apache.org/jira/browse/SOLR-350

ryan


[hidden email] wrote:

> Hi
> I've been playing with Multicore and MultiCoreHandler, and have got Unload &
> Reload working nicely.
> This was very little code, since all the basic mechanisms were already in
> place.
> I'd still need to get multi-core config persistence working to make the
> solution complete.
> This now gives me a great basis for getting index replication working
> nicely in a cross platform manner.
> Let me know if patches for this would be handy, and I'll email them
> across, with an explanation of what decisions I made on the way.
> Is there a std code formatting eclipse config for this project, so that my
> diffs look less crazy than they do now?
>
> Andy
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Multicore - Unload / Reload

Andy Olliver-2
Yes - I've been watching this issue, and am using latest code from trunk.
Current version of MultiCoreHandler has no support for UNLOAD, and RELOAD
will only reload a currently loaded core.

Andy


> Have you checked the latest patch from SOLR-350?
> https://issues.apache.org/jira/browse/SOLR-350
>
> ryan
>
>
> [hidden email] wrote:
>> Hi
>> I've been playing with Multicore and MultiCoreHandler, and have got
>> Unload &
>> Reload working nicely.
>> This was very little code, since all the basic mechanisms were already
>> in
>> place.
>> I'd still need to get multi-core config persistence working to make the
>> solution complete.
>> This now gives me a great basis for getting index replication working
>> nicely in a cross platform manner.
>> Let me know if patches for this would be handy, and I'll email them
>> across, with an explanation of what decisions I made on the way.
>> Is there a std code formatting eclipse config for this project, so that
>> my
>> diffs look less crazy than they do now?
>>
>> Andy
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Multicore - Unload / Reload

Henrib-2
In reply to this post by Andy Olliver-2
Andy,
Having your code will certainly help.

Regarding patch production, I can only suggest you use either cygwin if on Windows or diff/patch on Unix.
I usually post patches this way:
svn diff --diff-cmd /usr/local/bin/diff -x "-w -B -b -E -d -N -u" > ~/solr-350.patch
Which can be applied with:
/usr/local/bin/patch -u -p 0 < ~/solr-350.patch
Alternatively, you can send me the modified files (from the trunk + latest 350 patch) and I'll produce it (hbiestro at gmail dot com) so we can share it quickly.

Just to better understand, are you saying multicore persistence is not working or just not complete enough (aka reload/unload)?
Henri

Reply | Threaded
Open this post in threaded view
|

Re: Multicore - Unload / Reload

Andy Olliver-2
Henri
I might be missing something here - are some of the patches associated
with SOLR-350 not in trunk yet? I have only be looking at code in trunk.
thanks
Andy

Henrib wrote:

> Andy,
> Having your code will certainly help.
>
> Regarding patch production, I can only suggest you use either cygwin if on
> Windows or diff/patch on Unix.
> I usually post patches this way:
> svn diff --diff-cmd /usr/local/bin/diff -x "-w -B -b -E -d -N -u" >
> ~/solr-350.patch
> Which can be applied with:
> /usr/local/bin/patch -u -p 0 < ~/solr-350.patch
> Alternatively, you can send me the modified files (from the trunk + latest
> 350 patch) and I'll produce it (hbiestro at gmail dot com) so we can share
> it quickly.
>
> Just to better understand, are you saying multicore persistence is not
> working or just not complete enough (aka reload/unload)?
> Henri
>
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: Multicore - Unload / Reload

Henrib-2
Andy,
The code in the trunk is not the latest-greatest functionality wise, it reflects what we believe is stable enough to be made globally available - ie, a strong commitment that the APIs & functionality will not change; to get the latest level of functionality, the current development state, you still need to grab solr-350.patch (http://issues.apache.org/jira/secure/attachment/12374625/solr-350.patch)  and apply it to the latest source trunk.
Only when everything is agreed upon will the solr-350 code be merged in the trunk and the issue solved.
Henri
Reply | Threaded
Open this post in threaded view
|

Re: Multicore - Unload / Reload

Andy Olliver-2
OK - now got trunk + solr-350.patch running nicely.
(There has been a small change to SolrResourceLoader.java since patch
creation - I can post an updated patch for review if I make any successful
changes.)
Out of the methods defined in MultiCoreAction, not all are implemented:

STATUS - works nice
LOAD   - not implemented
UNLOAD - not implemented
RELOAD - works nice
CREATE - works nice
DROP   - not implemented
PERSIST - works nice
SWAP - works nice

Are these all still required?
There is definitely a need for UNLOAD and/or DROP. Is there a conceptual
difference in mind between the 2?

I think UNLOAD just requires:

case UNLOAD: {
            manager.remove(core.getName());
            do_persist = true;
            break;
          }

With CREATE working, is there a need for LOAD?

Andy

>
> Andy,
> The code in the trunk is not the latest-greatest functionality wise, it
> reflects what we believe is stable enough to be made globally available -
> ie, a strong commitment that the APIs & functionality will not change; to
> get the latest level of functionality, the current development state, you
> still need to grab solr-350.patch
> (http://issues.apache.org/jira/secure/attachment/12374625/solr-350.patch)
> and apply it to the latest source trunk.
> Only when everything is agreed upon will the solr-350 code be merged in
> the
> trunk and the issue solved.
> Henri
> --
> View this message in context:
> http://www.nabble.com/Multicore---Unload---Reload-tp15429182p15433433.html
> Sent from the Solr - Dev mailing list archive at Nabble.com.
>
>