-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
max_idle_time specification when using reactor-netty #3414
Comments
What is your opinion on the above points? I also have an additional point to check. However, the following issue is occurring. Do you have any insight into this?
|
Deadline for response: 2024/9/18
I suspect that other issues may also be involved.
|
@yuya17 Reactor Netty version 1.0.x reached its EOL and now is not supported. Is it possible for you to update to a supported version? |
@violetagg Also, where can I find information that version 1.0.x is EOL? |
Please check Readme -> Support and Deprecation Policies
…On Wed, 11 Sep 2024 at 7:40, yuya17 ***@***.***> wrote:
@violetagg <https://github.com/violetagg>
#3414 (comment)
<#3414 (comment)>
The above issue occurs even when changing to reactor-netty version 1.1.22.
Also, where can I find information that version 1.0.x is EOL?
Version 1.0.39 will be released on 2023/11/15, and there is no deprecated
tag in any of the documents.
—
Reply to this email directly, view it on GitHub
<#3414 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFKCVJKBCACTU3BG7LCBXLZV7CU5AVCNFSM6AAAAABNLQSDW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBSGYYDOMZYGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@yuya17 Please provide a reproducible example that shows the issue in Reactor Netty. |
@violetagg Internal implementation of REST communication wrapped in reactor-netty
Send the debugs that you ran three times above.
|
@violetagg
Regarding (1) and (2) of the log of port:34636, please check if there is any error in the following recognition. (1)Discard the communication information from PooledConnection (L:/aaa.aa.aa.aa:34636) (from inactive to inactive) to terminate communication. |
I don't understand this deadline The code snippet that you provided cannot be run, it shows only how the client is configured. Please provide a reproducible example as I requested. From the provided logs I can say the following:
And after some time the connection is closed, most probably this is because of the
Every time when we try to acquire a connection from the pool, we check whether the connection is still usable. This means that we will check whether the connection is not closed, the max idle time, max life time etc. If the connection is not usable then we will close it and remove it from the pool. |
On the other hand creating 3 times the pool is also very suspicious
|
|
@iwamoto703 Please check the link that I provided with my previous comment https://projectreactor.io/docs/netty/release/reference/index.html#connection-pool-timeout It is written there:
so if there is no acquisition the connection pool will do nothing. You need to configure |
@violetagg cc: @iwamoto703 Keystroke content Expected behavior ② The connection is closed after the first and second requests (Shot1, 2) have passed the max-idle-time of 10 seconds. Keystroke result ② The log shows that the connection was not closed 10 seconds after max-idle-time, and the connection for Shot1 and Shot2 was closed 20 seconds after evictinbackground.
|
@yuya17 @iwamoto703 As I wrote above, you create the connection pool on every request.
Do you create the WebClient for every request? Please provide a complete example so that we can investigate why the connection pool is created always. |
It is my understanding that the implementation does not create a WebClient for each request and open a new connection pool. |
There are paths that do not use the |
@yuya17 As you have the source and you can reproduce it, please try to debug why the connection pool is created always. reactor-netty/reactor-netty-core/src/main/java/reactor/netty/resources/PooledConnectionProvider.java Lines 127 to 129 in a8c996c
|
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed. |
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open. |
We have found that we need to send FIN packets due to the specification of the firewall that exists on the intermediate route, but we would like to confirm the following two points regarding the max_idle_time specification for that part.
(1) If the max_idle_time limit is exceeded, do we send a FIN packet?
(2) If FIN packets are not sent, is there any way to send them?
>(2) If a FIN packet is not sent, is there a way to send one?
In addition to the above questions, here is an additional check on the current behavior.
Current behavior: Even if a request is made to the same destination address, a new PORT is assigned for each request and a new connection is established.(Connections are not reused.)
In light of the above behavior, do you know the following points?
①When setting "reactor.netty.pool.maxConnections", do you know the general behavior when the respective upper limit is reached? (For example, if an additional setting is made in addition to max-idle-time, a FIN packet will be sent.)
②As stated in the following problem, the specification is such that FIN packets will not be sent as long as you use the build method of the ConnectionProvider class.
Other Issue:#3071
Expected behavior
・Sessions are destroyed as per the lifetime setting in max_idle_time
・Connections are reused
Actual behavior
・The session lifetime is set in max_idle_time, but the session is not destroyed after the lifetime.
・A new connection is created for each request and is not reused. (The destination IP address remains the same, but a new port number is assigned.)
Steps to reproduce
Same as Actual behavior.
Minimal yet complete reproducer code (or URL to code)
①Internal implementation of REST communication wrapped in reactor-netty
※REST communication executes methods in order from the top.
②Sample source code for the application side to use the REST communication function mentioned in ① above (for reference)
Reactor-Netty version
1.0.39
※SpringFramework Version:5.3.20
JVM version (e.g. java -version)
Container Image:ibmcom/websphere-liberty:22.0.0.6-full-java17-openj9-ubi
OS version (e.g. uname -a)
Linux/amd64
The text was updated successfully, but these errors were encountered: