Quote:Original post by abdulla
Actually I wrote 2 different RPC libraries, one that does block but uses tricks to reduce latency, the other that attempts to be completely asynchronous. Message passing is great, but it doesn't give the type-safety or convenience of RPC.
Type-safety? I don't believe that is even remotely an issue with message passing unless you're using C. If anything, with support from annotations (or whatever mechanism managed languages provide) it can be not only type-safe, but also implemented safely with regard to system security.
RPC works and is used, and even provided under any managed platform by default.
My experience with pure RPC based applications however has shown that they don't scale elegantly. As long as the system is under-utilized, assuming network transparency will work. Even more if co-location is used with half-sync-half-async model.
When dealing with hundreds of remote real-time entities however, blocking mandated by RPC model becomes a bottle-neck (even with futures). The problem of waiting for responses over network becomes so big, that actions begin to timeout, simply due to accumulation of delays caused by round-trip latency.
The biggest problem however are (un)expected increases in load, such as those caused by network hick-ups or application startup/shutdown, which cause cascading failures. (Several thousand remote entities, all shared over network using synchronous RPC using reactor dispatching)
But again, it depends on the type of application. For web protocols, thread-per-client will often be adequate. In almost all cases, the bottle-neck will lie in infrastructure behind the system (for web server it will be file-system, for web applications the database). The cost of request handling in this case is negligible.
Part of problem here (Java-specific) is lack of alternatives for those libraries. Database access is painfully thread-per-request oriented, file system access doesn't support non-blocking or even async access (except as emulated by threads).
Using non-blocking database access for example allows a single-thread to handle up to actual database capacity without pegging the CPU (or the bottle-neck will be DB queries), even in case of thousands of outstanding queries (again, as allowed by database itself).
What I'm trying to say is that RPC has been studied and implementation strategies have been documented extensively, perhaps by far most by the ACE/TAO. Unfortunately, Java is simply malnourished in some aspects (sound and multimedia, much of networking, certain memory management aspects), which may indeed result in certain solutions unexpectedly seeming better. But this remains a Java-specific topic.
What I'm trying to say is simply that I've found when it comes to scalability it needs to be studied on case-per-case basis. There are several competing techniques, some generally better than others, but often system isn't pushed hard enough for these distinctions to matter.