Details

Description

When running simple functionality tests (that use STOMP+SSL) against apollo-99-trunk-20130115.031918-158, everything works fine when the broker runs on top of a Java 6 JVM.

However, the exact same tests again the exact same version of Apollo fail randomly when the broker runs on top of a Java 7 JVM. For the record, we use: Java HotSpot(TM) 64-Bit Server VM 1.7.0_10 (Oracle Corporation).

Lionel Cons
added a comment - 08/Apr/13 13:12 Hiram, I ran several tests and I confirm that the problem goes away when using the Bouncy Castle jar. Thanks for the workaround while the Java bug gets fixed.
However, since console is rarely used (we start Apollo via as a service), it would be better to log the provider info as a normal message ending up in apollo.log...

Ok, lets try something else. Luckily the crypto implementations in the JVM are pluggable, and the bouncycastle folks have a very excellent implementation. I've just deployed a new version of Apollo [1] which will install the bouncycastle security provider if it finds it in the classpath. You just need to install the bcprov-jdk15on-148.jar [2] in Apollo's lib directory. You'll know it got loaded if on startup, you see the 'Loaded the Bouncy Castle security provider.' message logged to the console.

Hiram Chirino
added a comment - 05/Apr/13 15:14 Ok, lets try something else. Luckily the crypto implementations in the JVM are pluggable, and the bouncycastle folks have a very excellent implementation. I've just deployed a new version of Apollo [1] which will install the bouncycastle security provider if it finds it in the classpath. You just need to install the bcprov-jdk15on-148.jar [2] in Apollo's lib directory. You'll know it got loaded if on startup, you see the 'Loaded the Bouncy Castle security provider.' message logged to the console.
[1] : https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-apollo/99-trunk-SNAPSHOT/apache-apollo-99-trunk-20130405.150934-220-unix-distro.tar.gz
[2] : http://www.bouncycastle.org/download/bcprov-jdk15on-148.jar
Lionel, could you check to see if bouncycastle impl behaves better than the default JVM impl.

Lionel Cons
added a comment - 05/Apr/13 06:52 Hiram, I've enabled debugging but this is very verbose: I logged >100MB in only a few minutes. Also, the broker seemed slowed down because of this logging and the test results were different.
Most sessions appeared as:
%% Initialized: [Session-3, SSL_NULL_WITH_NULL_NULL]
%% Negotiating: [Session-3, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA]
...
Cipher Suite: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Regarding the client used, this is using Perl + Net::STOMP::Client.
You should be able to perform the same tests by fetching the same package ( http://svn.cern.ch/guest/MIG/trunk/mbtf ) and follow the instructions in README.howto.

Hi, could you enable the JVM's SSL debug logging by adding the '-Djavax.net.debug=all' JVM option? Typically that can be done by setting the following env variable before running Apollo: APOLLO_OPTS=-Djavax.net.debug=all

The SSL debug data will be sent to the console. That should give us more details what cypher suites are being picked etc. Also what OS/SSL library is your client using. Is there something you can share to reproduce?

Hiram Chirino
added a comment - 04/Apr/13 13:30 Hi, could you enable the JVM's SSL debug logging by adding the '-Djavax.net.debug=all' JVM option? Typically that can be done by setting the following env variable before running Apollo: APOLLO_OPTS=-Djavax.net.debug=all
The SSL debug data will be sent to the console. That should give us more details what cypher suites are being picked etc. Also what OS/SSL library is your client using. Is there something you can share to reproduce?

Folks in the post in the previous thread reported that disabling the Diffie-Hellman cypher suite lets them work around the issue /w Java 7. I've just deployed a new build of Apollo which supports disabling the Diffie-Hellman cypher suite.

Lionel, if you get a chance could you try out the new snapshot build on Java 7 and update the connector configuration similar to the following:

Hiram Chirino
added a comment - 03/Apr/13 14:31 - edited Folks in the post in the previous thread reported that disabling the Diffie-Hellman cypher suite lets them work around the issue /w Java 7. I've just deployed a new build of Apollo which supports disabling the Diffie-Hellman cypher suite.
Lionel, if you get a chance could you try out the new snapshot build on Java 7 and update the connector configuration similar to the following:
<connector id="ssl" bind="ssl://0.0.0.0:61614?disabled_cypher_suites=DHE" />
Let me know if disabling the DHE cyphers helps out on Java 7.

Lionel Cons
added a comment - 21/Jan/13 10:32 FWIW, I got the same errors with apollo-99-trunk-20130119.032027-161.
Also, others got similar errors with other applications: http://community.igniterealtime.org/thread/48499 .
BTW, it would probably help to log a stack trace for these exceptions.