[
https://issues.apache.org/jira/browse/GEODE-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160006#comment-17160006
]
ASF GitHub Bot commented on GEODE-8349:
---------------------------------------
bschuchardt commented on a change in pull request #5363:
URL: https://github.com/apache/geode/pull/5363#discussion_r456520985
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/tcp/ClusterConnection.java
##########
@@ -1142,31 +1154,46 @@ private Connection(ConnectionTable t, boolean
preserveOrder, InternalDistributed
InetSocketAddress addr =
new InetSocketAddress(remoteID.getInetAddress(),
remoteID.getDirectChannelPort());
- SocketChannel channel = SocketChannel.open();
- owner.addConnectingSocket(channel.socket(), addr.getAddress());
-
- try {
- channel.socket().setTcpNoDelay(true);
- channel.socket().setKeepAlive(SocketCreator.ENABLE_TCP_KEEP_ALIVE);
+ int connectTime = getP2PConnectTimeout(conduit.getDM().getConfig());
+ boolean useSSL = getConduit().useSSL();
+ if (useSSL) {
+ int socketBufferSize =
+ sharedResource ? SMALL_BUFFER_SIZE :
this.owner.getConduit().tcpBufferSize;
+ socket = getConduit().getSocketCreator().forAdvancedUse().connect(
+ new HostAndPort(remoteID.getHostName(),
remoteID.getDirectChannelPort()),
+ 0, null, false, socketBufferSize, true);
+ setSocketBufferSize(this.socket, false, socketBufferSize, true);
+ } else {
+ SocketChannel channel = SocketChannel.open();
+ socket = channel.socket();
// If conserve-sockets is false, the socket can be used for receiving
responses, so set the
// receive buffer accordingly.
if (!sharedResource) {
- setReceiveBufferSize(channel.socket(),
owner.getConduit().tcpBufferSize);
+ setReceiveBufferSize(socket, owner.getConduit().tcpBufferSize);
} else {
- setReceiveBufferSize(channel.socket(), SMALL_BUFFER_SIZE); // make
small since only
+ setReceiveBufferSize(socket, SMALL_BUFFER_SIZE); // make small since
only
// receive ack messages
}
- setSendBufferSize(channel.socket());
- channel.configureBlocking(true);
+ }
+ owner.addConnectingSocket(socket, addr.getAddress());
+
+ try {
+ socket.setTcpNoDelay(true);
+ socket.setKeepAlive(SocketCreator.ENABLE_TCP_KEEP_ALIVE);
- int connectTime = getP2PConnectTimeout(conduit.getDM().getConfig());
+ setSendBufferSize(socket);
+ if (!useSSL) {
+ socket.getChannel().configureBlocking(true);
+ }
try {
- channel.socket().connect(addr, connectTime);
-
- createIoFilter(channel, true);
+ if (!useSSL) {
+ // haven't connected yet
+ socket.connect(addr, connectTime);
+ }
+ configureInputStream(socket, true);
Review comment:
"client" socket is a term from TLS, where one side must be the "client"
and the other side is the "server".
The sockets in this class may be one-way or may be bidirectional. "Shared"
connections (those shared between threads) are one-way. Thread-owned
connections are bidirectional. A P2P "reader" thread reads from the socket and
DirectReplyProcessor writes responses.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> reinstate use of SSLSocket for cluster communication
> ----------------------------------------------------
>
> Key: GEODE-8349
> URL: https://issues.apache.org/jira/browse/GEODE-8349
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
> Reporter: Bruce J Schuchardt
> Assignee: Bruce J Schuchardt
> Priority: Major
> Labels: pull-request-available
>
> We've found problems with "new IO"'s SSLEngine with respect to support for
> TLSV1. We've also seen anomalous performance using that secure
> communications mechanism. The introduction of the use of the "new IO"
> SSLEngine was originally to 1) reduce code complexity in the
> org.apache.geode.internal.tcp package and 2) to set the stage for its use in
> client/server communications so that selectors could be used in c/s
> communications.
> This ticket aims to reintroduce the use of SSLSocket in cluster
> communications without restoring the old, poorly tested SSL code paths. The
> new implementation should have as good or better performance than the
> previous"old IO" implementation and the more recent "new IO" SSLEngine
> implementation as well. This should be apparent in the CI benchmark jobs.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
