Hi Sebastian,
the "intelligent routing" of Hot Rod being one of - if not the main - reason to use Hot Rod, I wonder if we shouldn't rather suggest people to stick with HTTP (REST) in such architectures.
Several people have suggested in the past the need to have an HTTP smart load balancer which would be able to route the external REST requests to the right node. Essentially have people use REST over the wider network, up to reaching the Infinispan cluster where the service endpoint (the load balancer) can convert them to optimised Hot Rod calls, or just leave them in the same format but routing them with the same intelligence to the right nodes.
I realise my proposal requires some work on several fronts, at very least we would need:
- feature parity Hot Rod / REST so that people can actually use it
- a REST load balancer
But I think the output of such a direction would be far more reusable, as both these points are high on the wish list anyway.
Not least having a "REST load balancer" would allow to deploy Infinispan as an HTTP cache; just honouring the HTTP caching protocols and existing standards would allow people to use any client to their liking, without us having to maintain Hot Rod clients and support it on many exotic platforms - we would still have Hot Rod clients but we'd be able to pick a smaller set of strategical platforms (e.g. Windows doesn't have to be in that list).
Such a load balancer could be written in Java (recent WildFly versions are able to do this efficiently) or it could be written in another language, all it takes is to integrate an Hot Rod client - or just the intelligence of it- as an extension into an existing load balancer of our choice.
Allow me a bit more nit-picking on your benchmarks ;)
As you pointed out yourself there are several flaws in your setup: "didn't tune", "running in a VM", "benchmarked on a mac mini", ...if you know it's a flawed setup I'd rather not publish figures, especially not suggest to make decisions based on such results.
At this level of design need to focus on getting the architecture right; it should be self-speaking that your proposal of actually using intelligent routing in some way should be better than not using it. Once we'll have an agreement on a sound architecture, then we'll be able to make the implementation efficient.
Thanks,
Sanne