-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How do I identify which replica a client tcp connection is on, and how do I route messages with rpc to that replica? #788
Comments
I looked at the Weaver project source code and found no relevant object and API exposure. If so, Weaver is only suitable for HTTP-based applications. |
@wind-c, you can interact with a Service Weaver application based on whatever you can export a listener. Our examples expose a http server, but you can use something else too (e.g., a grpc server). Now, for communication between different components we use RPCs on top of TCP. The weaver runtime is responsible to start components, and component replicas and propagate their addresses to all the other components that want to talk to. What exactly are you trying to do? |
Maybe I don't understand weaver's architecture. So there's this doubt. The single process deployment worked fine: D:\GolandProjects\ServiceWeaver> .\client.exe The multi-process deployment is abnormal: D:\GolandProjects\ServiceWeaver> weaver multi deploy weaver.toml D:\GolandProjects\ServiceWeaver> .\client.exe 400 Bad Request |
Got it. The problem is the way you're trying to send requests from the client to the server using raw TCP in case of the multi deployer. Our multi deployer implementation uses a HTTP proxy to export the However, Service Weaver DOES NOT make any assumptions about the kind of traffic you can send as long as it's TCP traffic. For example, if you try your example with the Kube deployer, it will work just fine. Same for the GKE deployer. So:
Is this something that blocks you to deploy weaver in production or just playing around on your local machine? |
I see. Another question: |
Will do. However, it's not a priority short term, because the multi deployer is intended to be used mostly for testing on the local machine. However, if this blocks you from adopting Service Weaver in production, please let us know. Listeners are intended to be the way you interact with a Service Weaver application. In your example, the main component exports a listener that receives requests. Number of replicas per component - the deployer computes the number of replicas. In case of multi, each component is replicated twice. The GKE/Kubernetes deployers rely on Kubernetes autoscalers to scale up/scale down then number of replicas based on load (a combination of cpu and memory usage on each pod). |
@rgrandl ,thank you very much for your reply. |
I wrote the tcp server example and the single-process mode is fine. The new question is, in the multi-process, multi-machine, or multi-replica deployment, how do you find out which replica a given client tcp connection is on? How do you route messages to this tcp connection?
Http is used for request-response services, but for push, notification, chat, pub-sub and other types of services are based on tcp connections, and messages must be routed to the specified client tcp connection.
The text was updated successfully, but these errors were encountered: