The 4 SQE tests jmxmp_sasl_[05|10|15|18] started to fail with Mustang b46; it is still the case with b49.
The jmxmp implementation used comes from JDMK 5.1.
The failure is not OS specific (Solaris 9 & 10, RedHat RHEL 3, RedHat RHEL 4). Windows has not been tried.
What failing tests have in common is that they do a connect that should fail because the handler on server side throws a java.lang.InternalError. What varies between tests is profile (PLAIN, CRAM-MD5, DIGEST-MD5).
Note that the same tests where it is an Exception which is thrown are fine.

After the Job_Executor0 thread on server side dies (as expected), the client side should receive an IOException.
With builds up to Mustang b45, the IOE was received within a minute; now you have to wait at leats one hour so it exceeds the total test time allocated by the test harness.

The stuck client can be unlocked if you kill manually the server side so it could mean some resource is not freed fast enough on server side.
The client is stuck on:
"main" prio=10 tid=0x00037910 nid=0x1 runnable [0xffbfd000..0xffbfe7f8]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
- locked <0xccccd2d8> (a java.io.BufferedInputStream)
at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2200)
at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2490)
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2500)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1267)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
at com.sun.jmx.remote.socket.SocketConnection.readMessage(SocketConnection.java:211)
at com.sun.jmx.remote.opt.security.AdminClient.connectionOpen(AdminClient.java:135)
at com.sun.jmx.remote.generic.ClientSynchroMessageConnectionImpl.connect(ClientSynchroMessageConnectionImpl.java:71)
- locked <0xcccb6418> (a [I)
at javax.management.remote.generic.GenericConnector.connect(GenericConnector.java:177)
- locked <0xccc774d0> (a [I)
at javax.management.remote.jmxmp.JMXMPConnector.connect(JMXMPConnector.java:119)
at javax.management.remote.generic.GenericConnector.connect(GenericConnector.java:124)
at javasoft.sqe.jmx.share.TestRoot.do_jmxClientConnect(TestRoot.java:163)
at javasoft.sqe.jmx.share.TestRoot.do_jmxClientUp(TestRoot.java:87)
at javasoft.sqe.jmx.test.functional.SecurityTest.run(SecurityTest.java:49)
at javasoft.sqe.jmx.share.TestStarter.<init>(TestStarter.java:40)
at javasoft.sqe.jmx.share.TestStarter.main(TestStarter.java:98)
As of Mustang b86 it's all the same. I would even say it's worse because, thanks daily automated run, we now know it can occur too in case it's an Exception which is thrown by the callback handler, no only when it's an Error.
That means all tests jmxmp_sasl_<i> where <i> is 2, 3, 4, 5, 7, 8, 9, 10, 12, 13, 14, 15, 17 or 18 are likely to fail.