Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
Great. Thanks for working this out, Ray. I've added support for setting the port via the namespace, but we'll still need a default port value, so I've switched it to 33389. The tests now use 53389 (by setting the port attribute) which is in the dynamic port range (http://www.iana.org/assignments/port-numbers). Ray Krueger wrote: > I found the problem! > > In the LdapBeanDefinitionParser I see this... > > //TODO: Allow port configuration > configuration.setLdapPort(3389); > > The TODO says it all :), the problem is that 3389 is the port that > Windows runs the Remote Desktop service on. I figured this out because > I saw "port already in use" errors in the tests. > > As a test I changed the 3389 (and the ldap urls in the tests and such) > to 3399 and everything passes in 2 minutes. We should definitely make > this a configurable property somehow. > > Can I change this port for now? > > > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
I found the problem!
In the LdapBeanDefinitionParser I see this...
//TODO: Allow port configuration
configuration.setLdapPort(3389);
The TODO says it all :), the problem is that 3389 is the port that
Windows runs the Remote Desktop service on. I figured this out because
I saw "port already in use" errors in the tests.
As a test I changed the 3389 (and the ldap urls in the tests and such)
to 3399 and everything passes in 2 minutes. We should definitely make
this a configurable property somehow.
Can I change this port for now?
On Nov 5, 2007 10:25 AM, Ray Krueger <[EMAIL PROTECTED]> wrote:
> Ok, so this is a Windows and/or Java 6 thing.
>
> I ran the full test suite on my linux box with java5 and all is well.
>
>
>
>
> On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > It looks like that all starts from this test...
> >
> > Running
> > org.springframework.security.providers.ldap.authenticator.PasswordComparisonAuthenticatorTests
> >
> > On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > > This type of stuff seems to be where it takes the longest...
> > >
> > > 2007-11-04 12:39:38,062 DEBUG
> > > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > > eating InitialDirContext with environment
> > > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > > ramework,dc=org,
> > > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > > java.naming.security.
> > > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > > java.naming.security.authenticat
> > > ion=simple, java.naming.security.credentials=**,
> > > java.naming.factory.object=org.springframework.
> > > ldap.core.support.DefaultDirObjectFactory}
> > >
> > > 2007-11-04 12:39:53,203 DEBUG
> > > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > > eating InitialDirContext with environment
> > > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > > ramework,dc=org,
> > > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > > java.naming.security.
> > > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > > java.naming.security.authenticat
> > > ion=simple, java.naming.security.credentials=**,
> > > java.naming.factory.object=org.springframework.
> > > ldap.core.support.DefaultDirObjectFactory}
> > >
> > > 2007-11-04 12:40:08,218 DEBUG
> > > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > > eating InitialDirContext with environment
> > > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > > ramework,dc=org,
> > > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > > java.naming.security.
> > > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > > java.naming.security.authenticat
> > > ion=simple, java.naming.security.credentials=**,
> > > java.naming.factory.object=org.springframework.
> > > ldap.core.support.DefaultDirObjectFactory}
> > >
> > > 2007-11-04 12:40:23,218 DEBUG
> > > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > > eating InitialDirContext with environment
> > > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > > ramework,dc=org,
> > > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > > java.naming.security.
> > > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > > java.naming.security.authenticat
> > > ion=simple, java.naming.security.credentials=**,
> > > java.naming.factory.object=org.springframework.
> > > ldap.core.support.DefaultDirObjectFactory}
> > >
> > >
> > >
> > >
> > > On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > > > Maven version: 2.0.7
> > > > Java version: 1.6.0_01
> > > > OS name: "windows xp" version: "5.1" arch: "x86"
> > > >
> > > > Yeah, the console scrolled way too far back for me to see what failed.
> > > > That was just the snippet of the end of the log I showed.
> > > >
> > > > I'm running it again with a fresh batch of code, and running it from
> > > > the project root.
> > > >
> > > > On 11/4/07, Luke Taylor <[EMAIL PROTECTED]> wrote:
> > > > > What tests are failing? And what platform are you running on, JVM,
> > > > > Maven
> > > > > version etc?
> > > > >
> > > > > The stuff about ehcache is something to do with the shutdown hooks in
> > > > > all the application contexts being executed when the VM exits so
> > > > > that's
> > > > > not the problem, though we should be aiming to make sure that existing
> > > > > tests call close() on any created app contexts to avoid this.
> > > > >
> > > > > Both my automated build and the ones on build.springframework.org seem
> > > > > to be running without any problems and I just built on my desktop
> > > > > machine (1min 29s for a "mvn clean test"):
> > > > >
> > > > > Maven version: 2.0.7
> > > > > Java version: 1.5.0_07
> > > > > OS name: "mac os x" version: "10.4.10" arch: "i386"
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Ray Krueger
Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
Ok, so this is a Windows and/or Java 6 thing.
I ran the full test suite on my linux box with java5 and all is well.
On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> It looks like that all starts from this test...
>
> Running
> org.springframework.security.providers.ldap.authenticator.PasswordComparisonAuthenticatorTests
>
> On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > This type of stuff seems to be where it takes the longest...
> >
> > 2007-11-04 12:39:38,062 DEBUG
> > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > eating InitialDirContext with environment
> > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > ramework,dc=org,
> > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > java.naming.security.
> > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > java.naming.security.authenticat
> > ion=simple, java.naming.security.credentials=**,
> > java.naming.factory.object=org.springframework.
> > ldap.core.support.DefaultDirObjectFactory}
> >
> > 2007-11-04 12:39:53,203 DEBUG
> > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > eating InitialDirContext with environment
> > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > ramework,dc=org,
> > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > java.naming.security.
> > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > java.naming.security.authenticat
> > ion=simple, java.naming.security.credentials=**,
> > java.naming.factory.object=org.springframework.
> > ldap.core.support.DefaultDirObjectFactory}
> >
> > 2007-11-04 12:40:08,218 DEBUG
> > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > eating InitialDirContext with environment
> > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > ramework,dc=org,
> > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > java.naming.security.
> > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > java.naming.security.authenticat
> > ion=simple, java.naming.security.credentials=**,
> > java.naming.factory.object=org.springframework.
> > ldap.core.support.DefaultDirObjectFactory}
> >
> > 2007-11-04 12:40:23,218 DEBUG
> > org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> > eating InitialDirContext with environment
> > {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> > ramework,dc=org,
> > java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> > java.naming.security.
> > principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> > java.naming.security.authenticat
> > ion=simple, java.naming.security.credentials=**,
> > java.naming.factory.object=org.springframework.
> > ldap.core.support.DefaultDirObjectFactory}
> >
> >
> >
> >
> > On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > > Maven version: 2.0.7
> > > Java version: 1.6.0_01
> > > OS name: "windows xp" version: "5.1" arch: "x86"
> > >
> > > Yeah, the console scrolled way too far back for me to see what failed.
> > > That was just the snippet of the end of the log I showed.
> > >
> > > I'm running it again with a fresh batch of code, and running it from
> > > the project root.
> > >
> > > On 11/4/07, Luke Taylor <[EMAIL PROTECTED]> wrote:
> > > > What tests are failing? And what platform are you running on, JVM, Maven
> > > > version etc?
> > > >
> > > > The stuff about ehcache is something to do with the shutdown hooks in
> > > > all the application contexts being executed when the VM exits so that's
> > > > not the problem, though we should be aiming to make sure that existing
> > > > tests call close() on any created app contexts to avoid this.
> > > >
> > > > Both my automated build and the ones on build.springframework.org seem
> > > > to be running without any problems and I just built on my desktop
> > > > machine (1min 29s for a "mvn clean test"):
> > > >
> > > > Maven version: 2.0.7
> > > > Java version: 1.5.0_07
> > > > OS name: "mac os x" version: "10.4.10" arch: "i386"
> > > >
> > > >
> > > >
> > > >
> > > > Ray Krueger wrote:
> > > > > I just pulled the latest code from Trunk this morning. I ran the unit
> > > > > tests in ./core and had the following result...
> > > > >
> > > > > 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting
> > > > > down with the CacheManager st
> > > > > ill active. Calling shutdown.
> > > > > Exception in thread "Thread-77" java.lang.IllegalStateException: The
> > > > > aclCache Cache is not alive.
> > > > > at net.sf.ehcache.Cache.checkStatus(Cache.java:1201)
> > > > > at net.sf.ehcache.Cache.dispose(Cache.java:1081)
> > > > > at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702)
> > > > > at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505)
> > > > > [INFO]
> > > > >
> > > > >
Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
It looks like that all starts from this test...
Running
org.springframework.security.providers.ldap.authenticator.PasswordComparisonAuthenticatorTests
On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> This type of stuff seems to be where it takes the longest...
>
> 2007-11-04 12:39:38,062 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=**,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
> 2007-11-04 12:39:53,203 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=**,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
> 2007-11-04 12:40:08,218 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=**,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
> 2007-11-04 12:40:23,218 DEBUG
> org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
> eating InitialDirContext with environment
> {java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
> ramework,dc=org,
> java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
> java.naming.security.
> principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
> java.naming.security.authenticat
> ion=simple, java.naming.security.credentials=**,
> java.naming.factory.object=org.springframework.
> ldap.core.support.DefaultDirObjectFactory}
>
>
>
>
> On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> > Maven version: 2.0.7
> > Java version: 1.6.0_01
> > OS name: "windows xp" version: "5.1" arch: "x86"
> >
> > Yeah, the console scrolled way too far back for me to see what failed.
> > That was just the snippet of the end of the log I showed.
> >
> > I'm running it again with a fresh batch of code, and running it from
> > the project root.
> >
> > On 11/4/07, Luke Taylor <[EMAIL PROTECTED]> wrote:
> > > What tests are failing? And what platform are you running on, JVM, Maven
> > > version etc?
> > >
> > > The stuff about ehcache is something to do with the shutdown hooks in
> > > all the application contexts being executed when the VM exits so that's
> > > not the problem, though we should be aiming to make sure that existing
> > > tests call close() on any created app contexts to avoid this.
> > >
> > > Both my automated build and the ones on build.springframework.org seem
> > > to be running without any problems and I just built on my desktop
> > > machine (1min 29s for a "mvn clean test"):
> > >
> > > Maven version: 2.0.7
> > > Java version: 1.5.0_07
> > > OS name: "mac os x" version: "10.4.10" arch: "i386"
> > >
> > >
> > >
> > >
> > > Ray Krueger wrote:
> > > > I just pulled the latest code from Trunk this morning. I ran the unit
> > > > tests in ./core and had the following result...
> > > >
> > > > 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting
> > > > down with the CacheManager st
> > > > ill active. Calling shutdown.
> > > > Exception in thread "Thread-77" java.lang.IllegalStateException: The
> > > > aclCache Cache is not alive.
> > > > at net.sf.ehcache.Cache.checkStatus(Cache.java:1201)
> > > > at net.sf.ehcache.Cache.dispose(Cache.java:1081)
> > > > at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702)
> > > > at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505)
> > > > [INFO]
> > > >
> > > > [ERROR] BUILD FAILURE
> > > > [INFO]
> > > >
> > > > [INFO] There are test failures.
> > > > [INFO]
> > > >
> > > > [INFO] For more information, run Maven with the -e switch
> > > > [INFO]
> > > > ---
Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
This type of stuff seems to be where it takes the longest...
2007-11-04 12:39:38,062 DEBUG
org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
eating InitialDirContext with environment
{java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
ramework,dc=org,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
java.naming.security.
principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
java.naming.security.authenticat
ion=simple, java.naming.security.credentials=**,
java.naming.factory.object=org.springframework.
ldap.core.support.DefaultDirObjectFactory}
2007-11-04 12:39:53,203 DEBUG
org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
eating InitialDirContext with environment
{java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
ramework,dc=org,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
java.naming.security.
principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
java.naming.security.authenticat
ion=simple, java.naming.security.credentials=**,
java.naming.factory.object=org.springframework.
ldap.core.support.DefaultDirObjectFactory}
2007-11-04 12:40:08,218 DEBUG
org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
eating InitialDirContext with environment
{java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
ramework,dc=org,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
java.naming.security.
principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
java.naming.security.authenticat
ion=simple, java.naming.security.credentials=**,
java.naming.factory.object=org.springframework.
ldap.core.support.DefaultDirObjectFactory}
2007-11-04 12:40:23,218 DEBUG
org.springframework.security.ldap.DefaultInitialDirContextFactory - Cr
eating InitialDirContext with environment
{java.naming.provider.url=ldap://127.0.0.1:3389/dc=springf
ramework,dc=org,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
java.naming.security.
principal=uid=admin,ou=system, com.sun.jndi.ldap.connect.pool=true,
java.naming.security.authenticat
ion=simple, java.naming.security.credentials=**,
java.naming.factory.object=org.springframework.
ldap.core.support.DefaultDirObjectFactory}
On 11/4/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> Maven version: 2.0.7
> Java version: 1.6.0_01
> OS name: "windows xp" version: "5.1" arch: "x86"
>
> Yeah, the console scrolled way too far back for me to see what failed.
> That was just the snippet of the end of the log I showed.
>
> I'm running it again with a fresh batch of code, and running it from
> the project root.
>
> On 11/4/07, Luke Taylor <[EMAIL PROTECTED]> wrote:
> > What tests are failing? And what platform are you running on, JVM, Maven
> > version etc?
> >
> > The stuff about ehcache is something to do with the shutdown hooks in
> > all the application contexts being executed when the VM exits so that's
> > not the problem, though we should be aiming to make sure that existing
> > tests call close() on any created app contexts to avoid this.
> >
> > Both my automated build and the ones on build.springframework.org seem
> > to be running without any problems and I just built on my desktop
> > machine (1min 29s for a "mvn clean test"):
> >
> > Maven version: 2.0.7
> > Java version: 1.5.0_07
> > OS name: "mac os x" version: "10.4.10" arch: "i386"
> >
> >
> >
> >
> > Ray Krueger wrote:
> > > I just pulled the latest code from Trunk this morning. I ran the unit
> > > tests in ./core and had the following result...
> > >
> > > 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting
> > > down with the CacheManager st
> > > ill active. Calling shutdown.
> > > Exception in thread "Thread-77" java.lang.IllegalStateException: The
> > > aclCache Cache is not alive.
> > > at net.sf.ehcache.Cache.checkStatus(Cache.java:1201)
> > > at net.sf.ehcache.Cache.dispose(Cache.java:1081)
> > > at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702)
> > > at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505)
> > > [INFO]
> > >
> > > [ERROR] BUILD FAILURE
> > > [INFO]
> > >
> > > [INFO] There are test failures.
> > > [INFO]
> > >
> > > [INFO] For more information, run Maven with the -e switch
> > > [INFO]
> > >
> > > [INFO] Total time: 30 minutes 11 seconds
> > > [INFO] Finished at: Sat Nov 03 21:11:26 CDT 2007
> > > [INFO] Final Memory: 15M/27M
> > > [INFO]
> > >
> > >
> > >
> > > Not cool, I'm not sure what's going on, but it appeared to be spending
> > > all it's time in ldap tests.
> > >
> >
> >
> > --
> > Luke Taylor
Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
Maven version: 2.0.7 Java version: 1.6.0_01 OS name: "windows xp" version: "5.1" arch: "x86" Yeah, the console scrolled way too far back for me to see what failed. That was just the snippet of the end of the log I showed. I'm running it again with a fresh batch of code, and running it from the project root. On 11/4/07, Luke Taylor <[EMAIL PROTECTED]> wrote: > What tests are failing? And what platform are you running on, JVM, Maven > version etc? > > The stuff about ehcache is something to do with the shutdown hooks in > all the application contexts being executed when the VM exits so that's > not the problem, though we should be aiming to make sure that existing > tests call close() on any created app contexts to avoid this. > > Both my automated build and the ones on build.springframework.org seem > to be running without any problems and I just built on my desktop > machine (1min 29s for a "mvn clean test"): > > Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" > > > > > Ray Krueger wrote: > > I just pulled the latest code from Trunk this morning. I ran the unit > > tests in ./core and had the following result... > > > > 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting > > down with the CacheManager st > > ill active. Calling shutdown. > > Exception in thread "Thread-77" java.lang.IllegalStateException: The > > aclCache Cache is not alive. > > at net.sf.ehcache.Cache.checkStatus(Cache.java:1201) > > at net.sf.ehcache.Cache.dispose(Cache.java:1081) > > at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702) > > at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505) > > [INFO] > > > > [ERROR] BUILD FAILURE > > [INFO] > > > > [INFO] There are test failures. > > [INFO] > > > > [INFO] For more information, run Maven with the -e switch > > [INFO] > > > > [INFO] Total time: 30 minutes 11 seconds > > [INFO] Finished at: Sat Nov 03 21:11:26 CDT 2007 > > [INFO] Final Memory: 15M/27M > > [INFO] > > > > > > > > Not cool, I'm not sure what's going on, but it appeared to be spending > > all it's time in ldap tests. > > > > > -- > Luke Taylor. Monkey Machine Ltd. > PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
What tests are failing? And what platform are you running on, JVM, Maven version etc? The stuff about ehcache is something to do with the shutdown hooks in all the application contexts being executed when the VM exits so that's not the problem, though we should be aiming to make sure that existing tests call close() on any created app contexts to avoid this. Both my automated build and the ones on build.springframework.org seem to be running without any problems and I just built on my desktop machine (1min 29s for a "mvn clean test"): Maven version: 2.0.7 Java version: 1.5.0_07 OS name: "mac os x" version: "10.4.10" arch: "i386" Ray Krueger wrote: > I just pulled the latest code from Trunk this morning. I ran the unit > tests in ./core and had the following result... > > 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting > down with the CacheManager st > ill active. Calling shutdown. > Exception in thread "Thread-77" java.lang.IllegalStateException: The > aclCache Cache is not alive. > at net.sf.ehcache.Cache.checkStatus(Cache.java:1201) > at net.sf.ehcache.Cache.dispose(Cache.java:1081) > at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702) > at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505) > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 30 minutes 11 seconds > [INFO] Finished at: Sat Nov 03 21:11:26 CDT 2007 > [INFO] Final Memory: 15M/27M > [INFO] > > > > Not cool, I'm not sure what's going on, but it appeared to be spending > all it's time in ldap tests. > -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Trunk tests take 30 minutes and then fail.
I just pulled the latest code from Trunk this morning. I ran the unit tests in ./core and had the following result... 2007-11-03 21:11:26,437 INFO net.sf.ehcache.CacheManager - VM shutting down with the CacheManager st ill active. Calling shutdown. Exception in thread "Thread-77" java.lang.IllegalStateException: The aclCache Cache is not alive. at net.sf.ehcache.Cache.checkStatus(Cache.java:1201) at net.sf.ehcache.Cache.dispose(Cache.java:1081) at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:702) at net.sf.ehcache.CacheManager$1.run(CacheManager.java:505) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 30 minutes 11 seconds [INFO] Finished at: Sat Nov 03 21:11:26 CDT 2007 [INFO] Final Memory: 15M/27M [INFO] Not cool, I'm not sure what's going on, but it appeared to be spending all it's time in ldap tests. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
