date:20090922

[jira] Commented: (SOLR-1447) Simple property injection

2009-09-22 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-1447:
--

committed r817976

thanks Jason

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

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

[jira] Updated: (SOLR-1447) Simple property injection

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen updated SOLR-1447:
---

Attachment: SOLR-1447.patch

I added a legacy test, and fixed a small NPE bug that happens via SolrPlugUtils

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

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

[jira] Commented: (SOLR-1316) Create autosuggest component

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen commented on SOLR-1316:


Ishan,

Feel free to post your disk TST implementation, it sounds interesting.

> Create autosuggest component
> 
>
> Key: SOLR-1316
> URL: https://issues.apache.org/jira/browse/SOLR-1316
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: 1.5
>
> Attachments: suggest.patch, TST.zip
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> Autosuggest is a common search function that can be integrated
> into Solr as a SearchComponent. Our first implementation will
> use the TernaryTree found in Lucene contrib. 
> * Enable creation of the dictionary from the index or via Solr's
> RPC mechanism
> * What types of parameters and settings are desirable?
> * Hopefully in the future we can include user click through
> rates to boost those terms/phrases higher

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

[jira] Commented: (SOLR-1447) Simple property injection

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen commented on SOLR-1447:


I think we need a legacy test?  

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

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

[jira] Commented: (SOLR-1335) load core properties from a properties file

2009-09-22 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-1335:
--

bq.can someone comment on whether the single core setup (solrconfig.xml) 
supports referencing a properties file now

yes, you can. The filename and location is fixed for single core. It should be 
$solr_home/conf/solrcore.properties

> load core properties from a properties file
> ---
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, 
> SOLR-1335.patch
>
>
> There are  few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to  keep separate solrconfig.xml for each instance.  
> #1 is error prone if the user fails to start with the correct system 
> property. 
> In our case we have four different configurations for the same deployment  . 
> And we have to disable replication of solrconfig.xml. 
> It would be nice if I can distribute four properties file so that our ops can 
> drop  the right one and start Solr. Or it is possible for the operations to 
> edit a properties file  but it is risky to edit solrconfig.xml if he does not 
> understand solr
> I propose a properties file in the instancedir as solrcore.properties . If 
> present would be loaded and added as core specific properties.

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

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-1449:
-

bq. particularly when people want to use the same plugins in multiple cores 
(that have unique instanceDirs)

That is taken care of by the sharedLib attribute in solr.xml

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

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

[jira] Updated: (SOLR-1395) Integrate Katta

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen updated SOLR-1395:
---

Attachment: zkclient-0.1-dev.jar
katta-core-0.6-dev.jar
test-katta-core-0.6-dev.jar

Copy these libraries into lib/ before executing the test.  The Katta jars are 
somewhat custom.  I'll post a patch there shortly.

> Integrate Katta
> ---
>
> Key: SOLR-1395
> URL: https://issues.apache.org/jira/browse/SOLR-1395
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: 1.5
>
> Attachments: hadoop-core-0.19.0.jar, katta-core-0.6-dev.jar, 
> KATTA-SOLR.patch, log4j-1.2.13.jar, SOLR-1395.patch, SOLR-1395.patch, 
> test-katta-core-0.6-dev.jar, zkclient-0.1-dev.jar, zookeeper-3.2.1.jar
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> We'll integrate Katta into Solr so that:
> * Distributed search uses Hadoop RPC
> * Shard/SolrCore distribution and management
> * Zookeeper based failover
> * Indexes may be built using Hadoop

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

[jira] Updated: (SOLR-1395) Integrate Katta

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen updated SOLR-1395:
---

Attachment: SOLR-1395.patch

New patch updated to Katta's latest from Git.  It's slimmed down a bit, 
removing the various extraneous config files etc.

> Integrate Katta
> ---
>
> Key: SOLR-1395
> URL: https://issues.apache.org/jira/browse/SOLR-1395
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: 1.5
>
> Attachments: hadoop-core-0.19.0.jar, KATTA-SOLR.patch, 
> log4j-1.2.13.jar, SOLR-1395.patch, SOLR-1395.patch, zookeeper-3.2.1.jar
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> We'll integrate Katta into Solr so that:
> * Distributed search uses Hadoop RPC
> * Shard/SolrCore distribution and management
> * Zookeeper based failover
> * Indexes may be built using Hadoop

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

[jira] Commented: (SOLR-1394) HTML stripper is splitting tokens

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen commented on SOLR-1394:


Anders, 

We're seeing the error again, we're going to try this patch and
HTMLStripReader and we'll see what happens. Here's the latest
stacktrace, which is pretty much the same as the last one:

{code}
SEVERE: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:485)
at org.apache.lucene.analysis.CharReader.reset(CharReader.java:63)
at 
org.apache.solr.analysis.HTMLStripCharFilter.restoreState(HTMLStripCharFilter.java:170)
at 
org.apache.solr.analysis.HTMLStripCharFilter.read(HTMLStripCharFilter.java:727)
at 
org.apache.solr.analysis.HTMLStripCharFilter.read(HTMLStripCharFilter.java:741)
at 
org.apache.lucene.analysis.standard.StandardTokenizerImpl.zzRefill(StandardTokenizerImpl.java:451
)
at 
org.apache.lucene.analysis.standard.StandardTokenizerImpl.getNextToken(StandardTokenizerImpl.java
:637)
at 
org.apache.lucene.analysis.standard.StandardTokenizer.incrementToken(StandardTokenizer.java:174)
at 
org.apache.lucene.analysis.standard.StandardFilter.incrementToken(StandardFilter.java:50)
at 
org.apache.lucene.analysis.LowerCaseFilter.incrementToken(LowerCaseFilter.java:38)
at 
org.apache.solr.analysis.SnowballPorterFilter.incrementToken(SnowballPorterFilterFactory.java:116
)
at org.apache.lucene.analysis.TokenStream.next(TokenStream.java:401)
at 
org.apache.solr.analysis.BufferedTokenStream.read(BufferedTokenStream.java:94)
at 
org.apache.solr.analysis.BufferedTokenStream.next(BufferedTokenStream.java:80)
at 
org.apache.lucene.analysis.TokenStream.incrementToken(TokenStream.java:316)
at 
org.apache.lucene.analysis.StopFilter.incrementToken(StopFilter.java:224)
at 
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:138)
at 
org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.jav
a:244)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:755)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2611)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2583)
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:241)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
{code}

> HTML stripper is splitting tokens
> -
>
> Key: SOLR-1394
> URL: https://issues.apache.org/jira/browse/SOLR-1394
> Project: Solr
>  Issue Type: Bug
>  Components: Analysis
>Affects Versions: 1.4
>Reporter: Anders Melchiorsen
> Attachments: SOLR-1394.patch
>
>
> I am having problems with the Solr HTML stripper.
> After some investigation, I have found the cause to be that the
> stripper is replacing the removed HTML with spaces. This obviously
> breaks when the HTML is in the middle of a word, like "Günther".
> So, without knowing what I was doing, I hacked together a fix that
> uses offset correction instead.
> That seemed to work, except that closing tags and attributes still
> broke the positioning. With even less of a clue, I replaced read()
> with next() in the two methods handling those.
> Finally, invalid HTML also gave wrong offsets, and I fixed that by
> restoring numRead when rolling back the input stream.
> At this point I stopped trying to break it, so there may still be more
> problems. Or I might have introduced some problem on my own. Anyway, I
> have put the three patches at the bottom of this mail, in case
> somebody wants to move along with this issue.

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

[jira] Commented: (SOLR-1335) load core properties from a properties file

2009-09-22 Thread Artem Russakovskii (JIRA)


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

Artem Russakovskii commented on SOLR-1335:
--

So, can someone comment on whether the single core setup (solrconfig.xml) 
supports referencing a properties file now? I'm not using multicore, like this 
bug's author, and after reading through the comments here, I'm still unclear on 
the single core solution.

Ideally, solrxonfig.xml would contain a location of the properties file, which 
it would load prior to parsing everything else.

Thanks.

> load core properties from a properties file
> ---
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
>  Issue Type: New Feature
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, 
> SOLR-1335.patch
>
>
> There are  few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to  keep separate solrconfig.xml for each instance.  
> #1 is error prone if the user fails to start with the correct system 
> property. 
> In our case we have four different configurations for the same deployment  . 
> And we have to disable replication of solrconfig.xml. 
> It would be nice if I can distribute four properties file so that our ops can 
> drop  the right one and start Solr. Or it is possible for the operations to 
> edit a properties file  but it is risky to edit solrconfig.xml if he does not 
> understand solr
> I propose a properties file in the instancedir as solrcore.properties . If 
> present would be loaded and added as core specific properties.

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

[jira] Updated: (SOLR-1431) CommComponent abstracted

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen updated SOLR-1431:
---

Attachment: SOLR-1431.patch

Same as the previous

> CommComponent abstracted
> 
>
> Key: SOLR-1431
> URL: https://issues.apache.org/jira/browse/SOLR-1431
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SOLR-1431.patch, SOLR-1431.patch, SOLR-1431.patch, 
> SOLR-1431.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We'll abstract CommComponent in this issue.

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

[jira] Resolved: (SOLR-908) Port of Nutch CommonGrams filter to Solr

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley resolved SOLR-908.
---

   Resolution: Fixed
Fix Version/s: 1.4

Committed.  Thanks everyone!

> Port of Nutch  CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
>  Issue Type: Wish
>  Components: Analysis
>Reporter: Tom Burton-West
>Assignee: Yonik Seeley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow.  We are reluctant 
> to just use stop words due to various problems with false hits and some 
> things becoming impossible to search with stop words turned on. (For example 
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) 
>  
> Several postings regarding slow phrase queries have suggested using the 
> approach used by Nutch.  Perhaps someone with more Java/Solr experience might 
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr  and create 
> a suitable Solr FilterFactory so that it could be used in Solr by listing it 
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing. 
> Optimize phrase queries to use the n-grams. Single terms are still indexed 
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.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-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-09-22 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-1449:


I feel like these comments aren't really on topic ... this type of feature has 
been discussed numerous times on the list as a desirable way for users to 
specify where a core should look to load plugins without needing to copy jars 
to a specific hardcoded directory -- particularly when people want to use the 
same plugins in multiple cores (that have unique instanceDirs)

Independent of any question of what our releases look like, and what kinds of 
examples we want to include, these is still a feature that users have been 
requesting.

My point about our examples was merely that an *additional* use case that would 
be improved by this feature is that we would be able to have a single copy of 
any jar in the  release, no matter how many examples wanted to refer to it 
(which would also make it easier to add examples that would work "as is" 
without debating the potential increase n the size of the release, or wether we 
should ask the user to copy the jars, etc...

bq. It's just that having a regex based class loading from externally located 
jars, although cool, seems an overly fancy way to solve this particular problem.

As i already said: that wasn't a particular goal, just a nice side effect -- 
but FWIW: the regex based loading was actually the easiest way i found to 
identify multiple jars -- i was looking for an easy way to do shell style 
fileglobbing in java and nothing jumped out at me, java.util.regex on the other 
hand is a stock and easy to use.


> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

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

[jira] Updated: (SOLR-1431) CommComponent abstracted

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen updated SOLR-1431:
---

Attachment: SOLR-1431.patch

Changed SearchHandler.getCommComponent to getMultiSearchHandler

> CommComponent abstracted
> 
>
> Key: SOLR-1431
> URL: https://issues.apache.org/jira/browse/SOLR-1431
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SOLR-1431.patch, SOLR-1431.patch, SOLR-1431.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We'll abstract CommComponent in this issue.

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

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-1449:
-

bq. For the same reason we have an example at all I guess - a better 
out-of-the-box experience.

I agree with that goal. It's just that having a regex based class loading from 
externally located jars, although cool, seems an overly fancy way to solve this 
particular problem.

bq. It would be nice if we could do database import from the same example 
server... but I think JDBC driver issues (and the necessity to have a database 
to connect to?) make this tougher.

The database and the driver jar is checked in. The only issue I guess is that 
our example is a single-core one and the DIH examples have db, rss and mail 
each of which requires its own schema.

The main problem is the mail DIH example. It uses Tika for indexing email 
attachments and therefore copies all its dependencies. I'm not sure if that is 
necessary. We can have an option to disable that and document the attachment 
support in the wiki only. I'm guessing that very few users will actually need 
to look at that example.

The other thing that we can do is to offer separate source and binary+example 
downloads.

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

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

[jira] Commented: (SOLR-908) Port of Nutch CommonGrams filter to Solr

2009-09-22 Thread Robert Muir (JIRA)


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

Robert Muir commented on SOLR-908:
--

i've been doing some tests, latest patch has been working fine for me.
i think jason cleared up any remaining reset/reusable issues with this latest 
patch.


> Port of Nutch  CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
>  Issue Type: Wish
>  Components: Analysis
>Reporter: Tom Burton-West
>Assignee: Yonik Seeley
>Priority: Minor
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow.  We are reluctant 
> to just use stop words due to various problems with false hits and some 
> things becoming impossible to search with stop words turned on. (For example 
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) 
>  
> Several postings regarding slow phrase queries have suggested using the 
> approach used by Nutch.  Perhaps someone with more Java/Solr experience might 
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr  and create 
> a suitable Solr FilterFactory so that it could be used in Solr by listing it 
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing. 
> Optimize phrase queries to use the n-grams. Single terms are still indexed 
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html

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

[jira] Assigned: (SOLR-908) Port of Nutch CommonGrams filter to Solr

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley reassigned SOLR-908:
-

Assignee: Yonik Seeley

> Port of Nutch  CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
>  Issue Type: Wish
>  Components: Analysis
>Reporter: Tom Burton-West
>Assignee: Yonik Seeley
>Priority: Minor
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow.  We are reluctant 
> to just use stop words due to various problems with false hits and some 
> things becoming impossible to search with stop words turned on. (For example 
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) 
>  
> Several postings regarding slow phrase queries have suggested using the 
> approach used by Nutch.  Perhaps someone with more Java/Solr experience might 
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr  and create 
> a suitable Solr FilterFactory so that it could be used in Solr by listing it 
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing. 
> Optimize phrase queries to use the n-grams. Single terms are still indexed 
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html

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

[jira] Resolved: (SOLR-1451) SolrPluginUtils#parseFieldBoosts - inconsistent javadoc

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-1451.
-

Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

Committed revision 817804.

Thanks Kay!

> SolrPluginUtils#parseFieldBoosts - inconsistent javadoc 
> 
>
> Key: SOLR-1451
> URL: https://issues.apache.org/jira/browse/SOLR-1451
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.4
>Reporter: Kay Kay
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1451.patch
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> Parameters:fieldLists an array of Strings eg. {"fieldOne^2.3", 
> "fieldTwo"}
> Returns:  Map of fieldOne => 2.3, fieldThree => -0.4
> inconsistent javadoc . parameter names and return values do not seem to match 

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

[jira] Commented: (SOLR-908) Port of Nutch CommonGrams filter to Solr

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-908:


bq. Yay! I think we could commit this now... any objections/concerns with the 
latest patch?

Looks good. +1 for commit.

> Port of Nutch  CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
>  Issue Type: Wish
>  Components: Analysis
>Reporter: Tom Burton-West
>Priority: Minor
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow.  We are reluctant 
> to just use stop words due to various problems with false hits and some 
> things becoming impossible to search with stop words turned on. (For example 
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) 
>  
> Several postings regarding slow phrase queries have suggested using the 
> approach used by Nutch.  Perhaps someone with more Java/Solr experience might 
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr  and create 
> a suitable Solr FilterFactory so that it could be used in Solr by listing it 
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing. 
> Optimize phrase queries to use the n-grams. Single terms are still indexed 
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html

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

[jira] Resolved: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-1366.
-

Resolution: Fixed

Committed revision 817801.

Thanks everybody!

> UnsupportedOperationException may be thrown when using custom IndexReader
> -
>
> Key: SOLR-1366
> URL: https://issues.apache.org/jira/browse/SOLR-1366
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java), search
>Affects Versions: 1.4
>Reporter: Andrzej Bialecki 
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: searcher.patch, SOLR-1366.patch
>
>
> If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and 
> IndexReader-s that it produces don't support IndexReader.directory() (such as 
> is the case with ParallelReader or MultiReader) then an uncaught 
> UnsupportedOperationException is thrown.
> This call is used only to retrieve the full path of the directory for 
> informational purpose, so it shouldn't lead to a crash. Instead we could 
> supply other available information about the reader (e.g. from its toString() 
> method).

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

[jira] Commented: (SOLR-908) Port of Nutch CommonGrams filter to Solr

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-908:
---

Yay!  I think we could commit this now... any objections/concerns with the 
latest patch?

> Port of Nutch  CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
>  Issue Type: Wish
>  Components: Analysis
>Reporter: Tom Burton-West
>Priority: Minor
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow.  We are reluctant 
> to just use stop words due to various problems with false hits and some 
> things becoming impossible to search with stop words turned on. (For example 
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) 
>  
> Several postings regarding slow phrase queries have suggested using the 
> approach used by Nutch.  Perhaps someone with more Java/Solr experience might 
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr  and create 
> a suitable Solr FilterFactory so that it could be used in Solr by listing it 
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing. 
> Optimize phrase queries to use the n-grams. Single terms are still indexed 
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html

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

[jira] Created: (SOLR-1453) Tree facet with stats component

2009-09-22 Thread sumit biyani (JIRA)

Tree facet with stats component
---

 Key: SOLR-1453
 URL: https://issues.apache.org/jira/browse/SOLR-1453
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: sumit biyani
Priority: Minor


Hi , 

My requirement is to fetch results like below sql query:

Select  txn_code,
txn_server,
max(total_time), 
min(total_time),
max(db_time), 
min(db_time),
from txn_table
group by txn_code,txn_server.

- statsComponent helps to get  aggregate results & stats.facet is available for 
single field , but my requirement is to have multi level facet on more than 1 
field while fetching results.

Please let me know , how to get this using solr , do we have this planned in 
any upcoming release, or any patch is available ?
 
Thanks & Regards,
Sumit.


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

[jira] Resolved: (SOLR-1452) deletes in segment cause different fieldcache instance

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley resolved SOLR-1452.


Resolution: Fixed

committed.

> deletes in segment cause different fieldcache instance
> --
>
> Key: SOLR-1452
> URL: https://issues.apache.org/jira/browse/SOLR-1452
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1452.patch
>
>
> FieldCache entries should be shared if segments are the same except for 
> deletes.

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

[jira] Commented: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader

2009-09-22 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  commented on SOLR-1366:
-

Looks good to me, +1.

> UnsupportedOperationException may be thrown when using custom IndexReader
> -
>
> Key: SOLR-1366
> URL: https://issues.apache.org/jira/browse/SOLR-1366
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java), search
>Affects Versions: 1.4
>Reporter: Andrzej Bialecki 
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: searcher.patch, SOLR-1366.patch
>
>
> If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and 
> IndexReader-s that it produces don't support IndexReader.directory() (such as 
> is the case with ParallelReader or MultiReader) then an uncaught 
> UnsupportedOperationException is thrown.
> This call is used only to retrieve the full path of the directory for 
> informational purpose, so it shouldn't lead to a crash. Instead we could 
> supply other available information about the reader (e.g. from its toString() 
> method).

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

[jira] Updated: (SOLR-1452) deletes in segment cause different fieldcache instance

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley updated SOLR-1452:
---

Attachment: SOLR-1452.patch

patch + tests attached.
the bug was caused by our not overriding getFieldCacheKey() (and thus not 
delegating to the impl in SegmentReader)

> deletes in segment cause different fieldcache instance
> --
>
> Key: SOLR-1452
> URL: https://issues.apache.org/jira/browse/SOLR-1452
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1452.patch
>
>
> FieldCache entries should be shared if segments are the same except for 
> deletes.

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

[jira] Assigned: (SOLR-1452) deletes in segment cause different fieldcache instance

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley reassigned SOLR-1452:
--

Assignee: Yonik Seeley

> deletes in segment cause different fieldcache instance
> --
>
> Key: SOLR-1452
> URL: https://issues.apache.org/jira/browse/SOLR-1452
> Project: Solr
>  Issue Type: Bug
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1452.patch
>
>
> FieldCache entries should be shared if segments are the same except for 
> deletes.

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

[jira] Created: (SOLR-1452) deletes in segment cause different fieldcache instance

2009-09-22 Thread Yonik Seeley (JIRA)

deletes in segment cause different fieldcache instance
--

 Key: SOLR-1452
 URL: https://issues.apache.org/jira/browse/SOLR-1452
 Project: Solr
  Issue Type: Bug
Reporter: Yonik Seeley
 Fix For: 1.4


FieldCache entries should be shared if segments are the same except for deletes.

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

[jira] Commented: (SOLR-908) Port of Nutch CommonGrams filter to Solr

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen commented on SOLR-908:
---

Thanks everyone on this, we deployed the latest patch with the latest Solr 
build and things work now, reliably. :)

> Port of Nutch  CommonGrams filter to Solr
> -
>
> Key: SOLR-908
> URL: https://issues.apache.org/jira/browse/SOLR-908
> Project: Solr
>  Issue Type: Wish
>  Components: Analysis
>Reporter: Tom Burton-West
>Priority: Minor
> Attachments: CommonGramsPort.zip, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, SOLR-908.patch, 
> SOLR-908.patch, SOLR-908.patch, SOLR-908.patch
>
>
> Phrase queries containing common words are extremely slow.  We are reluctant 
> to just use stop words due to various problems with false hits and some 
> things becoming impossible to search with stop words turned on. (For example 
> "to be or not to be", "the who", "man in the moon" vs "man on the moon" etc.) 
>  
> Several postings regarding slow phrase queries have suggested using the 
> approach used by Nutch.  Perhaps someone with more Java/Solr experience might 
> take this on.
> It should be possible to port the Nutch CommonGrams code to Solr  and create 
> a suitable Solr FilterFactory so that it could be used in Solr by listing it 
> in the Solr schema.xml.
> "Construct n-grams for frequently occuring terms and phrases while indexing. 
> Optimize phrase queries to use the n-grams. Single terms are still indexed 
> too, with n-grams overlaid."
> http://lucene.apache.org/nutch/apidocs-0.8.x/org/apache/nutch/analysis/CommonGrams.html

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

[jira] Updated: (SOLR-1167) Support module xml config files using XInclude

2009-09-22 Thread Bryan Talbot (JIRA)


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

Bryan Talbot updated SOLR-1167:
---

Affects Version/s: 1.4

> Support module xml config files using XInclude
> --
>
> Key: SOLR-1167
> URL: https://issues.apache.org/jira/browse/SOLR-1167
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Bryan Talbot
>Priority: Minor
> Attachments: SOLR-1167.patch, SOLR-1167.patch, SOLR-1167.patch
>
>
> Current configuration files (schema and solrconfig) are monolithic which can 
> make maintenance and reuse more difficult that it needs to be.  The XML 
> standards include a feature to include content from external files.  This is 
> described at http://www.w3.org/TR/xinclude/
> This feature is to add support for XInclude features for XML configuration 
> files.

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

[jira] Updated: (SOLR-1451) SolrPluginUtils#parseFieldBoosts - inconsistent javadoc

2009-09-22 Thread Kay Kay (JIRA)


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

Kay Kay updated SOLR-1451:
--

Fix Version/s: 1.4
Affects Version/s: 1.4

> SolrPluginUtils#parseFieldBoosts - inconsistent javadoc 
> 
>
> Key: SOLR-1451
> URL: https://issues.apache.org/jira/browse/SOLR-1451
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.4
>Reporter: Kay Kay
> Fix For: 1.4
>
> Attachments: SOLR-1451.patch
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> Parameters:fieldLists an array of Strings eg. {"fieldOne^2.3", 
> "fieldTwo"}
> Returns:  Map of fieldOne => 2.3, fieldThree => -0.4
> inconsistent javadoc . parameter names and return values do not seem to match 

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

[jira] Updated: (SOLR-1451) SolrPluginUtils#parseFieldBoosts - inconsistent javadoc

2009-09-22 Thread Kay Kay (JIRA)


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

Kay Kay updated SOLR-1451:
--

Attachment: SOLR-1451.patch

javadoc fix 

> SolrPluginUtils#parseFieldBoosts - inconsistent javadoc 
> 
>
> Key: SOLR-1451
> URL: https://issues.apache.org/jira/browse/SOLR-1451
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.4
>Reporter: Kay Kay
> Fix For: 1.4
>
> Attachments: SOLR-1451.patch
>
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> Parameters:fieldLists an array of Strings eg. {"fieldOne^2.3", 
> "fieldTwo"}
> Returns:  Map of fieldOne => 2.3, fieldThree => -0.4
> inconsistent javadoc . parameter names and return values do not seem to match 

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

[jira] Created: (SOLR-1451) SolrPluginUtils#parseFieldBoosts - inconsistent javadoc

2009-09-22 Thread Kay Kay (JIRA)

SolrPluginUtils#parseFieldBoosts - inconsistent javadoc 


 Key: SOLR-1451
 URL: https://issues.apache.org/jira/browse/SOLR-1451
 Project: Solr
  Issue Type: Bug
  Components: documentation
Reporter: Kay Kay


Parameters:fieldLists an array of Strings eg. {"fieldOne^2.3", "fieldTwo"}  
  
Returns:  Map of fieldOne => 2.3, fieldThree => -0.4

inconsistent javadoc . parameter names and return values do not seem to match 

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

[jira] Commented: (SOLR-1374) When a test fails, display the test file in the console via ant junit

2009-09-22 Thread Jason Rutherglen (JIRA)


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

Jason Rutherglen commented on SOLR-1374:


I was thinking the list of test files and their paths, like ant does
after building a war or jar.



> When a test fails, display the test file in the console via ant junit
> -
>
> Key: SOLR-1374
> URL: https://issues.apache.org/jira/browse/SOLR-1374
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Trivial
> Fix For: 1.5
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> When a test fails, it would be great if the junit test output file were 
> displayed in the terminal.

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

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-09-22 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-1449:


bq.  We can have some instructions or scripts (I assume we don't want ant) to 
copy the jars to the correct places for running solr-cell examples. Is there a 
problem with that?

For the same reason we have an example at all I guess - a better out-of-the-box 
experience.

IMO, Solr *is* an enterprise search server, not a bunch of jars you wire 
together yourself to create one.  It would be nice if we could do database 
import from the same example server... but I think JDBC driver issues (and the 
necessity to have a database to connect to?) make this tougher.

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

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

[jira] Assigned: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader

2009-09-22 Thread Mark Miller (JIRA)


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

Mark Miller reassigned SOLR-1366:
-

Assignee: Shalin Shekhar Mangar  (was: Mark Miller)

> UnsupportedOperationException may be thrown when using custom IndexReader
> -
>
> Key: SOLR-1366
> URL: https://issues.apache.org/jira/browse/SOLR-1366
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java), search
>Affects Versions: 1.4
>Reporter: Andrzej Bialecki 
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: searcher.patch, SOLR-1366.patch
>
>
> If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and 
> IndexReader-s that it produces don't support IndexReader.directory() (such as 
> is the case with ParallelReader or MultiReader) then an uncaught 
> UnsupportedOperationException is thrown.
> This call is used only to retrieve the full path of the directory for 
> informational purpose, so it shouldn't lead to a crash. Instead we could 
> supply other available information about the reader (e.g. from its toString() 
> method).

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

Re: DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Shalin Shekhar Mangar

On Tue, Sep 22, 2009 at 3:00 PM, Steve Sun  wrote:

> Done.
> http://issues.apache.org/jira/browse/SOLR-1450
>
>
This is fixed in trunk now. Thanks Steve!

-- 
Regards,
Shalin Shekhar Mangar.

[jira] Updated: (SOLR-1366) UnsupportedOperationException may be thrown when using custom IndexReader

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar updated SOLR-1366:


Attachment: SOLR-1366.patch

How about this?

{code}
** Experimental Feature **
Please note - Using a custom IndexReaderFactory may prevent certain other 
features
from working. The API to IndexReaderFactory may change without warning or may 
even
be removed from future releases if the problems cannot be resolved.

** Features that may not work with custom IndexReaderFactory **
The ReplicationHandler assumes a disk-resident index. Using a custom
IndexReader implementation may cause incompatibility between ReplicationHandler 
and
may cause replication to not work correctly. See SOLR-1366 for details.
{code}

> UnsupportedOperationException may be thrown when using custom IndexReader
> -
>
> Key: SOLR-1366
> URL: https://issues.apache.org/jira/browse/SOLR-1366
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java), search
>Affects Versions: 1.4
>Reporter: Andrzej Bialecki 
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: searcher.patch, SOLR-1366.patch
>
>
> If a custom IndexReaderFactory is specifiedd in solrconfig.xml, and 
> IndexReader-s that it produces don't support IndexReader.directory() (such as 
> is the case with ParallelReader or MultiReader) then an uncaught 
> UnsupportedOperationException is thrown.
> This call is used only to retrieve the full path of the directory for 
> informational purpose, so it shouldn't lead to a crash. Instead we could 
> supply other available information about the reader (e.g. from its toString() 
> method).

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

[jira] Updated: (SOLR-1447) Simple property injection

2009-09-22 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-1447:
-

Component/s: (was: update)
   Priority: Major  (was: Trivial)

this turned out to be a lot bigger

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

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

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-1449:
-

bq. Note: I've marked this issue as Fix for 1.4 to try and give it some 
visibility before the release since there seems to be some interest in getting 
the release size smaller

I haven't seen the patch yet. But I do not understand why we need to copy the 
jars in the released artifact. We can have some instructions or scripts (I 
assume we don't want ant) to copy the jars to the correct places for running 
solr-cell examples. Is there a problem with that?

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

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

[jira] Resolved: (SOLR-1447) Simple property injection

2009-09-22 Thread Noble Paul (JIRA)


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

Noble Paul resolved SOLR-1447.
--

Resolution: Fixed

committed : r817650
Thanks Jason

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

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

[jira] Commented: (SOLR-1443) Solr Cache is not working

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-1443:
-

Please use the solr-user mailing list for such questions.

http://lucene.apache.org/solr/mailing_lists.html#Users

> Solr Cache is not working
> -
>
> Key: SOLR-1443
> URL: https://issues.apache.org/jira/browse/SOLR-1443
> Project: Solr
>  Issue Type: Bug
>Reporter: satya
>
> I configured filter cache in solrconfig.xml as here under :
> class="solr.FastLRUCache"
>   size="16384"
>   initialSize="4096"
>   autowarmCount="4096"/>   
>   true
>  as per 
> http://wiki.apache.org/solr/SolrCaching#head-b6a7d51521d55fa0c89f2b576b2659f297f9
>   
>And executed a query as: 
> http://localhost:8080/solr/select/?q=*:*&fq=id:(172704 TO 2079813)&sort=id asc
>But when i deleted the doc having id:172704 and executed the query again , 
> i didnt find the same doc(172704 ) in my
>result.
>
>same way i am facing problems while working with documentCache and 
> queryResultCache
> 

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

[jira] Commented: (SOLR-1443) Solr Cache is not working

2009-09-22 Thread satya (JIRA)


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

satya commented on SOLR-1443:
-

Thanks first of all for the clarification.
So ,how does cache affect time ,does it  hold any reference in memory?
And the important thing is, how to test all these.
I am expecting an elaboration. 

> Solr Cache is not working
> -
>
> Key: SOLR-1443
> URL: https://issues.apache.org/jira/browse/SOLR-1443
> Project: Solr
>  Issue Type: Bug
>Reporter: satya
>
> I configured filter cache in solrconfig.xml as here under :
> class="solr.FastLRUCache"
>   size="16384"
>   initialSize="4096"
>   autowarmCount="4096"/>   
>   true
>  as per 
> http://wiki.apache.org/solr/SolrCaching#head-b6a7d51521d55fa0c89f2b576b2659f297f9
>   
>And executed a query as: 
> http://localhost:8080/solr/select/?q=*:*&fq=id:(172704 TO 2079813)&sort=id asc
>But when i deleted the doc having id:172704 and executed the query again , 
> i didnt find the same doc(172704 ) in my
>result.
>
>same way i am facing problems while working with documentCache and 
> queryResultCache
> 

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

[jira] Updated: (SOLR-1447) Simple property injection

2009-09-22 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-1447:
-

Attachment: SOLR-1447.patch

supports both syntax. logs out a warning if the old syntax is used

> Simple property injection 
> --
>
> Key: SOLR-1447
> URL: https://issues.apache.org/jira/browse/SOLR-1447
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SOLR-1447.patch, SOLR-1447.patch, SOLR-1447.patch, 
> SOLR-1447.patch, SOLR-1447.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> MergePolicy and MergeScheduler require property injection.  We'll allow these 
> and probably other cases in this patch using Java reflection.

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

[jira] Resolved: (SOLR-1445) Leading term in a multi-word synonym replaced with the token that follows it

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-1445.
-

Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

Committed revision 817643.

Added the test case.

Thanks Gregg and Robert!

> Leading term in a multi-word synonym replaced with the token that follows it
> 
>
> Key: SOLR-1445
> URL: https://issues.apache.org/jira/browse/SOLR-1445
> Project: Solr
>  Issue Type: Bug
>  Components: Analysis
>Affects Versions: 1.4
> Environment: Solr 1.4 nightly (09/14/2009)
>Reporter: Gregg Donovan
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: TestMultiWordSynonmys.java
>
>
> I'm running into an odd issue with multi-word synonyms. Things generally seem 
> to work as expected, but I sometimes see words that are the leading term in a 
> multi-word synonym being replaced with the token that follows them in the 
> stream when they should just be ignored (i.e. there's no synonym match for 
> just that token). When I preview the analysis at admin/analysis.jsp it looks 
> fine, but at runtime I see problems like the one in the attached unit test.

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

[jira] Commented: (SOLR-1445) Leading term in a multi-word synonym replaced with the token that follows it

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-1445:
-

I've verified it is fixed in trunk with yesterday's lucene upgrade.

> Leading term in a multi-word synonym replaced with the token that follows it
> 
>
> Key: SOLR-1445
> URL: https://issues.apache.org/jira/browse/SOLR-1445
> Project: Solr
>  Issue Type: Bug
>  Components: Analysis
>Affects Versions: 1.4
> Environment: Solr 1.4 nightly (09/14/2009)
>Reporter: Gregg Donovan
> Fix For: 1.4
>
> Attachments: TestMultiWordSynonmys.java
>
>
> I'm running into an odd issue with multi-word synonyms. Things generally seem 
> to work as expected, but I sometimes see words that are the leading term in a 
> multi-word synonym being replaced with the token that follows them in the 
> stream when they should just be ignored (i.e. there's no synonym match for 
> just that token). When I preview the analysis at admin/analysis.jsp it looks 
> fine, but at runtime I see problems like the one in the attached unit test.

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

Build failed in Hudson: Solr-trunk #932

2009-09-22 Thread Apache Hudson Server

See 

--
[...truncated 4386 lines...]
[junit] Running org.apache.solr.analysis.TestReversedWildcardFilterFactory
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.551 sec
[junit] Running org.apache.solr.analysis.TestStopFilterFactory
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.934 sec
[junit] Running org.apache.solr.analysis.TestSynonymFilter
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 4.728 sec
[junit] Running org.apache.solr.analysis.TestSynonymMap
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.768 sec
[junit] Running org.apache.solr.analysis.TestTrimFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.43 sec
[junit] Running org.apache.solr.analysis.TestWordDelimiterFilter
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 36.853 sec
[junit] Running org.apache.solr.client.solrj.SolrExceptionTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.941 sec
[junit] Running org.apache.solr.client.solrj.SolrQueryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.501 sec
[junit] Running org.apache.solr.client.solrj.TestBatchUpdate
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 26.846 sec
[junit] Running org.apache.solr.client.solrj.TestLBHttpSolrServer
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 19.87 sec
[junit] Running org.apache.solr.client.solrj.beans.TestDocumentObjectBinder
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.171 sec
[junit] Running org.apache.solr.client.solrj.embedded.JettyWebappTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 13.274 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.67 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.71 sec
[junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.047 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.223 sec
[junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.384 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.478 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 27.706 sec
[junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
[junit] Tests run: 10, Failures: 1, Errors: 0, Time elapsed: 45.056 sec
[junit] Test org.apache.solr.client.solrj.embedded.SolrExampleJettyTest 
FAILED
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 35.288 sec
[junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.912 sec
[junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.523 sec
[junit] Running 
org.apache.solr.client.solrj.response.AnlysisResponseBaseTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.447 sec
[junit] Running 
org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.452 sec
[junit] Running 
org.apache.solr.client.solrj.response.FieldAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.429 sec
[junit] Running org.apache.solr.client.solrj.response.QueryResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.763 sec
[junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 12.86 sec
[junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.434 sec
[junit] Running org.apache.solr.common.SolrDocumentTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.738 sec
[junit] Running org.apache.solr.common.params.ModifiableSolrParamsTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.838 sec
[junit] Running org.apache.solr.common.params.SolrParamTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.565 sec
[

[jira] Commented: (SOLR-1450) DIH - Jdbc connection properties such as batchSize are not applied if the driver jar is placed in solr_home/lib

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-1450:
-

Thanks for the report and fix Steve!

> DIH - Jdbc connection properties such as batchSize are not applied if the 
> driver jar is placed in solr_home/lib
> ---
>
> Key: SOLR-1450
> URL: https://issues.apache.org/jira/browse/SOLR-1450
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.1.0, 1.2, 1.3, 1.4, 1.5
> Environment: Generic
>Reporter: Steve Sun
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: jdbc-817524.loadClass.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
> page of Solr wiki), but not in tomcat's lib directory, the JDBC connection 
> will not be configured as specified in the DIH configuration.  Attributes 
> like autoCommit, readOnly and batchSize will be ignored.

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

[jira] Updated: (SOLR-1450) DIH - Jdbc connection properties such as batchSize are not applied if the driver jar is placed in solr_home/lib

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar updated SOLR-1450:


Summary: DIH - Jdbc connection properties such as batchSize are not applied 
if the driver jar is placed in solr_home/lib  (was: DIH import "out of memory" 
problem (batchSize and autoCommit not working))

> DIH - Jdbc connection properties such as batchSize are not applied if the 
> driver jar is placed in solr_home/lib
> ---
>
> Key: SOLR-1450
> URL: https://issues.apache.org/jira/browse/SOLR-1450
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.1.0, 1.2, 1.3, 1.4, 1.5
> Environment: Generic
>Reporter: Steve Sun
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: jdbc-817524.loadClass.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
> page of Solr wiki), but not in tomcat's lib directory, the JDBC connection 
> will not be configured as specified in the DIH configuration.  Attributes 
> like autoCommit, readOnly and batchSize will be ignored.

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

[jira] Resolved: (SOLR-1450) DIH - Jdbc connection properties such as batchSize are not applied if the driver jar is placed in solr_home/lib

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar resolved SOLR-1450.
-

Resolution: Fixed

Committed revision 817634.

> DIH - Jdbc connection properties such as batchSize are not applied if the 
> driver jar is placed in solr_home/lib
> ---
>
> Key: SOLR-1450
> URL: https://issues.apache.org/jira/browse/SOLR-1450
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.1.0, 1.2, 1.3, 1.4, 1.5
> Environment: Generic
>Reporter: Steve Sun
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: jdbc-817524.loadClass.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
> page of Solr wiki), but not in tomcat's lib directory, the JDBC connection 
> will not be configured as specified in the DIH configuration.  Attributes 
> like autoCommit, readOnly and batchSize will be ignored.

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

[jira] Updated: (SOLR-1450) DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar updated SOLR-1450:


Fix Version/s: 1.4
 Assignee: Shalin Shekhar Mangar

> DIH import "out of memory" problem (batchSize and autoCommit not working)
> -
>
> Key: SOLR-1450
> URL: https://issues.apache.org/jira/browse/SOLR-1450
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.1.0, 1.2, 1.3, 1.4, 1.5
> Environment: Generic
>Reporter: Steve Sun
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: jdbc-817524.loadClass.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
> page of Solr wiki), but not in tomcat's lib directory, the JDBC connection 
> will not be configured as specified in the DIH configuration.  Attributes 
> like autoCommit, readOnly and batchSize will be ignored.

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

[jira] Issue Comment Edited: (SOLR-1450) DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Steve Sun (JIRA)


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

Steve Sun edited comment on SOLR-1450 at 9/22/09 2:28 AM:
--

Move the connection setup code out of the try...catch block.


  was (Author: steve.sun):
Index: 
contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
===
--- 
contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
  (revision 817524)
+++ 
contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
  (working copy)
@@ -153,6 +153,15 @@
   "the jndi name : '"+jndiName +"' is not a valid 
javax.sql.DataSource");
 }
   }
+} catch (SQLException e) {
+  // DriverManager does not allow you to use a driver which is not 
loaded through
+  // the class loader of the class which is trying to make the 
connection.
+  // This is a workaround for cases where the user puts the driver jar 
in the
+  // solr.home/lib or solr.home/core/lib directories.
+  Driver d = (Driver) DocBuilder.loadClass(driver, 
context.getSolrCore()).newInstance();
+  c = d.connect(url, initProps);
+}
+if (c != null) {
   if (Boolean.parseBoolean(initProps.getProperty("readOnly"))) {
 c.setReadOnly(true);
 // Add other sane defaults
@@ -181,13 +190,6 @@
   } else {
 c.setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT);
   }
-} catch (SQLException e) {
-  // DriverManager does not allow you to use a driver which is not 
loaded through
-  // the class loader of the class which is trying to make the 
connection.
-  // This is a workaround for cases where the user puts the driver jar 
in the
-  // solr.home/lib or solr.home/core/lib directories.
-  Driver d = (Driver) DocBuilder.loadClass(driver, 
context.getSolrCore()).newInstance();
-  c = d.connect(url, initProps);
 }
 LOG.info("Time taken for getConnection(): "
 + (System.currentTimeMillis() - start));

  
> DIH import "out of memory" problem (batchSize and autoCommit not working)
> -
>
> Key: SOLR-1450
> URL: https://issues.apache.org/jira/browse/SOLR-1450
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.1.0, 1.2, 1.3, 1.4, 1.5
> Environment: Generic
>Reporter: Steve Sun
> Attachments: jdbc-817524.loadClass.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
> page of Solr wiki), but not in tomcat's lib directory, the JDBC connection 
> will not be configured as specified in the DIH configuration.  Attributes 
> like autoCommit, readOnly and batchSize will be ignored.

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

Re: DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Steve Sun

2009/9/22 Shalin Shekhar Mangar 

> On Tue, Sep 22, 2009 at 2:29 PM, Steve Sun  wrote:
>
> > Hi,
> >
> > I spent a whole day trying to make "batchSize" work for JdbcDataSource
> with
> > "org.postgresql.Driver", but got frustrated.  At last I took a look into
> > DIH's source code and found that there's actually a bug in there.  When
> JDBC
> > driver is placed in /lib (as instructed by DIHQuickStart page
> of
> > Solr wiki), but not in tomcat's lib directory, the JDBC connection will
> not
> > be configured as specified in the DIH configuration at all.  Attributes
> like
> > autoCommit, readOnly and batchSize will be ignored.  The fix is simple,
> have
> > attached my patch.
> >
> (contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
> > r817524)
> >
> > One work-around is: place your JDBC driver jar under tomcat's application
> > lib directory.  e.g., tomcat/webapps/solr/WEB-INF/lib/
> >
> > Have only tested with postgresql drivers, but seems the problem is
> generic
> > to all drivers placed in /lib.
> >
>
> Thanks Steve. The mailing list removed your attachment. Can you please open
> a jira issue and attach a patch there?
>
>
Done.
http://issues.apache.org/jira/browse/SOLR-1450

--
> Regards,
> Shalin Shekhar Mangar.
>

[jira] Updated: (SOLR-1450) DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Steve Sun (JIRA)


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

Steve Sun updated SOLR-1450:


Attachment: jdbc-817524.loadClass.patch

Index: 
contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
===
--- 
contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
  (revision 817524)
+++ 
contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
  (working copy)
@@ -153,6 +153,15 @@
   "the jndi name : '"+jndiName +"' is not a valid 
javax.sql.DataSource");
 }
   }
+} catch (SQLException e) {
+  // DriverManager does not allow you to use a driver which is not 
loaded through
+  // the class loader of the class which is trying to make the 
connection.
+  // This is a workaround for cases where the user puts the driver jar 
in the
+  // solr.home/lib or solr.home/core/lib directories.
+  Driver d = (Driver) DocBuilder.loadClass(driver, 
context.getSolrCore()).newInstance();
+  c = d.connect(url, initProps);
+}
+if (c != null) {
   if (Boolean.parseBoolean(initProps.getProperty("readOnly"))) {
 c.setReadOnly(true);
 // Add other sane defaults
@@ -181,13 +190,6 @@
   } else {
 c.setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT);
   }
-} catch (SQLException e) {
-  // DriverManager does not allow you to use a driver which is not 
loaded through
-  // the class loader of the class which is trying to make the 
connection.
-  // This is a workaround for cases where the user puts the driver jar 
in the
-  // solr.home/lib or solr.home/core/lib directories.
-  Driver d = (Driver) DocBuilder.loadClass(driver, 
context.getSolrCore()).newInstance();
-  c = d.connect(url, initProps);
 }
 LOG.info("Time taken for getConnection(): "
 + (System.currentTimeMillis() - start));


> DIH import "out of memory" problem (batchSize and autoCommit not working)
> -
>
> Key: SOLR-1450
> URL: https://issues.apache.org/jira/browse/SOLR-1450
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.1.0, 1.2, 1.3, 1.4, 1.5
> Environment: Generic
>Reporter: Steve Sun
> Attachments: jdbc-817524.loadClass.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
> page of Solr wiki), but not in tomcat's lib directory, the JDBC connection 
> will not be configured as specified in the DIH configuration.  Attributes 
> like autoCommit, readOnly and batchSize will be ignored.

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

[jira] Created: (SOLR-1450) DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Steve Sun (JIRA)

DIH import "out of memory" problem (batchSize and autoCommit not working)
-

 Key: SOLR-1450
 URL: https://issues.apache.org/jira/browse/SOLR-1450
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.3, 1.2, 1.1.0, 1.4, 1.5
 Environment: Generic
Reporter: Steve Sun


When JDBC driver is placed in /lib (as instructed by DIHQuickStart 
page of Solr wiki), but not in tomcat's lib directory, the JDBC connection will 
not be configured as specified in the DIH configuration.  Attributes like 
autoCommit, readOnly and batchSize will be ignored.

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

Re: DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Shalin Shekhar Mangar

On Tue, Sep 22, 2009 at 2:29 PM, Steve Sun  wrote:

> Hi,
>
> I spent a whole day trying to make "batchSize" work for JdbcDataSource with
> "org.postgresql.Driver", but got frustrated.  At last I took a look into
> DIH's source code and found that there's actually a bug in there.  When JDBC
> driver is placed in /lib (as instructed by DIHQuickStart page of
> Solr wiki), but not in tomcat's lib directory, the JDBC connection will not
> be configured as specified in the DIH configuration at all.  Attributes like
> autoCommit, readOnly and batchSize will be ignored.  The fix is simple, have
> attached my patch.
> (contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
> r817524)
>
> One work-around is: place your JDBC driver jar under tomcat's application
> lib directory.  e.g., tomcat/webapps/solr/WEB-INF/lib/
>
> Have only tested with postgresql drivers, but seems the problem is generic
> to all drivers placed in /lib.
>

Thanks Steve. The mailing list removed your attachment. Can you please open
a jira issue and attach a patch there?

-- 
Regards,
Shalin Shekhar Mangar.

DIH import "out of memory" problem (batchSize and autoCommit not working)

2009-09-22 Thread Steve Sun

Hi,

I spent a whole day trying to make "batchSize" work for JdbcDataSource with
"org.postgresql.Driver", but got frustrated.  At last I took a look into
DIH's source code and found that there's actually a bug in there.  When JDBC
driver is placed in /lib (as instructed by DIHQuickStart page of
Solr wiki), but not in tomcat's lib directory, the JDBC connection will not
be configured as specified in the DIH configuration at all.  Attributes like
autoCommit, readOnly and batchSize will be ignored.  The fix is simple, have
attached my patch.
(contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java
r817524)

One work-around is: place your JDBC driver jar under tomcat's application
lib directory.  e.g., tomcat/webapps/solr/WEB-INF/lib/

Have only tested with postgresql drivers, but seems the problem is generic
to all drivers placed in /lib.

Regards,
Steve

Re: [jira] Commented: (SOLR-1374) When a test fails, display the test file in the console via ant junit

2009-09-22 Thread Erik Hatcher



On Sep 19, 2009, at 11:35 AM, Yonik Seeley (JIRA) wrote:
Related - what's the reason that we use XML formatting for junit  
output?  Is it for hudson or something?  It's more difficult to read  
by hand.  Last I checked, it also causes all output to be buffered  
before it's comverted to XML in one shot - in the past this has lead  
to out-of-memory errors when running junit based stress tests from  
the command line.


It's so you can generate a readable and navigable report using "ant  
test-reports".


But if it's a hindrance, by all means turn off XML reporting.

Erik

Solr Nightly: build failed -- site not found (missing dir for maven?)

2009-09-22 Thread seanoc5


Hi all,
   I had an error message on several recent nightly builds. The error for me
arose with:
ant generate-maven-artifacts

   It seems the answer for my problem was simply creating the (missing)
folder "./site" in the base of the solr code folder. Should that be put into
the archive files to help avoid confusing those of us on the left side of
the learning curve?

   FWIW: I am trying the maven artifacts because I can't quite get Intellij
IDEA to import or checkout the code in a clean/simple way and I _think_ IDEA
handles maven projects a bit easier. 
Thanks,

Sean
-- 
View this message in context: 
http://www.nabble.com/Solr-Nightly%3A-build-failedsite-not-found-%28missing-dir-for-maven-%29-tp25530623p25530623.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

58 matches

Mail list logo