Conversation
* Took out the RPC timeout based on the agent heartbeat in the database. This isn't sure-fire and thus might harm guest communications. * Added better log messages during RPC timeouts which state the method which has timed out.
|
+1 |
|
You might want to think this over, before removing it. The reason it was added is so that the API calls don't hang forever if the agent is down or the instance stops responding etc. |
|
I'd emailed the team about this and no one knew why we had that code, so thanks for the update. We already have RPC timeouts so I don't understand what this adds. If its worthwhile in fact we should add it to all calls. My problem with it is if the clock time gets skewed somehow (which would be a bug anyway, but still happens all the time in my VM) it will shut off communication to all the guest for no reason. |
|
i'm all for the extra logging. the heartbeat part i am a little uneasy about removing it all together although i understand that it was only used in a single place/method. I think that might have been because as we added new features it was unclear what checking the heart beat would mean. I am speculating here but if it buys us an error faster than waiting for a timeout for guest agent calls that might not be a bad thing when our system grows. |
|
+1 |
1 similar comment
|
+1 |
5 participants
This isn't sure-fire and thus might harm guest communications.
which has timed out.