Minor Typo and Questions on distrib-read.html

[nobozo]

First, the typo:

"The client sends a get request" ->
"The client sends a GET request"

Next, the questions:

1. A new reader, such as yours truly, will wonder why Node 1 sent the request to Node 2, given that there's a shard replica containing the requested document on Node 1. Why the extra step?

2. There should be a 3rd step shown here showing where Node 2 returns the document. I think it's returned to Node 1, but I'm not 100% sure. Figure 9, on the previous page, shows the equivalent step.

3. I'm curious about the reason why the node returning the results is the node receiving the request rather than the node that performed the query/update. Is this because there's already a network connection between the client and the receiving node (e.g. Node 1 in Figure 10) so that the response doesn't involve opening a new connection between the node the performed the query/update (Node 2 in Figure 10) and the client? I could see how a firewall might block this.

[clintongormley]

Hi @nobozo

1. A new reader, such as yours truly, will wonder why Node 1 sent the request to Node 2, given that there's a shard replica containing the requested document on Node 1. Why the extra step?

A client may be sending all requests to a single node, which would mean that only that node would do any work. Instead, all requests are round-robin'ed around all shard copies.

There should be a 3rd step shown here showing where Node 2 returns the document. I think it's returned to Node 1, but I'm not 100% sure. Figure 9, on the previous page, shows the equivalent step.

Actually the previous diagram doesn't include the step that you mention. It has a 3rd step, but it relates to a different part of the process. That said, I've added a third step to make it more explicit.

I'm curious about the reason why the node returning the results is the node receiving the request rather than the node that performed the query/update. Is this because there's already a network connection between the client and the receiving node (e.g. Node 1 in Figure 10) so that the response doesn't involve opening a new connection between the node the performed the query/update (Node 2 in Figure 10) and the client? I could see how a firewall might block this.

Exactly. You can't push responses to HTTP clients, only return them where the connection is opened. You could potentially redirect the client to the right node but, as you say, firewalls could interfere with that process.