Hi Tim,
Yes we're using the ourmq.ourco.com address and the certificate common name
is the same.
So my very simplistic piece of java code looks like this:
System.setProperty("javax.net.debug","ssl");
ActiveMQSslConnectionFactory connectionFactory = new
ActiveMQSslConnectionFactory(
On 08/15/2016 09:53 AM, spamtrap wrote:
On Mon, 15 Aug 2016 09:06:42 -0400, Timothy Bish
wrote:
Thanks for the reply. However the broker string is configured by the
client so we cannot guarantee that it will be correct.
Our thoughts is to set startupMaxReconnectAttempts to >0. Will this
stop
On Mon, 15 Aug 2016 09:06:42 -0400, Timothy Bish
wrote:
Thanks for the reply. However the broker string is configured by the
client so we cannot guarantee that it will be correct.
Our thoughts is to set startupMaxReconnectAttempts to >0. Will this
stop it hanging?
>You are using failover so t
You are using failover so the client is attempting to reconnect, since
the port is wrong it never will obviously so giving it the correct port
is the way to go.
On 08/15/2016 08:34 AM, spamtrap wrote:
If the wrong port is given when trying to connect to a broker then we
get a hanging problem.
How do your clients address the broker when they connect to it? Do they
address it as ourmq.ourco.com, or as ourmq? The cert needs to match
whatever method they use to connect, though if you're not self-signing your
certs, FQDN is about to become the only option per this article:
https://www.goda
If the wrong port is given when trying to connect to a broker then we
get a hanging problem. The stack backtrace is:
#0 0x7f0ca3837a82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/usr/lib64/libpthread.so.0
(gdb) bt
#0 0x7f0ca3837a82 in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/usr
We are trying to use ACtiveMQ SSL with target-only authentication with a
trusted cert from DigiCert. We were able to use SSL with self-signed certs
but we seem to have an issue when we
move to using a commercial trusted cert. Looking at the documentation here:
https://access.redhat.com/documen
