(Go: >> BACK << -|- >> HOME <<)

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Queue strategy is being ignored when sending an array of messages to rpcCallRequest node #5848

Closed
NN01010101 opened this issue Jan 10, 2022 · 2 comments
Assignees
Labels

Comments

@NN01010101
Copy link

bug
Queue strategy is being ignored when sending an array of messages to rpcCallRequest node.

Server Environment

  • own setup
    • docker deployment
    • ThingsBoard 3.2.2CE/PE

Client Environment

  • OS: OSX, node app

  • Connectivity

    • MQTT
    • Gateway

To Reproduce
Steps to reproduce the behavior:

  1. generator node with array of numbers
  2. pass the message to checkpoint node (SequentialByOriginator)
  3. connect this not to script node that loops over the array and create message objects which are passed as array to rpcCallRequest node

Expected behavior
Messages incoming on client in incremental order.
Messages incoming one at a time, next message arrives only if client published response with requested

Actuall behavior
Messages incoming on client in random order.
Messages incoming all at once regardless of whether client published response with requested or not

Screenshots
rule-engine

script

Additional context
The idea is to send multiple chunks to the device via gateway since the throughput between the gateway and the device does not allow to send large packages. Throwing chunks onto the sequential queue should result in messages being sent in the same order as they were in the array, one by one, only after the previous rpc call was confirmed by the gateway. Unfortunately the opposite is the case, the order is random, and if no confirmation on topic v1/devices/me/rpc/response/requestId happened all messages are still sent out.

Maybe there is another way how to put multiple messages on a queue at one go, the one way that I've found (send array) seems to ignore strategy. Am I doing something wrong or is it a bug?
Thanks!

@NN01010101 NN01010101 added the bug label Jan 10, 2022
@NN01010101 NN01010101 changed the title [Bug] [Bug] Queue strategy is being ignored when sending an array of messages to rpcCallRequest node Jan 11, 2022
@NN01010101
Copy link
Author

I updated thinsboard to 3.3.2, apparently, sequential RPC is supported from 3.3.1. In order to turn it on, thingsboard.yml must be edited:sequential: "${ACTORS_RPC_SEQUENTIAL:true}"
Now all messages come in the right order, yet the queue does not care whether MQTT RPC response was made or not, further messages in the queue are sent anyway.
In the source of sequential RPC I found the following info:
"_When enabled, RPC will be sent sequentially. Be careful, this may introduce delays in RPC delivery. The next RPC will not be sent until the previous RPC call is delivered to the device."
Question: How does thingsboard know whether RPC was delivered or not? Since we are using gateway API, our gateway will see whether message was delivered to the target device and answer to RPC with the right request Id, only then next RPC message can be sent. How can we achieve this?

Please help!

@SuminDenis
Copy link

Hi @NN01010101,

Explanation of how does ThingsBoard know about delivered RPC you can find by the following link:Server RPC

For your purposes, you need to use Persistent RPC. You can read about light RPC and persistent RPC by the following link:RPC Guide.

Also, here is the configuration for the ThingsBoard IoT Gateway MQTT Connector: RPC Commands Configuration

When you read all the documentation mentioned above, you should be able to achieve the expected behavior!

We will close this ticket due to the long inactive time. You can open a new one if you need more help on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants