Thank you to everyone who participated in this discussion.
After a quick tally of responses, it looks like there are 6 people in favour of
the change happening right now and 3 who are in favour but would prefer it to
wait for a major version change. While this isn't a strong consensus, I do
I agree with Dan, here, along with the consensus that false is the better
default (in most cases).
So, I simply want to re-iterate the importance of "documentation" in whatever
direction we decide. There are, without a doubt, both pros and cons to each
configuration arrangement (true of
I will go ahead and withdraw my objection to this change. Based on some side
conversations, at least at VMWare it sounds like we don't have customers that
are not setting this flag. So the scenario I'm worried about where a customer
upgrades their production cluster and has it crash due to this
Barry, Thanks for the detailed response. Very helpful.
On 12/3/20, 4:22 PM, "Barrett Oglesby" wrote:
Anil, you wrote:
- We need to be thinking about auto setting of configuration values
(dynamic) based on the load, resource availability and service agreements.
It would be cool
Anil, you wrote:
- We need to be thinking about auto setting of configuration values (dynamic)
based on the load, resource availability and service agreements.
It would be cool to eventually remove this property altogether and
auto-configure it. Besides the things you mention, another thing
+1 for having the default be conserve-sockets=false. Any time there has been
trouble and conserve-sockets=true is involved we always suggest changing it to
false.
On 12/3/20, 6:58 AM, "Anilkumar Gingade" wrote:
I was conversing with few of the dev's about requirement of different
I was conversing with few of the dev's about requirement of different
settings/configuration for set of nodes in the cluster depending on the
business/application needs; for example set of nodes serving different kind of
application requirement (data store) than other nodes in the cluster
OK, I double checked, my memory is wrong. It was true as early as 6.0.
From: Xiaojian Zhou
Date: Wednesday, December 2, 2020 at 3:29 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false
+1
I think it’s good to change back the default to be
+1
I think it’s good to change back the default to be false. It was false before.
From: Barrett Oglesby
Date: Wednesday, December 2, 2020 at 3:14 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false
I ran a bunch of tests using the
I ran a bunch of tests using the long-running-test code where the servers had a
mix of conserve-sockets settings, and they all worked ok.
One set of tests had 6 servers - 3 with conserve-sockets=false and 3 with
conserve-sockets=true.
Another set of tests had 4 servers - 3 with
Udo, you’re correct that individual servers can set the property independently.
I was assuming this is more like the ’security-manager` property and others
that require all cluster members to be in agreement.
I’m not sure I understand the use case to allow this setting to be per-member.
That
Passed dunit tests is not enough. It might only mean we don't have enough test
coverage.
We need to inspect the code to see what will be the behavior when 2 servers
configured different conserve-sockets.
On 11/20/20, 3:30 PM, "Donal Evans" wrote:
Regarding behaviour during
Regarding behaviour during RollingUpgrade; I created a draft PR with this
change to test the feasibility and see what problems, if any, would be caused
by tests assuming the default setting to be true. After fixing two DUnit tests
that were not explicitly setting the value of conserve-sockets
@Anthony I cannot think of a single reason, why the server should not start up,
even in a rolling upgrade. This setting should not have an effect on the
cluster (other than potentially positive). Also, if the Geode were to enforce
this setting across the cluster, then we have seriously broken
1) Conserve-socket will only impact p2p connection. If set to false, that mean
the p2p connections between 2 servers can be created on request, as many as
needed.
2) currently the default setting is true (I don't remember when did we change
it from false to true)
3) For rollingUpgrade,
Question: how would this work with a rolling upgrade? If the user did not set
this property and we changed the default I believe that we would prevent the
upgraded member from rejoining the cluster.
Of course the user could explicitly set this property as you point out.
Anthony
> On Nov
While I agree that the potential impact of having the setting changed out from
a user may be high, the cost of addressing that change is very small. All users
have to do is explicitly set the conserve-sockets value to true if they were
previously using the default and they will be back to where
I think there are many good reasons to flip the default value for this
property. I do question whether requiring a user to allocate new hardware to
support the changed resource requirements is appropriate for a minor version
bump. In most cases I think that would come as an unwelcome surprise
Personally, this has caused enough grief in the past (both ways, actually!)
that I 'd say this is a major version change.
I agree with John. Either value of conserve-sockets can crash or hang your
system depending on your use case.
If this was just a matter of slowing down or speeding up
Just to clarify a comment from Owen, conserve-sockets=true does show improved
performance over conserve-sockets=false in certain specific scenarios, but this
isn't a hard and fast rule that applies everywhere, even excluding the cases
where using conserve-sockets=true can lead to distributed
I would argue that is doesn’t change the outward behavior of the product. It
does change the internal workings of the product. It does improve the
performance and reliability. As long as changes to the internals don’t have
effect on the outward facing behavior of the product I see no problem
I'm all in for changing the default to *false* but, unfortunately and for
all the reasons already stated in the thread, I'm hesitant to include this
change as part of a minor release.
Best regards.
On Thu, 19 Nov 2020 at 02:48, John Blum wrote:
> The downside of conserve-sockets = false is that
The downside of conserve-sockets = false is that you are (essentially) back to
a Thread|Socket / Request model (though Geode limits this system resource
consumption to a degree by the use of Thread Pools in p2p distribution layer)
and thus, you can run out of file descriptors (per newly opened
+1
* As nearly all of the production use-cases need "conserve-sockets" to be
set to false, I think we can aim for changing the default value to false for
1.14.0 release.
* We can highlight this change in the release notes and emails.
Regards,
Nabarun
I’m not familiar with the inner workings, but your writeup is excellent and
makes a compelling case.
It sounds like you are saying that the original motivation for
conserve-sockets=true was to improve performance, but in fact it makes
performance worse. Do you have some numbers to quantify
Hi there Donal,
Thank you for raising this. It is not an uncommon request to change the default
value of this field.
This has been discussed many times in the past. I would LOVE to approve this
change, but this would mean that users that don’t set this property might
suddenly have this
Hi Geode dev,
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
27 matches
Mail list logo
