Chrome Version:
OS: All

What steps will reproduce the problem?
For an HttpServerPropertiesImpl instance, do:
(1) Repeatedly mark AlternativeService "foo" broken using MarkAlternativeServiceBroken(), then wait until its brokenness expires. Do this a few times.
(2) Mark "foo" broken again, then mark a different AlternativeService "bar" broken for the first time.

What is the expected result?
AlternativeService "bar"'s brokenness should expire after its computed expiration time. Since it only broke once, its expiration time is relatively close in the future. 

What happens instead?
"bar"'s brokenness will not expire until "foo"'s expiration time is reached, which is relatively far in the future because it has already been marked broken many times before.


This happens because there's a queue in HttpServerPropertiesImpl that stores expiration times for broken AlternativeServices, and there's an assumption that this queue is sorted by expiration times from earliest to latest. The task to remove expired entries from this queue is scheduled based on the expiration time of the entry at the front of this queue (i.e. whenever the next broken AlternativeService is expected to expire, schedule this task to run at that time). The queue must be sorted by expiration time for this to work, but this assumption is currently not always true.