edgexfoundry / edgexfoundry/go-mod-messaging
Listen and wait pattern for mqtt causes performance issue
- Dominant language
- Go
- Stars
- 37
- Forks
- 58
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 3
Description
# 🚀 Feature Request
Relevant Package: internal/pkg/request.go and core-command
This feature request is for changing the send and wait implementation for mqtt
### Description
At this time in the DoRequest function of internal/pkg/request.go, it implements with a send and wait(with timeout) pattern.
If user sends the command quickly, for example I tried to send read command to core command with 1s delay, the core command will reports timeout quickly.
The error is as following:
level=ERROR ts=2025-07-07T23:42:51.342820133Z app=core-command source=internal.go:166 msg="Request to topic 'edgex/device/command/request/servicename/devicename/SwitchStatus/get' failed: timed out waiting for response on edgex/response/servicename/fc9f200c-044a-48de-a3b6-357c4b992ff0 topic"
level=ERROR ts=2025-07-07T23:44:21.358288411Z app=core-command source=internal.go:166 msg="Request to topic 'edgex/device/command/request/servicename/devicename/SwitchStatus/get' failed: unable to create response subscription: Timeout occured while performing a 'Subscribe' operation: Failed to create subscription".
I have tested with a dummy device service. The result shows that the issue is from this send and wait pattern, not from a slow device service.
I think this is not idea for a sub/pub solution.
### Describe the solution you'd like
For an event driven case I'd suggest to have following solution
1. Remove the sub and wait
2. redesign the topic. At this time the response topic is as following
edgex/response/servicename which is not easy to distinguish from other topic for example edgex/response/core-command.
I'd propose something as edgex/response/devices/xxxx
3. Have a global sub which is listening on edgex/response/devices/#. Then this sub forward the messages to edgex/response/core-command which makes it be compatible with current behavior.
Please let me know the feedback. I'd be happy to contribute a PR for this.
Contributor guide
Research direction
Start with DoRequest in internal/pkg/request.go and trace how core-command performs the current send-and-wait flow. Review the proposed response topic changes and global subscription behavior, then confirm the design and compatibility expectations with maintainers. Done should mean the request flow no longer depends on per-request waiting while preserving the stated core-command behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100