Re: Client Reconnect/failover problem via Core API with HA Configuration when configured with SSL

For what it's worth, I just tested with 1.4.0 and the result was the same as before (i.e. everything worked). Justin - Original Message - From: "Justin Bertram" To: users@activemq.apache.org Sent: Tuesday, January 31, 2017 6:47:07 PM Subject: Re: Client

Re: Network Connector too slow when receive high rate persistent message

ok, we re-ran the test with 3 brokers, 2 producer hosts, and 4 consumer hosts (each consumer host has 50 consumers on a single connection) and this time with the proper configs on the consumer side and the system behaved a little better, but still started queueing on the broker at about 500 tps.

Re: Client Reconnect/failover problem via Core API with HA Configuration when configured with SSL

I tried this on master so it would be beyond 1.5.2. That said, not much has changed with the SSL implementation stuff in quite some time so I wouldn't expect that to make a difference. As far as getting things down to the smallest set, I don't see any way around that. Until you can eliminate

Re: Network Connector too slow when receive high rate persistent message

oops, sorry about the last post ... the test with the 3 brokers, 2 producers, and 4 consumers had a bad configuration on the consumer side (something outside the scope of ActiveMQ) ... we're running that same test again (with conduitSubscriptions="false" and decreasNetworkConsumerPriority="false")

Re: Client Reconnect/failover problem via Core API with HA Configuration when configured with SSL

Did you try this with the latest 1.5.2? Or with 1.4.0? If you "just worked" with 1.5.2, maybe I'll try that first. There is a bit of work to do to extract everything enough to reproduce this and get it down to its smallest set. A couple of important questions: Did you actually use two

Looking for example for loading a msg with file attachment through REST

New to ActiveMQ here... I am trying to get a sense if it is possible to send a message with a binary attachment through the REST api. The idea is to connect a legacy application with 'curl'. Looking at http://activemq.apache.org/rest.html I do not see this as an option. Is it possible

Re: Network Connector too slow when receive high rate persistent message

Tim, We just ran another test with all 3 brokers, 2 producer hosts, and 4 consumer hosts ... and made sure that every broker had at least one consumer host directly connected ... and we saw the queues on broker1 build up immediately - event during the "ramp up" portion of the test. We're going to

Re: Client Reconnect/failover problem via Core API with HA Configuration when configured with SSL

I just set up an example to test this and everything worked fine. I essentially merged the "ssl-enabled" and "stop-server-failover" examples together. Could you perhaps work up a simple reproducer (e.g. using an existing example)? Justin - Original Message - From: "funkyjive"

Re: ARTEMIS: bad-performance behaviour after 7-10 days of usage

The bug wouldn't be on the persistence layer itself. The MQTT protocol manager is managing retainers by removing (acking) older messages. And something is broken. I'm not sure if it's a general case or something specifically to your use case. I was wondering if you could replicate the issue on a

Client Reconnect/failover problem via Core API with HA Configuration when configured with SSL

I have an Artemis 1.4.0 embedded in a Java application acting as the queuing server for 2->N wildly 10 nodes connected as clients. WildFly 10 is only connecting as a client to this external Artemis and it is obviously using the JMS interface since that is what is supported in WildFly. The Java

Re: Network Connector too slow when receive high rate persistent message

Also, what is network latency like between brokers and from client to broker? On Jan 31, 2017 7:03 AM, "Tim Bain" wrote: > Do either of your broker logs show Producer Flow Control kicking in? > > And for both of you, is performance normal if you have just a single >

Re: Problems setting up replicated ha-policy.

Replication, as currently implemented, only supports replicating to a single backup at a time (as noted previously). One can configure multiple backups for a single live, but only one of those slaves will receive the replicated data. If the live dies then the replica backup will become live

Re: Network Connector too slow when receive high rate persistent message

Do either of your broker logs show Producer Flow Control kicking in? And for both of you, is performance normal if you have just a single broker (or all clients on the same broker, which is the same thing)? On Jan 30, 2017 5:36 PM, "Adam Whitney" wrote: I'm having a

Re: Problems setting up replicated ha-policy.

Justin, Is there a use case where replicating to only some of the slaves in a cluster with N >= 3 is desirable, or does this just mean that replication as currently implemented is recommended only for N = 2? Tim On Jan 31, 2017 6:45 AM, "Justin Bertram" wrote: Your

Re: Problems setting up replicated ha-policy.

Your assumption is correct, and there is no way currently to replicate to multiple slaves concurrently. Replication occurs only to a single slave at a time. I believe there is a JIRA for implementing this feature (or something similar), but I can't locate it at the moment. Justin -

Re: Problems setting up replicated ha-policy.

Hi Clebert, Justin, Thanks a bunch for the the good feedback, helped me a lot. One final question. In a 3 node cluster setup with HA-policy, there is one active master and 2 slaves. One of these slaves is the active replicating slave and the other is a hot-standby (basically). So if the active