that makes sense, any failover reconnect will use the topology information, that will be wrong. you need to have artemis not do any reconnect, initialConnectAttempts=2 and on initial connection, it will choose the first working url from the two external dns names configured. You can get the failover behaviour from camel/jms template - it will create a new connection with the provided url but it too will recreate the connection/session/consumer etc so you won't really need the artemis client to do transparent failover.
On Wed, 12 Jan 2022 at 12:55, Vilius Šumskas <vilius.sums...@rivile.lt> wrote: > > Thanks, Gary. Ticket created > https://issues.apache.org/jira/browse/ARTEMIS-3640 > > We experimented a little bit more with this and found that if we use any of > the following parameters failover fails: > retryIntervalMultiplier=2,reconnectAttempts=1000,maxRetryInterval=120000 > > However if we remove these parameters the unknown host exception is still > present but the failover starts to work (at least from our initial tests). > This doesn't make sense to me and goes against what documentation says > regarding reconnectAttempt usage in HA. > > Do you have ideas what could be going on? We are using Camel library with > Spring Framework for our messaging. My theory is that without > reconnectAttempt parameter Artemis client itself doesn't try to reconnect, > but Camel (or Spring) somehow takes addresses from URL and reconnects? > > -- > Vilius > > -----Original Message----- > From: Gary Tully <gary.tu...@gmail.com> > Sent: Wednesday, January 12, 2022 1:40 PM > To: users@activemq.apache.org > Subject: Re: Artemis cluster topology and external clients > > there is a problem here, currently there is no way to "transform" the host > information in the topology update commands. the topology is used for ha and > for loadbalancing and the client will always end up with the internal dns > name via the topology update. > > This needs an enhancement, some thing along the lines of the what we have in > 5.x via the publishAddressStrategy for Artemis - > https://issues.apache.org/jira/browse/AMQ-6392 > > The only workaround is to forsake HA, ha=false and not do reconnects, and > have the two urls (with the external dns names) be candidates for > reconnection, as it will be an initial connection. > Something above the jms connection (the application, jms template) will have > to recreate the connection on failure. > > Please open a JIRA issue to track this need, and we can peek into how > difficult it is to resolve or if there are some alternatives that can help > this use case. > > On Mon, 10 Jan 2022 at 14:21, Vilius Šumskas <vilius.sums...@rivile.lt> wrote: > > > > Hi list, > > > > does anyone have more ideas regarding the issue with external consumers > > below? > > > > -- > > Vilius > > > > -----Original Message----- > > From: Vilius Šumskas > > Sent: Friday, January 7, 2022 11:43 AM > > To: users@activemq.apache.org > > Subject: RE: Artemis cluster topology and external clients > > > > We are still getting these errors on the external clients even when > > useTopologyForLoadBalancing is disabled and using > > (tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616 > > ) > > > > org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector: > > AMQ214033: Cannot resolve host > > java.net.UnknownHostException: internal-cluster-dns-1 > > > > The error is show 2 times every time the external consumer is started. The > > connection works until we power down cluster-dns-1 machine. Then the > > consumer just stops receiving messages and never reconnects to > > cluster-dns-2 node. > > > > > > When using the same consumer internally everything works as expected. > > > > -- > > Vilius > > > > -----Original Message----- > > From: Domenico Francesco Bruscino <bruscin...@gmail.com> > > Sent: Tuesday, January 4, 2022 8:02 PM > > To: users@activemq.apache.org > > Subject: Re: Artemis cluster topology and external clients > > > > Hi Vilius, > > > > the clients should disable topology for load balancing and use static > > connectors, i.e. > > > > (tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616 > > )?ha=true&reconnectAttempts=30&useTopologyForLoadBalancing=false > > > > Regards, > > Domenico > > > > On Mon, 3 Jan 2022 at 10:00, Vilius Šumskas > > <v.sums...@advantes.tech.invalid> > > wrote: > > > > > Hello list, > > > > > > we are trying to use Artemis HA shared storage cluster which our > > > SaaS application. In addition to consumers/producers internal to > > > SaaS application itself, we also have thousands of external > > > consumers/producers which are installed on client’s premises . > > > > > > As broadcast is not possible on Google Cloud we are using static > > > discovery configuration with these connectors: > > > > > > <connectors> > > > <!-- Connector used to be announced through cluster > > > connections and notifications --> > > > <connector > > > name="artemis-master">tcp://internal-cluster-dns-1:61616</connector> > > > <connector > > > name="artemis-slave">tcp://internal-cluster-dns2:61616</connector> > > > </connectors> > > > > > > Our acceptors are also configured to use internal DNS of the hosts > > > on both cluster nodes: > > > > > > <acceptor > > > name="artemis">tcp://internal-cluster-dns-1:61616?tcpSendBufferSize= > > > 10 > > > 48576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;pr > > > ot > > > ocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredit > > > s= > > > 10 > > > > > > 00;amqpLowCredits=300;amqpDuplicateDetection=true;supportAdvisory=fa > > > ls e;suppressInternalManagementObjects=false</acceptor> > > > > > > We don’t have issues with internal consumers/producers, however when > > > we try to connect external consumers (via external IP), they are > > > trying to connect via internal DNS which is probably set in the > > > cluster topology packet. > > > > > > This is probably expected and by design, but my question is how do > > > we correctly handle such case? We obviously do not want internal > > > clients to be served via external IP because external traffic is > > > expensive in the cloud and the performance would decrease > > > dramatically. Even with static discovery we would like to have a > > > possibility to expand our cluster in the future, i.e. use the topology so > > > that clients are configured automatically. > > > > > > Do we need to have a split-DNS server so that external and internal > > > clients will see different IP addresses? Or maybe it is possible to > > > have the same node serving different acceptors on different ports > > > and different DNS names? > > > > > > Any pointers are much appreciated. > > > > > > -- > > > Best Regards, > > > > > > Vilius Šumskas > > > Advantes technologies > > > IT manager > > > +370 614 75713 > > > > > >
