I'm using spring and rabbitmq, with auto-ack. I configured a RetryInterceptor (maxAttempts 2, min and max interval 60 secs., multiplier 1), and a x-message-ttl (125 sec. for this test) is configured in the queue. I have only 1 concurrent consumer.
I put 8 messages that will always fail. In this case, there are some messages that go directly to DLQ without being consumed, but I can't understand the logic and the order behind that.
The sequence that I see is:
Message 1 first attempt
Message 1 second attempt
Message 2 first attempt
Message 2 second attempt
Message 3 first attempt
Message 7 expires
Message 8 expires
Message 3 second attempt
Message 4 first attempt
Message 3 expires
Message 4 second attempt
Message 5 first attempt
Message 4 expires
Message 5 second attempt
Message 5 expires
Message 6 first attempt
Message 6 second attempt
Message 1 third attempt
Message 6 expires
Message 1 fourth attempt
Message 2 third attempt
Message 1 expires
Message 2 third attempt
Message 2 expires
What is the explanation to this order and behavior?
Related
Good afternoon!
I receive messages from systems on splunk, several messages from one system line up in a message chain.
As a rule, six messages from one system line up in a chain of six messages.
By message chain, I mean that splunk receives six messages with the same field: "srcMsgId".
Messages arrive one after another at different intervals, but the interval should not exceed the value of N.
Tell me how can I set up Alert in splunk, in case the interval between messages in the chain exceeds the value N.
Something like this should work:
index=ndx sourcetype=srctp srcMsgId=* system=*
| stats min(_time) as early max(_time) as late by srcMsgId system
| where (late-early)>N
Use a value (in seconds) for "N" - like | where (late-early)>90 for a minute and a half, or | where (late-early)>300 for 5 minutes
If my queue queue1 has property: x-message-ttl: 60000, but for part of the messages in this queue I want TTL 120000 or no TTL at all.
TLDR: All messages by default in this queue lives 1 minute, but part of them 2 minutes or has no time to live at all
RabbitMQ has separate mechanisms for setting per-queue and per-message TTLs, as described in the online manual. Using both at once is explicitly mentioned on that page:
When both a per-queue and a per-message TTL are specified, the lower value between the two will be chosen.
As such, neither of your examples will work:
Queue-level TTL of 1 minute + message-level TTL of 2 minutes => message will be deleted after 1 minute
Queue-level TTL of 1 minute + no message-level TTL => message will be deleted after 1 minute
But other combinations would work:
Queue-level TTL of 1 minute + message-level TTL of 30 seconds => message will be deleted after 30 seconds
Queue-level TTL of 2 minutes + message-level TTL of 1 minute => message will be deleted after 1 minute
This kind of makes sense: a message can end up in multiple queues, so if it specifies a TTL of 30 seconds, it shouldn't last longer than that in any of them; and a queue that's told to delete messages after 30 seconds doesn't care about individual message settings.
I created a new Redis steam using the following command.
XGROUP CREATE A mygroup $ MKSTREAM
I added the below mentioned data
xadd A * X 1
xadd A * X 2
xadd A * X 3
xadd A * X 4
I am reading the data using the following command.
XREADGROUP GROUP mygroup Alice COUNT 1 STREAMS A 0
Its returning an empty array
1) 1) "A"
2) (empty array)
I am using Redis version 6.2.1. Kindly help me to debug the error.
When you use XREADGROUP command to read message, you should specify > as ID, instead of 0.
Reference from the doc:
The special > ID, which means that the consumer want to receive only messages that were never delivered to any other consumer. It just means, give me new messages.
Any other ID, that is, 0 or any other valid ID or incomplete ID (just the millisecond time part), will have the effect of returning entries that are pending for the consumer sending the command with IDs greater than the one provided. So basically if the ID is not >, then the command will just let the client access its pending entries: messages delivered to it, but not yet acknowledged. Note that in this case, both BLOCK and NOACK are ignored.
If ID is not >, you can only read pending messages, however, in your case, there's no pending message, since you have not consume anything.
I want to use the Message Header ID generated in Queue 1 to Queue 2.
Can you please tell me how to achieve this in ActiveMQ?
Scenario:
Queue 1 message was not processed by ESB bus due to some failure
We will be using Queue 2 to post the message again after fixing it with
the same Message Header ID created in Queue 1
Queue 1 (Process):
Message Header ID : ID:XYZ-1234-1555664319032-4:2:1:1:1
Queue 2 (Re-process):
Message Header ID : ID:XYZ-1234-1555664319032-4:2:1:1:1
Many Thanks,
Samuel
ActiveMQ itself assigns the message IDs. It's not something which can be done from a client application. You'll need to use a different message header or property for your application-specific ID.
During load testing (using Load UI) of a new .Net web api using Mono hosted on a medium sized Amazon server I'm receiving the following results (in chronological order over the course of about ten minutes)
5 connections per second for 60 seconds
No errors
50 connections per second for 60 seconds
No errors
100 connections per second for 60 seconds
Received 3 errors, appearing later during the run
2014-02-07 00:12:10Z Error HttpResponseExtensions Error occured while Processing Request: [IOException] Write failure Write failure|The socket has been shut down
2014-02-07 00:12:10Z Info HttpResponseExtensions Failed to write error to response: {0} Cannot be changed after headers are sent.
5 connections per second for 60 seconds
No errors
100 connections per second for 30 seconds
No errors
100 connections per second for 60 seconds
Received 1 error same as above, appearing later during the run
100 connections per second for 45 seconds
No errors
Doing some research on this, this error seems to be a standard one received when a client closed the connection. As this is only occurring during the heavier load tests, I am wondering if it is just getting to the upper limits of what the server instance can support? If not any suggestions on hunting down the source of the errors?