[jbosstools-issues] [JBoss JIRA] (JBIDE-18818) Test timeout in org.jboss.tools.jsf.verification.test

[Mickael Istria (JIRA)]

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

Mickael Istria commented on JBIDE-18818:
----------------------------------------

About getting stacktrace on a tycho-surefire-plugin timeout, then the following discussion shows it's actually quite complicated: https://dev.eclipse.org/mhonarc/lists/tycho-user/msg04041.html

About running readAndDispatch, then this is obviously a very bad thing. This method is meant to be called only by the UI loop, no client should call it if there is a UI loop running it.

SWTBot mainly uses Display.asyncExec() and lets the user put their "wait" conditions when necessary. The wait methods are expected to be "functional" checks (such as a button enablement or label visibility) rather than SWT events polling. SWTBot finders (such as .button("buttonLabel") or .tree()) include internal wait conditions to wait for some time to find the requested widgets.
If you need to send events synchronously and wait for them to be processed before continuing, then you should indeed use Display.syncExec().
If you want to wait for a specific event to be processed and don't want to run Display.syncExec(), then the best solution is probably to put Listeners on the whole display with Display.addFilter, and to use wait/notify to re-enable the Test thread when the right listener is processed.
In general, have tests running in UI Thread is a bad practice as many test operations may not require UI. UI Thread should not be bocked by operations that don't do UI.

> Test timeout in org.jboss.tools.jsf.verification.test
> -----------------------------------------------------
>
>                 Key: JBIDE-18818
>                 URL: https://issues.jboss.org/browse/JBIDE-18818
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: jsf
>    Affects Versions: 4.2.1.CR1
>            Reporter: Nick Boldt
>            Assignee: Alexey Kazakov
>            Priority: Blocker
>             Fix For: 4.2.x, 4.3.x
>
>
> Tests that time out due to blocking UI or other thread lock result in builds that are recorded as ABORTED [0]. This isn't a problem in terms of publishing new content because the build runs quickly, publishes the new bits, and THEN starts running tests. 
> [0] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-javaee_4.2.luna/buildTimeTrend
> But where it IS a problem is where we use a buildflow job to run the whole stack of JBT projects. Buildflows will also abort if they encounter an aborted job [1].
> [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-buildflow_4.2.luna/
> Why is this a problem? Because when we do a weekend spin (or respin) not all the projects in the stack are guaranteed to rebuild to verify all the downstream component tests all still work.
> --
> If you cannot fix these tests so they run cleanly in Jenkins, please disable them or move them such that they can still be run LOCALLY using a profile, but will be skipped in Jenkins.



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)