Not concerned about performance as it can be handled by using persistent
connections. It is only the initial handshake which takes time, which is
acceptable during boot up time.
It is the management of keys and other resources required to do TLS. By
using proxy server, we can centralize certifi
sults?
Justin
- Original Message -
From: "abhijith"
To: dev@activemq.apache.org
Sent: Monday, May 16, 2016 12:23:44 PM
Subject: Re: [Artemis] Bug in ServerLocatorImpl.createSessionFactory()
Sorry! I don't really follow. Its a HA cluster where we always want client
to commun
Sorry! I don't really follow. Its a HA cluster where we always want client
to communicate to brokers via TLS. Its not an issue for broker to broker
communication. Its an issue when client tries to communicate with broker.
I have followed replicated-failback-static example given
here(https://git
You can have multiple cluster connections, and specify an acceptor
with a different one, in such way the other nodes are not exposed to
the clients.
On Mon, May 16, 2016 at 12:41 PM, abhijith wrote:
> SSL offloading is the most common use case for fronting with proxy.
>
> client ---TLS---> Proxy/
SSL offloading is the most common use case for fronting with proxy.
client ---TLS---> Proxy/Reverse-Proxy(ssl-offload) ---TCP--> Artemis broker.
Unless you are using a container like tomcat/jboss to deploy the apps, above
setup is pretty common. It also helps to have non-tls communication with
Can you elaborate on why you would front the broker with a proxy? I'm not
familiar with this use-case.
Justin
- Original Message -
From: "abhijith"
To: dev@activemq.apache.org
Sent: Saturday, May 14, 2016 12:20:36 PM
Subject: [Artemis] Bug in ServerLocatorImpl.creat
Hi,
I think there is a bug in ServerLocatorImpl.createSessionFactory() method.
Issue is that if factory.connect(initialConnectAttempts,
failoverOnInitialConnection) is successful, it is always assumed that client
should be able to download Cluster Toplogy.
This might not be the case for any brok
