See description in the JIRA issue.
Bela Ban <bela> made a comment on jira JGRP-1722 See if ENCRYPT could be moved *down* the stack, e.g. just below the reliable retransmission protocols ({{NAKACK}, {{UNICAST}}). I seem to recall though that ENCRYPT has a dep on GMS.
Bela Ban <bela> made a comment on jira JGRP-1722 See if ENCRYPT could be moved *down* the stack, e.g. just below the reliable retransmission protocols (NAKACK, UNICAST). I seem to recall though that ENCRYPT has a dep on GMS.
Martin Gencur <mgencur> made a comment on jira JGRP-1722 The replication works also with ENCRYPT placed under NAKACK while AUTH is placed under GMS. My functional test for the ISPN server passes with this configuration. Data is successfully replicated.
Bela Ban <bela> made a comment on jira JGRP-1722 I think this is only true if (a) there is no communication between joiner and coordinator needed or (b) the transport is reliable. * (a) If we have a shared keystore or username/password encryption, then this works * (b) If we need to send a key request to the coord, and the coord sends a response, then either the transport needs to be reliable or UNICAST needs to be below ENCRYPT, or else these requests are sent *unreliably* and might get lost. A possible solution for (b) could be to assume that the message sending is unreliable and send the key request to the coordinator until a valid key is received. In this case, ENCRYPT could be moved under NAKACK/UNICAST. [~mgencur] Either you used TCP as transport, or you were just lucky that the message wasn't dropped. Under real stress, there are no guarantees that a message isn't dropped.
Bela Ban <bela> updated the status of jira JGRP-1722 to Resolved
This needs further analysis. Moving target to 6.5. This will be revisited after 6.4