You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a simple use case: an adapter which uses Spring's RestTemplate. I know that RestTemplate, like many HTTP clients, does not set a timeout by default. So it can theoretically sit there spinning forever and tie up resources not to mention the caller.
So I thought, let me add a test with awailability to prove this. The test should fail. Then I'll add a timeout to RestTemplate and prove that it fixes the test.
Here's the thing: using org.awaitility:awaitility:4.1.1, I could not get the test to fail! It just never times out.
I thought I was going crazy, so I downgraded to org.awaitility:awaitility:3.1.6, and then it worked!
I hope it's not some obvious change from v3 to v4 that I've missed. Still it seems odd that a basic behavior like this would be changed even across major versions.
The text was updated successfully, but these errors were encountered:
I have a simple use case: an adapter which uses Spring's
RestTemplate
. I know thatRestTemplate
, like many HTTP clients, does not set a timeout by default. So it can theoretically sit there spinning forever and tie up resources not to mention the caller.So I thought, let me add a test with awailability to prove this. The test should fail. Then I'll add a timeout to
RestTemplate
and prove that it fixes the test.Here's the thing: using
org.awaitility:awaitility:4.1.1
, I could not get the test to fail! It just never times out.I thought I was going crazy, so I downgraded to
org.awaitility:awaitility:3.1.6
, and then it worked!This is what the test is doing:
I hope it's not some obvious change from v3 to v4 that I've missed. Still it seems odd that a basic behavior like this would be changed even across major versions.
The text was updated successfully, but these errors were encountered: