lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] Commented: (SOLR-2374) Create UpdateFileRequestHandler
Date Wed, 23 Feb 2011 10:05:38 GMT


Jan Høydahl commented on SOLR-2374:

I raised the question about "correct" Zk usage in this thread
bullet c). The ZK docs says we should only store lightweight config objects in ZK, thus the
1Mb node size limit. So I'm not sure the entire /solr/conf/ folder should just be dumped into
ZK. Dictionaries and other large files could live in something like Voldemort, with only a
reference stored in ZK. That scales, but demands a tool for up/downloading files to Voldemort

I don't have much ZK experience, but perhaps more in the spirit of ZK would be to model the
configs found in solr.xml and solrconfig.xml as a more fine-grained ZK node structure. Imagine
being able to change the mergeFactor by changing the ZK node /solr/collections/collection1/indexDefaults/mergeFactor
to a new value... :) instead of having to download the latest solrconfig.xml, modify it and
re-uploading. Such a strategy again requires tools to import a solrconfig.xml to ZK and exporting
an existing ZK config as XML.

> Create UpdateFileRequestHandler
> -------------------------------
>                 Key: SOLR-2374
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: update
>    Affects Versions: 1.4.1
>            Reporter: Timo Schmidt
>              Labels: config, file, patch, upload
>             Fix For: Next
>         Attachments: UpdateFileRequestHandler.patch, patchV2.diff
>   Original Estimate: 4h
>  Remaining Estimate: 4h
> It would be nice to be able to update files like synonyms.txt and stopwords.txt with
a seperrat request handler. Since i am very new to solr development i've prepared a patch
with a new UpdateFileRequest handler. Maybe it would be good to refactor the existing fileRequestHandler.
> Currently it is implemented that you need to whitelist all files which should be editable.
I think this is better for security reasons.

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message