Alex, I think we're talking about different things here. I understand _in general_ how ports for different protocols, etc. would be useful. The default broker.xml defines multiple ports for this very reason. My question is specifically about this user's situation with the cluster-connection and the Core protocol regardless of what is useful for other software.
Regarding your specific question, could you start a new thread? While the issues are conceptually related it's not clear to me that they are really about the same thing, and I don't want this thread to get hijacked. Justin On Fri, Apr 4, 2025 at 2:57 PM Alexander Milovidov <milovid...@gmail.com> wrote: > Hi Justin, > > There may be a reason to have different listeners, protocols and > other settings for servers and for clients. > For example, Apache Kafka can use different listeners for connections > between servers and advertised listeners for the clients: > https://kafka.apache.org/documentation/#brokerconfigs_advertised.listeners > https://kafka.apache.org/documentation/#brokerconfigs_listeners > > The documentation says that it can be useful in cloud environments. > > I have another question about using useTopologyForLoadBalancing=false > option. Does this option mean that if we have a cluster with two > primary/backup nodes, the clients will try to connect to both nodes as if > both were active? Can it cause problems? > We also have periodic random problems even for clients which do not ignore > the topology. Sometimes clients are trying to connect to a backup node > without any reason. > > Alexander > > пт, 4 апр. 2025 г. в 22:28, Justin Bertram <jbert...@apache.org>: > > > You are seeing the expected behavior. > > > > This is because the URL you provide to the Core client is only used for > the > > initial connection by default. Once the initial connection is made the > > broker informs the client about the cluster topology (if one exists), and > > when reconnecting or failing over the client uses this topology. This is > so > > that nodes in the cluster can come and go and the client always has > > up-to-date information about where to connect in case of a failure. The > > information in the cluster topology is based on the configuration of the > > cluster-connection (i.e. in the <connector-ref>). Since your cluster > > connections use port 6000 that is what is sent to the client. You can > > ignore the topology if you like by > > setting useTopologyForLoadBalancing=false in your connection URL at which > > point it will simply use what is statically configured in the URL. > > > > I can't think of any particular benefits to having the > cluster-connections > > use a different port from normal connections. Is there a reason why > you've > > configured them this way? > > > > > > Justin > > > > On Fri, Apr 4, 2025 at 10:33 AM <maximilian.rie...@systema.com> wrote: > > > > > Hello Community, > > > > > > I'm testing a clustered setup with two ActiveMQ Artemis brokers > > configured > > > for high availability. Each broker has two acceptors: one for client > > > connections on port 6666 and one for cluster connections on port 6000. > > > > > > In my test application, I connect using a failover URL: > > > (tcp://hostA:6666,tcp://hostB:6666)?failoverAttempts=-1 > > > Then I retrieve and print the remote address the client is connected to > > > using the following: > > > > > > ClientSessionFactory sessionFactory = connection.getSessionFactory(); > > > RemotingConnection remotingConnection = sessionFactory.getConnection(); > > > Connection transportConnection = > > > remotingConnection.getTransportConnection(); > > > String remoteAddress = transportConnection.getRemoteAddress(); > > > > > > Initially, the printed remote address correctly shows the client port, > > > e.g., hostB/192.123.123.123:6666. > > > > > > However, after shutting down the broker the client is connected to (to > > > simulate a failover), the client reconnects to the other broker — but > now > > > the remote address points to the cluster port (e.g., hostA/ > > > 192.123.123.124:6000) instead of the expected client port. > > > > > > Is this expected behavior? Should the remote address after failover > point > > > to the cluster port instead of the client port? > > > > > > I added a short test case on my github: > > > https://github.com/MaximilianRieder/ArtemisRemoteAddressTest > > > > > > Kind regards > > > Maximilian > > > ------------------------------ > > > > > > *Maximilian Rieder* > > > Software Engineer > > > > > > Phone: +49 941 / 7 83 92 84 > > > maximilian.rie...@systema.com > > > > > > www.systema.com > > > > > > [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/ > > >[image: > > > Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: > XING] > > > <https://www.xing.com/pages/systemagmbh> > > > > > > SYSTEMA > > > Systementwicklung Dipl.-Inf. Manfred Austen GmbH > > > > > > Manfred-von-Ardenne-Ring 6 | 01099 Dresden > > > HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786 > > > Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO > > > > > > P Please check whether a printout of this e-mail is really necessary. > > > > > >
