If your brokers are behind your private LAN, you don't need this: <networkConnector name="secured-nc" uri="multicast://secured" > failover="true"/> <!-Do I really need this? -->
Where did you see the "failover=true" attribute any way? On Mon, Oct 22, 2012 at 2:11 AM, matteo rulli <matteo.ru...@abodata.com>wrote: > Dear all, > > I'd like just to get experts' advice on the following ActiveMQ (5.6.0) use > case. > > > > I would like to establish a network of brokers and dispatch brokers > existence through auto-discovery. > > > > The network of broker exists within a private LAN. Some consumers/producers > will operate within the same LAN, some others outside the LAN. If the > consumers/producers operate within the LAN I want to consume and produce > messages through TCP openwire. Otherwise, if clients are outside the > private > LAN, I want them to interact with the network of brokers through SSL. > > > > In any case, I want the clients be able to discover new instances of > brokers > through discovery. > > > > So the question is: is the following broker-side configuration ok? > > > > . > > <networkConnectors> > > <networkConnector name="default-nc" uri="multicast://default"/> > > <networkConnector name="secured-nc" uri="multicast://secured" > failover="true"/> <!-Do I really need this? --> > > </networkConnectors> > > > > <transportConnectors> > > <transportConnector name="openwire" uri="tcp://0.0.0.0:61616" > updateClusterClients="true" > > discoveryUri="multicast://default"/> <!-- LAN connections --> > <transportConnector name="ssl" uri="ssl+nio://0.0.0.0:61617" > updateClusterClients="true" > > discoveryUri="multicast://secured"/> <!-- Extra-LAN connections --> > > </transportConnectors> > . > > > > And client-side I would use either the ssl or the tcp connector, depending > on client location: > > failover://tcp://primary:61616 if my client (producer or > consumer) is within the LAN > > failover://ssl://primary:61616 if my client (producer or > consumer) is outside the LAN > > > > Thank you for your answers! > > > > matteo > > > > -- *Christian Posta* http://www.christianposta.com/blog
