-
May 16th, 2016, 02:59 PM
#1
About the handshake pool queue:
When you say that it is full, I suppose you refer to the <handshake_pool_max_queue> setting.
In this case, backpressure is put not on the "server" thread pool but directly on the listening socket, which stops listening until the size falls below the limit.
However, no tasks are dropped and no connection requests are actively refused. Only the connection requests that can't be enqueued in the configured backlog will be discarded; but this is left to the system, so I'm not sure of the effect on the clients.
In your case, where the create_session requests have a dedicated port, you can leverage a non-documented flag, <CHECK_SERVER_QUEUE>, and set it to N in the <http_server> or <https_server> blocks related to the ports not used for create_session.
Obviously, the preconditions for the leverage of the <CHECK_SERVER_QUEUE> setting can only be ensured by the application.
Indeed, something similar could be devised for the <max_sessions> limit; your request makes sense.
The hit of the limit might cause either immediate refusal of the requests (as you suggest) or block of the accept loop (as done for the max_queue case).
Unfortunately, this is not currently available but we will evaluate whether to introduce it in a future release.
Similar Threads
-
By itsupport in forum Client SDKs
Replies: 3
Last Post: March 6th, 2009, 03:13 PM
-
By RichP1 in forum Client SDKs
Replies: 5
Last Post: February 24th, 2009, 10:42 AM
-
By RichP1 in forum General
Replies: 1
Last Post: November 16th, 2007, 11:28 AM
-
By DarioCrivelli in forum General
Replies: 2
Last Post: August 21st, 2007, 01:16 PM
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 09:28 AM.
Bookmarks