Tracking XPRISO Messages

XPRISO is the messaging protocol used by InfoGrid to keep distributed information consistent. The acronym stands for “eXtensible Protocol for the Replication, Integration and Synchronization of distributed Objects”.

The current version of InfoGrid uses XPRISO mostly for communication between an application’s main NetMeshBase, and the ShadowMeshBases that track (“shadow”) external data feeds.

Sometimes it is really useful to track XPRISO messages.The simplest way o track all XPRISO messages in your application is this:

  1. Determine the classes that your application instantiates that implement the NetMeshBases communicating via XPRISO. For example, that might be and org.infogrid.probe.shadow.m.MShadowMeshBase, or perhaps and
  2. Set their logging level to INFO.

This might be as simple as adding the following two lines to your file:

Voilá, all XPRISO messages are written to your logger. (Some detail is omitted to make the log readable.)

Here is an actual example:

INFO  2009-10-12 15:32:14,992 [pool-1-thread-1] (
 @ org.infogrid.util.logging.log4j.Log4jLog.logInfo:152
    route: http://localhost:8085/app1/ -> http://localhost:8085/app2/, requestId: 1255386734969

INFO  2009-10-12 15:32:15,018 [pool-1-thread-2] (
@ org.infogrid.util.logging.log4j.Log4jLog.logInfo:152
    route: http://localhost:8085/app2/ -> http://localhost:8085/app1/, responseId: 1255386734969
        id: http://localhost:8085/app2/

Here, the first NetMeshBase asked the second for an object, and promptly got a replica in return.

If you don’t like the logging format, or want to log them differently, you can use your own XprisoMessageLogger simply by invoking setXprisoMessageLogger on the NetMeshBase whose messages you like to track.

The NoSQL Business and Use Cases

My question about the most important business and use cases for NoSQL technologies on the NoSQL mailing list sparked an interesting discussion. There appears to be widespread agreement on the following three high-level use/business cases:

  1. The amount of data, or bandwidth, required by an application is so massive that a massively distributed architecture is needed.
    This is the original use case for systems such as Google’s BigTable built to index the internet.
  2. The query load or query complexity is too large to be handled by relational “joins”.
    Digg explained this very well as their reason to move to a NoSQL architecture.
  3. The gap between the physical relational data structures required by a SQL database and an application’s schema complexity and flexibility requirements is too large.
    This encompasses the entire range from needing very loose, weakly typed storage to needing very expressive, strongly typed systems (e.g. graph databases with explicit object models).

Each of these of course is a big category, and more detail can be added. But it is good to see that the community seems to be able to agree on the top-three. It should also put to rest the argument that “NoSQL is not needed”.