Regularly Expressed

As my colleague Patrick mentioned in our previous post, we at Oversee’s Retail Group have been using RabbitMQ as the communication layer for the remote procedure calls done from the UI (written in Python) to the backend (written in Java). In Patrick’s post, he described his homegrown Python framework, Chu, for quickly and easily creating RPC clients within Tornado. This post is all about the Java framework, Roger, for creating stand-alone RPC servers.

Our legacy website backends used Java Servlets to send JSON-formatted RPC responses to the Python UI. While we may have moved away from using Servlets and HTTP (mainly for load-balancing reasons as detailed in the previous post), we have always been happy with JSON as a data serialization format. If you’re writing Java, the Jackson JSON library is currently the uncontested choice for parsing & creating JSON. Add on the Jackson Mapper, and you can write all of your code using Plain-Old-Java-Objects, while barely aware of the fact that JSON serialization & deserialization is happening automatically. So, Roger uses Jackson’s ObjectMapper for all of its message serialization & deserialization. And if you want more fine grained control over how your Java Objects turn into JSON, you can add JacksonAnnotations to your request & response objects.

[Read more...]

Since the beginning of time, ShopWiki has split its architecture into a backend (“The API”) written in Java and a frontend (“The UI”) written in Python. The two communicated over HTTP; the UI would make a blocking request to the API and a servlet class would serve up a JSON response. A load balancer sat between the UI and the API and round robined requests to the appropriate servers. Unfortunately, not all of these RPCs were created equally. Some took significantly longer than others, and spurious timeouts were a possibility due to overloading a single server. The only solution was to add more API servers to the pool to lower the probability of such an event happening.

About two years ago, we began work on several new sites. The basic paradigm was the same: the UI was written in Python (now using a Tornado stack) and the backend API was written in Java. But we decided to change our messaging layer to something that could support a worker/consumer model rather than a blindly round-robined worker/receiver model. We chose to use RabbitMQ, and it has served us well. On the Rabbit server, permanent, named queues are constructed for each RPC type. API servers register themselves as workers willing to handle requests, and each server consumes requests at whatever rate it can. The load balancing is implicit in the model. It also comes with numerous other benefits: easy division and testing of staging environments using routing keys, eventing for cache invalidation and other small one-off tasks, highly granular realtime logging with configurable error levels, and more. But the benefits of the messaging layer as a whole are not what this post is about. This post is about Chu.

[Read more...]