netty-transport-native-epoll #4998
-
|
From my understanding, Glide uses Netty. Lettuce also uses netty and they support netty using native libraries. Netty provides three platform-specific JNI transports:
Lettuce defaults to native transports if the appropriate library is available within its runtime. Using a native transport adds features specific to a particular platform, generate less garbage and generally improve performance when compared to the NIO based transport. Native transports are required to connect to Redis via Unix Domain Sockets and are suitable for TCP connections as well. Does Glide support using native libraries such as these? Is this just a netty thing and would be levered if we provided the correct dependency on the corresponding OS? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
Apologies for the delayed reply. As far as I am aware, there is no way to configure the Netty transport in the current GLIDE release. Glide has a very specific use case for Netty. It is only used to send data to the Rust middleware, which allows the Rust middleware to communicate with the Valkey server. This is slightly different from how Lettuce directly uses Netty to communicate with the Valkey server. Important Note: Starting with GLIDE version 2.2.x, we have removed the use of Netty and Unix Domain Sockets in favor of a full JNI-based implementation. Hopefully this answers your question, feel free to followup if not. |
Beta Was this translation helpful? Give feedback.
Hi @patrickjamesbarry,
Apologies for the delayed reply. As far as I am aware, there is no way to configure the Netty transport in the current GLIDE release.
Glide has a very specific use case for Netty. It is only used to send data to the Rust middleware, which allows the Rust middleware to communicate with the Valkey server. This is slightly different from how Lettuce directly uses Netty to communicate with the Valkey server.
Important Note: Starting with GLIDE version 2.2.x, we have removed the use of Netty and Unix Domain Sockets in favor of a full JNI-based implementation.
Hopefully this answers your question, feel free to followup if not.