I think this exception should be thrown only when the bytes land in the
Directory. I think that in general we buffer bytes before sending them to
the actual IndexOutput? I don't know if this is done with RAMDir too i.e.
that there isn't code out there that buffers its writes to any IndexOutput,
On Thu, May 16, 2013 at 8:45 AM, Adrien Grand jpou...@gmail.com wrote:
Using the Mock IndexOutput to track bytes is an option, but I was
thinking it could be interesting too to see what happens with
directories that buffer content so that the disk full exception
happens in flush instead of
[
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659676#comment-13659676
]
Shawn Heisey commented on SOLR-4773:
[~andyfowler] - I finally found some time and
[
https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-4829:
---
Attachment: SOLR-4829.patch
Here's another version that cleans up tlog references during tlog
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/458/
Java: 64bit/jdk1.6.0 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 1523 lines...]
[javac] Compiling 392 source files to
: (b) is unlikely. Dump the allocation tree and see what's the major
: contributor to the size.
Right, see rmuir's response and the subsequent collection of aggregation
of info in my comment on SOLR-4825...
https://issues.apache.org/jira/browse/SOLR-4825#comment-13659117
-Hoss
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/328/
1 tests failed.
REGRESSION: org.apache.solr.cloud.ShardSplitTest.testDistribSearch
Error Message:
Wrong doc count on shard1_0 expected:125 but was:124
Stack Trace:
java.lang.AssertionError: Wrong doc count on shard1_0 expected:125
My suspicion is that its that map key'ed on solrcore.
in this case it would be holding references to SolrCores from previous
tests. Because test order and other things are randomized, it would
explain the huge size fluctuations.
On Thu, May 16, 2013 at 12:35 PM, Chris Hostetter
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5623/
Java: 32bit/jdk1.6.0_45 -client -XX:+UseSerialGC
All tests passed
Build Log:
[...truncated 1574 lines...]
[javac] Compiling 392 source files to
[
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659699#comment-13659699
]
Mark Miller commented on SOLR-4773:
---
I don't know that it would be that easy - I honestly
[
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659703#comment-13659703
]
Shawn Heisey commented on SOLR-4773:
bq. at this point, we are where we are, and I can
What's a little odd is that this should work exactly as it did before we used
log4j - I just pure copied the code from a Formatter to a Layout. I originally
suspected that the Layout is holding onto stuff, but thought perhaps that had
something to do with java util logging vs log4j, since this
Looking at the code, I think that today flush() cannot throw diskFullEx?
MockIO checks for diskFull in writeBytes and copyBytes, using
dir.sizeInBytes.
So I think if you limit maxSize=5 and write 4 + 4 bytes, to a Directory
with a buffer of 20 bytes, then both writeBytes will succeed (as
On May 16, 2013, at 12:59 PM, Mark Miller markrmil...@gmail.com wrote:
In any case, it seems likely we can improve the Layout - I can take a look.
Seems like we could get away with just using SolrCore#hashCode rather than
keying by the SolrCore.
- Mark
Hoss Man created SOLR-4833:
--
Summary: All(most all) Logger instances should be made static
Key: SOLR-4833
URL: https://issues.apache.org/jira/browse/SOLR-4833
Project: Solr
Issue Type: Improvement
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/259/
All tests passed
Build Log:
[...truncated 1578 lines...]
[javac] Compiling 392 source files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-4.x/lucene/build/analysis/common/classes/java
[javac]
: What's a little odd is that this should work exactly as it did before we
It just occured to me that one thing rmuir and i noticed in IRC never made
it into email or my jira comments: the Logger used by SolrRequestParsers
is not static, so the mem estimator would count that as ram used by
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5624/
Java: 32bit/jdk1.8.0-ea-b89 -client -XX:+UseG1GC
All tests passed
Build Log:
[...truncated 1435 lines...]
[javac] Compiling 392 source files to
These look like serious problems? Looks like the build is broken such
that analyzers is trying to pull in queryparser
On Thu, May 16, 2013 at 1:27 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/259/
All tests
I'm testing a patch right now and then i'll commit. the trick here is
to instead use a link like this:
a href={@docRoot}/../queryparser/overview-summary.htmlQueryParser/a
(since it really applies to all queryparsers anyway).
and its ok because if something is wrong our python linkchecker will
: I'm testing a patch right now and then i'll commit. the trick here is
: to instead use a link like this:
i just commited a change to not use a jdoc link at all actually
that's consistent with how FilteringTokenFilter refers to the same method
:
: a
FYI we currently have:
[exec] Crawl/parse...
[exec]
[exec]
file:///build/docs/analyzers-common/org/apache/lucene/analysis/util/FilteringTokenFilter.html
[exec] WARNING: anchor version appears more than once
I forget why this is a warning and not a hard fail, but we
On Thu, May 16, 2013 at 1:53 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: I'm testing a patch right now and then i'll commit. the trick here is
: to instead use a link like this:
i just commited a change to not use a jdoc link at all actually
that's consistent with how
Thanks Mike!
I had arrived at the same fix, but didnt' commit because the smoke tester was
also complaining (after running for 30 minutes) about Solr's NOTICE.txt not
having a verbatim copy of Lucene's NOTICE.txt - this is as a result of my
changing the text in Lucene's NOTICE.txt about
[
https://issues.apache.org/jira/browse/LUCENE-4989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659825#comment-13659825
]
Jessica Cheng commented on LUCENE-4989:
---
Thanks for the quick replies guys. Simon,
BUILD SUCCESSFUL on branch_4x for me - hopefully these javax.servlet issues are
all cleared up now. - Steve
On May 16, 2013, at 2:34 PM, Steve Rowe sar...@gmail.com wrote:
Thanks Mike!
I had arrived at the same fix, but didnt' commit because the smoke tester was
also complaining (after
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/472/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 9133 lines...]
[junit4:junit4] ERROR: JVM J0 ended with an exception, command line:
I'm experimenting with an IndexReader design over Accumulo and am wondering
what valid DocValues types are for norms in the FieldInfo constructor.
The actual fieldNorms method returns a numericDocValues, and norms have
historically always been numeric values. Is numeric the only valid type
here
[
https://issues.apache.org/jira/browse/SOLR-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659915#comment-13659915
]
yuanyun.cn commented on SOLR-1093:
--
Just found one small issue in the code.
If we put
[
https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-4816:
-
Attachment: SOLR-4816.patch
To get the existing tests to run I needed to limit the directUpdates
[
https://issues.apache.org/jira/browse/SOLR-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Bower resolved SOLR-4831.
Resolution: Duplicate
Transaction logs are leaking
[
https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659947#comment-13659947
]
Steven Bower commented on SOLR-4829:
I patched my 4.3.0 install with the attached patch
[
https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659950#comment-13659950
]
Joel Bernstein commented on SOLR-4816:
--
Existing tests now run with latest patch.
[
https://issues.apache.org/jira/browse/SOLR-4823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659604#comment-13659604
]
philip hoy edited comment on SOLR-4823 at 5/16/13 8:40 PM:
---
Here
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/459/
Java: 64bit/jdk1.6.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic
Error Message:
Connection to http://localhost:49252 refused
Stack Trace:
is not static, so the mem estimator would count that as ram used by the
object itself.
The estimation actually includes static fields -- if it didn't you
could easily overflow memory simply by allocating static byte[]
buffers or something else. Object-level fields are garbage collected
because
: is not static, so the mem estimator would count that as ram used by the
: object itself.
:
: The estimation actually includes static fields -- if it didn't you
: could easily overflow memory simply by allocating static byte[]
But clearly there is a diff between statics in the tests, and
[
https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659996#comment-13659996
]
Yonik Seeley commented on SOLR-4829:
Thanks for verifying Steven!
Committed to trunk,
[
https://issues.apache.org/jira/browse/SOLR-4829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-4829.
Resolution: Fixed
Fix Version/s: 4.4
transaction log reference leak
...surely if the SolrRequestParser *class* had a static var the Logger
(instead of an instance var) that wouldn't have counted against the amount
of memory being used by the SolrRequestParser ?
No, it wouldn't. We collect static fields from the suite class and
then traverse the object graph
: ...surely if the SolrRequestParser *class* had a static var the Logger
: (instead of an instance var) that wouldn't have counted against the amount
: of memory being used by the SolrRequestParser ?
:
: No, it wouldn't. We collect static fields from the suite class and
: then traverse the
The estimation actually includes static fields
Yeah, I probably misunderstood something along the way, apologies.
When you look at the code I linked to things are pretty simple:
1) collect values of static fields from the test suite class (and its
superclasses),
2) for non-null values, estimate
FYI: After consultation with the PMC, I've moved all committers from
ContributorsGroup to AdminGroup, the idea being that all committers should be
able to add people to ContributorsGroup.
This change affected just three people: Christian Moen, Shalin Mangar (who's
now on the PMC anyway), and
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2827/
Java: 64bit/jdk1.7.0_21 -XX:+UseCompressedOops -XX:+UseParallelGC
5 tests failed.
FAILED:
org.apache.solr.client.solrj.embedded.TestEmbeddedSolrServer.testShutdown
Error Message:
Stack Trace:
[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660124#comment-13660124
]
Tom Burton-West commented on SOLR-3076:
---
I'd like to test this out with some real
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660197#comment-13660197
]
Koji Sekiguchi commented on SOLR-4751:
--
Looks good! I'll commit shortly.
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-4751:
-
Fix Version/s: 4.3.1
4.4
5.0
The replication problem
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved SOLR-4751.
--
Resolution: Fixed
Committed on trunk, branch_4x and lucene_solr_4_3. Thanks!
[
https://issues.apache.org/jira/browse/SOLR-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660264#comment-13660264
]
Minoru Osuka commented on SOLR-4751:
Sekiguchi-san,
Thank you so much for your help!
Isaac Hebsh created SOLR-4834:
-
Summary: Surround QParser should enable query text analysis
Key: SOLR-4834
URL: https://issues.apache.org/jira/browse/SOLR-4834
Project: Solr
Issue Type:
On Thu, May 16, 2013 at 7:55 PM, Robert Muir rcm...@gmail.com wrote:
FYI we currently have:
[exec] Crawl/parse...
[exec]
[exec]
file:///build/docs/analyzers-common/org/apache/lucene/analysis/util/FilteringTokenFilter.html
[exec] WARNING: anchor version appears
[
https://issues.apache.org/jira/browse/SOLR-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660354#comment-13660354
]
Isaac Hebsh commented on SOLR-1375:
---
Hi, I know that this issue is not active for a long
[
https://issues.apache.org/jira/browse/SOLR-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Isaac Hebsh updated SOLR-4834:
--
Labels: analysis qparserplugin surround (was: )
Surround QParser should enable query text
Matthias Herrmann created SOLR-4835:
---
Summary: highlighting in combination with join does not work in
solr 4.0 - 4.2
Key: SOLR-4835
URL: https://issues.apache.org/jira/browse/SOLR-4835
Project:
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Description:
I need to highlight results based on a query that contains a join operation.
I
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Component/s: query parsers
highlighting in combination with join does not work in solr
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Description:
I need to highlight results based on a query that contains a join operation. I
[
https://issues.apache.org/jira/browse/SOLR-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Herrmann updated SOLR-4835:
Description:
I need to highlight results based on a query that contains a join operation. I
101 - 158 of 158 matches
Mail list logo
