[jira] Resolved: (SOLR-1160) AutoCommitTest randomly failed with NullPointerException
[ 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 > > > Key: SOLR-1160 > URL: https://issues.apache.org/jira/browse/SOLR-1160 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1160.patch > > > Saw a failure of AutoCommitTest with a NullPointer exception. Couldn't > replicate easily. Noticed that AutoCommit prints that same NullPointer > exception many times even when it doesnt fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1160) AutoCommitTest randomly failed with NullPointerException
[ 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 > > > Key: SOLR-1160 > URL: https://issues.apache.org/jira/browse/SOLR-1160 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1160.patch > > > Saw a failure of AutoCommitTest with a NullPointer exception. Couldn't > replicate easily. Noticed that AutoCommit prints that same NullPointer > exception many times even when it doesnt fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1160) 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 Miller Assignee: Mark Miller Priority: Minor Fix For: 1.4 Attachments: SOLR-1160.patch Saw a failure of AutoCommitTest with a NullPointer exception. Couldn't replicate easily. Noticed that AutoCommit prints that same NullPointer exception many times even when it doesnt fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AutoCommitTest
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 to just sleep(500) after the commit callback. Fair enough. It is difficult for me to fix this more permenently, since I can't get it to fail on local machines. I deleted a bunch of email recently so I checked nabble--it seems that in the last month that AutoCommitTest has failed once in Hudson (July 21) and once in the apache build (August 2). That isn't too bad, but I hope that your change eliminates those entirely. -Mike
AutoCommitTest
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. -Yonik
Re: AutoCommitTest failing
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 ) {
tracker.pending.cancel( true );
tracker.pending = null;
}
doDeletions();
closeSearcher();
closeWriter();
} finally {
iwCommit.unlock();
}
log.info("closed " + this);
}
Re: AutoCommitTest failing
On 2/5/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: On 2/5/07, Mike Klaas <[EMAIL PROTECTED]> wrote: > 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 take too long. Tried it a few times, no failures yet. Thanks! Phew! -Mike
Re: AutoCommitTest failing
On 2/5/07, Mike Klaas <[EMAIL PROTECTED]> wrote: 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 take too long. Tried it a few times, no failures yet. Thanks! -Yonik
Re: AutoCommitTest failing
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 take too long. I'm having an exceptionally hard time getting the old version to fail, but I haven't seen this version fail yet. -Mike
Re: AutoCommitTest failing
On 2/5/07 11:18 AM, "Yonik Seeley" <[EMAIL PROTECTED]> wrote: > > Yes, I think that's it. > SolrCore.close() shuts down the Executor. > From the trace, you can see SolrCore closing, then an attempt to open > up another searcher after that. > > The close of the update handler should probably shut down it's executor too. That is one cause, according to the docs: New tasks submitted in method execute(java.lang.Runnable) will be rejected when the Executor has been shut down, and also when the Executor uses finite bounds for both maximum threads and work queue capacity, and is saturated. http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecu tor.html wunder
Re: AutoCommitTest failing
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 testing this on a real system. I *think* the RejectedExecutionException is thrown when JUnit aborts all execution. Essentially this is the ScheduledFutureTask saying "hey! i didn't get to complete even though you told me to" Yes, I think that's it. SolrCore.close() shuts down the Executor. From the trace, you can see SolrCore closing, then an attempt to open up another searcher after that. The close of the update handler should probably shut down it's executor too. -Yonik
Re: AutoCommitTest failing
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 testing this on a real system. I *think* the RejectedExecutionException is thrown when JUnit aborts all execution. Essentially this is the ScheduledFutureTask saying "hey! i didn't get to complete even though you told me to" That's reassuring. I'll try to come up with a proposed fix in about an hour when I have a bit of free time. -Mike
Re: AutoCommitTest failing
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 RejectedExecutionException is thrown when JUnit aborts all execution. Essentially this is the ScheduledFutureTask saying "hey! i didn't get to complete even though you told me to"
Re: AutoCommitTest failing
> > 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 running something else that was eating CPU. Is there a way to output a warning - but not a failure? The problem with not failing when an egregious about of time passes is that that is exactly what the test is looking for!
Re: AutoCommitTest failing
On 2/4/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: Stack trace: INFO: Opening [EMAIL PROTECTED] main Feb 4, 2007 5:19:41 PM org.apache.solr.core.SolrException log SEVERE: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:486) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:514) at org.apache.solr.update.DirectUpdateHandler2$CommitTracker.run(DirectUpdateHandler2.java:625) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) 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? -Mike
Re: AutoCommitTest failing
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 within 1/2 sec. 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 running something else that was eating CPU. -Yonik
Re: AutoCommitTest failing
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 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. -Mike
Re: AutoCommitTest failing
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 exception that would be thrown in the wild?
Re: AutoCommitTest failing
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. Ah wait.. it still is timing/performance related. With NAV disabled, and one other shell doing "while true; do true; done", the test succeeds in 2m2s, but with two shells doing it, the test fails in 9m1s So I guess my antivirus is slowing my 3GHz P4 down enough to fail. It probably has more to do with the disk access checking than the CPU. [junit] Tests run: 2, Failures: 2, Errors: 0, Time elapsed: 10.687 sec [junit] Test org.apache.solr.update.AutoCommitTest FAILED http://lucene.apache.org/java/docs/api/";> http://java.sun.com/";> http://java.sun.com/cgi-bin/bugreport.cgi";> http://junit.sourceforge.net/javadoc/";> http://java.sun.com/j2se/1.5.0/docs/api/";> junit.framework.AssertionFailedError: should find one query failed XPath: //[EMAIL PROTECTED] xml response was:at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:157) at org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:98) junit.framework.AssertionFailedError: should find one query failed XPath: //[EMAIL PROTECTED] xml response was: 0 0 at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:157) at org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:150) -Yonik 0 0
Re: AutoCommitTest failing
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. -Yonik
Re: AutoCommitTest failing
Removing the directory did not help. I just tried a fresh checkout on my C: drive, still no dice. I'll try a reboot, and a remote login to my machine at work next. -Yonik http://lucene.apache.org/java/docs/api/";> http://java.sun.com/";> http://java.sun.com/cgi-bin/bugreport.cgi";> http://junit.sourceforge.net/javadoc/";> http://java.sun.com/j2se/1.5.0/docs/api/";> junit.framework.AssertionFailedError: should find one query failed XPath: //[EMAIL PROTECTED] xml response was:at org.apache.solr.util.AbstractSolrTestCase.assertQ(AbstractSolrTestCase.java:157) at org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:98) 0 0
Re: AutoCommitTest failing
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. Currently all is well (svn revision 503532): BUILD SUCCESSFUL Total time: 1 minute 16 seconds I ran it twice for good measure, and passed both times. Erik
Re: AutoCommitTest failing
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 where solr stores the testing index manually?
Re: AutoCommitTest failing
On 2/4/07, Ryan McKinley <[EMAIL PROTECTED]> wrote:
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...
I'm on WinXP, and it fails on both Java5 (_09), and Java6.
I'm running off a laptop drive connected via firewire though... so
that might slow it down compared to what you are running.
Here's all the output from when I run it in my IDE (fails there too):
Feb 4, 2007 5:19:37 PM org.apache.solr.core.Config getInstanceDir
INFO: Solr home defaulted to 'solr/' (system property solr.solr.home not set)
Feb 4, 2007 5:19:37 PM org.apache.solr.core.SolrConfig initConfig
INFO: Loaded SolrConfig: solrconfig.xml
Feb 4, 2007 5:19:37 PM org.apache.solr.core.SolrConfig initConfig
INFO: Loaded SolrConfig: solrconfig.xml
Feb 4, 2007 5:19:38 PM org.apache.solr.schema.IndexSchema readConfig
INFO: Reading Solr Schema
Feb 4, 2007 5:19:38 PM org.apache.solr.schema.IndexSchema readConfig
INFO: Schema name=test
Feb 4, 2007 5:19:39 PM org.apache.solr.schema.IndexSchema readConfig
INFO: default search field is text
Feb 4, 2007 5:19:39 PM org.apache.solr.schema.IndexSchema readConfig
INFO: unique key field: id
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler standard=solr.StandardRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler indexinfo=solr.IndexInfoRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler dismaxOldStyleDefaults=solr.DisMaxRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler dismax=solr.DisMaxRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler old=solr.tst.OldRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.tst.OldRequestHandler init
INFO: Unused request handler
arguments:{myparam=1000,ratio=1.4142135,myarr=[1, 2],null=foo}
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler oldagain=solr.tst.OldRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.tst.OldRequestHandler init
INFO: Unused request handler
arguments:{lst1={op=sqrt,val=2},lst2={op=log,val=10.0}}
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler test=solr.tst.TestRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.tst.TestRequestHandler init
INFO: Unused request handler arguments:{}
Feb 4, 2007 5:19:39 PM org.apache.solr.core.RequestHandlers
INFO: adding requestHandler defaults=solr.StandardRequestHandler
Feb 4, 2007 5:19:39 PM org.apache.solr.core.SolrCore
INFO: Opening new SolrCore at solr/,
dataDir=C:\DOCUME~1\Yonik\LOCALS~1\Temp\org.apache.solr.update.AutoCommitTest-testMaxDocs-1170627577515
Feb 4, 2007 5:19:39 PM org.apache.solr.core.SolrCore parseListener
INFO: Searching for listeners: //[EMAIL PROTECTED]"firstSearcher"]
Feb 4, 2007 5:19:39 PM org.apache.solr.core.SolrCore parseListener
INFO: Searching for listeners: //[EMAIL PROTECTED]"newSearcher"]
Feb 4, 2007 5:19:39 PM org.apache.solr.core.SolrCore initIndex
WARNING: Solr index directory
'C:\DOCUME~1\Yonik\LOCALS~1\Temp\org.apache.solr.update.AutoCommitTest-testMaxDocs-1170627577515\index'
doesn't exist. Creating new index...
Feb 4, 2007 5:19:39 PM org.apache.solr.search.SolrIndexSearcher
INFO: Opening [EMAIL PROTECTED] main
Feb 4, 2007 5:19:39 PM org.apache.solr.core.SolrCore registerSearcher
INFO: Registered new searcher [EMAIL PROTECTED] main
Feb 4, 2007 5:19:39 PM
org.apache.solr.update.DirectUpdateHandler2$CommitTracker
INFO: CommitTracker:
[EMAIL PROTECTED]
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A0} in 234ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A1} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A2} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A3} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A4} in 16ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A5} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A6} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A7} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A8} in 16ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A9} in 0ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A10} in 31ms
Feb 4, 2007 5:19:40 PM org.apache.solr.handler.XmlUpdateRequestHandler update
INFO: added id={A11} in 0ms
Feb 4, 2007
Re: AutoCommitTest failing
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]> 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
Re: AutoCommitTest failing
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
Re: AutoCommitTest failing
is this on your machine or on the apache machine? I have never had a problem running on my machine. The previous error made more sense to me.. it looked like commit did not actually complete within the given time period. This one seems more like a Problem. Do we need to explicitly handle the ThreadPoolExecutor.AbortPolicy? http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.AbortPolicy.html ryan On 2/4/07, Yonik Seeley <[EMAIL PROTECTED]> wrote: 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
Re: AutoCommitTest failing
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 PROTECTED] main Feb 4, 2007 5:19:41 PM org.apache.solr.core.SolrException log SEVERE: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:486) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:514) at org.apache.solr.update.DirectUpdateHandler2$CommitTracker.run(DirectUpdateHandler2.java:625) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:65) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:168) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -Yonik
AutoCommitTest failing
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 -Yonik
