langgenius/dify-plugin-daemon
1
0
Fork 0
mirror of https://github.com/langgenius/dify-plugin-daemon.git synced 2026-07-21 17:25:23 -04:00
Code Issues 111 Packages Projects Releases 10 Wiki Activity

[FEATURE] python starts multi-process replicas. #126

New Issue
Open
opened 2026-02-16 00:19:59 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 00:19:59 -05:00
Owner
Copy Link
Copy Source

Originally created by @luckylhb90 on GitHub (May 23, 2025).

Is your feature request related to a problem? Please describe.

For some unknown reason, daemon detected that azure was inactive and was restarted. However, when the restart occurred, the service was unable to handle new azure requests, resulting in an error.

So is there any way to start multiple process copies? Reduce the impact on the business.

A similar redis strategy can also be implemented. In case of failure, it is transferred to another node for retry

A certain plugin is unavailable on a pod, and there is no way to prevent the pod from continuing to receive requests from this plugin. Is it necessary to add a zk?（Or change the current implementation strategy of pd. pd can achieve a coordinating effect similar to zk, and then forward it again to the available plugin nodes through pd.）

There is another problem. If the plugin is restarted, the new requests will wait for the timeout before being interrupted. Can fast failure be achieved?

Image Image

Describe the solution you'd like
feature 1 : python starts multi-process replicas.
feature 2: fast failure
feature 3: After failure, request to transfer the node
feature 4: Connect to zk to detect whether a certain plugin is available?
feature 5: pd achieves a coordinating effect

Describe alternatives you've considered

Additional context

Originally created by @luckylhb90 on GitHub (May 23, 2025). **Is your feature request related to a problem? Please describe.** For some unknown reason, daemon detected that azure was inactive and was restarted. However, when the restart occurred, the service was unable to handle new azure requests, resulting in an error. So is there any way to start multiple process copies? Reduce the impact on the business. A similar redis strategy can also be implemented. In case of failure, it is transferred to another node for retry A certain plugin is unavailable on a pod, and there is no way to prevent the pod from continuing to receive requests from this plugin. Is it necessary to add a zk?（Or change the current implementation strategy of pd. pd can achieve a coordinating effect similar to zk, and then forward it again to the available plugin nodes through pd.） There is another problem. If the plugin is restarted, the new requests will wait for the timeout before being interrupted. Can fast failure be achieved? <img width="1281" alt="Image" src="https://github.com/user-attachments/assets/c40d3017-59c4-4a4a-a7bb-5b324379ce8b" /> <img width="864" alt="Image" src="https://github.com/user-attachments/assets/5292d07a-ef4f-42a8-a95b-71ec6063df40" /> **Describe the solution you'd like** feature 1 : python starts multi-process replicas. feature 2: fast failure feature 3: After failure, request to transfer the node feature 4: Connect to zk to detect whether a certain plugin is available? feature 5: pd achieves a coordinating effect **Describe alternatives you've considered** **Additional context**
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Windows
bug
cmd
documentation
enhancement
go
good first issue
plugin-daemon
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify-plugin-daemon#126
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?