[
https://issues.apache.org/jira/browse/GEODE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246834#comment-17246834
]
ASF GitHub Bot commented on GEODE-8778:
---------------------------------------
DonalEvans commented on pull request #5832:
URL: https://github.com/apache/geode/pull/5832#issuecomment-742069511
> Why are the two tests modified in this PR setting the the value against
the new default? If the default is `false` now it stands to reason that unless
a tests is explicitly testing socket conservation that it should use the new
default of `false`.
Thanks for bringing this up, Jake. After looking closer at the first test,
`ClusterDistributionManagerDUnitTest`, it doesn't need to explicitly set
conserve-sockets to true, just add an additional ignored exception due to a
slightly different code path resulting in (expected) logging about
`ack-severe-alert-threshold` being exceeded. I've modified the test to reflect
this.
The second test, `CloseConnectionTest` is explicitly testing the behaviour
of shared connections, so it requires that conserve-sockets=true. I think it
was just an oversight to not set the value and instead rely on the default.
----------------------------------------------------------------
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
> Change the default value of conserve-sockets to false
> -----------------------------------------------------
>
> Key: GEODE-8778
> URL: https://issues.apache.org/jira/browse/GEODE-8778
> Project: Geode
> Issue Type: Improvement
> Affects Versions: 1.14.0
> Reporter: Donal Evans
> Priority: Major
> Labels: pull-request-available
>
> See also the dev list discussion on this subject.
> First, from the docs[1], a brief explanation of the purpose of the
> conserve-sockets property:
>
> "The conserve-sockets setting indicates whether application threads share
> sockets with other threads or use their own sockets for member communication.
> This setting has no effect on communication between a server and its clients,
> but it does control the server’s communication with its peers or a gateway
> sender’s communication with a gateway receiver."
>
> The current default value for the conserve-sockets property is true, which
> at first glance makes sense, since in an ideal world, existing sockets could
> be shared between threads and there would be no need to create and destroy
> new sockets for each process, which can be somewhat resource-intensive.
> However, in practice, there are several known issues with using the default
> setting of true. From the docs[1]:
>
> "For distributed regions, the put operation, and destroy and invalidate for
> regions and entries, can all be optimized with conserve-sockets set to false.
> For partitioned regions, setting conserve-sockets to false can improve
> general throughput.
> Note: When you have transactions operating on EMPTY, NORMAL or PARTITION
> regions, make sure that conserve-sockets is set to false to avoid distributed
> deadlocks."
>
> and[2]:
>
> "WAN deployments increase the messaging demands on a Geode system. To avoid
> hangs related to WAN messaging, always set `conserve-sockets=false` for Geode
> members that participate in a WAN deployment."
>
> Given that it is generally accepted as best practice to set conserve-sockets
> to false for almost all use cases of Geode beyond the most simple, it would
> make sense to also change the default value to false, to prevent people
> having to encounter a problem, search for the solution, then change the
> setting to what is almost always the "correct" value.
>
> [1]
> [https://geode.apache.org/docs/guide/113/managing/monitor_tune/performance_controls_controlling_socket_use.html|http://example.com/]
> [2]
> [https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
