You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@eventmesh.apache.org by "qqeasonchen (via GitHub)" <gi...@apache.org> on 2026/09/22 08:54:09 UTC

[I] Serve the legacy SDK gRPC protocol on the v2 runtime (port 10205 compatibility bridge) (eventmesh)

qqeasonchen opened a new issue, #5411:
URL: https://github.com/apache/eventmesh/issues/5411

   ## Motivation
   
   The v2 runtime serves HTTP + CloudEvents on 10105/10106 (WS 10107, A2A 10108) and keeps `eventmesh.grpc.port=10205` **RESERVED** (configuration.md: "not served yet; keeps the 1.x default warm"). Meanwhile the legacy SDK surface is fully preserved on develop:
   
   - `eventmesh-sdks/eventmesh-sdk-java` ships complete gRPC clients — `EventMeshGrpcProducer` / `EventMeshGrpcConsumer` (blocking + async stubs) targeting `PublisherService` / `ConsumerService` / `HeartbeatService` / `RegistryService` (`org.apache.eventmesh.cloudevents.v1.*`)
   - The generated protocol classes live in `eventmesh-common` (`org.apache.eventmesh.common.protocol.grpc.*`), so no proto regeneration is needed
   - Go / Rust SDKs keep their gRPC protos too
   
   Per the capability table these SDKs are **Legacy-compatible: "kept so old clients run unmodified"** — but today an old gRPC client has nothing to connect to: the contract is broken. README/protocols.md advertise legacy gRPC compatibility; the runtime should honor it.
   
   ## Proposal
   
   Serve the legacy gRPC protocol on the reserved port 10205 as a **compatibility bridge** onto the v2 ingress path (no second messaging engine):
   
   1. **`EventMeshGrpcServer`** (new, `eventmesh-runtime/.../grpc/`): gRPC `ServerBuilder` on `eventmesh.grpc.port` (default 10205, `0` = disabled — opt-in like the WS port), graceful shutdown with the app lifecycle.
   2. **Publisher bridge**: `publish` / `batchPublish` / `requestReply` — map the proto `CloudEvent` (attributes via `EventMeshCloudEventUtils`) to a v2 `io.cloudevents.CloudEvent` and hand it to `UniIngressService.publish` (WAL durability, at-least-once — same semantics as the HTTP path). `requestReply` maps onto the existing request/reply correlation. Reply: legacy `Response` codes in `StatusCode`.
   3. **Consumer bridge**: `register`/`subscribe`/`unsubscribe` map onto the v2 subscription registry (clientId derived from `consumerGroup`+`env`+`idc` headers; `url` webhook style and the SDK's own client-callback are bridged to long-poll internally). `subscribeStream` (bidi) is served by pumping the v2 push pipeline into the stream — same dispatcher the SSE path uses.
   4. **Heartbeat / Registry**: in-memory registrations with the same TTL model the agent plane uses; heartbeats refresh, reaper evicts stale gRPC clients.
   5. **Group semantics**: legacy `consumerGroup` maps to a v2 subscription group with `LOAD_BALANCE` mode (SDK default `CLUSTERING`), URL-subscriptions to `BROADCAST` where the old protocol used broadcasting — documented in a compatibility table.
   6. **Docs**: protocols.md legacy-gRPC section + configuration.md flips the 10205 row from RESERVED to served (opt-in); README capability-table row unchanged (still Legacy-compatible) but the Recommendation note gains "gRPC bridge served since #<this PR>".
   7. **Tests**: hermetic unit tests for the proto↔v2 CloudEvent mapping; an integration test booting the gRPC server against the in-memory storage and driving it with the **existing** `EventMeshGrpcProducer`/`EventMeshGrpcConsumer` (the SDK is its own conformance suite).
   
   ### Non-goals (follow-ups)
   
   - New (non-legacy) gRPC-native v2 API — HTTP + CloudEvents stays the primary path
   - gRPC admin surface (the `AdminService` proto stays unimplemented, as on 1.x)
   - Go/Rust SDK verification against the bridge (Java SDK first; the protos are shared so others should follow, tracked separately)
   
   ## Compatibility risk
   
   Low: the bridge is opt-in (`eventmesh.grpc.port` unset = off), touches no existing path, and reuses the v2 delivery engine, so offset/ACK/retry semantics cannot diverge.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@eventmesh.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@eventmesh.apache.org
For additional commands, e-mail: issues-help@eventmesh.apache.org


Re: [I] Serve the legacy SDK gRPC protocol on the v2 runtime (port 10205 compatibility bridge) (eventmesh)

Posted by "qqeasonchen (via GitHub)" <gi...@apache.org>.
qqeasonchen closed issue #5411: Serve the legacy SDK gRPC protocol on the v2 runtime (port 10205 compatibility bridge)
URL: https://github.com/apache/eventmesh/issues/5411


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@eventmesh.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@eventmesh.apache.org
For additional commands, e-mail: issues-help@eventmesh.apache.org