Re: Solr Logo thought

[Erik Hatcher]

On Aug 1, 2008, at 1:00 PM, Walter Underwood wrote:

I kind of like the flaming version at http://www.solrmarc.org


which is coopted from the original/current logo 


Erik

Re: Solr Logo thought

[Shalin Shekhar Mangar]

+0

A bit late if you ask me, since a second poll is now running.

Personally, I'd love to have more choice. I followed the logo thread on
Mahout and it would definitely be great if Lukas is interested. I'll go with
whatever you decide.

On Fri, Aug 1, 2008 at 10:15 PM, Otis Gospodnetic <
[EMAIL PROTECTED]> wrote:

> Hola,
>
> Yes, logo, trivial issue (hi Lance).  But logos are important, so:
>
> I've cast my vote, but I don't really love even the logo I voted for (#2 --
> a little too pale/shinny, not very "bold", so to speak).  Lukas (BCCed) did
> the logo for Mahout.  He made a number of variations and was very open to
> suggestions during the process.  I wonder if we could ask him to give Solr
> logo a shot if he is not on vacation.  Do we have time for another logo,
> assuming Lukas is willing to contribute?
>
>
> Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
>
>


-- 
Regards,
Shalin Shekhar Mangar.

Re: Solr Logo thought

[Walter Underwood]

I kind of like the flaming version at http://www.solrmarc.org/
Not very fired up about the other choices.

wunder

On 8/1/08 9:45 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote:

> Hola,
> 
> Yes, logo, trivial issue (hi Lance).  But logos are important, so:
> 
> I've cast my vote, but I don't really love even the logo I voted for (#2 -- a
> little too pale/shinny, not very "bold", so to speak).  Lukas (BCCed) did the
> logo for Mahout.  He made a number of variations and was very open to
> suggestions during the process.  I wonder if we could ask him to give Solr
> logo a shot if he is not on vacation.  Do we have time for another logo,
> assuming Lukas is willing to contribute?
> 
> 
> Otis
> --
> Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

Solr Logo thought

[Otis Gospodnetic]

Hola,

Yes, logo, trivial issue (hi Lance).  But logos are important, so:

I've cast my vote, but I don't really love even the logo I voted for (#2 -- a 
little too pale/shinny, not very "bold", so to speak).  Lukas (BCCed) did the 
logo for Mahout.  He made a number of variations and was very open to 
suggestions during the process.  I wonder if we could ask him to give Solr logo 
a shot if he is not on vacation.  Do we have time for another logo, assuming 
Lukas is willing to contribute?


Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch

[jira] Commented: (SOLR-665) FIFO Cache (Unsynchronized): 9x times performance boost

[Fuad Efendi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619058#action_12619058
 ] 

Fuad Efendi commented on SOLR-665:
--

Guys at LingPipe (Natural Language Processing) http://alias-i.com/ are using 
excellent Map implementations with optimistic concurrency strategy:
http://alias-i.com/lingpipe/docs/api/com/aliasi/util/FastCache.html
http://alias-i.com/lingpipe/docs/api/com/aliasi/util/HardFastCache.html


> FIFO Cache (Unsynchronized): 9x times performance boost
> ---
>
> Key: SOLR-665
> URL: https://issues.apache.org/jira/browse/SOLR-665
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.3
> Environment: JRockit R27 (Java 6)
>Reporter: Fuad Efendi
> Attachments: ConcurrentFIFOCache.java, ConcurrentFIFOCache.java, 
> ConcurrentLRUCache.java, ConcurrentLRUWeakCache.java, FIFOCache.java, 
> SimplestConcurrentLRUCache.java
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Attached is modified version of LRUCache where 
> 1. map = new LinkedHashMap(initialSize, 0.75f, false) - so that 
> "reordering"/true (performance bottleneck of LRU) is replaced to 
> "insertion-order"/false (so that it became FIFO)
> 2. Almost all (absolutely unneccessary) synchronized statements commented out
> See discussion at 
> http://www.nabble.com/LRUCache---synchronized%21--td16439831.html
> Performance metrics (taken from SOLR Admin):
> LRU
> Requests: 7638
> Average Time-Per-Request: 15300
> Average Request-per-Second: 0.06
> FIFO:
> Requests: 3355
> Average Time-Per-Request: 1610
> Average Request-per-Second: 0.11
> Performance increased 9 times which roughly corresponds to a number of CPU in 
> a system, http://www.tokenizer.org/ (Shopping Search Engine at Tokenizer.org)
> Current number of documents: 7494689
> name:  filterCache  
> class:org.apache.solr.search.LRUCache  
> version:  1.0  
> description:  LRU Cache(maxSize=1000, initialSize=1000)  
> stats:lookups : 15966954582
> hits : 16391851546
> hitratio : 0.102
> inserts : 4246120
> evictions : 0
> size : 2668705
> cumulative_lookups : 16415839763
> cumulative_hits : 16411608101
> cumulative_hitratio : 0.99
> cumulative_inserts : 4246246
> cumulative_evictions : 0 
> Thanks

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

Re: SolrJ and DataImportHandler nightly javadocs on website

[Shalin Shekhar Mangar]

On Fri, Aug 1, 2008 at 4:12 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:

>
> Also, FYI, if any committer wants a Hudson account, let me know.  I think I
> still have karma to make that happen, if not, I know who to ask.


It would help if you can get me access to Hudson. After attending to
javadocs, I would also like to work on maven integration so that we can
release SolrJ artifacts to maven repositories with 1.3

-- 
Regards,
Shalin Shekhar Mangar.

Re: [jira] Updated: (SOLR-622) SpellCheckComponent should build or load indices on startup and commits

[Sean Timm]

Thanks.  I saw the "multicore" part of the issue title and disregarded 
it. :-)


-Sean

Shalin Shekhar Mangar wrote:

We have SOLR-433 open. Not sure what needs to be done there.

On Fri, Aug 1, 2008 at 7:46 PM, Sean Timm <[EMAIL PROTECTED]> wrote:

  

Is there a recommended way to replicate the spell checker index from the
master to the slaves?

-Sean


Shalin Shekhar Mangar (JIRA) wrote:



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

Shalin Shekhar Mangar updated SOLR-622:
---

   Attachment: SOLR-622.patch

The last patch was generated incorrectly. Uploading new one.

We are introducing a configuration parameter for spell checker with this
issue
{code:xml}
true
{code}
Now there is no need to check if a spell checker is built from Solr field
or not. If the configuration param is present, we can blindly build it on
newSearcher event.



  

SpellCheckComponent should build or load indices on startup and commits
---

   Key: SOLR-622
   URL: https://issues.apache.org/jira/browse/SOLR-622
   Project: Solr
Issue Type: Improvement
Components: spellchecker
  Affects Versions: 1.3
  Reporter: Shalin Shekhar Mangar
  Assignee: Shalin Shekhar Mangar
  Priority: Minor
   Fix For: 1.3

   Attachments: SOLR-622.patch, SOLR-622.patch, SOLR-622.patch


SpellCheckComponent must be able to build/load spell check index on
startup and commits. With SOLR-605, SpellCheckComponent can register an
event listener for firstSearcher and newSearcher events and rebuild/reload
indices as appropriate.
* If index uses a FSDirectory and exists on disk then just reload it or
else build it on firstSearcher event.
* If index is built from a Solr field then re-build it on newSearcher
event.
This will help avoid having to add QuerySenderListener in configuration
and will not force people to issue build on first query.
All this should be configurable so that people who don't want to rebuild
on commits should be able to turn this feature off per configured spell
checker.





  



  

Re: SolrJ and DataImportHandler nightly javadocs on website

[Shalin Shekhar Mangar]

Ok, I can work on SOLR-484.

On Fri, Aug 1, 2008 at 4:12 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:

> Haven't looked, but we could merge them all into 1 javadocs.  Or maybe do
> like Lucene does and have an "all" and a separate one per contrib.
>
> The Hudson job runs:
>
> ant clean nightly
>
> It archives:
> trunk/dist/*.tgz, trunk/dist/*.zip
>
> And published javadocs from:
> trunk/build/docs/api
>
>
> The current Javadocs, IMO, on the main website are actually incorrect:
> http://lucene.apache.org/solr/api/index.html
> They are listed as nightly and we should not be publishing so prominently
> anything that is nightly.  Nightly docs are only meant for developers, so as
> not to construe them as official releases.   If your feeling particularly
> interested in helping, see https://issues.apache.org/jira/browse/SOLR-484
>
> I suppose if I have my PMC hat on, I would suggest we try and clean up
> these issues for 1.3.
>
> Also, FYI, if any committer wants a Hudson account, let me know.  I think I
> still have karma to make that happen, if not, I know who to ask.
>
>
>
> On Jul 31, 2008, at 2:19 AM, Shalin Shekhar Mangar wrote:
>
>  Hi,
>>
>> Currently the nightly build copies only the main javadocs (api folder) to
>> the Solr site. It should do that for SolrJ and DataImportHandler too. I
>> believe this is being done through hudson but I don't have a hudson
>> account.
>>
>> Can someone with appropriate privileges do that? I can do that if I can
>> get
>> access to hudson. Once it is done, those two javadocs need to be linked
>> off
>> the Solr website too.
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
>>
>
>
>
>
>


-- 
Regards,
Shalin Shekhar Mangar.

Re: [jira] Updated: (SOLR-622) SpellCheckComponent should build or load indices on startup and commits

[Shalin Shekhar Mangar]

We have SOLR-433 open. Not sure what needs to be done there.

On Fri, Aug 1, 2008 at 7:46 PM, Sean Timm <[EMAIL PROTECTED]> wrote:

> Is there a recommended way to replicate the spell checker index from the
> master to the slaves?
>
> -Sean
>
>
> Shalin Shekhar Mangar (JIRA) wrote:
>
>> [
>> https://issues.apache.org/jira/browse/SOLR-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Shalin Shekhar Mangar updated SOLR-622:
>> ---
>>
>>Attachment: SOLR-622.patch
>>
>> The last patch was generated incorrectly. Uploading new one.
>>
>> We are introducing a configuration parameter for spell checker with this
>> issue
>> {code:xml}
>> true
>> {code}
>> Now there is no need to check if a spell checker is built from Solr field
>> or not. If the configuration param is present, we can blindly build it on
>> newSearcher event.
>>
>>
>>
>>> SpellCheckComponent should build or load indices on startup and commits
>>> ---
>>>
>>>Key: SOLR-622
>>>URL: https://issues.apache.org/jira/browse/SOLR-622
>>>Project: Solr
>>> Issue Type: Improvement
>>> Components: spellchecker
>>>   Affects Versions: 1.3
>>>   Reporter: Shalin Shekhar Mangar
>>>   Assignee: Shalin Shekhar Mangar
>>>   Priority: Minor
>>>Fix For: 1.3
>>>
>>>Attachments: SOLR-622.patch, SOLR-622.patch, SOLR-622.patch
>>>
>>>
>>> SpellCheckComponent must be able to build/load spell check index on
>>> startup and commits. With SOLR-605, SpellCheckComponent can register an
>>> event listener for firstSearcher and newSearcher events and rebuild/reload
>>> indices as appropriate.
>>> * If index uses a FSDirectory and exists on disk then just reload it or
>>> else build it on firstSearcher event.
>>> * If index is built from a Solr field then re-build it on newSearcher
>>> event.
>>> This will help avoid having to add QuerySenderListener in configuration
>>> and will not force people to issue build on first query.
>>> All this should be configurable so that people who don't want to rebuild
>>> on commits should be able to turn this feature off per configured spell
>>> checker.
>>>
>>>
>>
>>
>>
>


-- 
Regards,
Shalin Shekhar Mangar.

Re: [jira] Updated: (SOLR-622) SpellCheckComponent should build or load indices on startup and commits

[Sean Timm]

Is there a recommended way to replicate the spell checker index from the 
master to the slaves?


-Sean

Shalin Shekhar Mangar (JIRA) wrote:

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

Shalin Shekhar Mangar updated SOLR-622:
---

Attachment: SOLR-622.patch

The last patch was generated incorrectly. Uploading new one.

We are introducing a configuration parameter for spell checker with this issue
{code:xml}
true
{code}
Now there is no need to check if a spell checker is built from Solr field or 
not. If the configuration param is present, we can blindly build it on 
newSearcher event.

  

SpellCheckComponent should build or load indices on startup and commits
---

Key: SOLR-622
URL: https://issues.apache.org/jira/browse/SOLR-622
Project: Solr
 Issue Type: Improvement
 Components: spellchecker
   Affects Versions: 1.3
   Reporter: Shalin Shekhar Mangar
   Assignee: Shalin Shekhar Mangar
   Priority: Minor
Fix For: 1.3

Attachments: SOLR-622.patch, SOLR-622.patch, SOLR-622.patch


SpellCheckComponent must be able to build/load spell check index on startup and 
commits. With SOLR-605, SpellCheckComponent can register an event listener for 
firstSearcher and newSearcher events and rebuild/reload indices as appropriate.
* If index uses a FSDirectory and exists on disk then just reload it or else 
build it on firstSearcher event.
* If index is built from a Solr field then re-build it on newSearcher event.
This will help avoid having to add QuerySenderListener in configuration and 
will not force people to issue build on first query.
All this should be configurable so that people who don't want to rebuild on 
commits should be able to turn this feature off per configured spell checker.



  

Re: SolrJ and DataImportHandler nightly javadocs on website

[Grant Ingersoll]

Haven't looked, but we could merge them all into 1 javadocs.  Or maybe  
do like Lucene does and have an "all" and a separate one per contrib.


The Hudson job runs:

ant clean nightly

It archives:
trunk/dist/*.tgz, trunk/dist/*.zip

And published javadocs from:
trunk/build/docs/api


The current Javadocs, IMO, on the main website are actually incorrect: 
http://lucene.apache.org/solr/api/index.html
They are listed as nightly and we should not be publishing so  
prominently anything that is nightly.  Nightly docs are only meant for  
developers, so as not to construe them as official releases.   If your  
feeling particularly interested in helping, see https://issues.apache.org/jira/browse/SOLR-484


I suppose if I have my PMC hat on, I would suggest we try and clean up  
these issues for 1.3.


Also, FYI, if any committer wants a Hudson account, let me know.  I  
think I still have karma to make that happen, if not, I know who to ask.



On Jul 31, 2008, at 2:19 AM, Shalin Shekhar Mangar wrote:


Hi,

Currently the nightly build copies only the main javadocs (api  
folder) to
the Solr site. It should do that for SolrJ and DataImportHandler  
too. I
believe this is being done through hudson but I don't have a hudson  
account.


Can someone with appropriate privileges do that? I can do that if I  
can get
access to hudson. Once it is done, those two javadocs need to be  
linked off

the Solr website too.

--
Regards,
Shalin Shekhar Mangar.

Re: SOLR-555 ... Solr 1.3?

[Andrew Savory]

Hey there,

2008/8/1 Chris Hostetter <[EMAIL PROTECTED]>:

> I'd hoped to be long done with SOLR-555 by now, have it all polished and
> spiffy and committed ... but it's not.

Autogenerate "user" docs about "plugins" from code,
http://issues.apache.org/jira/browse/SOLR-555

> is it worth it to
> start using this, and start generating better documentation that we can
> include in 1.3 even if the documentation isn't pretty to look at?  Will we
> take the time before releasing to fill in the documentation so it's actually
> useful?  ... or should we hold off, stick with the status quo (all "user"
> docs are in wiki pages)  and worry about after 1.3?

I'd suggest "commit early, commit often", especially for something
that is not API-level and therefore problematic if it's changed. This
gives other people the opportunity to work on the three things you
list that need improvement, and also allows anyone to start writing
docs. If lots of docs are added before 1.3, great. If they aren't, no
problem.


Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/

Build failed in Hudson: Solr-trunk #514

[Apache Hudson Server]

See http://hudson.zones.apache.org/hudson/job/Solr-trunk/514/changes

Changes:

[shalin] Try all MBeanServers before giving up

[shalin] Fail main build on error in contrib builds

[shalin] Fixed directory name for DataImportHandler's javadoc target

[shalin] SOLR-622: SpellCheckComponent supports auto-loading indices on startup 
and optionally, (re)builds indices on newSearcher event, if configured in 
solrconfig.xml

[yonik] pass current searcher to newSearcher hook

[yonik] LRUCache impl synchronizes on the map, not the cache

[koji] SOLR-662: solr-ruby now supports all highlighter parameters.

[shalin] Removing files generated by DataImportHandler tests.

--
[...truncated 1430 lines...]
[junit] Running org.apache.solr.analysis.TestCapitalizationFilter
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.191 sec
[junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.089 sec
[junit] Running org.apache.solr.analysis.TestKeepWordFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.415 sec
[junit] Running org.apache.solr.analysis.TestPatternReplaceFilter
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.02 sec
[junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.133 sec
[junit] Running org.apache.solr.analysis.TestPhoneticFilter
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.483 sec
[junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.5 sec
[junit] Running org.apache.solr.analysis.TestSynonymFilter
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.317 sec
[junit] Running org.apache.solr.analysis.TestSynonymMap
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.459 sec
[junit] Running org.apache.solr.analysis.TestTrimFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.186 sec
[junit] Running org.apache.solr.analysis.TestWordDelimiterFilter
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 12.143 sec
[junit] Running org.apache.solr.common.SolrDocumentTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.506 sec
[junit] Running org.apache.solr.common.params.SolrParamTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.386 sec
[junit] Running org.apache.solr.common.util.ContentStreamTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.875 sec
[junit] Running org.apache.solr.common.util.IteratorChainTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.565 sec
[junit] Running org.apache.solr.common.util.TestNamedListCodec
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.802 sec
[junit] Running org.apache.solr.common.util.TestXMLEscaping
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.422 sec
[junit] Running org.apache.solr.core.RequestHandlersTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.411 sec
[junit] Running org.apache.solr.core.ResourceLoaderTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.604 sec
[junit] Running org.apache.solr.core.SolrCoreTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.929 sec
[junit] Running org.apache.solr.core.TestBadConfig
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.675 sec
[junit] Running org.apache.solr.core.TestConfig
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.595 sec
[junit] Running org.apache.solr.core.TestJmxIntegration
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 5.59 sec
[junit] Test org.apache.solr.core.TestJmxIntegration FAILED
[junit] Running org.apache.solr.core.TestJmxMonitoredMap
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.615 sec
[junit] Running org.apache.solr.core.TestQuerySenderListener
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.435 sec
[junit] Running org.apache.solr.handler.AnalysisRequestHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.81 sec
[junit] Running org.apache.solr.handler.MoreLikeThisHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.856 sec
[junit] Running org.apache.solr.handler.SpellCheckerRequestHandlerTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 7.818 sec
[junit] Running org.apache.solr.handler.StandardRequestHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.671 sec
[junit] Running org.apache.solr.handler.TestCSVLoader
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 13.038 sec
[junit] Running org.apache.solr.han