[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404429#comment-13404429
]
Uwe Schindler commented on LUCENE-4123:
---
You should make the II correctly throw IOE
Hi Steve.
So, the problem is that POM descriptors declare:
1
and then:
${tests.iters}
This effectively overrides any annotations (@Repeat) and thus the
assertion failure. It'd be better if this property was empty by
default (as in the ant build). I'll fix the test too anyway.
[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikola Tankovic updated LUCENE-3312:
Attachment: lucene-3312-patch-06.patch
Patch 06: summary of discussions. If we can somewha
[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404433#comment-13404433
]
Nikola Tankovic edited comment on LUCENE-3312 at 6/30/12 9:40 AM:
-
[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404449#comment-13404449
]
Uwe Schindler commented on LUCENE-3312:
---
Hi Nikola,
I will think about the core API
[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404450#comment-13404450
]
Nikola Tankovic commented on LUCENE-3312:
-
Agreed! No problem about commit access
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404452#comment-13404452
]
Uwe Schindler commented on LUCENE-4123:
---
When thinking more about the patch:
Can we
[
https://issues.apache.org/jira/browse/LUCENE-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudarshan Gaikaiwari updated LUCENE-3842:
-
Attachment: LUCENE-3842.patch
> Analyzing Suggester
> ---
>
[
https://issues.apache.org/jira/browse/LUCENE-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404537#comment-13404537
]
Sudarshan Gaikaiwari commented on LUCENE-3842:
--
bq. maybe we can tie-break i
[
https://issues.apache.org/jira/browse/LUCENE-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2188:
--
Fix Version/s: (was: 4.0)
3.1
> A handy utility class for tracking
[
https://issues.apache.org/jira/browse/LUCENE-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2183:
--
Fix Version/s: (was: 4.0)
3.1
> Supplementary Character Handling in
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404629#comment-13404629
]
Toke Eskildsen commented on LUCENE-4062:
In the hope of getting a better overview
Mikhail Khludnev created SOLR-3585:
--
Summary: processing updates in multiple threads
Key: SOLR-3585
URL: https://issues.apache.org/jira/browse/SOLR-3585
Project: Solr
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/SOLR-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-3585:
---
Attachment: multithreadupd.patch
> processing updates in multiple threads
> --
[
https://issues.apache.org/jira/browse/SOLR-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-3585:
---
Description:
Hello,
I'd like to contribute update processor which forks many threads which
c
[
https://issues.apache.org/jira/browse/LUCENE-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404656#comment-13404656
]
Michael McCandless commented on LUCENE-4161:
bq. The meaning of n is actually
Nothing?
Bill Bell
Sent from mobile
On Jun 29, 2012, at 9:09 PM, Bill Bell wrote:
> We are getting large Solr pauses on Java garbage collection in 1.6 Java.
>
> We have tried CMS. But we still have. 4 second wait on GC.
>
> What works well for Solr when using 16 GB of RAM?
>
> I have read l
[
https://issues.apache.org/jira/browse/SOLR-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13404666#comment-13404666
]
David Smiley commented on SOLR-1770:
+1 to remove the multicore example. Furthermore,
Bill,
As you know, it really depends on the size of your index combined with which
features you're using. There is really no substitute for having a good load
test and monitoring tool and to run multiple tests while trying different
settings.
My guess is that you're experiencing "full" gc's,
Is that a 4 second or 0.4 second wait?
You can benchmark the different collectors yourself.
CMS is probably the best choice.
If you have more heap than you need, then the collections will be longer than
necessary. At some point, the collector has to look at all of the heap and that
is slow. T
Out of curiosity, how long does your Solr instance run before you hit a GC
issue? Minutes, hours, days? If reasonably long, maybe you simply need to
periodically take each Solr instance out of rotation and shut it down and
restart the JVM before any of them hit the GC issue.
The first question
Build:
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java7-64/288/
All tests passed
Build Log:
[...truncated 1434 lines...]
[junit4] 2012-07-01 06:02:26
[junit4] Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed
mode):
[junit4]
[junit4]
"TEST-TestSc
It GC after about 10 minutes.
Bill Bell
Sent from mobile
On Jun 30, 2012, at 10:48 PM, "Jack Krupansky" wrote:
> Out of curiosity, how long does your Solr instance run before you hit a GC
> issue? Minutes, hours, days? If reasonably long, maybe you simply need to
> periodically take each Sol
23 matches
Mail list logo
