Final Exam Question 6 : I believe my answer is an acceptable one

Hi All,

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?

your thoughts?

1 Like

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 default w: 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.

3 Likes

Hi @neillunn

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.

wtimeout

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.

IMHO poor question

@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.

Do you mean the Write Concern error is not related to the wtimeout? and if so when does this write Concern error get thrown?

@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.

Hi @xtianus,

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.

Thanks again for bringing this up. :smile:

2 Likes

you’re literally explainging why we didn’t choose a timeout error. This needs to be explained better. can you help

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.

Visually you can think of it like this:

IO / write request occurs ==> || 1st barrier --> (server selection - (err -> serverSelectionTimeoutMS ) ) ==> || 2nd barrier --> connection to server - (err -> ‘connectionTimeoutMS’) ==> || 3rd barrier --> socket connection - (err -> ‘socketTimeoutMS’) ==**Write Concern Options Barriers==> || 4th barrier --> ‘write concern specification { w: <value>, j: <boolean>, wtimeout: <number> }’ ==> || 5th barrier --> a successful write / read operation

***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.

https://docs.mongodb.com/manual/reference/write-concern/

https://www.mongodb.com/blog/post/server-selection-next-generation-mongodb-drivers/

2 Likes

Hi @xtianus,

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).

Cheers:-)

2 Likes