You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by matteor <ma...@abodata.com> on 2013/11/15 18:13:52 UTC
Updateclusterclients attributes specified on NIO+SSL transports
I'm debugging for days the behavior of NIO+SSL transport against the
updateClusterClients, rebalanceClusterClients and
updateClusterClientsOnRemove props.
I have a broker configured with two different transport conn: NIO and
NIO+SSL, something like
nio://0.0.0.0:61616
nio+ssl://0.0.0.0:61619
Client-side I specified a connection string that point to NIO+SSL connector.
The point is that after a while the client switch from NIO+SSL to pure NIO.
Is this the expected behavior for client? I would expect that a client does
not change protocol.
I'm using AMQ 5.9.0.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Updateclusterclients-attributes-specified-on-NIO-SSL-transports-tp4674570.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
RE: Updateclusterclients attributes specified on NIO+SSL transports
Posted by matteor <ma...@abodata.com>.
Well, thank you for the insights about the PublishedAddressPolicy stuff. I
completely ignored that! Besides, I'll definitely try with "finite" ip
addresses instead of 0.0.0.0 one.
Still, I cannot understand why a client initially connected to a ssl
connector should switch to tcp just because server connectors specified
updateclusterclients prop. both for nio and nio+ssl.
And I cannot understand what role the PublishedAddressPolicy could have in
this process either...
Is there a transport property to configure the client to stick with ssl+nio,
instead of switching to tcp connections?
--
View this message in context: http://activemq.2283324.n4.nabble.com/Updateclusterclients-attributes-specified-on-NIO-SSL-transports-tp4674570p4674581.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
RE: Updateclusterclients attributes specified on NIO+SSL transports
Posted by Timothy Creswick <Ti...@vorboss.com>.
> Clients connect to tls-connector connector on port 51619 and point to the
> first broker.
>
> After few seconds they switch misteriously to the nio connector.
This makes sense to me.
I think if you look at the updateClusterClients behaviour you will see that the broker will announce other network brokers to its clients.
For this to work, my understanding is that the network of brokers needs to be interconnected using _the same_ transport connector that your clients connect to.
I might be wrong (I need to go through the source code again), however I'm pretty sure that "updateClusterClients" will cause the broker to announce the URIs that it uses to connect to other brokers in the network (in this case, the NIO connectors discovered on multicast).
Regards,
Tim
RE: Updateclusterclients attributes specified on NIO+SSL transports
Posted by matteor <ma...@abodata.com>.
Well, I use an embedded broker and the config file is not in a standard
activemq xml format. Thus the config entries are slightly different from
standard activemq ones:
<cnf:networkConnectors>
<cnf:networkConnector uri="multicast://239.252.0.10" networkTTL="5"
duplex="true"
suppressDuplicateQueueSubscriptions="true"
decreaseNetworkConsumerPriority="true"/>
</cnf:networkConnectors>
<cnf:transportConnectors>
<cnf:transportConnector name="openwire"
uri="nio://10.0.3.30:61616?transport.soTimeout=60000"
discoveryUri="multicast://239.252.0.10"
updateClusterClients="true" auditNetworkProducers="true" />
<cnf:transportConnector name="tls-connector"
uri="nio+ssl://10.0.3.30:51619?needClientAuth=true&transport.soTimeout=60000"
updateClusterClients="true" />
</cnf:transportConnectors>
where updateClusterClients means update on removal and balance clients as
well. Besides, we set the following
<conditionalNetworkBridgeFilterFactory replayWhenNoConsumers="true" />
Configuration of second broker is similar.
Clients connect to tls-connector connector on port 51619 and point to the
first broker.
After few seconds they switch misteriously to the nio connector.
I hope I have enough time this week to put into practice your suggestions
and keep on working on this.
Thank you very much, I really appreciate your help.
--
View this message in context: http://activemq.2283324.n4.nabble.com/Updateclusterclients-attributes-specified-on-NIO-SSL-transports-tp4674570p4674644.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
RE: Updateclusterclients attributes specified on NIO+SSL transports
Posted by Timothy Creswick <Ti...@vorboss.com>.
> Still, I cannot understand why a client initially connected to a ssl
> connector should switch to tcp just because server connectors specified
> updateclusterclients prop. both for nio and nio+ssl.
> And I cannot understand what role the PublishedAddressPolicy could have in
> this process either...
>
> Is there a transport property to configure the client to stick with ssl+nio,
> instead switching to tcp connections?
I'm not sure about that, but I think for this to work, your network of brokers needs to be using SSL between the brokers.
Can you share your configuration?
RE: Updateclusterclients attributes specified on NIO+SSL transports
Posted by matteor <ma...@abodata.com>.
Well, thank you for the insights about the PublishedAddressPolicy stuff. I
completely ignored that! Besides, I'll definitely try with "finite" ip
addresses instead of 0.0.0.0 one.
Still, I cannot understand why a client initially connected to a ssl
connector should switch to tcp just because server connectors specified
updateclusterclients prop. both for nio and nio+ssl.
And I cannot understand what role the PublishedAddressPolicy could have in
this process either...
Is there a transport property to configure the client to stick with ssl+nio,
instead switching to tcp connections?
--
View this message in context: http://activemq.2283324.n4.nabble.com/Updateclusterclients-attributes-specified-on-NIO-SSL-transports-tp4674570p4674580.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
RE: Updateclusterclients attributes specified on NIO+SSL transports
Posted by Timothy Creswick <Ti...@vorboss.com>.
> Client-side I specified a connection string that point to NIO+SSL connector.
> The point is that after a while the client switch from NIO+SSL to pure NIO.
> Is this the expected behavior for client? I would expect that a client does
> not change protocol.
Hi Matteo,
I spent a lot of time debugging something similar with the failover transport a couple of weeks ago and posted this message: http://activemq.2283324.n4.nabble.com/Setting-PublishedAddressPolicy-on-TransportConnector-incl-workaround-tt4673632.html
It looks like the transport connectors are effectively "self aware" when they announce across the broker network. It appears to be imperative that you have your hostnames correctly setup, and you also have PTR which resolves properly. I think that using 0.0.0.0 addresses in the connector can cause problems because the PublishedHostStrategy will attempt to figure out the hostname using an alternative method.
In our deployment we ended up specifying the PublishedAddressPolicy. This will likely be a bit different for you if you need SSL.
Hope this helps.
Regards,
T