Based on the question for final exam question 6 I feel my question is a more of an acceptable one than the given correct answer.
Let me explain.
wTimeout gives this explanation in its documentation per the mongodb docs:
wtimeout
This option specifies a time limit, in milliseconds, for the write concern. wtimeout is only applicable for w values greater than 1 .
The question states this:
Assume that none of the connection settings have been changed, and that the client is only sending insert statements with write concern w: 1 to the server.
After 30 seconds, the client still cannot connect to a new primary.
So if I am reading this correctly the wtimeout isnāt applicable in this answer because the question states the insert statement is forcing a w: 1 replica set to the serverā¦
Furthermore, if I reduce the durability of the write i.e. change it to w: 0 this would āresolveā the issue of not being able to connect to the primary in a literal sense.
It may not be the best course of action considering the type of data concern but that was not illustrated in the question. Also, why is providing a try/write block an answer for a resolution to anything? It is a way of dealing with the issue and reporting it but it is not something that āresolvesā an issue.
I feel this question could be worded different and my points, if they hold up, would be actionable for an adjusted score?
My thoughts are that this was brought up over a week ago:
So I did manage to submit the correct answer but the point I was arguing there was that it was āat bestā a 50/50 chance on submission for most people considering that the āNodeJS driver does not actually exhibit the behavior expected in the questionā, and the little script I provide there proves the actual driver will hang indefinately until a Primary node is contactable.
As for your answer and argument, there is one basic problem and the solid reason why it was not one of the 50/50 choices as mentioned earlier. Your end deduction:
To be literal the only thing done by w: 0 is that you donāt receive an āacknowledgementā of the write as compared to the defaultw: 1. The problem is " if you cannot contact the Primary AT ALL, then you simply cannot write"
So really the only āfair gameā in reasoned answers are:
Turn it off and on again - This is basically what the option proposes, and arguably by what I was trying to present itās actually the most truthful to what the driver does, but clearly āturn it off and on againā is not the answer. The writes are stalled, but itās more likely due to network partition than needing a server restart. So this is wrong.
Duplicate Key - Aside from there being nothing raised in the question to indicate a duplicate key error being possibly raised, the basic problem here is we cannot write. So you canāt get this error at all if we donāt have a Primary to write to. So this is wrong.
Reduce Durability - Already covered above. We cannot contact the Primary, so it does not matter what write concern is set at all by this point. So this is wrong.
This brings us to the final two, and the 50/50 as mentioned. So the coin toss becomes one of does something actually respond with an error. At this point you should be referring to what the course actually told you, and which is why I brought up the specific video.
When it comes down to being a write concern error or a timeout the main logic leads to ātimeoutā, and purely because as was reasoned for the other choices we simply cannot contact the primary AT ALL. This rules out write concern with a thrown error in this case.
And finally thereās that slide as mentioned in the course material which shows you:
Always configure for and handle serverSelectionTimeout errors
But then of course it never shows you any practical usage. Partly because this is a generic video shown to all language variants of the course, and secondly because āitās just not even implemented in the NodeJS driver!ā
But the timeout wording is right there regardless, and ātimeoutsā are basically what happen when āyou are unable to contact something over a specified period of timeā.
I hope that at least explains āWhy?ā the other answers are wrong and how it gets reasoned that the only answer left has to be the correct one, even if itās arguably incorrect at this present point in time.
Note also that the other 50/50 hint without reasoning through the other possibilities was the phrasing in the question:
āWhich of the following errors will be thrown by the Node.js driver, and how should it be handled?ā
The course material shows you handling thrown errors by implementing a try/catch block to trap these and take actions. So the logical conclusion is that the things that actually mention try/catch are the possible valid answers.
One of the reasons the made me go for the timeout error is this paragraph from MongoDB docs but Iām not completely sure if I got it right. And would like to hear your thoughts.
This option specifies a time limit, in milliseconds, for the write concern. wtimeout is only applicable for w values greater than 1 .
wtimeout causes write operations to return with an error after the specified limit, even if the required write concern will eventually succeed. When these write operations return, MongoDB does not undo successful data modifications performed before the write concern exceeded the wtimeout time limit.
If you do not specify the wtimeout option and the level of write concern is unachievable, the write operation will block indefinitely. Specifying a wtimeout value of 0 is equivalent to a write concern without the wtimeout option.
If you do not specify the wtimeout option and the level of write concern is unachievable, the write operation will block indefinitely
What does block indefinitely mean? Will it throw an error or not?
Perhaps this is some of the confusion. Is this syntax/verbiage different from wtimeout? I think that is what I was wheighing my answer on not being a timeout issue. i.e. the post I and the other reply has given per the docs?
Your answer for me is understandable except for one thingā¦ the word āresolveā vs. āhandleā if the question said handle error I would have been right with you for that answer choice. but, resolve? to me that means how do you fix. Which yes, that makes turning off and off or restarting another viable choice.
@ayam1701 No it will not throw an error. Block indefinitely means wait forever, which is an accurate description. However itās not really relevant to the question.
To be clear on the relevance to the question though, the text does say:
āAssume that none of the connection settings have been changed, and that the client is only sending insert statements with write concern w: 1 to the server.ā
This is not the best wording, but take it to mean āWe did not set any configuration options other than the defaultsā. Basically that means there was no setting for wtimeout specified. With that in mind, even the w: 1 on each insert is a āred herringā since that is also the default.
If you presumed that sentence to mean an error caused by wtimeout then that is not the case because of :
There is no wtimeout setting on the connection at all; Yet
wtimeout is only applicable for w values greater than 1
w: 1 is the basic part that rules out wtimeout having anything to do with the question.
@ayam1701 It does not throw a write concern error. Thatās what the description of the answer explains. The error is a ātimeoutā, which is related to not being able to select an available Primary to write to.
Thank you for bringing this up. This is what caused me to change my original answer/choice of Timeout error to that of a Write Concern error. My initial choice was correct, but then when I dug in a bit deeper into the docs, I was convinced that my original choice was incorrect, so I switched my answer/choice.
Admittedly, I have not read this entire thread yet, but I plan on doing so now that I have some free time. I will also likely come back to this tomorrow with a fresh head to see if I can gain some more insight into why I/we ended up choosing the wrong answer.
I have figured it out and will clean up some confusion mainly caused by a lack of explanation in the lessons. I am not being critical but further explanation is required to properly answer this question.
First, when connecting to mongodb through an application you will be using a driver. This driver has barriors it must pass through in order to do anything with the mongodb server. When you understand this barrior concept you will then understand this question.
Every connection that is ultimately made a list of things have to occur in order to pass throuh the barriers and ultimately conduct a write or read operaton.
***Note: Anywhere along this pipeline a falure occurs based on your logic a successful write / read operation may not occur.
We can think of barriers 1 - 3 as network barriers of connectivity. If the network is down or having issues these are the problems one would notice through timeouts and exception handling of those timeouts. What one has to understand is that you canāt perform a write operation with write concerns if you canāt connect to the server in the first place. The lesson could have illustrated these points.
The first set of barriers to a write or read operation are to have an established connection to the serverā¦ This is illustrated above by barries 1 - 3.
Then, after you have a server connection via a cluster and or replica set of clusters then you can define write concerns.
After we have an established connection a write may not happen for reasons other than network connectivity. These can be collisions of data or an extreme allotment of writes due to DDOS or hacking or in general not enough server space for the data be written to the server. Point is, something else can cause a reaction to the write concern and hence the control through options to handle write concern errors.
I hope this helps because it made me understand the question and the right answer accordingly. Mostly, we werenāt really taugh this so I hope this helps others learn and understand this feedback loop.
Here are some articles I read to help me get to this answer / conclusion. If someone has a better or improvement on my explanation please feel free to provide feedback.
Thank you for taking the time to construct this well-thought out post! This clears up much of the confusion that I was experiencing. Iām bookmarking this, as well as the links that you have provided (which Iām going to read now).
