Posts

Problem Description When using gRPC for communication in a Python project, issues such as blocking or errors can occur when used across processes (the symptoms vary depending on the version of gRPC.io). The following code demonstrates a cross-process usage demo where the main process sends requests to a gRPC server on port 30001, and the child process also sends requests to the same server. def send(): channel = grpc.insecure_channel('localhost:30001') stub = message_pb2_grpc.GreeterStub(channel) response = stub.SayHello(message_pb2.HelloRequest(name='you')) print(f"Greeter client received 1: " + response.message) def main(): channel = grpc.insecure_channel('localhost:30001') stub = message_pb2_grpc.GreeterStub(channel) response = stub.SayHello2(message_pb2.HelloRequest(name='you')) print("Greeter client received 2: " + response.message) p = multiprocessing.Process(target=send) p.start() p.join() if __name__ == '__main__': main() When using gRPC.io version 1.28.1, an error occurs: the main process can receive the server’s response normally, but the child process reports Socket operation on non-socket. ...

Problem Description VSCode cannot run Go projects in run mode (it can only debug in debug mode), and the following error occurs. The obscured part in the image is a package within the project, not a third-party package. This means that when running a Go project in run mode, it cannot find other Go files, only the entry file. Initial Investigation The first thought about not finding other files is an issue with the GO_PATH. However, the project uses Go modules, allowing the creation of projects outside the GO_PATH, so this suspicion is ruled out. Next, I suspected an issue with the VSCode configuration. Each VSCode project has a .launch.json file that configures the environment when running code. Below is the .launch.json from the project. ...

Problem Description Viper (version 1.1.0 in this context) is a comprehensive configuration solution for Go applications, widely used across various projects. etcd is a distributed key-value store, often used as a configuration center. Viper supports reading configurations not only from files but also from remote configuration centers. The following code is used for configuration. viper.AddRemoteProvider("etcd", "http://127.0.0.1:2379", "conf.toml") viper.SetConfigType("toml") err := viper.ReadRemoteConfig() if err != nil { panic(err) } Running this results in the error panic: Remote Configurations Error: No Files Found. Upon investigation, it was found that etcd had TLS enabled, requiring access to its API via HTTPS. The code was updated as follows. ...

Many programming languages provide support for environment isolation, such as Node.js with node_modules, Golang with go mod, and Python with virtualenv and pyvenv. To create a dependency snapshot, the pip freeze > requirements.txt command is often used to generate a requirements.txt file. In some scenarios, this method suffices, but in more complex situations, requirements.txt falls short. requirements.txt appdirs==1.4.3 astroid==2.3.3 attrs==19.3.0 black==19.3b0 certifi==2019.11.28 chardet==3.0.4 click==7.1.1 et-xmlfile==1.0.1 Flask==1.1.1 gevent==1.4.0 greenlet==0.4.15 idna==2.9 isort==4.3.21 itsdangerous==1.1.0 jdcal==1.4.1 Jinja2==2.11.1 lazy-object-proxy==1.4.3 MarkupSafe==1.1.1 mccabe==0.6.1 numpy==1.18.2 openpyxl==3.0.3 pandas==1.0.3 pylint==2.4.4 python-dateutil==2.8.1 pytz==2019.3 requests==2.23.0 six==1.14.0 tinydb==3.15.2 toml==0.10.0 typed-ast==1.4.1 urllib3==1.25.8 Werkzeug==1.0.0 wrapt==1.11.2 The requirements.txt file only records the versions of dependencies. If the official PyPI source is slow, and you need to use a faster domestic mirror, you typically have to use pip install -i or modify the global pip.conf file. ...

Problem Description When creating a Docker image, there is a need to copy all files and directories from a certain path into the image. The following Dockerfile was written: FROM alpine WORKDIR /root/test_docker_proj COPY * ./ The original directory structure is as follows: /projects/test_docker_proj ├── Dockerfile ├── dir1 │ ├── dir11 │ │ └── file11 │ └── file1 └── file2 However, the directory structure copied into the Docker image turns out like this: ...