geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrel Schneider (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-332) Add thread pooling to peer to peer distribution layer
Date Tue, 15 Sep 2015 21:19:45 GMT

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

Darrel Schneider commented on GEODE-332:
----------------------------------------

We found when testing network outages that calling close could hang. Bruce attempted to get
rid of the async close in 7.0 by setting SO_LINGER but we still saw close hangs. Here is his
last comment on this (he made it 3 years ago):
{quote}
The problem seems to be that we believed that removing the SO_LINGER setting on a tcp/ip socket
would keep it from hanging when closed in a situation like this. I removed the spawning of
threads to close receiver sockets in the com.gemstone.gemfire.internal.tcp package because
of that belief and it seemed to be working. That change has been run through network-down
tests many times but maybe we haven't run the pull-the-plug tests very much?
I'm going to revert the change and have it spawn threads to do the closing again.
{quote}


> Add thread pooling to peer to peer distribution layer
> -----------------------------------------------------
>
>                 Key: GEODE-332
>                 URL: https://issues.apache.org/jira/browse/GEODE-332
>             Project: Geode
>          Issue Type: Improvement
>            Reporter: Darrel Schneider
>            Assignee: Darrel Schneider
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Every time geode makes a peer-to-peer connection it creates a thread to read from that
connection. When the connection is closed it creates another thread to do the socket close
in the background just in case the close hangs. For certain use cases the lifetime of these
threads can be short but the rate at which they are created can be high.
> It would both improve performance and improve memory footprint if these threads were
reused from a pool instead of creating them every time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message