I'm currently researching on Redis to retrieve data via UNIX sockets.
I've updated the redis.conf file to reflect this, by defining the path to redis.sock (in my case it is /tmp/redis.sock).
Using Spring Data Redis (via JedisConnectionFactory), I can see that it has methods for connecting to Redis via TCP (i.e. defining hostname and port). However, I don't see there being any methods used for connecting via UNIX sockets (unless I've overlooked something).
Does anyone know how I can connect to Redis using UNIX sockets via Spring Data Redis?
Any help/advice is appreciated.
Java cannot create or access Unix Domain Sockets without using a 3rd party (native) library.
That's correct in general. Jedis has (as of writing this answer) no Unix Domain Socket support. Lettuce and Redisson use netty for I/O which has support for native transports (epoll and kqueue). A native transport is required to use Unix Domain Sockets which depends on the underlying operating system.
Lettuce is integrated into Spring Data Redis but there's no native transport option yet.
References:
Jedis #492 Support Unix Domain Sockets
Lettuce: Reference documentation on Unix Domain Sockets
Redisson: Configuration of Unix Domain Sockets
Java cannot create or access Unix Domain Sockets without using a 3rd party (native) library.
And the spring-data-redis use the Jedis or Jredis or others as engine. Jedis does not support this method to connect. I think others do not support it also. Because the unix socket can only be used in local machine.
You can check this client library to make sure this.
You can use a workaround with socat. This is what I did for my DockerSwarmDiscoveryClient which required access to the /var/run/docker.sock but I only had the Spring WebClient which only supports TCP connections.
In a Docker context you can set up
daemon:
image: alpine/socat
command: tcp-listen:2375,fork,reuseaddr unix-connect:/var/run/docker.sock
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
Related
Does Azure Redis support transport over http. I am aware of the setting that allows me to choose whether to enable SSL or not. But it seems to me the connection to Azure Redis happens over TCP.
"Every Redis Cluster node requires two TCP connections open. The normal Redis TCP port used to serve clients, for example 6379, plus the port obtained by adding 10000 to the data port, so 16379 in the example."
I have also posted this question on the Microsoft forum. It can be found here.
No, Redis (and Azure's as well) does not use HTTP but rather a text-based protocol called RESP. There are 3rd party servers that let you do that, such as Lark, Webdis and tinywebdis.
I've had a search over the internet but can't seem to find any straightforward instructions on how to use the Thrift protocol from behind a proxy.
To give you a bit of background - we have a Zipkin instance setup (https://github.com/twitter/zipkin) that uses a Cassandra instance (http://cassandra.apache.org/) to store Zipkin traces. Our intention is to negotiate over the thrift protocol to a collector that is then responsible for writing traces to Cassandra.
What conditions have to be in place for us to negotiate successfully via our corporate proxy? Do we just have to set certain proxy properties when trying to negotiate or do we have to set something else up that allows this negotiation to happen?
Any help people can give in this direction with regards to resources and/or an answer would be greatly appreciated.
The Apache Thrift TSocketTransport (almost certainly what you are using) uses TCP on a configurable port. Cassandra usually uses port 9160 for thrift. When using Thrift/TCP no HTTP setup is necessary. Just open 9160 (and any other ports your custom thrift servers may be listening on).
Though you can use Thrift over HTTP, Thrift is RPC, not REST, so proxy caching will cause problems, the client needs a direct comm channel with the server.
If you do need to access a thrift service via a proxy, something like this would work:
https://github.com/totally/thrift_goodies/blob/master/transport.py
You can kill the kerberos stuff if you don't need that.
A JDBC driver implementation provides the low level details that allows a client to communicate with a third party datababase. I am just curious what it is doing behind the scenes. Communication between two systems written in different languages usually happens through web services.
Does the jdbc driver use web services to communicate between the client and the db server? Or am i oversimplifying?
People who write JDBC drivers have several options to choose from:
Type 1 driver: Use the generic JDBC-ODBC bridge, don't actually make a driver.
Type 2: Make a "wrapper" that uses JNI to call functions in a native client library.
Type 3: A generic driver that connects to a "middleware" service that talks with the database.
Type 4: a pure-Java implementation of the database communication protocol.
A type 3 driver might use web services to talk with the middleware. The other types of driver most likely communicate in a database-specific binary protocol over TCP/IP sockets (if the database is on a remote host) or other suitable reliable transport, not through web services.
You should check this link as this shows you how JDBC works.
Now coming to your question : No JDBC do not use web services. The way it connects to different types of databases is due to the database vendors because different database vendors provide their own driver implementation and you just need to use that implementation. There's nothing like web services. Each database vendor provides you with some api of their own to access database which they map to the Java's api to access database which is generic.
Java is provides a generic api for database operations which ultimately does operations and communication with database using sockets.
So what you need to read is TCP/IP , Socket programming, IO and JDBC. Please don't forget to check the link it will surely help you understand the concept.
I would like to use thrift with a Java server sending data to a browser using websockets. Is this possible?
According to this issue: https://issues.apache.org/jira/browse/THRIFT-2355 Thrift recieved support for web sockets in the javascript compiler for version 0.9.2.
In thrift there are 2 important things: protocol, and transport. Protocol defines how is data serialized into the data stream. And transport defines how are those streams of data exchanged between communicating entites.
There is json protocol in thrift which is supported by javascript, but as far as transports go I think Thrift supports only 2 transports raw tcp, and http. Later can be used to invoke operation on a HTTP server, and fetch the result from it, but not the other way around as you need it.
I guess you might be able to use json protocol, but you would need to roll your sleeves up and implement your own websockets transport. This could be a a non trivial task.
As of v.0.9.0 of Thrift, the answer is no.
On the client side, the javascript generated uses AJAX for it's transport as seen in Thirft.js library, so if a client was to use a WebSocket, then transport in Thrift needs modified.
On the server side, the Java code shows a socket server, but I believe it doesn't have the handshaking needed for the WebSocket server side code. Again, probably be added somewhat easily. It probably makes more sense for you to use jWebSocket as your server and the Java object classes created by thrift than the Thrift version of the server. You can inspect the code to know it better in Thrift. see /lib/java/src/org/apache/thrift/ section of the trunk in Thrift.
I have a local server outputting my real-time home sensor data, and I want to visualize it in my browser.
My question is, can I use a websocket to open the connection from my browser to the local server? How would I go about doing that?
The local server runs on a non-http designated port number, and I can't change that.
Yes and no.
No:
WebSockets are not raw TCP connections. They have an HTTP compatible handshake (for both security and compatibility with existing servers) and have some minimal framing for each packet to make WebSockets a message based protocol. Also, the current WebSocket API and protocol that exists in browsers as of today do not directly support binary data messages. They only UTF-8 encoded payloads.
Yes:
You can use websockify to proxy a WebSockets connection to a raw binary TCP server. websockify is a python proxy/bridge that has binary support and also includes a javascript library to make interacting with it easier. In addition, websockify includes the web-socket-js fallback/polyfill (implemented in Flash) for browser that do not have native WebSockets support. The downside is that you have to run websockify somewhere (either on the client system, the server system, or some other system). Also, websockify is Linux/UNIX only for now. On the plus side, websockify has a special mode that you can use to launch and wrap an existing service.
Disclaimer: I made websockify.