[jboss-jira] [JBoss JIRA] Updated: (JBAS-3221) Need to rewrite JBossMQ tests to be more robust

[Dimitris Andreadis (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-3221?page=all ]

Dimitris Andreadis updated JBAS-3221:
-------------------------------------

    Issue Type: Task  (was: Bug)

Change the issue from bug to task.

> Need to rewrite JBossMQ tests to be more robust
> -----------------------------------------------
>
>                 Key: JBAS-3221
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3221
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.2.0.CR1
>
>
> Repeated runs of the JMSContainerInvokerQueueMessageDrivenUnitTestCase on my laptop (1.6GHz Pentium M) will result in the following failure:
> <testcase classname="org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase" name="testRestartJMS" time="30.891">
>   <error message="Wrong number of messages, expected=2
>     got=1" type="java.lang.Exception">java.lang.Exception: Wrong
>     number of messages, expected=2 got=1
>    at org.jboss.test.messagedriven.support.CheckMessageSizeOperation.run(CheckMessageSizeOperation.java:46)
>    at org.jboss.test.messagedriven.support.BasicMessageDrivenUnitTest.runTest(BasicMessageDrivenUnitTest.java:112)
>    at org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase.testRestartJMS(JMSContainerInvokerQueueMessageDrivenUnitTestCase.java:67)
> From Adrian:
> The fundamental problem is waiting on a timeout for asynchronous work which will be subject to all sorts of random failures if for example you run it on your laptop while you are doing compiles or downloading e-mail.
> The thread doing the wait (or the server thread doing the work) simply doesn't get scheduled in time because the cpu is busy.
> The hard part is when you do a wait and you expect nothing to happen in that wait time. You don't want to slow down the testsuite doing long waits.
> In general, these tests can be written better, but doing so also means testing things beyond the spec like looking at service instrumentation to check there is no outstanding work to performed before asserting state.
> e.g. The jms queue is empty or a thread pool has no scheduled work, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira