[Feature Request] Number of messages in the queue

[softy2k]

Hello, and thanks for queue-gate.

Is it possible to implement status object (the state of the gate) directly in the output of q-gate ? In other words, I would need the number of messages in the queue, directly from the q-gate node, not from the status node

[colinl]

Why?

[softy2k]

To have access to the queue number, right somewhere directly after the q-gate node I should have: a) an additional node-join (an entry from the status-node and another directly from the stream coming from the node q-gate). b) from node-status I retain with flow.set the value of queue number, then in the flow that comes directly from q-gate I access it with flow.get.

Or maybe there is another option, simpler, but I miss it.

*** I hope I managed to make myself understood somehow, English is not my first language.

[colinl]

Do you mean you want the queue count included with the queued message? In that case then yes a Join node would be the way I would do it. Why do you want the queue size with the queued message? Note the it may immediately be wrong as another message could come in and change the queue size.

[softy2k]

Do you mean you want the queue count included with the queued message?

Yes

I am particularly interested when the queue number is zero, in other words, when all the packets have finished processing.

In my case, even if other packages come, they will be processed in turn, then they will end. I just want to know when the package series is finished processing.

Basically I will have series of packages, which will be processed, but I need to know when a series ends.

[colinl]

OK, yes, I can see that could be useful, knowing that the message you have is the last one in a sequence.

In fact, I would probably not use a Join node for that, I would just feed the status node directly into the flow, with a very short delay to make sure it gets into the flow after the released message, then in the downstream flow ignore any messages that have msg.status present until at the point where you want to know whether the queue is empty then interpret the status message.

[drmibell]

@softy2k, it would be possible to do what you suggest, but I am reluctant to do it for several reasons. The basic design of the node was intended to keep the stream of messages flowing through the gate as separate as possible from the messages controlling the state or reporting the status of the node. This is why the control messages are not passed through to the output. I have also avoided modifying the messages passing through in any way.

I am not certain exactly what your requirement is. If you use the trigger command to release messages from the queue one at a time, the status text will always show the number remaining in the queue, and the status command will refresh that status so that a status node can generate a message. When that number is zero, the queue is empty. If you use flush, open, or toggle to release the entire queue at once, you can first use status to determine the number of messages in the queue and then count messages as they arrive to confirm that you have received them all.

[softy2k]

Thanks to everyone for the answers.

But, I have other ideas :

1. Add status info to [msg]

2. q-gate with two outputs. The second output will send status information (same as status node). No need to flush, just realtime info.

[colinl]

What is the difference between the second output and a status node linked to the gate node?

[softy2k]

No need to select something else (like in Status Node). It would be easier to use.

In addition, I would have the certainty that what I receive from the second output is 100% from q-gate. In other words, I would eliminate any mistake that would occur if I selected something wrong from the status node.

It could also be considered as an additional option (improvement) for q-gate.

[colinl]

The logical extension of that is that any node that has a useful status indication should have that available as an additional output.

[drmibell]

To clarify, are you trying to achieve something that cannot be done now with q-gate and status nodes, or are you just hoping to use a different flow structure, perhaps neater or more to your taste?

Regarding your other ideas:

1. Add status info to [msg] As I said, modifying the messages passing through the gate is not a great idea. The user's decisions on the structure and content of his messages really should be respected. It is not clear whether the status would be added to the payload or some other property, and whatever you name the status property, it has the possibility to conflict with something that user has defined.
2. q-gate with two outputs As @colinl says, I don't see how the second output is really different from using a status node, except that the extra node actually makes it easier to see the logic. The effort in setting up the status node correctly is a one-time cost that does not really affect the utility of the node.

The project is open source, so if you feel strongly enough to invest the effort you are welcome to develop and use a new fork or even publish a revised node.

[softy2k]

Like I said, I am particularly interested when the queue number is zero, in other words, when all the packets (from a series) have finished processing. But to achieve this in a simpler way, without using other external nodes (status nodes). In other words, to have all the necessary information from a single node (q-gate), without intermediaries.

@drmibell I don't have (yet) the knowledge to modify this node, so I have no choice, I will use status node.

Anyway, thank you for the answers. For me, q-gate is a super node (even if it's not 100% as I would have liked).

[drmibell]

I'm glad you are finding the node useful, even without exactly the features you might find ideal. Please let me know if you have suggestions for other improvements. In the meanwhile, I will close this issue.