MongoDB should connect to STH sever after reconnectTries value is exhausted

[Gauravp-NEC]

Issue Description:

This issue originates from issue #570.
When MongoDB is down, reconnect functionality starts working and make attempts till reconnectTries value reaches 30. If the reconnectTries value is exhausted and after that MongoDB starts running then STH server could not connect to MongoDB.

Reproduction Steps:

1. Make sure that STH server and MongoDB are running and connected together.

2. Stop the MongoDB.

3. Start the MongoDB when the reconnectTries value is exhausted.

4. Execute the GET API.

Expected Result :

1. MongoDB should connect to STH server.

2. GET API should respond with attribute values.

Actual Result :

1. MongoDB is not connected to STH server.

2. GET API respond with:

statusCode: 500
error: Internal Sever Error
message: MongoDB is not connected

[Gauravp-NEC]

@fgalan @mapedraza
This scenario was covered in PR #574 and we observed that the following code of the patch has been removed in PR #583

   } else {
       client.connect(function(err) {
           if(err) {
               return callback(err,null);
           }
       });
   }
}

Can you please let me know the reason of removal of above code as due to the same, the scenario mentioned in the description is not working.

[fgalan]

Can you please let me know the reason of removal of above code as due to the same, the scenario mentioned in the description is not working.

The reason is the separation of concerns between the MongoDB driver and the code using that driver (STH itself). The reconnection is a job for the driver, not for STH.

With regards to the use case you describe, I have two doubts, pls:

1. Which reconnectTries and reconnectInterval values are you using?
2. With regards to step 4, if MongoDB is started before reconnectTries have been exhausted, is STH reconnecting and responding correctly?

[Gauravp-NEC]

@fgalan

The reason is the separation of concerns between the MongoDB driver and the code using that driver (STH itself). The >reconnection is a job for the driver, not for STH.

If MongoDB is started after reconnectTries is exhausted, Then in this scenario both the STH and MongoDB are running but user will receive error 500 which doesn't seem a good behavior. Please let me know your opinion.

With regards to the use case you describe, I have two doubts, pls:

1. Which reconnectTries and reconnectInterval values are you using?

We are using default values i.e., reconnectTries: 30 and reconnectInterval: 1000

2. With regards to step 4, if MongoDB is started before reconnectTries have been exhausted, is STH reconnecting and responding correctly?

Yes, STH is reconnecting and responding correctly when MongoDB is started before reconnectTries value is getting exhausted.

[Gauravp-NEC]

@fgalan , What can be minimum and maximum values for reconnectTries and reconnectInterval?

As per my investigation only default values are provided in standard document and source code. Please find the below references:
https://mongodb.github.io/node-mongodb-native/3.3/reference/connecting/connection-settings/ https://github.com/mongodb/node-mongodb-native/blob/v3.6.12/lib/mongo_client.js#L117-L118

Can you please let me know what could be the minimum and maximum values for reconnectTries and reconnectInterval?

[fgalan]

The reason is the separation of concerns between the MongoDB driver and the code using that driver (STH itself). The >reconnection is a job for the driver, not for STH.

If MongoDB is started after reconnectTries is exhausted, Then in this scenario both the STH and MongoDB are running but user will receive error 500 which doesn't seem a good behavior. Please let me know your opinion.

With regards to the use case you describe, I have two doubts, pls:

1. Which reconnectTries and reconnectInterval values are you using?

We are using default values i.e., reconnectTries: 30 and reconnectInterval: 1000

2. With regards to step 4, if MongoDB is started before reconnectTries have been exhausted, is STH reconnecting and responding correctly?

Yes, STH is reconnecting and responding correctly when MongoDB is started before reconnectTries value is getting exhausted.

Thank you for your feedback!

Under my understanding, STH is behaving as expected. The reconnectTries/reconnectInterval configuration specifies the time you want to wait for reconnections. Expired that time, STH "gives up" so it's normal that even in the case MongoDB gets up again, STH doesn't longer tries to reconnect. In fact, maybe the behaviour should be that after that time STH process stops with a FATAL error, so an administrator can take the proper administrative actions.

If you what STH try to reconnect forever, then use "infinite" reconnectTries/reconnectInterval time. Of course, infinite doesn't exist in computer science, but a time absurdly high (e.g. 100 years :) has an equivalent effect.

With regards to

Can you please let me know what could be the minimum and maximum values for reconnectTries and reconnectInterval?

I think it has been already answered by @AlvaroVega at #572 (comment)

[fgalan]

Btw, could you provide some detail about your use case with STH? I mean, in which application are you using it?