You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Bruce Schuchardt (JIRA)" <ji...@apache.org> on 2017/10/13 18:17:00 UTC

[jira] [Comment Edited] (GEODE-3637) configureClientSSLSocket call can block Acceptor thread

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

Bruce Schuchardt edited comment on GEODE-3637 at 10/13/17 6:16 PM:
-------------------------------------------------------------------

It seems to me that the point here is to have the client connection honor client->server timeout settings.  In this case the thread on the server is involved in a synchronous communications with other servers in preparation for creating a Region and possibly transferring state for the region from another server.  That can't really be done asynchronously and the tcp/ip connections really must be formed in order to perform that communication.  If we just dropped the slow server out of the algorithm we might end up creating an empty region when there was actually state for the region on that slow server.

I do agree, though, that we need to move this code out of the AcceptorImpl if at all possible.  Creating the client's subscription queue should be moved to the ServerConnection thread.


was (Author: bschuchardt):
It seems to me that the point here is to have the client connection honor client->server timeout settings.  In this case the thread on the server is involved in a synchronous communications with other servers in preparation for creating a Region and possibly transferring state for the region from another server.  That can't really be done asynchronously and the tcp/ip connections really must be formed in order to perform that communication.  If we just dropped the slow server out of the algorithm we might end up creating an empty region when there was actually state for the region on that slow server.

> configureClientSSLSocket call can block Acceptor thread
> -------------------------------------------------------
>
>                 Key: GEODE-3637
>                 URL: https://issues.apache.org/jira/browse/GEODE-3637
>             Project: Geode
>          Issue Type: Bug
>          Components: client/server
>    Affects Versions: 1.1.0, 1.2.0
>            Reporter: Vahram Aharonyan
>            Priority: Critical
>
> org.apache.geode.internal.net.SocketCreator#configureClientSSLSocket timeout for Socket is being configured before starting SSL handshake only if passed "timeout" argument is larger than 0.
> Having sslSocket.startHandshake issued without setting timeout can result to the blocking of caller thread as in GEODE-2898, GEODE-3023.
> Below is the example of Handshaker thread stack-trace that got stacked:
> "Handshaker /10.124.195.100:10000 Thread 183" Id=526300 in RUNNABLE (running in native)
> Total blocked: 4   Total waited: 884
>   java.net.SocketInputStream.socketRead0(Native Method)
>   java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>   java.net.SocketInputStream.read(SocketInputStream.java:171)
>   java.net.SocketInputStream.read(SocketInputStream.java:141)
>   sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>   sun.security.ssl.InputRecord.read(InputRecord.java:503)
>   sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>   sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>   sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>   sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>   org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1088)
>   org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:967)
>   org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:929)
>   org.apache.geode.internal.net.SocketCreator.connectForServer(SocketCreator.java:908)
>   org.apache.geode.internal.tcp.Connection.<init>(Connection.java:1306)
>   org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1094)
>   org.apache.geode.internal.tcp.ConnectionTable.getOrderedAndOwned(ConnectionTable.java:553)
>   org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:664)
>   org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:1037)
>   org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:543)
>   org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:319)
>   org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:605)
>   org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1684)
>   org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1875)
>   org.apache.geode.distributed.internal.DistributionChannel.send(DistributionChannel.java:82)
>   org.apache.geode.distributed.internal.DistributionManager.sendOutgoing(DistributionManager.java:3416)
>   org.apache.geode.distributed.internal.DistributionManager.sendMessage(DistributionManager.java:3453)
>   org.apache.geode.distributed.internal.DistributionManager.putOutgoing(DistributionManager.java:1832)
>   org.apache.geode.internal.cache.UpdateAttributesProcessor.sendProfileUpdate(UpdateAttributesProcessor.java:162)
>   org.apache.geode.internal.cache.UpdateAttributesProcessor.distribute(UpdateAttributesProcessor.java:97)
>   org.apache.geode.internal.cache.DistributedRegion.initialized(DistributedRegion.java:1128)
>   org.apache.geode.internal.cache.LocalRegion.initialize(LocalRegion.java:2413)
>   org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1117)
>   org.apache.geode.internal.cache.HARegion.initialize(HARegion.java:345)
>   org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3308)
>   org.apache.geode.internal.cache.HARegion.getInstance(HARegion.java:265)
>   org.apache.geode.internal.cache.ha.HARegionQueue.createHARegion(HARegionQueue.java:348)
>   org.apache.geode.internal.cache.ha.HARegionQueue.<init>(HARegionQueue.java:328)
>   org.apache.geode.internal.cache.ha.HARegionQueue$BlockingHARegionQueue.<init>(HARegionQueue.java:2199)
>   org.apache.geode.internal.cache.ha.HARegionQueue$DurableHARegionQueue.<init>(HARegionQueue.java:2450)
>   org.apache.geode.internal.cache.ha.HARegionQueue.getHARegionQueueInstance(HARegionQueue.java:2030)
>   org.apache.geode.internal.cache.tier.sockets.CacheClientProxy$MessageDispatcher.<init>(CacheClientProxy.java:2315)
>   org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.initializeMessageDispatcher(CacheClientProxy.java:1728)
>   org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.initializeProxy(CacheClientNotifier.java:660)
>   org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerClient(CacheClientNotifier.java:587)
>   org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerGFEClient(CacheClientNotifier.java:379)
>   org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.registerClient(CacheClientNotifier.java:324)
>   org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.handleNewClientConnection(AcceptorImpl.java:1510)
>   org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$5.run(AcceptorImpl.java:1298)
>   java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   java.lang.Thread.run(Thread.java:748)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)