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