init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web
compile-solrj:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj
[javac] Compiling 87 source files to /tmp/apache-solr-nightly/build/solrj
On Oct 20, 2009, at 7:52 PM, Yonik Seeley wrote:
Actually just copying the example schema to contrib seemed to work
fine... those should probably be kept in alignment regardless of if we
decide to do something different about the data directory.
Then maybe we should use an svn:external? Exc
[
https://issues.apache.org/jira/browse/SOLR-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved SOLR-1403.
---
Resolution: Won't Fix
SolrJS has been moved to a third party repository
> solrjs broken when
ValueSource/DocValues returning multiple values per document
-
Key: SOLR-1518
URL: https://issues.apache.org/jira/browse/SOLR-1518
Project: Solr
Issue Type: Improvement
bq. and Mark is representing "just keep working, ok?".
But I'm not :) Like I said, I don't view the purpose of a soft value
cache as avoiding OOM's. Size your caches correctly for that.
For those that don't understand the how and why of soft value caches,
they probably should not choose to use i
Grant,
Subversion started supporting externals on single files with version
1.6, so depending on what's running you could do it.
On Oct 21, 2009, at 6:39 AM, Grant Ingersoll wrote:
On Oct 20, 2009, at 7:52 PM, Yonik Seeley wrote:
Actually just copying the example schema to contrib seeme
Here's an interesting warning in the failed TestLBHttpSolrServer logs:
WARNING: SimpleHttpConnectionManager being used incorrectly. Be sure
that HttpMethod.releaseConnection() is always called and that only on
e thread and/or method is using this connection manager at a time.
The test failure th
This code would be more deterministic with a sleep for 1 second after
stopping the thread. This would allow the thread machinations to
finish.
solr[0].jetty.stop();
solr[0].jetty = null;
->Thread.sleep(1000);
resp = lbHttpSolrServer.query(solrQuery);
On Wed, Oct 21, 2009 at 6:49 AM, Yon
On Wed, Oct 21, 2009 at 3:57 PM, Lance Norskog wrote:
> This code would be more deterministic with a sleep for 1 second after
> stopping the thread. This would allow the thread machinations to
> finish.
I considered that, but jetty.stop() looks like this:
public void stop() throws Exception
why it takes more and more time with small rows but increased start across
distributed Solr
-
Key: SOLR-1519
URL: https://issues.apache.org/jira/browse/SOLR-1519
[
https://issues.apache.org/jira/browse/SOLR-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
johnson.hong updated SOLR-1519:
---
Description:
Hi,
I get a problem on Distributed Search:
There are 5 shards in my system, and I
[
https://issues.apache.org/jira/browse/SOLR-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-1519.
-
Resolution: Invalid
Please ask such questions on the solr-user mailing list before
I'm looking through a bunch of logs that have:
UpdateRequestProcessor - {add=[aa, bb, cc, dd, ee, ff, gg, hh, ...(142 more)]}
Would it be more reasonable to say: "150 total" rather then make you
count the previous 8?
kinda stupid, but i guess this is what drives you nuts while chasing
real proble
On Thu, Oct 22, 2009 at 9:14 AM, Ryan McKinley wrote:
> I'm looking through a bunch of logs that have:
> UpdateRequestProcessor - {add=[aa, bb, cc, dd, ee, ff, gg, hh, ...(142
> more)]}
>
> Would it be more reasonable to say: "150 total" rather then make you
> count the previous 8?
>
+1
--
Reg
On Wed, Oct 21, 2009 at 11:44 PM, Ryan McKinley wrote:
> I'm looking through a bunch of logs that have:
> UpdateRequestProcessor - {add=[aa, bb, cc, dd, ee, ff, gg, hh, ...(142 more)]}
>
> Would it be more reasonable to say: "150 total" rather then make you
> count the previous 8?
Yep, I did reco
[
https://issues.apache.org/jira/browse/SOLR-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768563#action_12768563
]
johnson.hong commented on SOLR-1519:
thank you for your answer,
but I don't understand t
On Wed, Oct 21, 2009 at 6:34 PM, Mark Miller wrote:
> bq. and Mark is representing "just keep working, ok?".
>
> But I'm not :) Like I said, I don't view the purpose of a soft value
> cache as avoiding OOM's. Size your caches correctly for that.
>
> For those that don't understand the how and why
QueryElevationComponent does not work when unique key is of type 'sint'
---
Key: SOLR-1520
URL: https://issues.apache.org/jira/browse/SOLR-1520
Project: Solr
Issue Type: Bug
18 matches
Mail list logo
