When using ActiveMQ, some problems troubles me:
1. When broker crashed or stopped, messages from sender will be lost(I set
timeout, because the sender have others to do).
2. consumer receives all messages from broker, but how i dnow the consumer
received all messages(zero lost).
3. If message is l
Nope, you're not missing anything. There is a bug in there. Taking a look
right now...
On Tue, Sep 25, 2012 at 2:49 PM, Aliquip wrote:
> ActiveMQ (5.7 snapshot) and MQTT: connection times out while still
> connected
> to a topic for receiving
>
> I'm using mosquitto's python client to connect
Well, the network of brokers (the connections between the brokers) needs to
connect over the tcp transport only (it's all internal). your clients to
the brokers will connect via tcp (interna) or ssl (external).
On Mon, Oct 22, 2012 at 9:02 AM, matteo rulli wrote:
> Thank you for your answer!
>
>
Thank you for your answer!
Well, failover="true" is indeed a "cut and paste" idiosyncrasy of mine :)
So, in the end I will use just one discoveryUri="multicast://default" for
both ssl and tcp transports, right?
Thank you again.
matteo
-Messaggio originale-
Da: Christian Posta [mailto:ch
If your brokers are behind your private LAN, you don't need this:
failover="true"/>
Where did you see the "failover=true" attribute any way?
On Mon, Oct 22, 2012 at 2:11 AM, matteo rulli wrote:
> Dear all,
>
> I'd like just to get experts' advice on the following ActiveMQ (5.6.0) use
> cas
This is over a networked broker and according to JMX the ack queue does
exist. I also tried using 5.6 and that too doesn't work. Without changing
any code and using the same config file, 5.5.1 works but 5.6 and 5.7 do not.
I didn't see any logs on the issue. I don't understand why it doesn't work.
On Mon, Oct 22, 2012 at 1:42 PM, Gary Tully wrote:
> KahaDB is the current default persistence provider, and kaha will be
> depreciated in the future.
>
Gary I think you should log a JIRA about this. Then we can start
getting the message out to the community that the old kaha is
deprecated, so pp
KahaDB is the current default persistence provider, and kaha will be
depreciated in the future.
I agree, the naming is a little confusing, it reflects something of
the evolution of the stores.
There was jdbc, then amq store, then kaha, then kahadb.
KahaDB has been hardening for the past 2 years,
It indeed seems that there are two different Kaha persistence adapters, the
KahaPersistenceAdapter and KahaDBPersistenceAdapter. So what you are saying
is that the KahaDBPersistenceAdapter should work better? Or were you just
pointing out an error in my previous post (me talking about KahaDB instea
from the stack trace, it appears you are using the old kaha persistence adapter.
you should be using
On 22 October 2012 08:33, Pauli Kaila wrote:
> For the latest release of our product we switched from Apache DerbyDB to
> KahaDB for ActiveMQ persistence. We also upgraded ActiveMQ to 5.6.0. Now
Dear all,
I'd like just to get experts' advice on the following ActiveMQ (5.6.0) use
case.
I would like to establish a network of brokers and dispatch brokers
existence through auto-discovery.
The network of broker exists within a private LAN. Some consumers/producers
will operate within
For the latest release of our product we switched from Apache DerbyDB to
KahaDB for ActiveMQ persistence. We also upgraded ActiveMQ to 5.6.0. Now two
of the three production installations, that have been updated to our latest
version, are experiencing issues with ActiveMQ persistence causing Active
On Oct 20, 2012, at 6:36 AM, kureckam wrote:
> I'm in the process of updating from 5.5.1 to 5.7.0 but have an issue. The app
> being updated sends a message on one queue and listens on a different queue.
> The message is successfully sent and received by a Spring based app running
> in Tomcat and
13 matches
Mail list logo
