Re: [Fixed] Programatically setting up a proxying broker

There is a pending pull request in activemq artemis to add that feature. On Thu, Aug 3, 2017 at 11:51 AM Mark Raynsford < list+org.apache.activ...@io7m.com> wrote: > On 2017-08-03T08:57:38 -0600 > Tim Bain wrote: > > > > My question was why you needed to subclass it in the first place. > > Ah, t

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

That looks like a good approach to me. Justin On Thu, Aug 3, 2017 at 2:02 PM, Michael André Pearce < michael.andre.pea...@me.com> wrote: > That's fair enough. > > Going with then the other option of skipping the node if it's next in the > list. That works if the node comes back in the first pos

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

That's fair enough. Going with then the other option of skipping the node if it's next in the list. That works if the node comes back in the first position but you'll still end up with the same problem if it is in the second position. Eg initial node order: A B C Topology B A C First three

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

As stated previously, I'm not in favor of using the initial connection only for discovery as I think it's wasteful. Justin On Thu, Aug 3, 2017 at 12:41 PM, Michael André Pearce < michael.andre.pea...@me.com> wrote: > How much would it be for it to also only use the topology eg the solution > th

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

How much would it be for it to also only use the topology eg the solution that just uses the first connection for discovery only, and then topology for the actual connections, as so then at least support expanding the cluster also but also load balancing better the initial connections. That way

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

I see your point. I supposed I was focusing on the title of his message (i.e. "use initial connectors instead of received topology") rather than the the details in the description of his problem. FWIW, I plan on implementing a new connector parameter to support ignoring the topology because I thi

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

From what I read the double connection due to using both lists is the underlying issue from the original mail. " There is a number of problems and inneficiencies we see on this approach. If we have a cluster with 3 hosts for example, and we declare those on the host list and get 3 connections usi

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

That would work. Sent from my iPhone > On 3 Aug 2017, at 17:41, Justin Bertram wrote: > > IMO the way to deal with this is to just add a bit of logic so you don't > get 2 consecutive connections to the same host. Making a connection with > the static connectors, getting the topology, closing

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

IMO the way to deal with this is to just add a bit of logic so you don't get 2 consecutive connections to the same host. Making a connection with the static connectors, getting the topology, closing the connection, and then making another connection with the topology is wasteful. In any case, an

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

We saw this too when running cluster mode and static discovery before we moved to UDP and then finally went to single master cluster due to cost in some support licensing as had to reduce cpu counts. Sent from my iPhone > On 3 Aug 2017, at 17:31, Michael André Pearce > wrote: > > The bit I'm

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

The bit I'm getting at is it uses the discovery connection when on static instead of discovering getting the topology and then using that to make the connection. This is why when using topology and static you see first two connections to same host as it uses the discovery connection first which

Re: Network of brokers and destination policies

Thank you very much Tim. That is enough information to get me started thinking about this. It wasn't clear to me if the brokers had separate policies or if the same policy was communicated between brokers via administrative messages. I will almost certainly take you up on the offer of more specifi

Re: [Fixed] Programatically setting up a proxying broker

On 2017-08-03T08:57:38 -0600 Tim Bain wrote: > > My question was why you needed to subclass it in the first place. Ah, that was down to an error in thinking on my part when looking at the available network connectors. It went something like this: "Hm, need a NetworkConnector. Don't seem to need '

Re: Artemis 2.1.0: Production/Ops hardening guide.

What happens when you pull the cable between these nodes? but they can still talk to clients? if you can guarantee network will not have a split brain.. then you may be fine.. I would recommend at least using the NetworkHealthCheck if you can't have more than 3 pairs. On Thu, Aug 3, 2017 at 10:4

Re: [Fixed] Programatically setting up a proxying broker

My question was why you needed to subclass it in the first place. On Aug 3, 2017 6:51 AM, "Mark Raynsford" wrote: > On 2017-08-03T06:29:48 -0600 > Tim Bain wrote: > > > OK, glad to hear that it's working properly now. > > > > But I'm surprised to hear that you think the existing classes don't d

Re: Artemis 2.1.0: Production/Ops hardening guide.

We are using one backup pair (1 master/1 slave). I did not know this was an issue. We are running in AWS and only have 2 availability zones to use. I have the master in one zone and the slave in another. What do we need to do to avoid a split brain? Thanks! On Aug 3, 2017 9:27 AM, "Justin Bertra

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

On Thu, Aug 3, 2017 at 9:01 AM, Michael André Pearce wrote: > But what I'm saying is should it be that the discovery should happen but then > the real connection is made from the returned topology. Like for UDP instead > of hoodwinking on the discovery connection. I'm not understanding your poi

How can I speed up read message from queue

Hi, When I write and read message from a queuq, The TPS more than 2000; But when I write many msg to queue(More than 10,000) firs, then I read message, the TPS is very slow(Only 70),Why??? -- View this message in context: http://activemq.2283324.n4.nabble.com/How-can-I-speed-up-read-messag

Re: Artemis 2.1.0: Production/Ops hardening guide.

How many live/backup pairs are you using? A single live/backup pair is going to be at serious risk of split brain. Ideally you'd have 3 (potentially colocated) live/backup pairs to mitigate the risk of split brain. Justin On Thu, Aug 3, 2017 at 6:46 AM, sfmckenrick wrote: > Thanks for the re

Re: Artemis activemq with jconsole doesn't show topics management

In addition to what Andy said... You have to remember that Artemis is a generic messaging broker and as such it supports many different protocols (e.g. AMQP, MQTT, STOMP, etc.). Most protocols share the same basic point-to-point and publish-subscribe semantics but these semantics are represented

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

But what I'm saying is should it be that the discovery should happen but then the real connection is made from the returned topology. Like for UDP instead of hoodwinking on the discovery connection. Sent from my iPhone > On 3 Aug 2017, at 12:52, Clebert Suconic wrote: > > It is not a bug. Peo

Re: [Fixed] Programatically setting up a proxying broker

On 2017-08-03T06:29:48 -0600 Tim Bain wrote: > OK, glad to hear that it's working properly now. > > But I'm surprised to hear that you think the existing classes don't do what > you want; what are you looking for that you couldn't get? Sorry, that was phrased poorly. What I meant was that the a

Re: Duplicate messages received with ActiveMQ 5.13.2

> On 1 Aug 2017, at 15:36, tpavelka wrote: > > It looks like the check for networkSubscription is there for a reason, > described in https://issues.apache.org/jira/browse/AMQ-2327 > The commit 6c5732b also mentions: > > /key is not to conduit proxy/proxy consumers b/c the dependencies cannot be

Re: Remove "terminateJVM " from JMX

That's because it's not possible to remove specific actions. You can allow the MBean that contains the action to be registered, or prevent it from being registered. All or nothing for a given MBean. On Aug 2, 2017 7:45 PM, "abhillman" wrote: > Hi! > > I am trying to use the "suppressMBean" funct

Re: Why is concurrentStoreAndDispatchTopics option not recommended?

Read the comments on the bug you linked to. They explain why the option was recommended against, and the concerns that Gary, Chris, and Tim have about whether all of the edge cases have been properly addressed even if the NPE in question is prevented. Tim On Aug 2, 2017 8:14 AM, "alvinlin" wrote

Re: [Fixed] Programatically setting up a proxying broker

OK, glad to hear that it's working properly now. But I'm surprised to hear that you think the existing classes don't do what you want; what are you looking for that you couldn't get? Tim On Aug 3, 2017 4:38 AM, "Mark Raynsford" wrote: > I discovered what the problem was. > > I'd created my own

Re: Duplicate messages received with ActiveMQ 5.13.2

I have opened an issue for this and added a unit test that reproduces the problem to it: https://issues.apache.org/jira/browse/AMQ-6784 Tomas -- View this message in context: http://activemq.2283324.n4.nabble.com/Duplicate-messages-received-with-ActiveMQ-5-13-2-tp4728627p4729221.html Sent from

Re: ActiveMQConnectionFactory: use initial connectors instead of received topology

It is not a bug. People use this to feed an initial list than the topology could be much bigger. On Thu, Aug 3, 2017 at 1:18 AM Michael André Pearce < michael.andre.pea...@me.com> wrote: > To me this sounds like a bug, where you get two connections because you > use two lists. > > as in why doesn

Re: Artemis 2.1.0: Production/Ops hardening guide.

Thanks for the reply. We are running Artemis in a HA failover configuration with replication. We are also using static connectors. The steps I have taken so far are moving the logs directory to a separate mount, enabled ssl and forced clients to authenticate with Artemis. Are there any other item

Re: Artemis activemq with jconsole doesn't show topics management

Internally Artemis has no notion of topics, only addresses and queues, JMS topics are an abstraction built on top of these in the client. I would read the addressing chapter of the user manual to understand how a topic maps internally on to an address and a queue On 3 August 2017 at 10:45, aragoub

Re: [Fixed] Programatically setting up a proxying broker

I discovered what the problem was. I'd created my own subclass of NetworkConnector, because none of the existing implementations seemed to be what I needed. It turns out that I actually needed to use DiscoveryNetworkConnector; the abstract NetworkConnector base class doesn't actually do any useful

Artemis activemq with jconsole doesn't show topics management

I have a standalone artemis activemq broker. I start the broker, and I open jconsole in order to see and manage activemq, but I am not seeing topic, I can see only queues. Before, I was using activemq, and I was able to see topics through jconsole. jconsole.png