[
https://issues.jboss.org/browse/CDITCK-219?page=com.atlassian.jira.plugin...
]
Bob Nettleton commented on CDITCK-219:
--------------------------------------
I've investigated this further, and I've become convinced that the delay time in
this test is not long enough to handle the problem of intermittent failures.
Even with an interval time of 1 second set for the servlet container to check sessions for
possible invalidation, it's still possible for this to fail.
Could someone take a look at this, and let me know if this test will be excluded?
Thanks!
SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut
uses too short of a sleep delay time
----------------------------------------------------------------------------------------------------------
Key: CDITCK-219
URL:
https://issues.jboss.org/browse/CDITCK-219
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: Bob Nettleton
The following test case:
org.jboss.jsr299.tck.tests.context.session.SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut
uses the following line to sleep after asking the application server to invalidate the
session:
" Thread.sleep(1500);"
The test attempts to verify that the session context is destroyed properly after the
timeout.
The problem with this test is that it appears as if it could potentially introduce a
timing problem. Since Thread.sleep() behaves slightly differently for each platform, and
as far as I can tell is not even guaranteed to sleep as long as requested in some
situations, there is a chance that the client may make the second request before 1.5
seconds has expired. Since the behavior of System.getTimeMillis() is also
system-dependent, I'd be inclined to think that 1.5 seconds is probably not a long
enough timeout in order to keep this test from having intermittent failures.
I request that this test case be excluded, and that this test be modified in a later
version of the TCK to use a larger sleep value.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira