[ 
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)

Reply via email to