ActiveMQ 5.13.3 Linux distro signature verification failed

[Arkin Yetis]

Hi,
After downloading the 5.13.3 Linux distribution, the MD5 and ASC
verifications failed. I tried more than once.
I used the following page to download:
http://activemq.apache.org/activemq-5133-release.html
Could someone confirm that the signature verification has worked for them?
Thanks,
- Arkin

Re: AMQ 5.13.2 : Kaha DB logs cleanup issue

[Shobhana]

Sure, I'll check when I have some time.

Btw, I tried to use JConsole to view the current status of consumers. I
tried hard getting JConsole to connect to my broker that runs on an EC2
instance, but couldn't succeed. Can I use the Jolokia Rest APIs instead? Do
these APIs give same result as JMX viewer (cumulative stats) or only from
the time the broker is restarted?

Are you talking about  AMQ-6203
  ? Currently we use
ActiveMQ 5.13.2 and still see this problem. If the enhancement that you are
talking about is AMQ-6203, we will upgrade to 5.13.3 version in which this
is implemented.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/AMQ-5-13-2-Kaha-DB-logs-cleanup-issue-tp4712046p4712109.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Default pre-fetch behavior of ActiveMQ and the "competing consumer"

[petergdoyle]

So I don't want to repeat a Thread Discussion (
http://activemq.2283324.n4.nabble.com/slow-consumer-not-working-td2346908.html

 
) but I am not sure the questions were answered about how to control
"prefetch" on consumers using the API. And the Javadocs do not seem to
provide any details on how to use the "prefetch" controls 
http://activemq.apache.org/maven/apidocs/index.html?org/apache/activemq/ActiveMQPrefetchPolicy.html

  
I do not believe the default behavior of ActiveMQ follows the "competing
consumer" model as indicated http://activemq.apache.org/clustering.html.If I
want to make use of an entire compute cluster (message consumers) most
efficiently, I would want the fastest consumers to take up the slack if
slower consumers are not able to keep up. The slow consumer can be cause by
a variety of reasons but it could be nothing more than a mixture of hardware
varying in speed. When I run a test-harness that introduces latency into 1
of 3 "competing" consumers and I send 99 messages from a producer at an even
rate, I see that each of the 3 consumers ingests 33 messages. The 1 that is
sleeping between message handling continues to chug away at its load and the
others sit idle. Even when I stop a fast consumer and restart it, the slow
one still chugs away on his even portion of the total. If I run the same
test-harness with IBM MQ and the same JMS producer / consumer code. I see
the slow consumer take what he can and the balance of the load be evenly
distributed across the fast consumers - as I would expect.I cannot see any
use where the default ActiveMQ behavior is desirable. Regardless, it does
seem to be controlled by a "prefetch" limit. It seems like one could control
the default for all use cases with the setAll() ?void   setAll(int i) void
setDurableTopicPrefetch(int durableTopicPrefetch) void
setMaximumPendingMessageLimit(int maximumPendingMessageLimit)Sets how many
messages a broker will keep around, above the prefetch limit, for
non-durable topics before starting to discard older messages.void
setOptimizeDurableTopicPrefetch(int optimizeAcknowledgePrefetch) void
setQueueBrowserPrefetch(int queueBrowserPrefetch) void  setQueuePrefetch(int
queuePrefetch) void setTopicPrefetch(int topicPrefetch) So any guidance on
using the ActiveMQPrefetchPolicy class in general is appreciated - as well
while I am assuming I can set the default to allow competing customers to
work at their combined optimal compute capacity and there is a setting for
that... Are there any pitfalls as well?Thank you 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Default-pre-fetch-behavior-of-ActiveMQ-and-the-competing-consumer-tp4712108.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Network of Brokers with load balancing

[issacjohn81]

Hi,

I have 3 brokers. Let say B1, B2 and B3.

B1 has a network connector configuration as shown below:

*
 











*

The connection is duplex in nature from B1 to B2 as well as from B1 to B3. I
am able to publish messages (using mosquitto publish command) from B2 to a
subscriber connected to B1. Similarly a subscriber connected to B2 is able
to receive messages published from B1 (using mosquitto publish command). But
at the same time, i am not able to do the same between B1 and B3.

I would like to a have network where in messages sent from outside (towards
B1) should be load balanced between B2 and B3 subscribers (without any
duplication ), and also messages published from B2 or B3 should be sent to
the outside world subscribers (subscribed to B1). 



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Network-of-Brokers-with-load-balancing-tp4712096.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: ActiveMQ not starting

[finnjohnsen]

OrangeJuice wrote
> INFO: Loading '/etc/default/activemq'

The problem is that /etc/default/activemq is left over from the debian
repository installation of activeMQ you've had on your computer. Delete it.





--
View this message in context: 
http://activemq.2283324.n4.nabble.com/ActiveMQ-not-starting-tp4708599p4712094.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: AMQ 5.13.2 : Kaha DB logs cleanup issue

[Tim Bain]

You're right, your interpretation is consistent with the documented
example, whereas mine is consistent with the text of the log line.  In that
situation, I always assume the documentation is wrong, but that's just an
assumption.  If you or someone else has time to look at the algorithm and
confirm how it actually works, we can update the wiki.  If not, I'll get to
it when I have time.  In the meantime, you should investigate the
conclusions from both algorithms, since you can't be sure which is correct.

I'd be interested to hear what you see via JMX.

Also every durable subscriber on a topic has a subscription message that
can't be GC'ed, so you're never going to get to zero files.  I think I saw
a recent JIRA enhancement to allow those messages to be replayed (into the
newest file) when there are no messages on the topic.  You might want to
search for that enhancement and confirm whether it's in the version you're
using, and upgrade if not.

Tim
On May 17, 2016 9:38 PM, "Shobhana"  wrote:

> Thanks Tim, I did not know that the stats are reset when the broker is
> restarted. I'll check how to use JConsole to view the current status of
> consumers.
>
> Yes, all topics have durable subscribers.
>
> I used the logic mentioned in the example given at
>
> http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html
> <
> http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html
> >
> to identify the topic that prevents log file from being GCed. Even I was
> confused with the example. I expected "dest:0:J" to be holding messages in
> #86; but since the example said "dest:0:I", I thought the trace log was
> meant for "before" and not "after". Maybe this example can be corrected in
> the AMQ link.
> However, since I was unsure whether the trace log was wrong or the example
> was wrong, I cross-checked for any pending messages in both
> riderride.chat.209 and passengerride.user.1234567890 and found that both
> were 0. Hence I raised this question.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/AMQ-5-13-2-Kaha-DB-logs-cleanup-issue-tp4712046p4712083.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>