Indeed, I had realized that if you look at the unit tests... which expect
the equality failure.

Please review https://github.com/apache/httpcomponents-core/pull/166

I do not think I wanted to chew off to big a bite when I initially offered
TimeValue ;-)

Gary


On Sun, Dec 15, 2019 at 3:20 PM Gary Gregory <[email protected]> wrote:

> Looking...
>
> On Sun, Dec 15, 2019 at 11:11 AM Michael Osipov <[email protected]>
> wrote:
>
>> Gary,
>>
>> while working on HTTPCLIENT-2036 I have found a bug in
>> TimeValue#equals() method. It does not properly scale the value if time
>> unit prefixes are different. It says that "1000 ms != 1 s" which is
>> wrong mathematically.
>> You have to multiply with the smallest prefix not to lose precision when
>> comparing scaled durations.
>>
>> Can you please run "mvn verify" on client and have a look at TimeValue?
>>
>> > [ERROR] Failures:
>> > [ERROR]
>>  
>> TestCacheValidityPolicy.testApparentAgeIsResponseReceivedTimeLessDateHeader:81
>> expected:<4 SECONDS> but was:<4,892 MILLISECONDS>
>> > [ERROR]
>>  
>> TestCacheValidityPolicy.testCorrectedInitialAgeIsCorrectedReceivedAgePlusResponseDelay:138
>> expected:<20 SECONDS> but was:<20,000 MILLISECONDS>
>> > [ERROR]
>>  
>> TestCacheValidityPolicy.testFreshnessLifetimeIsFromExpiresHeaderIfNoMaxAge:217
>> expected:<4 SECONDS> but was:<4,000 MILLISECONDS>
>> > [ERROR]   TestCacheValidityPolicy.testHeuristicFreshnessLifetime:227
>> expected:<1 SECONDS> but was:<1,000 MILLISECONDS>
>> > [ERROR]
>>  TestCacheValidityPolicy.testNegativeApparentAgeIsBroughtUpToZero:89
>> expected:<0 SECONDS> but was:<0 MILLISECONDS>
>> > [ERROR]
>>  TestCacheValidityPolicy.testResidentTimeSecondsIsTimeSinceResponseTime:144
>> expected:<6 SECONDS> but was:<6,000 MILLISECONDS>
>> > [ERROR]
>>  
>> TestCacheValidityPolicy.testResponseDelayIsDifferenceBetweenResponseAndRequestTimes:121
>> expected:<4 SECONDS> but was:<4,000 MILLISECONDS>
>>
>> Thank you!
>>
>> Michael
>>
>

Reply via email to