Pragmatic Dictator

I’m currently working on getting 2.0-alpha3 out the door which means all the usual release procedures and in particular a lot of thumb-twiddling whilst various tests run. People often ask about the testing that goes into a Blitz release and so, given that I’m suffering from test-induced thumb-twiddling it seems like this would be a good time to write something down.

Blitz is basically a layered Jini service with remote wrappers cleanly separated from the core JavaSpace implementation. Thus we can thrash the core without needing to do a full remote deployment which provides many benefits such as eliminating a lot of network I/O that can hide race conditions and deadlocks.

My test machine is a dual processor dual core machine (2 x 2.6Ghz Xeons with HyperThreading, 2Gb, 2x70Gb SCSI Disks) and it’s main duties are to run the long term soak tests for long periods of time (unit tests get run as part of day-to-day development on my PowerMac Dual G5). There are two basic types of soak test that get run regularly they are:

1. TxnStress – a multi-threaded test which fills a Blitz instance with a fixed number of entry’s and then randomly takes and re-writes one of those Entry’s with each take/write pair done under a separate transaction.
2. Stream – a multi-threaded test which writes a sequence of Entry’s into Blitz whilst another thread takes them. Writers and Takers are run in pairs up to a configured number.

Whilst these tests run I typically have jconsole hooked up plotting memory consumption so leaks can be detected and fixed. In addition, Blitz’s in-built statistics API is used to check queue sizes, number of entry’s etc (this is the same API used by the remote dashboard). Finally, each test has code that ensures we are not leaking Entry’s or missing them. Blitz also has a debug-mode where one can simply connect to a pre-configured socket and trigger the dumping of statistics to the console at any time.

These tests get run against Blitz in both transient and persistent mode (which is a mere flip of a configuration variable).

Stream is just about done, so I’ll be shipping a release to SourceForge shortly.

Technorati Tags: javaSpaces, jini, Blitz

Okay, so Patrick has laid down the gauntlet and I’m of a mind to pick it up but there’s a sticking point which is that I must earn a living. I simply can’t dedicate time to work on Jini documentation, books etc for free and it seems no-one else is willing to either. So, inspired by a tongue-in-cheek comment from Cameron and some other conversations, I have a tentative, likely insane proposition for feedback/consideration:

I’m thinking about something I’ll call “micro-consulting”. Normally people pay me by the day or the week to complete some agreed upon set of work products. What if I were to offer my time via the web an hour at a time to write documentation or code tackling some aspect of Jini usage? What if the entity paying for the hour of my time got to dictate or choose the subject I focused on? Perhaps the way to do this is to get together a list of possible projects, after which I would provide a “quote” for the work and then have people place sufficient “bids” against a piece of work to cover my quote. Whichever piece of work met it’s quote first would be the next piece of work I’d pickup.

Just a thought……..

Yep, there is a specification for JavaSpace bulk operations but it’s clear from recent discussions it’s still not well known. It was released in Jini 2.1 and provides:

1. Bulk write
2. Bulk take
3. Bulk read
4. New notify method

Bulk take and write are straightforward, bulk read less so because due to the nature of reads it has to provide a streaming style of interface. And the new notify method allows you to get a copy of the Entry which triggered the event but also provides facilities for Entry’s becoming available/visible again as the result of transaction aborts etc.

The JavaDoc for JavaSpace05 is here.

Technorati Tags: distributed systems, jini, javaSpaces, technology

Been playing around with REST based systems and http etc recently. Also been pondering how to best make use of web technologies in distributed systems and this popped up on JINI-USERS a while back.

So, the challenge was clear – I wanted to:

1. Expose Jini Services behind a firewall to users outside
2. Build a solution that was web friendly – i.e. used webservers etc
3. Have selective publishing – not all Jini services should be exposed outside the firewall
4. Provide service lookup methods similar to those one uses inside the firewall

Thus, after 4 days of hacking, Sabot is born. An alpha-grade appliance which provides all these abilities to clients outside of a firewall and it’s all done via a webserver on whatever port and http. Codebases are handled correctly so code-downloading is possible. There’s nothing needs to be done to the Jini Service configuration or code, no special magic opening ports on the firewall etc. You should even be able to do forwarding type setups where you have a front-end web-server like Apache forward requests over to Sabot for servicing.

Next up is to release it to a few eager testers and then productization.

Been meaning to tackle this subject for a while. With a hectic week of coding behind me, a day focused on communication ahead and a number of google queries hitting my blog/site on this subject, it seems like it’s time to do this.

Right so it’s often said that JavaSpaces are all about flows of objects hence the API being the way it is. What does this actually mean in real terms?

1. Most objects in the space are transient – that is they temporarily reside in the space before heading elsewhere.
2. Some objects remain in the space forever because they represent “bootstrap state” for clients.

As an aside, it’s worth noting at this stage that leases are orthogonal to the above classification. Bootstrap state might need refreshing or become stale in which case, having old state clean itself up automatically is helpful. Temporary state is to be used by some operation somewhere and that may need to be timed out in which case, again it’s useful if the state automatically cleans itself up.

Right, so what’s in a JavaSpace at any particular time? It’s a snapshot of a set of conversations between multiple senders and recipients. Each conversation is going to have a small amount of state and it’s only relevant to a conversation for a short period of time because the conversation will naturally move on to other things. This material then, isn’t really query’able there’s not much structure around, not even much data. This is in marked contrast to an RDBMS which tends to contain everything and the kitchen sink. When you store everything you need a good mechanism for locating the things of interest – an advanced query language, when you store only a little, locating things is much easier and the querying that much simpler, JavaSpaces simple one might say.

Now, there is a class of application that doesn’t fit this description and does indeed have the JavaSpace holding a lot of state. It’s typically a form of the blackboard pattern, caching or some other form of shared state. Now, caching tends to be performed on entities with unique keys and thus fits cleanly with the JavaSpaces API. Other forms of shared state don’t fit so well – why is this?

If we go back to LINDA, we see that the tuplespace concept was conceived as a tool for simplifying concurrent access to state within what was a single SMP machine (which might be somewhat distributed in the form of a hypercube or a NUMA system, anyone remember transputers?). There was no concept of remoteness present in this concept. When you add remoteness to LINDA you get JavaSpaces or something similar (tuplespaces plus leases, new kinds of exception and in some cases, code movement). And it’s this addition of remoteness that makes these other forms of shared state difficult (though not impossible) to handle. Typically because the amount of state is large but for network efficiency we want to transfer only a little of it which forces us down the route of granular data representations and query languages – sounds like RDBMS?

So, does that mean we can’t use JavaSpaces to handle shared state type problems? No but if you try and solve this problem entirely within the JavaSpace you’re making a mistake because whilst they’re great for solving some parts of this problem, they aren’t good for other aspects.

In summary, databases handle large amounts of shared state and provide query languages to assist with state location and updating. They don’t provide tools for remote co-ordination – this is the domain of the JavaSpace and it becomes supremely powerful once you mix in the simple concurrency model and the ability to move code and have it be secured along with the data. There is some crossover between these two technologies but they’re going in very different directions. Which suits your problem is determined by whch direction is closer to that of your system.