I've reproduced your problem and am looking into it. It turns out that
it doesn't have to do with security-udp-dhalgo but with security
credentials.
On 4/15/18 11:08 PM, Thacker, Dharam wrote:
Thanks John/Bruce!
But it does not work as expected.
I tried setting (*security-udp-dhalgo=*) in properties file in both
locators and servers.
I also confirmed the same by verifying config level logs and using
locator with following command which explicitly mentions that
*“security-udp-dhalgo” is empty (gemfire.sys.security-udp-dhalgo =)*
>> describe config –member=locator1
>> describe config –member=server1
But even after that, I see following exception which is same as before.
More, it looks like that once GEODE server member reboot itself after
force disconnection, it does not respect *security-udp-dhalgo*
override in properties file (/My assumption based on logs/)
I see *security-udp-dhalgo=********* in startup configuration *after
member’s attempt to connect to distributed system*.
[warning 2018/04/15 21:23:57.095 EDT event-server-1<ReconnectThread>
tid=0x215] Exception occurred while trying to connect the system
during reconnect
org.apache.geode.security.AuthenticationRequiredException: Failed to
find credentials from [host-001(event-server-1:32054)<ec>:1025]
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.attemptToJoin(GMSJoinLeave.java:424)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.join(GMSJoinLeave.java:318)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:656)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:745)
at
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:181)
at
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at
org.apache.geode.distributed.internal.DistributionManager.<init>(DistributionManager.java:1112)
at
org.apache.geode.distributed.internal.DistributionManager.<init>(DistributionManager.java:1160)
at
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:202)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2675)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2508)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:983)
at
org.apache.geode.distributed.internal.DistributionManager$MyListener.membershipFailure(DistributionManager.java:4307)
John,
This does not kill GEODE application. It still runs as it is. This
makes APM tool to assume that application is healthy and is not facing
any issues.
What do you suggest to rectify this?
Is there any example if I can report state of GEODE server as
“UNHEALTHY”/”DISCONNECTED”?
Is there any example if I can listen to these notifications and come
up with some health check service?
Thanks & Regards,
Dharam
*From:*John Blum [mailtojb...@pivotal.io <mailto:jb...@pivotal.io>]
*Sent:* Friday, April 13, 2018 2:59 AM
*To:* user@geode.apache.org <mailto:user@geode.apache.org>
*Subject:* Re: AuthenticationRequiredException on force disconnection
Regarding /Spring/, not really too differently actually, see here
<https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/resources/spring-server-cache.xml#L24-L33> [1]
(XML) and here
<https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/java/server/JavaConfiguredGeodeServerApplication.java#L66-L84> [2]
(/JavaConfig/) (followed by this
<https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/java/server/JavaConfiguredGeodeServerApplication.java#L91> [3]
and this
<https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/java/server/JavaConfiguredGeodeServerApplication.java#L96> [4]).
There is even an Annotation-based approach
<https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/annotation/server/AnnotationConfiguredGeodeServerApplication.java> [5]
for the curious onlooker.
[1]
https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/resources/spring-server-cache.xml#L24-L33
[2]
https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/java/server/JavaConfiguredGeodeServerApplication.java#L66-L84
[3]
https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/java/server/JavaConfiguredGeodeServerApplication.java#L91
[4]
https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/java/server/JavaConfiguredGeodeServerApplication.java#L96
[5]
https://github.com/jxblum/contacts-application/blob/master/configuration-example/src/main/java/example/app/spring/annotation/server/AnnotationConfiguredGeodeServerApplication.java
On Thu, Apr 12, 2018 at 2:17 PM, Bruce Schuchardt
<bschucha...@pivotal.io <mailto:bschucha...@pivotal.io>> wrote:
The setting merely causes Geode to encrypt packets sent over UDP.
On 4/11/18 10:29 AM, Thacker, Dharam wrote:
Would there be any negative impact on disabling 'security-udp-dhalgo'
on peer to peer members or pulse or jmx notifications ?
Thanks,
Dharam
--
-John
john.blum10101 (skype)
This message is confidential and subject to terms at:
http://www.jpmorgan.com/emaildisclaimer
<http://www.jpmorgan.com/emaildisclaimer> including on
confidentiality, legal privilege, viruses and monitoring of electronic
messages. If you are not the intended recipient, please delete this
message and notify the sender immediately. Any unauthorized use is
strictly prohibited.