You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficcontrol.apache.org by GitBox <gi...@apache.org> on 2020/08/06 00:06:35 UTC

[GitHub] [trafficcontrol] zrhoffman commented on issue #4935: Internal Server Error when perform a /GET update_status on a non-unique hostname

zrhoffman commented on issue #4935:
URL: https://github.com/apache/trafficcontrol/issues/4935#issuecomment-669607245


   > So, at one point hostname was unique and like @&#8203;rob05c said the uniqueness was changed to hostname + profile. I believe this was done to support MSO delivery services in some way but i forget exactly why.
   
   @mitchell852 If the only reason we dropped unique hostnames was to support MSOs, origins should be the only server type that can have non-unique hostnames. We can adjust the constraint for that and re-add the constraint, right?
   
   > in this scenario, would it make sense to set upd_pend=1 for BOTH servers IF 2 servers (for example) share a hostname?
   
   Because we queue updates by server ID, that endpoint thankfully will not have this issue.
   
   ---
   
   > But with regard to the parent pending, I'm not 100% sure but looking at the SQL, I think it's probably implicitly returning if parents of either server are pending. But that's not where the error is.
   
   @rob05c That's correct. But since we have no preference for which of those 2 servers with that hostname we get, that is undefined behavior.
   
   > The error is in `WHERE s.cachegroup != (SELECT s.cachegroup FROM server s WHERE s.host_name = $4)`, which I don't fully understand.
   
   Our set of cachegroups initially contains the cachegroup we want to filter out as the base result of the query's recursive CTE. We could filter it out within the base result itself, but that would double the size of the base result SQL. From this discussion, it's probably still worth it.
   
   > Changing it to `WHERE s.cachegroup NOT IN` would make it execute successfully, and might have that effect. @zrhoffman ?
   
   Depends on what you mean by "successfully". If the unintended server's cachegroup parents the intended server's cachegroup in the topology and updates are queued on the unintended server's cachegroup, we would still get inaccurate results. But maybe that is an infrequent edge case. Without the constraint, I'm not confident that a server's hostname is enough info to produce a well-defined result.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org