[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499369
]
Hoss Man commented on SOLR-243:
---
regarding the IndexReaderFactory.DEFAULT, i have ahard time viewing it as good
coding style at all ..but then again i've never seen any literature arguming
for or against the concept, so i'm not sure what the "pros" are. My personal
list of "cons"...
a) violates the API / impl abstraction; interfaces shouldn't have to know about
any of their Impls
b) forces people who want to write their own impl to have the "default" class
loaded at run time even if they don't use it.
c) can't be changed; static variables in interfaces are be final (even if they
aren't declared final) and can give the false impression to people reading an
API that they can change it to something else.
as far as #6 above (an init method) SolrCore.parseListener is a good example
of how to NamedList style initing (see the SolrEventListener API).
IndexSchema.readTokenFilterFactory is a good example of the simpler Map style
initing.
I saw an idea thrown around recently about making super interfaces for each of
the two types of initialization so a lot of this code could be refactored away
... but that probably won't happen soon, and when/if it does it will be a big
undertaking that will clean up everything, so in the mean time a
cut/paste/tweak approach would be the best way to proceed
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-128) Include Newer version of Jetty
[ https://issues.apache.org/jira/browse/SOLR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499364 ] Yonik Seeley commented on SOLR-128: --- Doing some quick connection handling tests with the python client: from solr import * c = SolrConnection(host='localhost:8080', persistent=False) for i in xrange(1): c.search(q='id:1234' Java 1.5 -server on WindowsXP Jetty 5.1.??, persistent=20.9s, non-persistent=44s, sometimes "address already in use" exception Jetty 6.1.3, persistent=20.1s, non-persistent=114s Tomcat 6.0.13, persistent=20.2s, non-persistent=29s, sometimes "address already in use" exception Could be a python client issue, (SO_REUSE_ADDR for python http-lib?), but it does seem like Jetty 6.1.3 is slower at handling new connections? Anyone have benchmarks from a different client? > Include Newer version of Jetty > -- > > Key: SOLR-128 > URL: https://issues.apache.org/jira/browse/SOLR-128 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley > Assigned To: Ryan McKinley >Priority: Minor > Attachments: jetty-6.3-example.zip, Jetty6.config.patch, lib.zip, > start.jar > > > It would be good to include an up-to-date jetty version for the example. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r541940 - /lucene/solr/trunk/example/solr/conf/solrconfig.xml
: > FYI: the old query was as complex as it was to try and make clear the "no : > URL escaping" aspect of how it (unfortunately) needs to be written. (hence : > the white spaces and "*" charaters). : : Can we move the complex example into the comments? I suppose, or just toss the fq=id:[* TO *] back in .. if anyone changes their schema enough to get rid of the id field *and* cares about the ping query, i think it's fair to assume they've read the solrconfig.xml in depth enough to see that they can/should change it. -Hoss
Re: svn commit: r541940 - /lucene/solr/trunk/example/solr/conf/solrconfig.xml
On 5/26/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: : & separated key=val pairs ... but there shouldn't be any : URL escaping of the values --> : : - qt=dismax&q=solr&start=3&fq=id:[* TO *]&fq=cat:[* TO *] : + qt=standard&q=solrpingquery : FYI: the old query was as complex as it was to try and make clear the "no URL escaping" aspect of how it (unfortunately) needs to be written. (hence the white spaces and "*" charaters). Can we move the complex example into the comments? -Yonik
Re: svn commit: r541940 - /lucene/solr/trunk/example/solr/conf/solrconfig.xml
: & separated key=val pairs ... but there shouldn't be any : URL escaping of the values --> : : - qt=dismax&q=solr&start=3&fq=id:[* TO *]&fq=cat:[* TO *] : + qt=standard&q=solrpingquery : FYI: the old query was as complex as it was to try and make clear the "no URL escaping" aspect of how it (unfortunately) needs to be written. (hence the white spaces and "*" charaters). -Hoss
Re: solrconfig.xml defaults
On 5/25/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: : What about commenting out most of the default parameters in the dismax : handler config, so it becomes more standard & usable (w/o editing it's : config) after someone customizes their schema? i'm torn on this ... those defaults make sense for the example schema/data -- which is the main point of the whole example/solr/conf. but i appreciate that people can be confused by errors from dismax when they chagne their schema (see pingQuery) perhaps the best solution is to remove the qf/pf/bf defaults for "dismax" and add them to "partitioned" It's minor... I'm OK with either. For a person just learning dismax though, it almost made sense to "build up" by adding additional parameters to get more complex queries. In any case, I changed pingQuery to be simple... IMO, it's not meant to be a complex test or anything, but just that a query *can* be issued. -Yonik
[jira] Commented: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499354 ] Yonik Seeley commented on SOLR-240: --- I'm running ThrashIndex against two solr/resin instances on a RHEL4 box, one using the servlet, another using the new dispatch filter. I haven't seen any exceptions for either yet... > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, stacktrace.txt, > ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: solrconfig.xml defaults
On 5/25/07, Mike Klaas <[EMAIL PROTECTED]> wrote: On 25-May-07, at 2:09 PM, Yonik Seeley wrote: > On 5/25/07, Mike Klaas <[EMAIL PROTECTED]> wrote: >> HashDocSet maxSize: perhaps consider increasing this, or making this >> by default a parameter which is tuned automatically (.5% of maxDocs, >> for instance) > > I think when HashDocSet is large enough, it can be slower than > OpenBitSet for taking intersections, even when it still saves memory. > So it depends on what one is optimizing for. > > I picked 3000 long ago since that it seemed the fastest for faceting > with one particular data set (between 500K to 1M docs), but that was > before OpenBitSet. It also caps the max table size at 4096 entries Wasn't HashDocSet significantly optimized for intersection recently? More like optimized/simplified for storing lucene doc ids. Only about 8-10% speedup. OpenBitSet was more on the order of 2 to 4 times improvement over BitSet for intersections. Here's one data point from someone else: http://www.nabble.com/Aggregating-category-hits-tf1623611.html#a4831982 -Yonik
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499294
]
John Wang commented on SOLR-243:
1) Sorry about this, my eclipse IDE showed 2 spaces. I will remember in the
future.
2) Sorry about this one as well, I changed them from public to private to do
some testing and forgot to change them back. I have no problem with them being
public.
3) That sounds good. I just picked a spot in solrConfig.xml
4) Sure.
5) I think that is a coding style, but I am not religious about it.
6) That is a great idea! I wanted to add this but wasn't sure how to do it.
7) Ok.
Thanks for the code review!
-John
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
