[jira] Resolved: (SOLR-171) Add per-doc and per-field boosts
[ https://issues.apache.org/jira/browse/SOLR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-171. --- Resolution: Fixed Assignee: Erik Hatcher Applied, thanks again Coda! > Add per-doc and per-field boosts > > > Key: SOLR-171 > URL: https://issues.apache.org/jira/browse/SOLR-171 > Project: Solr > Issue Type: Improvement > Components: clients - ruby - flare >Reporter: Coda Hale > Assigned To: Erik Hatcher > Attachments: solr-boosts.diff > > > Adding a patch to provide optional per-field and per-document boosts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-182) register SolrRequestHandlers at runtime / lazy loading
[ https://issues.apache.org/jira/browse/SOLR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-182: --- Attachment: SOLR-182-RuntimeRequestHandlers.patch This update loads handlers in the style suggested by Hoss. It makes sure everything is instanciated and registered before calling init() on any handlres registered in solrconfig.xml It calls init() on handlers in the order they were defined. The only open issue is if SolrCore.getRequestHandler() should be synchronized. I can't think of any potential problems if it isn't but i could be missing something. I'll let whoever commits this decide if it should be synchronized or not. > register SolrRequestHandlers at runtime / lazy loading > -- > > Key: SOLR-182 > URL: https://issues.apache.org/jira/browse/SOLR-182 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 1.2 > > Attachments: SOLR-182-RuntimeRequestHandlers.patch, > SOLR-182-RuntimeRequestHandlers.patch, SOLR-182-RuntimeRequestHandlers.patch, > SOLR-182-RuntimeRequestHandlers.patch > > > It would be useful to be able to register handlers after SolrCore has been > initialized initialized. It is also useful to be able to ask what handlers > are registered and to where. This patch adds the following functions to > SolrCore: > SolrRequestHandler registerRequestHandler(String handlerName, > SolrRequestHandler handler); > Collection getRequestHandlers(Class SolrRequestHandler> clazz); > It also guarantees that request handlers will be initialized with an argument > saying what path it is registered to. RequestHandlerBase gets a bean for the > registered path. > While discussing this, Yonik suggested making it possible to defer > initialization of some handlers that will be infrequently used. I added the > 'LazyRequestHandlerWrapper' (if taking this out makes the patch any easier > to commit - it can get its own issue) > check: > http://www.nabble.com/Dynamic-RequestHandler-loading-tf3351707.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: /update performance testing
Nothing that I know of, but I've been considering writing a python script to hammer Solr with multiple threads to check for concurrency issues. Something to check for performance would be nice as well. -Yonik On 3/6/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: does anyone have performance testing scripts for /update? The three key things i'd like to test are: * SOLR-139, i'd like to make sure using the IndexDocumentCommand (without modifying the existing document) is equivalent to what we have. * /update as servlet vs /update/xml as filter -- *should* be the same * most importantly, SOLR-133 - i've been using StAX in a bunch of custom handlers - its much easier then XPP and purports to be equally fast. we should make sure. Any pointers would be great. It would be nice to have a performance test in /trunk that adds a ton of files and spits back timing info. thanks ryan
/update performance testing
does anyone have performance testing scripts for /update? The three key things i'd like to test are: * SOLR-139, i'd like to make sure using the IndexDocumentCommand (without modifying the existing document) is equivalent to what we have. * /update as servlet vs /update/xml as filter -- *should* be the same * most importantly, SOLR-133 - i've been using StAX in a bunch of custom handlers - its much easier then XPP and purports to be equally fast. we should make sure. Any pointers would be great. It would be nice to have a performance test in /trunk that adds a ton of files and spits back timing info. thanks ryan
[jira] Updated: (SOLR-188) bin scripts do not support non-default webapp names
[
https://issues.apache.org/jira/browse/SOLR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Rodenburg updated SOLR-188:
Attachment: scripts_url.patch
This patch updates the following scripts:
abc
abo
commit
optimize
readercycle
The primary addition to these files is the "-U" parameter, which accepts a full
url path to the update url. When included, the -U parameter overrides the -h
(hostname), -p (port) and -w (webapp) parameters.
In addition, the -w (webapp) parameter has been incorporated into the script as
well (wasn't previously). Default values of hostname=localhost and webapp=solr
are used.
> bin scripts do not support non-default webapp names
> ---
>
> Key: SOLR-188
> URL: https://issues.apache.org/jira/browse/SOLR-188
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.1.0, 1.2
> Environment: Unix/Linux operating systems
>Reporter: Jeff Rodenburg
> Fix For: 1.1.0, 1.2
>
> Attachments: scripts_url.patch
>
>
> If the solr web application has been configured in a non-default location,
> i.e. http://localhost:8080/solrapp2/, the operation scripts under
> http://localhost:8080/solrapp2/bin/ will fail. The current logic assumes the
> location to be {hostname}:{port}/solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-188) bin scripts do not support non-default webapp names
bin scripts do not support non-default webapp names
---
Key: SOLR-188
URL: https://issues.apache.org/jira/browse/SOLR-188
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.1.0, 1.2
Environment: Unix/Linux operating systems
Reporter: Jeff Rodenburg
Fix For: 1.1.0, 1.2
If the solr web application has been configured in a non-default location, i.e.
http://localhost:8080/solrapp2/, the operation scripts under
http://localhost:8080/solrapp2/bin/ will fail. The current logic assumes the
location to be {hostname}:{port}/solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-183:
---
Attachment: SOLR-183-required-param.patch
This adds a RequiredSolrParams class that wraps most of the getXXX() functions
and makes sure the value exists and is valid.
the case Hoss mentioned:
Integer bar = required.getInt( "yak", null );
isn't possible since getInt() takes an 'int' not an Integer as the default
I put the class in "org.apache.solr.util" rather then "org.apache.solr.request"
- I'm really hoping with SOLR-135 most of the general non-lucene based helper
classes can be in "util"
You'll notice some of the code style is a little non-standard - that helps my
dyslexic head keep stuff straight (at least sometimes).
Yonik - there are no extra hash lookups with this.
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch,
> SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-182) register SolrRequestHandlers at runtime / lazy loading
[ https://issues.apache.org/jira/browse/SOLR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478571 ] Ryan McKinley commented on SOLR-182: #2, smart! yes > register SolrRequestHandlers at runtime / lazy loading > -- > > Key: SOLR-182 > URL: https://issues.apache.org/jira/browse/SOLR-182 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 1.2 > > Attachments: SOLR-182-RuntimeRequestHandlers.patch, > SOLR-182-RuntimeRequestHandlers.patch, SOLR-182-RuntimeRequestHandlers.patch > > > It would be useful to be able to register handlers after SolrCore has been > initialized initialized. It is also useful to be able to ask what handlers > are registered and to where. This patch adds the following functions to > SolrCore: > SolrRequestHandler registerRequestHandler(String handlerName, > SolrRequestHandler handler); > Collection getRequestHandlers(Class SolrRequestHandler> clazz); > It also guarantees that request handlers will be initialized with an argument > saying what path it is registered to. RequestHandlerBase gets a bean for the > registered path. > While discussing this, Yonik suggested making it possible to defer > initialization of some handlers that will be infrequently used. I added the > 'LazyRequestHandlerWrapper' (if taking this out makes the patch any easier > to commit - it can get its own issue) > check: > http://www.nabble.com/Dynamic-RequestHandler-loading-tf3351707.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-182) register SolrRequestHandlers at runtime / lazy loading
[
https://issues.apache.org/jira/browse/SOLR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478561
]
Hoss Man commented on SOLR-182:
---
two outstanding questions from the email discussion...
1) yonik seemed to be concerned about synchronization issues involved with
geting a request handler by name now that they can be registered dynamicly on
the fly ... flarify that.
2) if we want request handlers to be able to find out what nam(es) they are
registered with (now that anyone can call core.registerRequestHandler I might
give the exact same identicle instance multiple names) they should be able to
do that from the init method ... since we aren't changing the API of the init
method, we should probably make sure that registering a handler causes...
handler = clazz.newInstance();
this.register( name, handler );
handler.init( args );
...to happen in that order.
i would even argue that when registering multiple handlers (ie: from the
config) we may want the psuedocode to be...
foreach (handlerconfig) {
handler = clazz.newInstance();
this.register( name, handler );
}
foreach (key in registry) {
lookup(key).init( args );
}
...so that all handlernames are defined before any init methods are called.
> register SolrRequestHandlers at runtime / lazy loading
> --
>
> Key: SOLR-182
> URL: https://issues.apache.org/jira/browse/SOLR-182
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
> Fix For: 1.2
>
> Attachments: SOLR-182-RuntimeRequestHandlers.patch,
> SOLR-182-RuntimeRequestHandlers.patch, SOLR-182-RuntimeRequestHandlers.patch
>
>
> It would be useful to be able to register handlers after SolrCore has been
> initialized initialized. It is also useful to be able to ask what handlers
> are registered and to where. This patch adds the following functions to
> SolrCore:
> SolrRequestHandler registerRequestHandler(String handlerName,
> SolrRequestHandler handler);
> Collection getRequestHandlers(Class SolrRequestHandler> clazz);
> It also guarantees that request handlers will be initialized with an argument
> saying what path it is registered to. RequestHandlerBase gets a bean for the
> registered path.
> While discussing this, Yonik suggested making it possible to defer
> initialization of some handlers that will be infrequently used. I added the
> 'LazyRequestHandlerWrapper' (if taking this out makes the patch any easier
> to commit - it can get its own issue)
> check:
> http://www.nabble.com/Dynamic-RequestHandler-loading-tf3351707.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478556
]
Yonik Seeley commented on SOLR-183:
---
I like anything that can avoid yet another hash lookup in the common cases.
I think either the original getRequired() or the separate "SolrParams
required" could fit the bill.
The latter is more powerful since it applies to all get methods, but it's also
more awkward as you need to construct it wherever you need to get a required
param.
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478552
]
Ryan McKinley commented on SOLR-183:
I'm getting into it now... the easiest is to throw a 400 exception for
everyting. the SolrParams abstract class calls get( '' ) for each of the getX(
name, devault ) - so, we would have to overwrite all the getX functions rather
then just the one. If we do that, we may as well catch the 'parse exception'
from Integer.parseInt() and send a 400 rather then a 500 w/ stack trace.
That is cleaner from user standpoint, so it must be the better option.
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478548
]
Hoss Man commented on SOLR-183:
---
i see no reason why it shouldn't be "equivolent to myParams.getInt( "yak", 100
);" ... here's the interesting case...
Integer bar = required.getInt( "yak", null );
...in that case, i think there should be an exception unless "yak" exists.
the contract would be sumarized as "no method will ever return null, under any
circumstances"
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-182) register SolrRequestHandlers at runtime / lazy loading
[ https://issues.apache.org/jira/browse/SOLR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-182: --- Attachment: SOLR-182-RuntimeRequestHandlers.patch Updated in response to Hoss' comments: http://www.nabble.com/Re%3A-Dynamic-RequestHandler-loading-p9337978.html 1. gets rid of the get by class thing 2. adds Map<> getRequestHandlers() 3. gets rid of the extra param to init() > register SolrRequestHandlers at runtime / lazy loading > -- > > Key: SOLR-182 > URL: https://issues.apache.org/jira/browse/SOLR-182 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley > Fix For: 1.2 > > Attachments: SOLR-182-RuntimeRequestHandlers.patch, > SOLR-182-RuntimeRequestHandlers.patch, SOLR-182-RuntimeRequestHandlers.patch > > > It would be useful to be able to register handlers after SolrCore has been > initialized initialized. It is also useful to be able to ask what handlers > are registered and to where. This patch adds the following functions to > SolrCore: > SolrRequestHandler registerRequestHandler(String handlerName, > SolrRequestHandler handler); > Collection getRequestHandlers(Class SolrRequestHandler> clazz); > It also guarantees that request handlers will be initialized with an argument > saying what path it is registered to. RequestHandlerBase gets a bean for the > registered path. > While discussing this, Yonik suggested making it possible to defer > initialization of some handlers that will be infrequently used. I added the > 'LazyRequestHandlerWrapper' (if taking this out makes the patch any easier > to commit - it can get its own issue) > check: > http://www.nabble.com/Dynamic-RequestHandler-loading-tf3351707.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478525
]
Ryan McKinley commented on SOLR-183:
yes, this is better.
but what should happen with
Integer bar = required.getInt( "yak", 100 );
* treat it as required.getInt() that will throw 400 if missing?
* equivolent to myParams.getInt( "yak", 100 );?
* unsuported operation? no.
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478523
]
Hoss Man commented on SOLR-183:
---
yeha ... the one thing about an approach like this that i'm not sure how i feel
about yet is that it pushes the list of things that should be required away
from where they are actually used (at the moment of construction)
another approach that might cleaner would be to eliminate the explicit list of
required fields, and say that if you use the decorator *every* param is
required unless a default is specified, and then each time you ask for a
param's value, you can use the orriginal params instance if it's not required,
or the decorated params if it is...
SolrParams myParams = ...;
SolrParams required = new RequiredSolrParams(myParams);
...
Integer foo = myParams.getInt("yak"); ... not required, may be null
...
Integer bar = required.getInt("yak"); ... required in this use, exception if
missing
...
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-186) webapp_name not used in optimize and commit scripts
[
https://issues.apache.org/jira/browse/SOLR-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-186.
---
Resolution: Duplicate
> webapp_name not used in optimize and commit scripts
> ---
>
> Key: SOLR-186
> URL: https://issues.apache.org/jira/browse/SOLR-186
> Project: Solr
> Issue Type: Bug
> Environment: *nix
>Reporter: galo
>Priority: Trivial
>
> Both scripts should use the webapp_name variable to send the relevant request
> commit 102: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
> ""`
> optimize 101: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
> ""`
> should be
> commit 102: rs=`curl
> http://${solr_hostname}:${solr_port}/${webapp_name}/update -s -d ""`
> optimize 101: rs=`curl
> http://${solr_hostname}:${solr_port}/${webapp_name}/update -s -d
> ""`
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478517
]
Ryan McKinley commented on SOLR-183:
I've been using it as a check just before you use the variable:
String key = params.getRequiredParam( 'key' );
This is nice and simple, the advantage to your suggestion is that you could use
it to check non-string values:
SolrParams required = new RequiredSolrParams( params, "size", "debug" );
int size = required.getInt( "size" );
boolean debug = required.getBool( "debug" );
String other = required.get( "somethingelse", "defaultValue" );
I guess simple things might not be as simple as they seem!
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-187) abc, abo, commit, optimize, and readercycle scripts have erroneous curl statements for multi-instance environments
abc, abo, commit, optimize, and readercycle scripts have erroneous curl
statements for multi-instance environments
---
Key: SOLR-187
URL: https://issues.apache.org/jira/browse/SOLR-187
Project: Solr
Issue Type: Bug
Components: replication
Environment: Gentoo, Solr 1.1
Reporter: Graham Stead
Priority: Minor
The current curl statements look like this:
abc: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
abo: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
commit: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
optimize: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
readercycle: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
To ensure correct operation in multi-instance environments, replace /solr/ with
/${webapp_name}/ like this:
abc: rs=`curl http://${solr_hostname}:${solr_port}/${webapp_name}/update -s -d
""`
abo: rs=`curl http://${solr_hostname}:${solr_port}/${webapp_name}/update -s -d
""`
commit: rs=`curl http://${solr_hostname}:${solr_port}/${webapp_name}/update -s
-d ""`
optimize: rs=`curl http://${solr_hostname}:${solr_port}/${webapp_name}/update
-s -d ""`
readercycle: rs=`curl
http://${solr_hostname}:${solr_port}/${webapp_name}/update -s -d ""`
I use the modified scripts in environments with 3 Solr instances and have no
problems.
This bug does not affect single instances running with the default path, only
multiple instances with different paths.
best regards,
-Graham
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-186) webapp_name not used in optimize and commit scripts
webapp_name not used in optimize and commit scripts
---
Key: SOLR-186
URL: https://issues.apache.org/jira/browse/SOLR-186
Project: Solr
Issue Type: Bug
Environment: *nix
Reporter: galo
Priority: Trivial
Both scripts should use the webapp_name variable to send the relevant request
commit 102: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
optimize 101: rs=`curl http://${solr_hostname}:${solr_port}/solr/update -s -d
""`
should be
commit 102: rs=`curl http://${solr_hostname}:${solr_port}/${webapp_name}/update
-s -d ""`
optimize 101: rs=`curl
http://${solr_hostname}:${solr_port}/${webapp_name}/update -s -d ""`
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478508
]
Hoss Man commented on SOLR-183:
---
Ryan: this patch is nice and simple ... but it has me wondering if it might be
more generally usefull to have this in a SolrParams decorator that applied it
at the outermost level to all of the methods which don't take in a default? ...
SolrParams myParams = ...
myParams = new RequiredSolrParams(myParams, "sort", "q", "qf",
"f.foo.facet.limit");
...
public class RequiredSolrParams extends SolrParams {
...
SolrParams nested;
Set required;
...
public String get(String param) {
String val = nester.get(param);
if (null == val) throw new SolrException( 400, "Missing parameter:
"+param );
return val;
}
...
public String get(String param, String def) {
return nested.get(param, def); // bypass exception throwing when default
}
...
}
?
> add getRequiredParameter() to SolrParams
>
>
> Key: SOLR-183
> URL: https://issues.apache.org/jira/browse/SOLR-183
> Project: Solr
> Issue Type: Wish
>Reporter: Ryan McKinley
>Priority: Trivial
> Attachments: SOLR-183-required-param.patch
>
>
> I find myself including this with every patch, so i'll just separate it out.
> This simply adds a utilty function to SolrParams that throws a 400 if the
> parameter is missing:
> /** returns the value of the param, or throws a 400 exception if missing */
> public String getRequiredParameter(String param) throws SolrException {
> String val = get(param);
> if( val == null ) {
> throw new SolrException( 400, "Missing parameter: "+param );
> }
> return val;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-133) change XmlUpdateRequestHandler to use StAX instead of XPP
[ https://issues.apache.org/jira/browse/SOLR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-133: --- Attachment: SOLR-133-XmlUpdateRequestHandler-StAX-139.patch updated to work with most recent SOLR-139 > change XmlUpdateRequestHandler to use StAX instead of XPP > - > > Key: SOLR-133 > URL: https://issues.apache.org/jira/browse/SOLR-133 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man > Attachments: SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, SOLR-133.diff, SOLR-133.diff > > > there has been discussion of using StAX for XML parsing of updates instead of > XPP ... opening an issue to track it as a possible improvement (orriginally > mentioned in SOLR-61, but that task was more specificly about refactoring the > existing code) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
patches patches and more patches
In an effort to make the serious patches touch fewer files focus on the central issues, i extracted some required small bits into their own bite sized issues. These are quite simple and (I hope) are generally usefull SOLR-183-required-param.patch SOLR-184-EchoHandler.patch SOLR-185-RequestHandlerUtils.patch Another one that does not need much review is: SOLR-172-uniqueKey-NPE.patch thanks! ryan
[jira] Created: (SOLR-185) RequestHandlerUtils - helpers for commit, optimize, and format warnings
RequestHandlerUtils - helpers for commit, optimize, and format warnings --- Key: SOLR-185 URL: https://issues.apache.org/jira/browse/SOLR-185 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Trivial Attachments: SOLR-185-RequestHandlerUtils.patch Add a helper class to let RequestHandlers share some common code. This patch adds support for 1. standard 'Experimental' format warning 2. getCharsetFromContentType() 3. handler parameters ?commit,optimize,waitFlush,waitSearcher - this change makes the CommitRequestHandler unnecessary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-185) RequestHandlerUtils - helpers for commit, optimize, and format warnings
[ https://issues.apache.org/jira/browse/SOLR-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-185: --- Attachment: SOLR-185-RequestHandlerUtils.patch > RequestHandlerUtils - helpers for commit, optimize, and format warnings > --- > > Key: SOLR-185 > URL: https://issues.apache.org/jira/browse/SOLR-185 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Trivial > Attachments: SOLR-185-RequestHandlerUtils.patch > > > Add a helper class to let RequestHandlers share some common code. This patch > adds support for > 1. standard 'Experimental' format warning > 2. getCharsetFromContentType() > 3. handler parameters ?commit,optimize,waitFlush,waitSearcher > - this change makes the CommitRequestHandler unnecessary -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-139: --- Attachment: SOLR-139-IndexDocumentCommand.patch An updated and cleaned up versoin. The big change is to the SolrDocument interface - rather then expose Maps directly, it hides them in an interface: http://solrstuff.org/svn/solrj/src/org/apache/solr/util/SolrDocument.java Still needs some test cases > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley > Attachments: SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-XmlUpdater.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-81) Add Query Spellchecker functionality
[ https://issues.apache.org/jira/browse/SOLR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478302 ] Adam Hiatt commented on SOLR-81: BTW updated patch added. > Add Query Spellchecker functionality > > > Key: SOLR-81 > URL: https://issues.apache.org/jira/browse/SOLR-81 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-81-edgengram-ngram.patch, > SOLR-81-ngram-schema.patch, SOLR-81-ngram.patch, SOLR-81-ngram.patch, > SOLR-81-ngram.patch, SOLR-81-ngram.patch, SOLR-81-spellchecker.patch, > SOLR-81-spellchecker.patch > > > Use the simple approach of n-gramming outside of Solr and indexing n-gram > documents. For example: > > lettuce > let > let ett ttu tuc uce > uce > lett > lett ettu ttuc tuce > tuce > > See: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html > Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-81) Add Query Spellchecker functionality
[ https://issues.apache.org/jira/browse/SOLR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hiatt updated SOLR-81: --- Attachment: SOLR-81-spellchecker.patch Good call on the DEFAULT_ACCURACY constant. BTW it should probably be .5. As for: > The SpellCheckerCommitRequestHandler assumes that: > a) one wants to populate the spellchecker index with data from another > Lucene index. > b) the Lucene index to be used for populating is available on the same box > where the spellchecker service is running. This does not necessarily have to be true (well a. sort of has to be true). The way I've been testing this is to make my primary index an index of search terms + related metadata. The SpellChecker simply creates a separate index for the pieces it needs to do its work. In essence this is a standalone spellchecker. However, as you note, this same setup allows for the primary index to be any field. Can you see a downside to this approach? > Add Query Spellchecker functionality > > > Key: SOLR-81 > URL: https://issues.apache.org/jira/browse/SOLR-81 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-81-edgengram-ngram.patch, > SOLR-81-ngram-schema.patch, SOLR-81-ngram.patch, SOLR-81-ngram.patch, > SOLR-81-ngram.patch, SOLR-81-ngram.patch, SOLR-81-spellchecker.patch, > SOLR-81-spellchecker.patch > > > Use the simple approach of n-gramming outside of Solr and indexing n-gram > documents. For example: > > lettuce > let > let ett ttu tuc uce > uce > lett > lett ettu ttuc tuce > tuce > > See: > http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html > Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
