[
https://issues.jboss.org/browse/JGRP-2131?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-2131:
--------------------------------
Great investigation, Dennis!
I'm thinking of using an out-of-channel mechanism (e.g. separate SSL socket) to obtain
the secret key from the keyserver.
Although, if {{ASYM_ENCRYPT}} learns about the membership via {{JOIN_RSP}} or
{{INSTALL_MERGE_VIEW}} messages, it could go ahead and send a request for the secret key
to the keyserver...
If {{JOIN_RSP}} is the first message, then things will work, so the above mechanism would
be a second-line of-defense.
I'll write a unit test that uses Byteman to inject receiving a message that's not
tagged as first before the {{JON_RSP}} message. This should lead to a loop of {{JOIN_REQ}}
msgs sent from joiner to coordinator, eventually leading to a singleton cluster for the
joiner.
UNICAST3 drops all messages until it receives the first one
-----------------------------------------------------------
Key: JGRP-2131
URL:
https://issues.jboss.org/browse/JGRP-2131
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.10
Reporter: Dennis Reed
Assignee: Bela Ban
Fix For: 3.6.12, 4.0
UNICAST3.getReceiverEntry returns null if it hasn't seen the first message yet.
This causes UNICAST3.handleDataReceived to drop the message.
When you add *ENCRYPT, this causes a major deadlock. *ENCRYPT will queue most messages
until it gets the encryption key, which can often include the first message (so UNICAST3
won't see it yet). Then when an important message such as JOIN_RSP comes through,
UNICAST3 drops it. Since UNICAST3 never lets any messages through in this case, the
encryption key will never get set so that *ENCRYPT can pass the first message up and free
the deadlock.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)