DDevelopment & Design

HAProxy load balancing with sticky sessions based on request body

Integrating systems you have no influence on needs a lot of workarounds. Recently we could not scale Python service consuming SOAP messages with a new hardware. It just didn’t benefit from more processing cores. On the other hand (and this happens often with older software) setting up several instances gave almost linear scalability. Only thing left – configure a loadbalancer and we are done.

Easier said than done. We had to make sure messages are loadbalanced but also that all messages related to given customer USSD conversation always hit the same backend service. So, we had to use application layer information to configure sticky sessions. This is not straightforward in HAProxy when you have to look into http payload and parse some specific information. We used HAProxy 1.6 and simple LUA script to do just that:

core.Alert("LUA script parsing SOAP element loaded");

function parseElement(txn, salt)

    local payload = txn.req:dup()

    -- parses integer value from element named "element"
    local value = string.match(string.match(payload, "element>%d+<"), "%d+")
    core.Info("value: " .. value)
    return value
end

-- register HAProxy "fetch"
core.register_fetches("parseElement", parseElement)

Put this script into a file and it can be loaded in HAProxy configuration using lua-load directive.

Script registers new HAProxy fetch which can be used to configure session stickiness.

balance roundrobin
stick-table type string size 30k expire 30m
stick on "lua.parseElement" table nodes

You have to also make sure all payload is loaded before you start parsing it. This can be achieved with option http-buffer-request configuration directive.

— Previous article

Formatting Java Time with Spring Boot using JSON

Next article —

Sputnik lands on GitHub!

You May Also Like
DDevelopment & Design

Inconsistent Dependency Injection to domains with Grails

I've encountered strange behavior with a domain class in my project: services that should be injected were null. I've became suspicious as why is that? Services are injected properly in other domain classes so why this one is different?

Constructors experiment

I've created an experiment. I've created empty LibraryService that should be injected and Book domain class like this:

class Book {
    def libraryService

    String author
    String title
    int pageCount

    Book() {
        println("Finished constructor Book()")
    }

    Book(String author) {
        this()
        this.@author = author
        println("Finished constructor Book(String author)")
    }

    Book(String author, String title) {
        super()
        this.@author = author
        this.@title = title
        println("Finished constructor Book(String author, String title)")
    }

    Book(String author, String title, int pageCount) {
        this.@author = author
        this.@title = title
        this.@pageCount = pageCount
        println("Finished constructor Book(String author, String title, int pageCount)")
    }

    void logInjectedService() {
        println("    Service libraryService is injected? -> $libraryService")
    }
}
class LibraryService {
    def serviceMethod() {
    }
}

Book has 4 explicit constructors. I want to check which constructor is injecting dependecies. This is my method that constructs Book objects and I called it in controller: 

class BookController {
    def index() {
        constructAndExamineBooks()
    }

    static constructAndExamineBooks() {
        println("Started constructAndExamineBooks")
        Book book1 = new Book().logInjectedService()
        Book book2 = new Book("foo").logInjectedService()
        Book book3 = new Book("foo", 'bar').logInjectedService()
        Book book4 = new Book("foo", 'bar', 100).logInjectedService()
        Book book5 = new Book(author: "foo", title: 'bar')
        println("Finished constructor Book(Map params)")
        book5.logInjectedService()
    }
}

Analysis

Output looks like this:

Started constructAndExamineBooks
Finished constructor Book()
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
Finished constructor Book()
Finished constructor Book(String author)
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
Finished constructor Book(String author, String title)
    Service libraryService is injected? -> null
Finished constructor Book(String author, String title, int pageCount)
    Service libraryService is injected? -> null
Finished constructor Book()
Finished constructor Book(Map params)
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2

What do we see?

  1. ✔

    Empty constructor injects dependencies.

  2. ✔

    Constructor that invokes empty constructor explicitly injects dependencies.

  3. ✘

    Constructor that invokes parent's constructor explicitly does not inject dependencies.

  4. ✘

    Constructor without any explicit call declared does not call empty constructor thus it does not inject dependencies.

  5. ✔

    Constructor provied by Grails with a map as a parameter invokes empty constructor and injects dependencies.

Conclusion

Always explicitily invoke empty constructor in your Grail domain classes to ensure Dependency Injection! I didn't know until today either!