But sir
fileSize is of type string, how will it compare?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Can-files-be-faceted-based-on-their-size-tp3518393p3520569.html
Sent from the Solr - User mailing list archive at Nabble.com.
@topcat: you need to call close() method for solr request after using them.
In general,
SolrQueryRequest request = new SolrQueryRequest();
try {
.
} finally {
request.close();
}
--
View this message in context:
http://lucene.472066.n3.nabble.com/fieldCache-problem-OOM-exception-tp30670
@topcat: you need to call close() method for solr request after using them.
In general,
SolrQueryRequest request = new SolrQueryRequest();
try {
.
} finally {
request.close();
}
--
View this message in context:
http://lucene.472066.n3.nabble.com/fieldCache-problem-OOM-exception-tp30670
Hi,
When we pass the terms.limit parameter to the master (which has many shard
cores), it's not getting pushed down to the individual cores. Instead the
default value of -1 is assigned to Terms.limit parameter is assigned in the
underlying shard cores. The issue being the time taken by the Master
test
--
View this message in context:
http://lucene.472066.n3.nabble.com/Jetty-logging-tp3476715p3520897.html
Sent from the Solr - User mailing list archive at Nabble.com.
Im sure that my deltaQueries are causing this issue, but I have the
logging turned on the FINEST. It would be great if this Exception was
handles properly and the failing PK test was also displayed. I will
open a Jira for this request, but does anyone have any pointers on how
to determine which d
On Nov 19, 2011, at 4:19 AM, mechravi25 wrote:
> Hi,
>
> When we pass the terms.limit parameter to the master (which has many shard
> cores), it's not getting pushed down to the individual cores. Instead the
> default value of -1 is assigned to Terms.limit parameter is assigned in the
> underlyi
Hello,
I use solr 3.4 with jetty that is included in it. Periodically, I see this
error in the jetty output
SEVERE: org.mortbay.jetty.EofException
at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:791)
at
org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerat
It's not Jetty. It is broken TCP pipe due to client-side. It happens when
client closes TCP connection.
And I even had this problem with recent Tomcat 6.
Problem disappeared after I explicitly tuned keep-alive at Tomcat, and started
using "monitoring thread" with HttpClient and SOLRJ...
Fuad
I found out that curl timeout was set to 10 and for queries taking longer than
10 sec it was closing connection to jetty.
I noticed that when number of docs found is large solr returns results for
about 20 sec. This is too long. I set caching to off but it did not help.
I think solr spends too mu
10 matches
Mail list logo