You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@edgent.apache.org by "Dale LaBossiere (JIRA)" <ji...@apache.org> on 2018/01/30 20:32:00 UTC

[jira] [Commented] (EDGENT-445) Console testOverridePortNumber() fails in Jenkins

    [ https://issues.apache.org/jira/browse/EDGENT-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345754#comment-16345754 ] 

Dale LaBossiere commented on EDGENT-445:
----------------------------------------

Yeah the singleton and test ordering, or not spawning a new JVM for each test class, is the issue. 

Looks like J8 tests get a new JVM for each test class - i.e., both HttpServerPortTest and HttpServerTest get new HttpServer instances regardless of which order the tests are run.  For J7 tests, only the first of those two classes gets a new server instance.  Hence when HttpServerTest happens first (Jenkins) HttpServerPortTest fails (you can see the actual port that's reported is the same as the port that got used for the preceding HttpServerTest and there's no "getInstance" log message indicating a new HttpServer is being created.

> Console testOverridePortNumber() fails in Jenkins
> -------------------------------------------------
>
>                 Key: EDGENT-445
>                 URL: https://issues.apache.org/jira/browse/EDGENT-445
>             Project: Edgent
>          Issue Type: Test
>          Components: Test
>            Reporter: Dale LaBossiere
>            Assignee: Dale LaBossiere
>            Priority: Major
>
> The way the test is currently written doesn't seem to work well in the Jenkins test environment (the actual port != expected port).  Hmm... maybe something to do with the j8+j7 tests and the "singleton" HttpServer instance?  Would hope that something would fail if for example the "available port" was no longer available when the server started.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)