telefonicaid / fiware-sth-comet

A component of the FIWARE ecosystem in charge of managing historical and aggregated time series context information
https://fiware-sth-comet.rtfd.io
GNU Affero General Public License v3.0
27 stars 28 forks source link

MongoDB should connect to STH sever after reconnectTries value is exhausted #592

Closed Gauravp-NEC closed 2 years ago

Gauravp-NEC commented 2 years ago

Issue Description:

This issue originates from issue https://github.com/telefonicaid/fiware-sth-comet/issues/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 thereconnectTries 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 commented 2 years ago

@fgalan @mapedraza This scenario was covered in PR https://github.com/telefonicaid/fiware-sth-comet/pull/574 and we observed that the following code of the patch has been removed in PR https://github.com/telefonicaid/fiware-sth-comet/pull/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 commented 2 years ago

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 reconnectTriesand 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 commented 2 years ago

@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 reconnectTriesand reconnectInterval values are you using?

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

  1. 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 commented 2 years ago

@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 commented 2 years ago

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 reconnectTriesand reconnectInterval values are you using?

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

  1. 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 https://github.com/telefonicaid/fiware-sth-comet/pull/572#issuecomment-1083138376

fgalan commented 2 years ago

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