Per the preceding discussion in #53, synchronously retrieve the instances registered with a given secure or insecure VIP address, optionally filtering and shuffling them too. This is a first step ("polling"), deferring the "consuming" and "caching" facilities for a subsequent patch.
Note that writing the code under test took a day or two, but writing the tests has been a month-long pursuit. It's not difficult to figure out how to exercise the new capabilities; what's painfully frustrating is trying to accommodate Euereka's replication and cache eviction delays.
Here are the concessions I've tried:
Have the client talk to only a single Eureka server, rather than alternating between two or more.
Use only a single Eureka server, with no peer replica.
Adjust the eureka.responseCacheAutoExpirationInSeconds and eureka.responseCacheUpdateIntervalMs configuration parameters down to negligible magnitudes.
Note that in Eureka version 1.1.147—which we use in the Docker-hosted tests—it's not possible to defeat the Eureka server's response cache entirely.
Poll the Eureka server after writing to confirm that the intended changes eventually become visible.
Unfortunately, if the code under test doesn't work, the tests will run forever, absent a timeout.
Impose empirically-derived delays in the tests in between important write-read-compare steps.
The proposal here includes that final, remorseful hack: wait for an amount of time that seems to work often enough, where waiting any less works less reliably. It's the only one I could get to work. I am open to other ideas if this one is sufficiently distasteful.
Since two of these new tests take so long to run, I skip them when testing.Short is true (summoned via go test -short). We might consider adding this short v. long sensitivity to other long-running test functions.
Per the preceding discussion in #53, synchronously retrieve the instances registered with a given secure or insecure VIP address, optionally filtering and shuffling them too. This is a first step ("polling"), deferring the "consuming" and "caching" facilities for a subsequent patch.
Note that writing the code under test took a day or two, but writing the tests has been a month-long pursuit. It's not difficult to figure out how to exercise the new capabilities; what's painfully frustrating is trying to accommodate Euereka's replication and cache eviction delays.
Here are the concessions I've tried:
eureka.responseCacheAutoExpirationInSecondsandeureka.responseCacheUpdateIntervalMsconfiguration parameters down to negligible magnitudes.Note that in Eureka version 1.1.147—which we use in the Docker-hosted tests—it's not possible to defeat the Eureka server's response cache entirely.
Unfortunately, if the code under test doesn't work, the tests will run forever, absent a timeout.
The proposal here includes that final, remorseful hack: wait for an amount of time that seems to work often enough, where waiting any less works less reliably. It's the only one I could get to work. I am open to other ideas if this one is sufficiently distasteful.
Since two of these new tests take so long to run, I skip them when
testing.Shortis true (summoned via go test -short). We might consider adding this short v. long sensitivity to other long-running test functions.