> Why initialConnectAttempts=2? That I got from this code: https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/client/impl/ServerLocatorImpl.java#L1722
It looks like with 0, it won't ever try the second url, and I don't see a randomise option in there On Wed, 12 Jan 2022 at 21:49, Vilius Šumskas <vilius.sums...@rivile.lt> wrote: > > Thank you! We will try to apply your suggestions. > > One last thing, as I understood the proper URL string for external clients > then would be: > (tcp://external-cluster-dns-1:61616,tcp://external-cluster-dns-2:61616)?ha=false&useTopologyForLoadBalancing=false&initialConnectAttempts=2&failoverOnInitialConnection=true > > Why initialConnectAttempts=2? I saw that default is 0 which means one > attempt. Does this mean that 2 will try to reconnect three times (master -> > slave -> master)? > > -- > Vilius > > -----Original Message----- > From: Gary Tully <gary.tu...@gmail.com> > Sent: Wednesday, January 12, 2022 7:30 PM > To: users@activemq.apache.org > Subject: Re: Artemis cluster topology and external clients > > 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=1200 > > 00 > > > > 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:616 > > > 16 > > > ) > > > > > > 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:616 > > > 16 )?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?tcpSendBufferSiz > > > > e= > > > > 10 > > > > 48576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400; > > > > pr > > > > ot > > > > ocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCred > > > > it > > > > 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 > > > > > > > >
