[jira] [Commented] (GEODE-7061) Under heavy load and many threads the C++ Native client may open lots of connections

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16916857#comment-16916857 ] 

ASF subversion and git services commented on GEODE-7061:
--------------------------------------------------------

Commit cd6a95f54dad874d1075e5f3eecf073113044098 in geode-native's branch refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cd6a95f ]

GEODE-7061: Reduce conns created during high load with many threads

- Process each TcrConnection as soon as it is evaluated

> Under heavy load and many threads the C++ Native client may open lots of connections
> ------------------------------------------------------------------------------------
>
>                 Key: GEODE-7061
>                 URL: https://issues.apache.org/jira/browse/GEODE-7061
>             Project: Geode
>          Issue Type: Bug
>          Components: native client
>            Reporter: Alberto Gomez
>            Assignee: Alberto Gomez
>            Priority: Major
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> Under heavy load and many threads (>30) the C++ Native client tends to open a lot of connections which, if the idleTimeout is not relatively small, could provoke client port exhaustion.
> The reason for this uncontrolled creation of connections is the implementation of the thread managing connections (ThinClientPoolDM::cleanStaleConnections()) that, in order to determine which connections to close due to timeout or load conditioning, gets all the connections from the pool for some time. Threads requiring a connection when this operation is fired, will create new connections while the maximum is not reached.
> The proposed solution consists of changing the implementation of the cleanStaleConnections so that it does not get all the connections from the pool at some point but instead, takes one at a time in order to determine if it should close it.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)