You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Galen O'Sullivan (JIRA)" <ji...@apache.org> on 2017/06/14 22:58:00 UTC
[jira] [Created] (GEODE-3076) Simplify connection count logic in
AcceptorImpl
Galen O'Sullivan created GEODE-3076:
---------------------------------------
Summary: Simplify connection count logic in AcceptorImpl
Key: GEODE-3076
URL: https://issues.apache.org/jira/browse/GEODE-3076
Project: Geode
Issue Type: Improvement
Components: client/server
Reporter: Galen O'Sullivan
It looks like AcceptorImpl gets the number of connections, then creates a connection, then increments the count, then handles errors.
This logic is a bit confusing. It could cause real problems if {{AcceptorImpl}}s were running in multiple threads.
This code would be much cleaner if it did an {{incrementAndGet()}} on the server count, checked the value, and incremented if it had gotten a valid number in the count.
{code}
if (communicationMode != CLIENT_TO_SERVER_FOR_QUEUE) {
int curCnt = this.getClientServerCnxCount();
if (curCnt >= this.maxConnections) {
<snip -- error handling, early exit>
}
}
ServerConnection serverConn = new ServerConnection(s, this.cache, this.crHelper, this.stats,
AcceptorImpl.handShakeTimeout, this.socketBufferSize, communicationModeStr,
communicationMode, this, this.securityService);
synchronized (this.allSCsLock) {
this.allSCs.add(serverConn);
ServerConnection snap[] = this.allSCList; // avoid volatile read
this.allSCList = (ServerConnection[]) ArrayUtils.insert(snap, snap.length, serverConn);
}
if (communicationMode != CLIENT_TO_SERVER_FOR_QUEUE) {
incClientServerCnxCount();
}
if (isSelector()) {
serverConn.registerWithSelector();
} else {
try {
pool.execute(serverConn);
} catch (RejectedExecutionException rejected) {
<snip -- error handling, cleanup and exit>
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)