Blitz JavaSpaces FAQ

  1. My Entries are expired, why is the dashboard still showing active instances?
  2. Dashboard is showing inaccurate/negative instance counts - whats wrong?
  3. I'm getting OutOfMemoryErrors, what should I do?
  4. What about all those configuration variables?
  5. Can I View the Entry's in a Blitz JavaSpace?
  6. Where is the documentation for FIFO?
  7. How can I empty a Blitz instance?
  8. Dashboard can't discover Blitz - what's wrong?

My Entries are expired, why is the dashboard still showing active instances?

This is normal behaviour. Unless active lease reaping is enabled (see the install guide for your particular distribution) Blitz will only lazily delete expired Entry's and update statistics. Even when active lease reaping is enabled the stats can still be out of date though they will be at their most accurate just after Blitz has performed an active reap.


Dashboard is showing a negative instance count - whats wrong?

Nothing....

The dashboard provides only an approximation of the current state of the Blitz engine. Forcing the statistics to be 100% accurate would impact performance significantly and cannot be guarenteed in various circumstances (in particular in respect of lease cleanup).

Statistics are generated concurrently alongside all other activity and can, for example, include counts derived from a partially committed transaction (that is, one that is in the process of being committed).


I'm getting OutOfMemoryErrors, what should I do?

First, check for pathalogical application behaviours via the dashboard:

  1. Check that active transactions is not continuously growing. If it is and the application uses transactions, make sure they're being committed/aborted under all circumstances including errors. If transactions are not used and you're using the contents() method ensure that you are explicitly releasing the Lease object associated with the MatchSet.
  2. Check that instance counts are tracking appropriately for the application. If there should be a relatively stable pool of Entry instances it's likely the application is attempting to take with an incorrect/non-matching template.

If there are no pathalogical behaviours identified, likely the configuration needs tweaking for load and resources, read these for background:

Blitz uses it's cache to hold both live and dead (taken or lease expired) Entry's. It only clears it's cache once it is full.

i.e. If you set the cache size to 100 and you have only five entry's with one writer and one taker, Blitz will have a cache containing 5 live entries and 95 dead ones after things have run for a while.

Each type of Entry is given it's own cache (there isn't one shared cache). So approximate total memory usage (to get an accurate figure would require estimating garbage requirements etc) is:

memory = 0;
for (X in all Entry types) {
memory = memory + (cache_size * size_of X)
}

memory = memory + Db database cache size

Where Db database cache size is specified in the configuration file under dbCache

Thus in OutOfMemory situations, the correct approach is to reduce entry cache size or the db cache or increase available JVM heap or a combination of the three. Note that in the case of a persistent Blitz, you should also consider enabling log file serialization stream reset by setting the first boolean parameter to the Persistent class constructor (defined as the storageModel in the configuration file) to true.

Note that there is a tool (EntrySizer) in the Blitz distribution (see Extensions in the documentation for your chosen version) which can be used to compute the approximate size of an Entry as it will be stored in Blitz's cache.

Note also that you can specify individual cache sizes per Entry type using EntryConstraint examples of which can be found in the configuration files. A good basic approach to using these constraints would be to set entryReposCacheSize to something small like 256 or 512 and then use the EntryConstraints to allocate bigger caches (e.g. 1024, 4096) to specific Entry types.

In cases where you are submitting Blitz to high load for sustained periods of time and the CPU usage is close to 100%, consider enabling throttling to prevent overflow of internal queues. See eventQueueBound and taskQueueBound in the Installation Guide for your chosen distribution.


What about all those configuration variables?

For most situations, the out of the box configurations should be fine. When that's not the case first check the relevant installation guide for your Blitz JavaSpaces Edition which contains details of configuration variables in Appendix B:


Can I View the Entry's in a Blitz JavaSpace?

Yes, as of Pure Java version 1.06 there is support for com.sun.jini.outrigger.JavaSpaceAdmin which will allow any appropriate Service Browser (e.g. the community edition from Inca X) to view and manipulate the Entry's held within a Blitz instance.

If you still have questions, subscribe to the users list and post questions there or submit a support request.


Where is the documentation for FIFO?

The documentation regarding FIFO can be found in the Extensions section under the Documentation link for the relevant Edition.


How can I empty a Blitz instance?

One can do this trivially by performing a repeating take() until null is returned. However, there is a tool already provided, see the tools section of the documentation here.


Dashboard can't discover Blitz - what's wrong?

Ensure that multicast is correctly enabled on appropriate network interfaces. For linux use ifconfig -a to list the available network interfaces and ensure that MULTICAST is present e.g.:

lo: UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1
To enable multicast on an interface:
ifconfig lo multicast
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo