But that's not a good explanation I think. Realtime protection is always on,
and I agree w/ Mark - if NativeFSLock fails because of that, we should fix
that b/c Lucene is run on users' machines, where AV software is running too.
Moreover, this happens very rarely for me ... I even ran the tests while
scanning the Temp folder at the same time, and it didn't happen.

I'll re-post the next time it happens for me, w/ the full stacktrace.

Shai

On Tue, Apr 27, 2010 at 8:43 PM, Uwe Schindler <[email protected]> wrote:

>  Realtime protection is mostly the problem.
>
>
>
> -----
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: [email protected]
>
>
>
> *From:* Shai Erera [mailto:[email protected]]
> *Sent:* Tuesday, April 27, 2010 7:35 PM
>
> *To:* [email protected]
> *Subject:* Re: LuceneJUnitResultFormatter sometimes fails to lock
>
>
>
> I use Windows XP, and have no indexing service nor AV running at the same
> time (except its real time protection). Also, the lock file is attempted to
> obtain on the temp folder, which is usually excluded from many services that
> monitor the file system ...
>
> I will try to reproduce it again, because I see that I've left out the
> nested exception from the trace above.
>
> Shai
>
> On Tue, Apr 27, 2010 at 7:56 PM, Shai Erera <[email protected]> wrote:
>
> Yes it is Windows. Didn't mention it - thought the C:\ part says it all :).
>
> I wonder then why it only sometimes happens. And I've never run into
> such problems w/ NativeFSLock on Windows, only w/ the tests. But I
> agree it does deserve a closer look …
>
> Shai
>
>
> On Tuesday, April 27, 2010, Mark Miller <[email protected]> wrote:
> > Ah - didn't look closely. This is while making the lock, not trying to
> acquire it for stdout locking. So that seems like a bug in our native lock
> impl we should try and fix.
> >
> > On 4/27/10 12:27 PM, Uwe Schindler wrote:
> >
> > When aquiring a test lock it does not wait. It just is not able to
> produce the file there. This happens sometimes on windows and has nothing to
> do with the tests, is a problem of NativeLockF.
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: [email protected]
> >
> >
> >
> > -----Original Message-----
> > From: Mark Miller [mailto:[email protected]]
> > Sent: Tuesday, April 27, 2010 6:20 PM
> > To: [email protected]
> > Subject: Re: LuceneJUnitResultFormatter sometimes fails to lock
> >
> > We might need a higher timeout. Its like 5 seconds now. Otherwise we
> > should try and isolate the problem.
> >
> > - Mark
> >
> > On 4/27/10 11:52 AM, Uwe Schindler wrote:
> >
> > Windows?
> >
> > -----
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de<http://www.thetaphi.de/>
> >
> > eMail: [email protected]
> >
> > *From:* Shai Erera [mailto:[email protected]]
> > *Sent:* Tuesday, April 27, 2010 5:50 PM
> > *To:* [email protected]
> > *Subject:* LuceneJUnitResultFormatter sometimes fails to lock
> >
> > Hi
> >
> > I ran "ant test-core" today and hit this:
> >
> > [junit] Exception in thread "main" java.lang.RuntimeException: Failed
> >
> > to
> >
> > acquire random test lock; please verify filesystem for lock directory
> > 'C:\DOCUME~1\shaie\LOCALS~1\Temp\lucene_junit_lock' supports locking
> > [junit] at
> >
> >
> > org.apache.lucene.store.NativeFSLockFactory.acquireTestLock(NativeFSLoc
> > kFactory.java:88)
> >
> > [junit] at
> >
> >
> > org.apache.lucene.store.NativeFSLockFactory.makeLock(NativeFSLockFactor
> > y.java:127)
> >
> > [junit] at
> >
> >
> > org.apache.lucene.util.LuceneJUnitResultFormatter.<init>(LuceneJUnitRes
> > ultFormatter.java:74)
> >
> >
> > All the tests still pass, but Ant reports a failure in the end. Also,
> > this rarely happens, but I've run into it several times already.
> >
> > Anyone
> >
> > got an idea?
> >
> > Shai
> >
> >
> >
> >
> > --
> > - Mark
> >
> > http://www.lucidimagination.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
> >
> >
> > --
> > - Mark
> >
> > http://www.lucidimagination.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
>
>

Reply via email to