So I found one issue that seems to have stabilized it a bit.
My ops gave me 3 boxes with only 1 Gig Ram and 1 CPU.
I increased that to 4 Gig Ram and 2 CPU's and it seems to be running better.
I don't see any out of order messages so nothing to report.
I performed a few reboot's to test fail ov
By late, I mean out-of-order.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Help-with-a-Failover-testing-that-shows-missing-messages-tp4707916p4708822.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
What happens in the test if a message arrives late?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Help-with-a-Failover-testing-that-shows-missing-messages-tp4707916p4708821.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Thanks for the response.
I'll give that a try and report back.
Mike
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Help-with-a-Failover-testing-that-shows-missing-messages-tp4707916p4708802.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Also, let's establish for sure whether the problem is that the Camel route
is occasionally failing to publish to the topic, or that messages make it
to the topic but are lost before consumption. Add a log line the prints
the current ID as the very last step in your Camel route; if there are
gaps,
You can quickly test that by inspecting the subscription via JMX on the
broker; it'll have a flag that tells you whether it's durable. If not,
submit a bug in JIRA.
On Mar 1, 2016 8:08 PM, "mtod" wrote:
> Sorry yes I did read his post.
>
> I was already using a durable subscription.
>
> C# code.
Sorry yes I did read his post.
I was already using a durable subscription.
C# code.
public SimpleTopicSubscriber(string topicName, string brokerUri,
string clientId, string consumerId, string filter, string userID, string
password, string message)
{
try
{
Did you read Art's post where he suggested that your problem is that you're
breaking the network connection between brokers with non-durable topic
subscriptions, which is expected to lose messages?
To test the theory, temporarily change your consumers to use durable
subscriptions and see if the me
To expand on model a bit :
The model is currently designed to support a Pub/Sub model. We have several
applications that publish documents and events to ActiveMQ. Each application
is assigned a queue each message that is submitted to the queue is placed in
an XML wrapper (see below) using a Camel
Thanks for all the help.
I removed the chaos monkey and started a new run. I don't think I will see
any errors this model has been running in my production for 2 years. The
only difference is that this is using a newer version of ActiveMQ and
LevelDB on a Linux cluster.
Granted I have not had to
Excellent catch, Art.
On Mar 1, 2016 8:38 AM, "artnaseef" wrote:
> I missed something critical here - Topics.
>
> Topic flow across a network of brokers with non-durable subscriptions only
> is not reliable. Brokers subscribe to one-another in the same manner that
> end-clients subscribe to a br
I missed something critical here - Topics.
Topic flow across a network of brokers with non-durable subscriptions only
is not reliable. Brokers subscribe to one-another in the same manner that
end-clients subscribe to a broker. So, for topic subscriptions, that means
that while the bridge between
Also, can you shut off the chaos monkey script and confirm that they really
aren't related? Knowing that answer will limit the problem space so we
don't waste time on things that aren't relevant.
What do the enqueue and dequeue counts on both destinations tell you? Are
all N messages getting enq
Can you provide a minimal test that reproduces the problem and can be shared?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Help-with-a-Failover-testing-that-shows-missing-messages-tp4707916p4708594.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
I'm checking for the missing messages at the subscriber client.
I generate the messages with sequential numbering so the client can detect
when one is missing.
I ran it over the weekend and I don't see any correlation between the
missing messages and the reboots/failovers.
subscriber :
Starting
By the way, where in the processing is the check for missed messages?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Help-with-a-Failover-testing-that-shows-missing-messages-tp4707916p4708425.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Are there any messages in the application logs?
Messages from camel indicating failures on messages (aka exchanges)?
Messages from ActiveMQ (or camel's JMS component) indicating lost connection
and need to reconnect?
Connection pooling and consumer caching may be coming into play. Although
if t
Great suggestions I'll increase some of my logging to see if I can narrow it
down a bit.
I'm not logging the reboots so I'll add a log for that.
Also check the DLQ and the invalid.schema
Add a general exception trap.
Thanks
I'll do some more testing and report back.
Mike
--
View this messa
In your route you're only catching org.apache.camel.ValidationException;
what would happen if some other exception was thrown? Also, I assume
you've already checked the DLQ and your invalid.schema queue and the
missing messages aren't in either place?
Can you correlate the times the messages are
Thanks for the reply.
So I'm still seeing this issue even after turning on Camel transacted=true.
http://camel.apache.org/schema/spring";
xmlns:km="http:///messaging/esb"/>
Are the missing messages from non-durable consumers of a Topic? If so, there
are two perfectly normal causes of message loss that may be affecting the
test:
1. dropped connection between the client and the broker
2. dropped connection between brokers in a network of brokers
--
View this mess
Thanks I'll give it a try and report back.
Mike
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Help-with-a-Failover-testing-that-shows-missing-messages-tp4707916p4708038.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
This Camel route doesn’t appear to use any sort of transactional control - i.e.
CLIENT_ACKNOWLEDGE or SESSION_TRANSACTED.
Try adding “transacted=true” in your consuming URI -
> On Feb 22, 2016, at 8:05 AM, mtod wrote:
>
> Thanks for the reply.
>
> The messages were missing across all cli
Thanks for the reply.
The messages were missing across all clients.
Not sure what you referring to about Camel Ack mode.
I add the Camel file using an import in the ActiveMQ file
...
Here is my Camel Code:
http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/
Were you missing those messages for all topic consumers, or only for one
but not the other three?
What ack mode does your Camel route use? What would it do if the broker
was unavailable when it came time to publish to the topic?
Tim
On Feb 21, 2016 7:39 PM, "mtod" wrote:
> I setup a fail-over
25 matches
Mail list logo
