How come I'd never seen that "Then send the latest message" option? 
What does the Filter contribute? It seems to work according to specification without it?
if you just send one message it will get repeated without the filter.
1 Like
If there are multiple messages in the queue (which have been added with toFront) then flush: 1 sends the latest and the reset clears out the rest.
1 Like
Yes, I think it does, provided the payload is a value or a simple object (otherwise the filter doesn't like it). I think this will do the job, which is to help with Two way switch infinite loop
Thanks.
I can see a problem with those methods, if two messages arrive in quick succession then the second one will get through before the gate is closed.
It is almost impossible to handle race conditions like that without using semaphore-like techniques to ensure the loop gets closed before the next one gets in.
Yes, you could insert a rate limit eg 1 message per 20ms but I doubt if that would guarantee that the gate isn't left open too long.
How about DCJ's solution but set the filter to block unless msg._msgid changes? I think that removes the issue of filtering out genuine repeated messages.
There is another, related problem, imagine that there is a message waiting in the gate node, another in the rate limit node, and the Set Mode trigger is about to run down. It is possible that the trigger will run down, open the queue releasing the message in the gate and if the rate limit node releases the message at that moment then that one will get straight through as the gate is still open.
1 Like
In fact, for the application here, it doesn't matter if genuine repeated messages get lost.
Is msg._msgid guaranteed unique? I suspect that if you RED.util.cloneMessage() a message it may end up with the same id. Other than that, though, yes it should work.
Were any of mine any good?
Did any of them satisfy all of the requirements?
That's a rhetorical question - yes?
I don't know. I've asked for clarity and haven't seen an answer to it.
Sorry, I didn't realise I had missed a request for more information. Which aspect is not clear?
I read it that "ideally" there would be 3 (maybe 4) message received in a short time.
The first one is sent on directly.
The second one - if received in less than 5 seconds - is dropped.
The third - and subsequent - are then on sent at 5 second intervals.
To what limit?
Can it be "ongoing" forever?
Or to a nominal of.... 10?
What is supposed to happen to the messages? (after the nominal 10)
Just some of the flows I saw didn't seem to allow for more than 3 messages to arrive and handle more than that.
Yes, I could be wrong. Usually I am, but that's another chapter, so I was making flows to deal with a near infinite stream of messages.
And - just out of interest - was wondering how well I parsed the request.
It is not of any help to me or anyone else if I am answering the wrong question or don't understand the one asked.
As I said in the first post "I have a scenario with messages coming in at random intervals". There is no ideal sequence, there could be many close together, or none for hours.
Both correct.
What gave you that idea? Requirement 3 states "If a third (and subsequent) message comes in when there is already one queued then it replaces the one already in the queue". Therefore there is never more than one in the queue. When the five seconds is up then the one and only message in the queue will be released.
I can't read.
Hey, tell me something I don't know.
Ok.
Point 3 could have been made a bit clearer, it should probably have been
3. If a third (and subsequent) message comes in when there is already one queued then it replaces the one already in the queue and will be released at the end of the period, unless yet another message appears within the five seconds.
So, there is a message in the queue. It is waiting for the 5 seconds.
A third message comes in.
The new message replaces the one in the queue - still waiting for the 5 seconds to pass.
4 seconds after that ANOTHER message arrives.
That replaces the message in the queue. 4 seconds have passed. So does the timeout start again or wait for the original remaining 1 second?
If in that remaining time, YET ANOTHER message arrives.
When does the message finally get spat out?
To me, there is ambiguity there.
Ah, I am (third time today) overthinking things.
I'm not helping so I shouldn't spend more time on it.
The timer is not restarted by subsequent messages within the five seconds. Then the timer is restarted by the next message (which is the first message of the next set). So any message in the queue is released five seconds after the first one.
In fact you are right, there is a condition that I had not defined, and that is that when the five seconds is up and it releases a message it should restart the timer again. The flow using the trigger node does not do this. More thought required.
Nah, I'm way out of my depth.
The one with the qgate is probably the one I would put my money on as being best matching and that trick with the queue limit that I missed.
