Posts

Showing posts from 2018

Asynchronous Operation Execution with Netty on Redis

Netty got my attention a while back and I just wanted to play a bit around with it. Given the fact that I am already fallen in love with Redis, what would be more fun than implementing a low level client for Redis based on Netty? Let's begin to answer the question "What the hell is Netty?". Netty is an asynchronous (Java based) event-driven network application framework. It is helping you to develop high performance protocol servers and clients. We are obviously more interested in the client part here, meaning that this article is focusing on how to interact with a Redis Server. Netty is already coming with RESP  support. The package 'io.netty.handler.codec.redis' contains several Redis message formats: RedisMessage : A general Redis message ArrayRedisMessages : An implementation of the RESP Array message SimpleRedisStringMessage : An implementation of a RESP Simple String message ... So all we need to do is to: Boostrap a channel : A channel is

Data Encryption at Rest

Data security and protection is currently a hot topic. It seems that we reached the point when the pendulum is swinging back again. After years of voluntary openness by sharing personal information freely with social networks, people are getting more and more concerned about how their personal data is used in order to profile or influence them. Social network vendors are getting currently bad press, but maybe we should ask ourself the fair question "Didn't we know all the time that their services are not for free and that we are paying them with our data?". Maybe not strictly related to prominent (so called) 'data scandals' but at least following the movement of the pendulum is the new European GDPR regulation around data protection. Even if I think that it tends to 'overshoot the mark' (as we would say in German) and leaves data controllers and processors sometimes in the dark (unexpected rhyme ...), it is a good reason for me address some security topics

To PubSub or not to PubSub, that is the question

Introduction   The PubSub pattern is quite simple: Publishers can publish messages to channels Subscribers of these channels are able to receive the messages from them There is no knowledge of the publisher about the functionality of any of the subscribers. So they are acting independently. The only thing which glues them together is a message within a channel. Here a very brief example with Redis: Open a session via 'redis-cli' and enter the following command in order to subscribe to a channel with the name 'public'  In another 'redis-cli' session enter the following command in order to publish the message 'Hello world' to the 'public' channel: The result in the first session is: BTW: It's also possible to subscribe to a bunch of channels by using patterns, e.g. `PSUBSCRIBE pub*`    Fire and Forget  If we would start additional subscribers after our experiment then they won't receive the previous message