[Question] After runtime crashes and reconnects, TCP and GRPC will resend subscription information, but HTTP does not
- Dominant language
- Java
- Stars
- 1.8k
- Forks
- 658
- Avg merge
- 11h 29m
- Merged PRs (30d)
- 52
Description
### Search before asking
- [X] I had searched in the [issues](https://github.com/apache/eventmesh/issues?q=is%3Aissue) and found no similar issues.
### Question
Both tcp and grpc will resend the subscription information after the runtime is disconnected. Why doesn't http resend the subscription information?And after testing, it was indeed found that when keeping sub started and restarting the runtime, sending events through pub again, only grpc and tcp sub can be consumed again, while http
sub cannot consume events.
---
tcp和grpc都会在runtime断开连接后重新发送订阅信息,为什么http不重新发送订阅信息?并且经过测试也确实发现,当保持sub启动,而重启runtime后,再次通过pub发送事件,仅有grpc和tcp的sub可以再次消费,而http sub无法消费事件。

(org.apache.eventmesh.client.grpc.consumer.EventMeshGrpcConsumer#heartBeat)

(org.apache.eventmesh.client.http.consumer.EventMeshHttpConsumer#heartBeat)

(org.apache.eventmesh.client.tcp.impl.cloudevent.CloudEventTCPSubClient#reconnect)
(org.apache.eventmesh.client.tcp.impl.eventmeshmessage.EventMeshMessageTCPSubClient#reconnect)
Contributor guide
Research direction
Compare org.apache.eventmesh.client.http.consumer.EventMeshHttpConsumer#heartBeat with org.apache.eventmesh.client.grpc.consumer.EventMeshGrpcConsumer#heartBeat and the TCP client reconnect methods named in the issue. Restart the runtime while a subscription remains active, publish an event again, and verify that the HTTP subscriber receives it as TCP and gRPC subscribers do.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grpc, java
- Domain
- distributed-systems, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100