Add warmup functionality for the servers/clients #1455
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1455 +/- ##
============================================
- Coverage 70.99% 70.93% -0.06%
- Complexity 1872 1888 +16
============================================
Files 145 146 +1
Lines 9239 9286 +47
Branches 1263 1268 +5
============================================
+ Hits 6559 6587 +28
- Misses 2024 2037 +13
- Partials 656 662 +6
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
I added a small change to the Javadoc which is identical in many places. Also wondering, since the Javadoc in the base classes ClientTransport and ServerTransport appears to be the same maybe the sub-classes don't need to repeat it as they inherit the Javadoc of the parent method.
In addition, this feature seems like a worthwhile topic to mention somewhere in the reference docs.
| * Based on the actual configuration, returns a {@link Mono} that triggers an initialization of | ||
| * the event loop group, the host name resolver, loads the necessary native libraries for the transport. | ||
| * and the necessary native libraries for the security if there is such. | ||
| * By default warmup is not performed and all resources are loaded on the first request. |
There was a problem hiding this comment.
| * By default warmup is not performed and all resources are loaded on the first request. | |
| * By default, when method is not used, the first request absorbs the extra time needed to load resources. |
| * Based on the actual configuration, returns a {@link Mono} that triggers an initialization of | ||
| * the event loop groups, loads the necessary native libraries for the transport | ||
| * and the necessary native libraries for the security if there is such. | ||
| * By default warmup is not performed and all resources are loaded on the first request. |
There was a problem hiding this comment.
| * By default warmup is not performed and all resources are loaded on the first request. | |
| * By default, when method is not used, the first request absorbs the extra time needed to load resources. |
| /** | ||
| * Based on the actual configuration, returns a {@link Mono} that triggers an initialization of | ||
| * the event loop group, the host name resolver and loads the necessary native libraries for the transport. | ||
| * By default warmup is not performed and all resources are loaded on the first request. |
There was a problem hiding this comment.
| * By default warmup is not performed and all resources are loaded on the first request. | |
| * By default, when method is not used, the first request absorbs the extra time needed to load resources. |
| /** | ||
| * Based on the actual configuration, returns a {@link Mono} that triggers an initialization of | ||
| * the event loop groups and loads the necessary native libraries for the transport. | ||
| * By default warmup is not performed and all resources are loaded on the first request. |
There was a problem hiding this comment.
| * By default warmup is not performed and all resources are loaded on the first request. | |
| * By default, when method is not used, the first request absorbs the extra time needed to load resources. |
| * Based on the actual configuration, returns a {@link Mono} that triggers an initialization of | ||
| * the event loop group, the host name resolver, loads the necessary native libraries for the transport. | ||
| * and the necessary native libraries for the security if there is such. | ||
| * By default warmup is not performed and all resources are loaded on the first request. |
There was a problem hiding this comment.
| * By default warmup is not performed and all resources are loaded on the first request. | |
| * By default, when method is not used, the first request absorbs the extra time needed to load resources. |
| * Based on the actual configuration, returns a {@link Mono} that triggers an initialization of | ||
| * the event loop groups, loads the necessary native libraries for the transport | ||
| * and the necessary native libraries for the security if there is such. | ||
| * By default warmup is not performed and all resources are loaded on the first request. |
There was a problem hiding this comment.
| * By default warmup is not performed and all resources are loaded on the first request. | |
| * By default, when method is not used, the first request absorbs the extra time needed to load resources. |
When the URL scheme is HTTPS and there is no security configured,
the default security will be used thus always try to load the OpenSsl natives
see HttpClientConnect.MonoHttpConnect#subscribe
The URL is parsed on request so the scheme is not known in advance
in order to use this information in the warmup.
With one and the same HttpClient you may trigger various requests
HttpClient client = HttpClient.create();
...
client.get().uri("https://abc.com/")
...
client.get().uri("http://qwe.com/")
The subclasses load also the security natives. Is there a way to inherit the parent javadoc and add this information? |
|
Yes, that would be another option to document what is done in the base class, then inherit and explain in sub-classes what is done in addition to the base class. Something like: /**
* {@inheritDoc}
* <p>more text....
*/ |
|
Please check now the javadoc and reference documentation. I decided to be more specific when the lazy loading happens depending on the protocol. @Buzzardo Can you review the documentation. Thanks a lot! |
|
Hi there 👋 We upgraded Spring Boot to 2.4.2 with reactor-netty 1.0.3 but still encounter this issue. Our call with WebClient: With debugging enabled via application.yaml: We now see this during application startup: This should be an indication that the warmup works as expected? But on first request this happens: In our case, creating the client pool is the problem. On a decent machine, it takes about 13 seconds. Can you give us any comment on that? This is very frustrating for us. Thanks a lot! |
|
@benjaminknauer If you think this is a problem in Reactor Netty please open a new issue. For questions please consider using Gitter or stackoverflow.com Connection pool warmup is not an option because most of the servers close the idle connection after some time. |
|
Yes, I actually believe there is a problem with the Reactor-netty and Spring MVC combination. I have created an example repository that can be used for testing. Interestingly, the run duration looks good when the client is called directly via a test or via MockMVC with a test. However, if the application is called from outside via Demo Repo: https://github.com/benjaminknauer/spring-mvc-web-client-first-request-slow-demo As you suggested I created a new issue: #1509 Many thanks for your help! |
Do we need to call warmup for each HttpClient we create.My Target is to create reactor threads before first request as both clients use same threads.CASE ONE: call warmup for each client.CASE TWO: call warmup only once for any client |
|
@piyushSKY The examples above share the resources so you do not need to invoke |
|
Still seeing the same issue intermittently after certain period of intervals. org.springframework.web.reactive.function.client.WebClientRequestException |
The warmup triggers an initialisation of the event loop groups, the host name resolver,
loads the necessary native libraries for the transport and native libraries
for the security if security is enabled.
Related to #560, #1023, #1425