Thanks Bruce.
Will take a look at "WaitForViewInstallation".
-Anil.
On Fri, Apr 17, 2020 at 3:44 PM Anilkumar Gingade
wrote:
> Thanks Kirk.
> This is for PR clear; I ended up registering/adding a new membership
> listener on DistributionManager (DM).
>
> I was trying to take advantage of M
Thanks Kirk.
This is for PR clear; I ended up registering/adding a new membership
listener on DistributionManager (DM).
I was trying to take advantage of MembershipListener on PR region-advisor.
It turns out that this gets called even before the view is updated on DM.
-Anil
On Fri, Apr 17, 2020
AdvisorListener.memberDeparted() is invoked from paths other than membership
view changes, such as when a Region is destroyed. A member may still be in
the cluster (membership view) after AdvisorListener.memberDeparted() has been
invoked.
If isCurrentMember() returns true then the server is s
Any requirements for this to be a User API vs internal API?
For internal APIs, you can register a MembershipListener on
DistributionManager -- at least one flavor of which returns a
Set of current members which you could check
before relying on callbacks.
On Fri, Apr 17, 2020 at 3:03 PM Anilkumar
Conditional +1 from me too, pending a few days on develop with happy
results :)
Thanks Juan!
On Fri, Apr 17, 2020 at 1:41 AM Ju@N wrote:
> Hello devs,
>
> I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* branch.
> The bug is not new, seems quite old actually, but still seems
Is there a better way to know if a member has left the distributed system,
than following:
I am checking using:
"partitionedRegion.getDistributionManager().isCurrentMember(requester));"
This returns true, even though the AdvisorListener on
ParitionedRegion already processed memberDeparted() event.
I just started using this IntelliJ plugin and really like it:
https://plugins.jetbrains.com/plugin/10345-assertions2assertj
To install, go to IntelliJ Preferences -> Plugins -> Marketplace. Search
for "Assertions2Assertj" and Install it. You'll have to restart IntelliJ
before you can use it.
To u
Hi Alberto,
I think that if we want to support limited rolling downgrade some other version
interchange needs to be done and there need to be tests that prove that the
downgrade works. That would let us document which versions are compatible for
a downgrade and enforce that no-one attempts it
AvailableConnectionManagerConcurrentTest is passing after changing it to
use plain java coded stubs (no Mockito) which required some changes to
Connection and PooledConnection (internal classes). The other
ConcurrentTests are passing on the Mockito upgrade PR branch.
Locally, AvailableConnectionMa
Hi Bruce,
Thanks a lot for your answer. We had not thought about the changes in
distributed algorithms when analyzing rolling downgrades.
Rolling downgrade is a pretty important requirement for our customers so we
would not like to close the discussion here and instead try to see if it is
stil
Memcached IntegrationJUnitTest hangs the PR IntegrationTest job because
Cache.close() calls GeodeMemcachedService.close() which again calls
Cache.close(). Looks like the code base has lots of Cache.close() calls --
all of them could theoretically cause issues. I hate to add
ThreadLocal
isClosingThr
This log message about the GFE version is suspicious too. That is a VERY old
version with ordinal value 1. The C++ client is supposed to be sending 45 which
is GFE 9.0.0 / Geode 1.0.0.
Looks like there might be a handshake protocol misalignment somewhere. Will
keep digging.
-Jake
> On Apr 17,
Agreed… this definitely meets the inclusion requirements.
+1
On Apr 17, 2020, 1:50 AM -0700, Owen Nichols , wrote:
Hi Juan, this looks like a great fix and definitely meets the “critical fix"
standard. Also thanks for the detailed description.
I noticed it was just merged to develop very recentl
Can you confirm that when log level less than debug that the IOException goes
away and the client appears to function?
-Jake
> On Apr 17, 2020, at 1:12 AM, Jakov Varenina wrote:
>
> Hi Jacob,
>
> Thanks for your response!
>
> Regarding GEODE-7944, "Unable to deserialize *membership id*
> j
Sounds like something we should include.
+1
On Fri, Apr 17, 2020 at 4:41 AM Ju@N wrote:
> Hello devs,
>
> I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* branch.
> The bug is not new, seems quite old actually, but still seems pretty
> critical as it can lead to data loss in
Sounds good Owen, thanks!.
On Fri, 17 Apr 2020 at 09:50, Owen Nichols wrote:
> Hi Juan, this looks like a great fix and definitely meets the “critical
> fix" standard. Also thanks for the detailed description.
>
> I noticed it was just merged to develop very recently. I would like to
> see tha
Hi Juan, this looks like a great fix and definitely meets the “critical fix"
standard. Also thanks for the detailed description.
I noticed it was just merged to develop very recently. I would like to see
that it gets through all tests and spends a couple days on develop, then I will
be happy
Hello devs,
I'd like to propose bringing *GEODE-7940 [1]* to the *support/1.12* branch.
The bug is not new, seems quite old actually, but still seems pretty
critical as it can lead to data loss in WAN topologies.
Long story short: when there are multiple parallel *gateway-senders* attached
to the
Hi Jacob,
Thanks for your response!
Regarding GEODE-7944, "Unable to deserialize *membership id*
java.io.EOFException" is not logged but thrown, and it breaks processing
of QueueConnectionRequest in locator. This reflects in native client
with "No locators found" even though they are availabl
19 matches
Mail list logo
