[Dennis Reed]

ENCRYPT appears to have threading issues (JGroups 2.6.x).

ENCRYPT shares one symDecodingCipher object for all incoming messages on the channel, and when two messages come through ENCRYPT at the same time, it's throwing an exception on one of them:

2010-08-16 11:14:23,723 WARN [org.jgroups.protocols.ENCRYPT] (Incoming-16,127.0.0.2:12345) exception occurred decrypting message
javax.crypto.BadPaddingException: Given final block not properly padded
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.BlowfishCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at org.jgroups.protocols.ENCRYPT._decrypt(ENCRYPT.java:852)
at org.jgroups.protocols.ENCRYPT.decryptMessage(ENCRYPT.java:844)
at org.jgroups.protocols.ENCRYPT.handleUpMessage(ENCRYPT.java:687)
at org.jgroups.protocols.ENCRYPT.up(ENCRYPT.java:546)

I replicated this error by just adding ENCRYPT to the default "udp" stack in EAP 5 and starting two instances.
...
<FRAG2 frag_size="60000"/>
<ENCRYPT sym_init="56" sym_algorithm="Blowfish" asym_init="512" asym_algorithm="RSA"/>
<!-- pbcast.STREAMING_STATE_TRANSFER/ -->
...

Would just synchronizing on the Cipher object in _decrypt be a good fix for this?
(I know there's been a lot of work in the newer versions to avoid synchronization where possible).

It looks like the same issue could occur in encyptMessage with the symEncodingCipher as well.

-Dennis