Does the rate limiter in delay node accept also decimal values?
I need to serialize each incoming message in order to avoid overlapping...
Pretty sure it does (and certainly easy enough to test).
Unless your messages go through a node which does async operation or you branch off, then messages should be in order regardless! What exactly do you mean here?
Perhaps you need a kinda semaphore to prevent executing a node before it has finished?
Sure, why not? Unless you have side effects in that function node (e.g. it has state or uses context), i see no reason.
You could of course order them by using link-call
and behind the scenes 1 msg in 0.1 s is the same as 10 msgs in 1 sec ...
1 Like
Yes. But one by one. Not all at once
In fact 10 msgs in one second does them one by one too. It has been argued that it should do them all at once, but it doesn't.
2 Likes
Ok. But do you think that using that limiter can hurt?
In what way would it hurt anything?
Ok. you answered, Thanks
Steve, how would the error handling work in your example? 
AFAIK the link-call node doesn't (re-)throw an error if the corresponding link-return gets fed with an error message (meaning a msg with msg.error set). The only "real" error it throws is the timeout.
In all other cases, you'd have to manually check for msg.error after each link-call and perform some error handling.
(Which is why I still prefer using subflows instead of link-calls, because I can make proper use of catch nodes. 
)
EDIT: We can move this into a separate topic if you like, because it's slightly off-topic from the original question.
correct.
there is ongoing thoughts and discussion around improving the link call.
It can however be handled with methods you discuss. And, personally, the savings that can be made in processing time that it takes to init instance x subflow nodes vs a simple check after the link-call, i know what I would chose.
Have you written this pattern up in any of the discussions (I forget - it is not currently on my radar - please link to it)
2 Likes
Good to know it's on the radar. I haven't found any relevant discussion on the matter in the designs repo on Github so far.
I totally agree about the performance issues when using many (nested) subflows. Link-calls would absolutely suffice in most cases.
But I'm also an advocate of clean error handling, and that involves using the try-catch pattern. So porting all of them to link-calls would introduce a lot of extra manual error handling.
If you like, we can start a feature request topic and I'll write up my thoughts on that. (this evening, I have some other tasks at the moment)
there was some talk here: Capturing errors caused inside link-call flows - #3 by gregorius
And some design proposals here: FR: Dynamic Link node enhancement request (backlog item) · Issue #3836 · node-red/node-red · GitHub - the design stalled after failing to come to a resolution. I personally like choice (sometimes I want link call to pass msg with error, sometimes i want it to throw) but that was vetoed!
1 Like
Oh boy, I'm getting old. 
I have already mumbled my exact thoughts on the matter in the topic you mentioned, which is using the .error property... 
And I realize (again), that there's no trivial solution to it, either.
2 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
