so a batch of 6 messages came into the broker, 5 disappeared. They were not
persisted. One was delivered to the consumer and the rest just simply vanished.
tcpdump proves they arrived at the boker but never made it to the consumer.
The activemq logs show the same set of entries for everything th
I resorted to tcpdump on the broker and the consumer to track the messages and
it seems the consumer is dropping messages. Of 16 incoming identical messages,
it only acted upon 3. Also, it failed to act on another single message. By
that, it didn't pass them to the message handler. tcpdump showe
this is the code that does the sending. I've just watched a batch of three
messages being sent, two simply disappeared.
ActiveMQConnectionFactory connectionFactory = new
ActiveMQConnectionFactory(brokerURL);
connection = connectionFactory.createConnection();
connection.se
the topic consumers don't need to be present when the message is sent as the
messages are persistent and they are durable topic subscribers. They are never
persisted by activemq. They just disappear. I can't track the messages through
the system as isAllowedToConsume is never called for the orig
please provide some code that demonstrates your problem. Are you sure
that the topic consumers are present when the messages are sent?
Try and reduce the complexity of your usecase, the bottom line is that
messages won't just disappear without good reason, there are hundreds
of test cases that veri
not a lot seems to work. 8 identical messages sent to the broker in quick
succession. Three arrived, 5 just disappeared. It's complicated by the fact
MessageAuthorizationPolicy::isAllowedToConsume never seems to be called for the
original message, so I can't really verify whether the message dis
trying to log incoming messages at the broker to narrow the problem and another
problem appears. This works on one server but adds 0x0 chars on another so the
message fails to parse:
public boolean isAllowedToConsume(ConnectionContext context, Message message) {
new String(message.getContent().
Is this code shared by multiple threads? does it need synchronization?
What you are experiencing does seem odd, it would be great if you
could provide a simple junit test case that can reproduce.
Also, peeking that the code of the logging plugin, it should be
logging sends, that is again odd:
htt
would someone be kind enough to have a quick look at this code to see if it
could cause problems? The method returns a reusable connection so the user of
the class doesn't have to connect/disconnect on every message. The first
message never fails, it's always when reusing the connection that ran
nothing seems to help. There are still messages just disappearing. Also the
logging doesn't seem to log anything to do with producers:
I can see lots of camel consumers from the local machine looking at the routes
but nothing about incoming messages from producers.
Alistair
--
mov eax,1
mov
I'm running ActiveMQ 5.5.0 as a spring webapp rather than the standalone
version. Would you recommend the standalone one? Not sure how to use camel with
that though.
there's quite a high rate of packet loss on the network it seems and according
to this:
http://activemq.apache.org/async-sends.ht
What is the exact broker version used on your side?
In case its not the latest released version, can you try the latest version?
Do you set any particular headers on the Topic message in your producer?
On Sep 21, 2011, at 1:54 PM, Alistair Young wrote:
> I can't explain this at all. It's almo
I can't explain this at all. It's almost like the opposite of reliable
messaging. At times, almost 1 in 3 messages just disappears. No errors. The
KahaDB/db-*.log show no record of the message every arriving and yet the
producer doesn't get an error.
Alistair
--
mov eax,1
mov ebx,0
int 80h
yep, there is a durable topic consumer waiting for them
Alistair
--
mov eax,1
mov ebx,0
int 80h
On 21 Sep 2011, at 12:20, Gary Tully wrote:
> topic messages are only persisted to the store if there are durable
> consumers/subscriptions
>
> On 21 September 2011 11:04, Alistair Young wrote
topic messages are only persisted to the store if there are durable
consumers/subscriptions
On 21 September 2011 11:04, Alistair Young wrote:
> I should say, the messages go to a topic on the broker and are then routed by
> camel to another topc. Would camel be dropping the messages? Would they
I should say, the messages go to a topic on the broker and are then routed by
camel to another topc. Would camel be dropping the messages? Would they not be
logged in the kahadb store no matter what though?
Alistair
--
mov eax,1
mov ebx,0
int 80h
On 21 Sep 2011, at 10:25, Alistair Young w
I doubt it. In a batch of three messages sent in 2 seconds, one disappeard. Is
there a default throttle limit perhaps on the broker? But surely that would
cause the producer to error out or something?
Alistair Young
Àrd-Innleadair air Bathar-Bog
UHI@Sabhal Mò
Any chance you can reproduce this behavior in a little JUnit test case?
On Sep 21, 2011, at 10:15 AM, Alistair Young wrote:
>> There was no producer, broker or connection crash while the msg was in
>> transit?
> no, the logs show it was up and sending
>
>> The msg does not have an expiration
> There was no producer, broker or connection crash while the msg was in
> transit?
no, the logs show it was up and sending
> The msg does not have an expiration time?
no
> Are you certain that no consumer has got the msg already?
yes, there's no record of it arriving at the consumer and no lo
There was no producer, broker or connection crash while the msg was in transit?
The msg does not have an expiration time?
Are you certain that no consumer has got the msg already?
You could turn on full logging inside the broker, it will log each msgs being
received. Might not be suitable for a
20 matches
Mail list logo
