edgexfoundry / edgexfoundry/go-mod-messaging

Listen and wait pattern for mqtt causes performance issue

Open
#424 12 comments 1 reaction 0 assignees View on GitHub
enhancement help wanted
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.