[
https://issues.apache.org/jira/browse/SOLR-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-1160.
---
Resolution: Fixed
AutoCommitTest randomly failed with NullPointerException
AutoCommitTest randomly failed with NullPointerException
Key: SOLR-1160
URL: https://issues.apache.org/jira/browse/SOLR-1160
Project: Solr
Issue Type: Bug
Reporter: Mark
[
https://issues.apache.org/jira/browse/SOLR-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1160:
--
Attachment: SOLR-1160.patch
AutoCommitTest randomly failed with NullPointerException
AutoCommitTest was failing for me a good percentage of the time...
the comment suggested that adding another doc after the commit
callback would block until the new searcher was registered. But
that's not the case. I've hacked the test for now to just sleep(500)
after the commit callback
On 5-Aug-08, at 3:32 PM, Yonik Seeley wrote:
AutoCommitTest was failing for me a good percentage of the time...
the comment suggested that adding another doc after the commit
callback would block until the new searcher was registered. But
that's not the case. I've hacked the test for now
On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote:
hymmm. what do you think the best option is?
Should we increase the time it waits to check if stuff autocommited?
It currently waits 1 second for something that *should* start an
autocommit within 1/2 sec.
Perhaps we should increase the
On 2/5/07, Mike Klaas [EMAIL PROTECTED] wrote:
On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote:
hymmm. what do you think the best option is?
Should we increase the time it waits to check if stuff autocommited?
It currently waits 1 second for something that *should* start an
autocommit
Perhaps we should increase the alloted time _and_ check explicitly if
an egregious amount of time has passed in the unittest. If so, we can
skip the test instead of failing it.
That's probably a good idea.
I was able to get the current version to fail on my PC at work
intermittently by
Getting the test to pass is one thing... but this exception is
another. Is it possible that this could be triggered by normal use of
Solr? Perhaps by too-frequent commits?
I don't *think* so... I haven't seen any trouble while load testing
this on a real system.
I *think* the
On 2/5/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Getting the test to pass is one thing... but this exception is
another. Is it possible that this could be triggered by normal use of
Solr? Perhaps by too-frequent commits?
I don't *think* so... I haven't seen any trouble while load
On 2/5/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Getting the test to pass is one thing... but this exception is
another. Is it possible that this could be triggered by normal use of
Solr? Perhaps by too-frequent commits?
I don't *think* so... I haven't seen any trouble while load
On 2/5/07, Yonik Seeley [EMAIL PROTECTED] wrote:
That's probably a good idea.
I was able to get the current version to fail on my PC at work
intermittently by running something else that was eating CPU.
Could you try the latest trunk? It should block on pending commits if
they happen to
I just posted a simple change on SOLR-126... it cancels any pending
activity when you close the UpdateHandler
public void close() throws IOException {
log.info(closing + this);
iwCommit.lock();
try{
// cancel any pending operations
if( tracker.pending != null ) {
On 2/4/07, Yonik Seeley [EMAIL PROTECTED] wrote:
With the latest changes to AutoCommitTest, now I'm getting failures:
[junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 5.593 sec
[junit] Test org.apache.solr.update.AutoCommitTest FAILED
Stack trace:
INFO: Opening [EMAIL
On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote:
is this on your machine or on the apache machine? I have never had a
problem running on my machine.
My local machine happens every time now.
I think Erik said it was failing for him also.
-Yonik
Can you tell specifically what part triggers the bad behavior? or is
it whenever autocommit gets triggered?
I wish I could be more useful, but from my system (win XP,
jdk1.5.0_07) things look ok...
On 2/4/07, Yonik Seeley [EMAIL PROTECTED] wrote:
On 2/4/07, Ryan McKinley [EMAIL PROTECTED]
still trying (in vain) to make this fail on my setup...
The one line that looks suspicious from your stack trace is:
WARNING: best effort to remove
C:\DOCUME~1\Yonik\LOCALS~1\Temp\org.apache.solr.update.AutoCommitTest-testMaxDocs-1170627577515
FAILED !
can you delete the directory
On Feb 4, 2007, at 8:34 PM, Yonik Seeley wrote:
On 2/4/07, Ryan McKinley [EMAIL PROTECTED] wrote:
is this on your machine or on the apache machine? I have never had a
problem running on my machine.
My local machine happens every time now.
I think Erik said it was failing for him also.
On 2/4/07, Yonik Seeley [EMAIL PROTECTED] wrote:
OK, the wildcard seems to be norton antivirus.
Antivirus on:
BUILD FAILED
Total time: 2 minutes 22 seconds
Antivirus off:
BUILD SUCCESSFUL
Total time: 1 minute 24 seconds
Not yet sure why that would make the difference... and only on this test.
hymmm. what do you think the best option is?
Should we increase the time it waits to check if stuff autocommited?
It currently waits 1 second for something that *should* start an
autocommit within 1/2 sec.
Is the RejectedExecutionException only thrown because JUnit failed?
or is this an
20 matches
Mail list logo
