Travis-CI build fails due to MongoDB connection timeout

Travis CI Discussions & Feedback
1

My build started to fail without any changes in the project code, so it looks like a problem with Travis runtime.

My build uses MongoDB to run integration tests:

services:
  - mongodb

and since 2018-12-08, every time the build is run it fails because integration tests can’t connect to MongoDB:

com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting to connect. Client view of cluster state is {type=UNKNOWN, servers=[{address=travis-job-b0d8719f-570a-4f48-88a2-1d864ae48787:33492, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketOpenException: Exception opening socket}, caused by {java.net.ConnectException: Connection refused (Connection refused)}}]

see
https://travis-ci.org/javers/javers/builds/463952979

I’m a bit confused because I can’t see a way how to get support or report an issue with the Travis-Ci builds when it seems that a problem is not on my side.

2

MongoDB server appears to start fine. https://travis-ci.org/javers/javers/builds/463952979#L920 Is it perhaps dying without your knowledge?

Your builds may also fail because of changes in your dependencies as well. https://docs.travis-ci.com/user/common-build-problems/#my-tests-broke-but-were-working-yesterday

3

Hi @BanzaiMan, yes, MongoDB service seems to start but I don’t know why it dies or stops listening.

This is a Java/Gradle build, so all my dependencies are fixed and controlled. I have no idea what is changed. I have restarted a build that used to be green and now it fails.

4

https://travis-ci.org/javers/javers/builds/465270231#L1014 says:

address=travis-job-799337c2-0504-4daf-8374-3f399182937f:42865

whereas in the successful one, it was binding to 127.0.0.1 https://travis-ci.org/javers/javers/builds/463952803#L1274.

If you can, could you try tweaking the MongoDB configuration?

In the mean time, I’ll ask around for possible explanations on our side.

Thanks.

5

In my build, there is no MongoDB configuration. All I have is the declaration of mongodb service in the .travis.yml

services:
  - mongodb

My integration tests connect to mongodb server using defaults, so they expect the mongodb service to listen on 127.0.0.1:27017. If the mongodb address is changed to travis-job-799337c2-0504-4daf-8374-3f399182937f:42865, definitely my tests won’t be able to connect. It looks like a blocker. Do you know why mongodb address is changed and how to get the defaults back?

6

Looks like the problem is caused by this big infrastructure migration on Travis-CI

Whatever I do, my integration tests can’t connect to MongoDB.
Moreover, this problem is not caused by the MongoDB service that is launched in the build environment.
I got the same error after switching to Embedded Mongo.

7

How is your client code connecting to the MongoDB server? mongo is connecting to mongodb://127.0.0.1:27017 and getting a response.

8

Just a standard way in Java:

class MongoIntegrationTest extends JaversMongoRepositoryE2ETest {

    @Override
    protected MongoDatabase getMongoDb() {
        new MongoClient().getDatabase("j_int_test")
    }
}

which is equiv to:

...
new MongoClient('127.0.0.1', 27017).getDatabase("j_int_test")
9

I think it is localhost, not 127.0.0.1, according to API documentation. Could you try hard coding 127.0.0.1?

10

already tried :wink:
see https://github.com/javers/javers/commit/2008ec53ffe89e25ac951360eb2c19a9f7c4c4a5

11

Hmmm. I am at my wits end. We can enable the debug feature if you’d like to have an interactive session to troubleshoot this further.

12

let’s try if there is a chance that it would help

13

It’s enabled now. Please read https://docs.travis-ci.com/user/running-build-in-debug-mode/#restarting-a-job-in-debug-mode-via-api carefully before starting a debug session. Thanks!

14

https://github.com/travis-ci/travis-build/pull/1620 might fix the issue with localhost, though 127.0.0.1 not working casts certain amount of doubt.

15

Could you test again? #1620 might (or might not!) address the underlying issue.

16

looks like specifying “localhost” is a good workaround, but please give me a while to double check it

17

@joepvd , @BanzaiMan , the trick with connecting explicitly to localhost works. The build is green now, thanks a lot.