Questions about the RequestExecutor's initial topology update

[damccull]

In the RequestExecutor's firstTopologyUpdate method, I understand the process to be, generally, this:

1. Run through the list of inital urls, contacting each in turn. If successfully got a topology, stop and save it. Log all bad url errors.
2. If none of the urls worked, see if there's already a NodeSelector available and grab it's topology
3. If no node selector was available, just create a new topology, trusting the user's initially supplied URLs are correct
4. Create a new NodeSelecter with either the previous NodeSelector's topology, or the newly created topology

I don't understand two things, though:

1. Why are we looking for an existing NodeSelector during the first toplogy update? Shouldn't it not exist yet?
2. After creating the new NodeSelector, the client is checking to see if initialUrls still exists and has a >0 length. But there's nowhere above that line is there anywhere that would clear or destroy initialUrls, so why is this checking for it before starting an update timer and returning early?

[ayende]

1/ This may happen if we failed the first time we run FirstTopologyUpdate, so we already have some defaults there. Better to stick with them. May also happen if we loaded the topology from local file cache.
Basically, consider what happens when we retry after a failure, that is why we have this behavior.

2/ I believe that this is protection when the user is passing an empty / null array directly.