we should provide a way to disable the background thread with a configurable delay time
(delay <= 0 means no thead) .
if during a test we need to test the cleaning then the method cleanExpiredTokens() should
be called directly on the service.
does it make sense ?
On Apr 24, 2013, at 11:10 AM, Trong Tran <trongtt(a)gmail.com> wrote:
Hi,
Today the cookie token storage is initialized lazily at the first time there is any kind
of operation interacting with the token storage. And there is a thread for a scheduled
executor to clean up expired tokens, the first execution is performed right after the
service is starting up, as following snippet code :
executor.scheduleWithFixedDelay(new Runnable() {
public void run() {
try {
AbstractTokenService.this.cleanExpiredTokens();
} catch (Throwable t) {
log.warn("Failed to clean expired tokens", t);
}
}
}, 0, DELAY_TIME, TimeUnit.SECONDS);
That could explain why the "Thread.sleep(1000)" is needed, to be sure that the
cookie token storage is not initialized twice concurrently which raises an exception.
To solve the problem, we could initialize the token storage at beginning of the service
starting up, then we can start the thread of cleaning up executor. Actually, we solve a
similar issue in GadgetTokenInfoService in
https://issues.jboss.org/browse/GTNPORTAL-2711
I believe that the cleaning up expired tokens by a thread is leading to the NPE. Not only
this test, it is also leading to similar exceptions in other tests that I have addressed
at
https://issues.jboss.org/browse/GTNPORTAL-2944
On 22 April 2013 23:09, Julien Viet <julien(a)julienviet.com> wrote:
Hi,
I had an issue with the TestSimpleGeneratorService that can randomly fail and I suspect
it could be related to the "Thread.sleep(1000)" statement:
https://github.com/gatein/gatein-portal/blob/master/component/web/securit...
can someone give me the reason of this and if there is a possible track for improving
this ?
The observed issue with Jenkins (exo private instance) was:
java.lang.NullPointerException
at
org.exoplatform.web.security.TestSimpleGeneratorService.testDuplicatedTokenGeneration(TestSimpleGeneratorService.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at
org.exoplatform.component.test.AbstractGateInTest.runBare(AbstractGateInTest.java:81)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Julien
_______________________________________________
gatein-dev mailing list
gatein-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
--
Trong Tran
(+84) 983841909 | trongtt(a)gmail.com
Twitter:
http://twitter.com/trongtt