I'm new to Meteor and wondering if anyone can point me to a package or technique for returning a ping round trip time to a remote server from a Meteor Client?
Would leitwarte:ping do the job for you?
Related
I have a Python gRPC server running on AWS Fargate (configured very similar to this AWS guide here), and another AWS Fargate task (call it the "client") that attempts to make a connection to my gRPC server (also using Python gRPC). However, the client is unable to make a call to my server, with the following error:
<_InactiveRpcError of RPC that terminated with:
status = StatusCode.UNAVAILABLE
details = "failed to connect to all addresses"
debug_error_string = "{"created":"#1619057124.216955000","description":"Failed to pick subchannel",
"file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":5397,
"referenced_errors":[{"created":"#1619057124.216950000","description":"failed to connect to all addresses",
"file":"src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc",
"file_line":398,"grpc_status":14}]}"
Based on my reading online, it seems like there are myriad situations in which this error is thrown, and I'm having trouble figuring out which one pertains to my case. Here is some additional information:
When running client and server locally, I am able to successfully connect by having the client connect to localhost:[PORT]
I have configured an application load balancer target group following the guide from AWS here that makes health check requests to the / route of my gRPC server, using the gRPC protocol, and expect gRPC response code 12 (UNIMPLEMENTED); these health check requests are coming back as expected, which I believe implies the load balancer is able to successfully communicate with the server (although I could be misunderstanding)
I configured a service discovery system (following this guide here) that should allow me to reach my gRPC server within my VPC via the name service-name.dev.co.local. I can confirm that the corresponding DNS record exists in Route 53, and when I SSH into my VPC, I am indeed able to ping service-name.dev.co.local successfully.
Anyone have any ideas? Would appreciate any and all advice, and I'm happy to answer any further questions.
Thank you for your help!
on your grpc server use 0.0.0.0:[port] and expose this port with TCP on your container.
I have an ASP.NET.Core server which uses Microsoft.AspNet.SignalR(2.2.1) for communication to WPF client. Because I use AspNet.SignalR and AspNet.SignalR.Owin on server side I host this app like a Kestrel console application. This application has been hosted on 3 different servers and there are problems with the servers hosted on Amazon EC2. First connection (running Connection.Start() method) takes a lot of time(about 60 seconds!!!). Invokes hub's method and requests to the controller working with normal speed. I tried to research this, of course I configured security group and firewall for HTTP traffic, but I really have no idea what is going on. Has anyone else had this problem? Does Amazon use any network monitor for EC2?
Update
Oh vey. I understand. Problem is much logic in OnConnected() hub method. All is OK but some my services on amazon start very slow. Thank you!
The problem
I'm having an issue where when I start my local dev server with meteor, about 3/5 times the client's socksjs connection via ddp-client.js isn't able to connect and gets an ERR_CONNECTION_REFUSED error. All other connections work fine (websocket, JS, css, etc).
I'm seeing this in the console
The socks is attempting to connect to 192.168.1.14, which is my correct internal ip.
What I've tried
setting the port manually with meteor --port 3000
waiting for Meteor.status().status === 'connected' on the client before making any calls
If you'd like to recreate the problem yourself you can pull down the package I'm working on, ProseMeteor at commit 51c0a304338228102edc75427f72e689a7aafb8a and try running the app yourself by running the bash run_demo script, you should see the problem when you visit http://localhost:3000.
I appreciate any help!
If we define our microservice inside Kubernetes pods, do we need to instrument a gRPC client reconnection if the service pod is restarting?
When the pod restarts the host name is not changed, but we cannot guarantee the IP address remains the same. So is the gRPC client still be able to detect the new server to reconnect to?
When the TCP connection is disconnected (because the old pod stopped) gRPC's channel will attempt to reconnect with exponential backoff. Each reconnect attempt implies resolving the DNS address, although it may not detect the new address immediately because of the TTL (time-to-live) of the old DNS entry. Also, I believe some implementations resolve the address when a failure is detected instead of before an attempt.
This process happens naturally without your application doing anything, although it may experience RPC failures until the connection is re-established. Enabling "wait for ready" on an RPC would reduce the chances the RPC fails during this period of transition, although such an RPC generally implies you don't care about response latency.
If the DNS address is not (eventually) re-resolved, then that would be a bug and you should file an issue.
You need client-side load balancing as described here. You can watch the endpoints of a service with Kubernetes api. I have created a package for Go programming language and it is on github. Sorry but I didn't write a documentation yet. Basic concept is get service endpoints at beginning than watch service endpoints for changes.
The following error seems to have appeared overnight, and is not identified with any community package that I can tell. Seems to be part of the core DDP and WebSocket modules.
stream error Error during WebSocket handshake: Unexpected response code: 404
It shows up in the log generated when starting the server. mike:mocha Mocha testing also seems to have broken.
Again, seems to have cropped up out of nowhere after having the app running correctly for a long time. May have been due to a meteor update. Meteor version is currently Meteor 1.1.0.2.
This can happen when you have a package or code on your server side that connects to another server using DDP or Websockets and there is an interruption where the server you're connecting to has a proxy and the underlying server goes offline.
This can happen from time to time. When you use websockets the connection is persisted for a very long time. It will immediately try to reconnect if there is a disconnection.
Nearly no cloud hosting provider is able to give 100% uptime so you can expect a few of these when there is an interruption. The error comes from trying to reconnect at this moment most likely.
If you have no package that bears this remote websocket connection attribute it could be meteor's package reporting system itself. You could opt out of this by adding the package-stats-opt-out package using meteor add package-stats-opt-out