[weld-issues] [JBoss JIRA] Commented: (CDITCK-219) SessionContextTest.testSessionContextDestroyedWhenHttpSessionTimesOut uses too short of a sleep delay time

[Bob Nettleton (JIRA)]

    [ https://issues.jboss.org/browse/CDITCK-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608985#comment-12608985 ] 

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