Hi all,
I've installed solr on a RHEL 5 server and it fails to start properly
- apparently it's failed to create or find index files.
when running :
nohup /usr/java/jdk1.5.0_14/bin/java -jar -Xmx1024m -Xms1024m start.jar &
I get the following in nohup
27-Nov-2007 15:57:42 org.apache.solr.core.So
[
https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546249
]
Will Johnson commented on SOLR-421:
---
it would also be good to make the same changes to all of the solrj library
clas
-
java.lang.RuntimeException: java.io.FileNotFoundException: no
segments* file found in
org.apache.lucene.store.FSDirectory@/usr/local/apache-solr-1.2.0/slando/solr/data/index:
files:
The configuration is identical to a working instal
On 28/11/2007, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> >
> > -
> > java.lang.RuntimeException: java.io.FileNotFoundException: no
> > segments* file found in
> > org.apache.lucene.store.FSDirectory@/usr/local/apache-solr-1.2.0/slando/s
On Nov 28, 2007 4:45 AM, Aaron Trevena <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've installed solr on a RHEL 5 server and it fails to start properly
> - apparently it's failed to create or find index files.
>
> when running :
> nohup /usr/java/jdk1.5.0_14/bin/java -jar -Xmx1024m -Xms1024m start.ja
Aaron Trevena wrote:
On 28/11/2007, Ryan McKinley <[EMAIL PROTECTED]> wrote:
-
java.lang.RuntimeException: java.io.FileNotFoundException: no
segments* file found in
org.apache.lucene.store.FSDirectory@/usr/local/apache-solr-1.2.0/slan
I'm pretty sure i restarted solr after adding some stopwords (look, need) to
stopwords.txt and a synonym like
LLC => limited liability company to synonyms.txt
But for some reason, i still see the stop words like 'look', 'need' in the
parsedquery_toString when debugQuery is turned on.
And no resul
On Nov 28, 2007 12:01 PM, anuvenk <[EMAIL PROTECTED]> wrote:
> My index data is grouped in to categories. For certain search terms , results
> from 'forms' category comes up first. Similar results exist in 'premium
> forms' category too..But they are pushed to the bottom of the result set.
> But id
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-417:
--
Assignee: Ryan McKinley
> Move SortSpec to top level class and cleanup
>
On 28/11/2007, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> I'm only talking about the data, not the configs. From the error it
> looks like your index is broken. If you can rebuild it that is probably
> the best option. If you have a backup elsewhere, that should also work.
Deleting the index di
On 28/11/2007, Aaron Trevena <[EMAIL PROTECTED]> wrote:
> On 28/11/2007, Ryan McKinley <[EMAIL PROTECTED]> wrote:
> > I'm only talking about the data, not the configs. From the error it
> > looks like your index is broken. If you can rebuild it that is probably
> > the best option. If you have a
: > Deleting the index directory and restarting seems like the plan - I'll
: > try that next.
:
: Tried this - it worked.
Just to be very explicit about this for posterity: the dataDir (as
specified in the solrconfig.xml, or the default of "data" in the solr home
dir) must exist when you start
SolrRequestHandler close notification
-
Key: SOLR-423
URL: https://issues.apache.org/jira/browse/SOLR-423
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: G
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-423:
-
Attachment: SOLR-423.patch
Draft patch that implements close() callback on the SolrRequestHandler a
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-417.
Resolution: Fixed
committed in #599071
> Move SortSpec to top level class and cleanup
>
On 28/11/2007, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> Incidently: this thread probably should have been on solr-user.
Yes - drat!
I thought I subscribed to the solr-user list!
sorry
A.
--
http://www.aarontrevena.co.uk
LAMP System Integration, Development and Hosting
If you are using a standard lucene query, add it as a clause
+text:foo category:premium^10
If you are using dismax, add it via bq (a boosting query)
bq=category:premium^10
-Yonik
On Nov 28, 2007 4:01 PM, anuvenk <[EMAIL PROTECTED]> wrote:
>
> Hi, Forgive me if this question is silly..did u mea
Hi, Forgive me if this question is silly..did u mean adding the param
qf=category:premium forms^10 to the request to solr? Anything else to be
added?
Yonik Seeley wrote:
>
> On Nov 28, 2007 12:01 PM, anuvenk <[EMAIL PROTECTED]> wrote:
>> My index data is grouped in to categories. For certain se
I'm trying to write some tests for SOLR-418 and I can't tell if this is
a real error or that I'm using the TestHarness incorrectly. I don't see
this error running the site normally.
The test is setup like this:
1. add docs and commit
2. query check results
3. query check results
...
The secon
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546427
]
ryantxu edited comment on SOLR-423 at 11/28/07 2:02 PM:
--
Aaaah that freaking interface! S
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546427
]
Ryan McKinley commented on SOLR-423:
Aaaah that freaking interface! So far, we have not broken API compatibility i
To duplicate the same error on trunk, add a 'sort asc' test to
StandardRequestHandlerTest
Index: StandardRequestHandlerTest.java
===
--- StandardRequestHandlerTest.java (revision 599100)
+++ StandardRequestHandlerTest.java (
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546434
]
Hoss Man commented on SOLR-423:
---
i was thinking the same thing about #1 but that got me thinking that instead of
SolrCor
On Nov 28, 2007, at 5:02 PM, Ryan McKinley (JIRA) wrote:
with java 1.5 this could be:
for( SolrRequestHandler handler : handlers ) {
handler.close();
}
Old habits die hard. Especially when I am so used to typing "itco" in
IntelliJ for the Live Template mechanism.
: The test is setup like this:
: 1. add docs and commit
: 2. query check results
: 3. query check results
: ...
Hmmm.. can you post the test, that works fine in a lot of existing tests.
-Hoss
I tried bq=resourceType:Premium%20Forms^10. But it didn't make any
difference.
You can see the results here:
http://h9.lawinfo.com:8080/solr/select?indent=on&version=2.2&q=ca+incorporation&start=0&rows=10&fl=*%2Cscore&qt=qfacet&wt=standard&debugQuery=on&explainOther=&hl.fl=&bq=resourceType:Premium
H... the problem doesn't seem to be related to sorting at all, it
looks like it has to do with the fact that most of the tests are reusing
the same LocalSolrQueryRequest object over and over (just changing the
params) assertQ calls close() on the request object, which decrements
some refr
: I tried bq=resourceType:Premium%20Forms^10. But it didn't make any
: difference.
: You can see the results here:
look at the parsedquery_toString in the debug section of your responses.
the space in your value makes it parse as resourceType:Premium
text:form^10
try bq=resourceType:"Premium%
That worked. Perfect. thanks.
hossman wrote:
>
>
> : I tried bq=resourceType:Premium%20Forms^10. But it didn't make any
> : difference.
> : You can see the results here:
>
> look at the parsedquery_toString in the debug section of your responses.
> the space in your value makes it parse as r
Yeah, SolrQueryRequest classes weren't really meant for re-use.
In general, we shouldn't re-use them for tests since they aren't
reused for normal requests.
nulling the searcher ref on a close may be a nice safety precaution though.
-Yonik
On Nov 28, 2007 6:13 PM, Chris Hostetter <[EMAIL PROTECT
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546526
]
Koji Sekiguchi commented on SOLR-414:
-
Ryan,
On SOLR-319, I'd like SynonymFilterFactory to implement SolrCoreAware
[
https://issues.apache.org/jira/browse/SOLR-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546539
]
Yonik Seeley commented on SOLR-424:
---
I believe the underlying issue is that there isn't validation during indexing.
A
[
https://issues.apache.org/jira/browse/SOLR-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kurt Schrader updated SOLR-424:
---
Attachment: fix_ruby_output.patch
Here is a patch for the issue. The code seems to be untested, along
The ruby output type produces incorrect output for numeric types without a value
Key: SOLR-424
URL: https://issues.apache.org/jira/browse/SOLR-424
Project: Solr
[
https://issues.apache.org/jira/browse/SOLR-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-424:
--
Attachment: zero_length_int.patch
Attaching patch for the output side of things.
> The ruby output type
35 matches
Mail list logo