NetKernel News Volume 3 Issue 31

July 13th 2012

What's new this week?

• Repository Updates
• SimpleDynamicImportHook Maximum Version Import
• On Extrinsic Constraint
• NKEE Cache Cost Threshold - Default to Zero

Catch up on last week's news here

Repository Updates

There are no repository updates this week.

SimpleDynamicImportHook Maximum Version Import

We're still testing the pending kernel and layer1 updates we discussed last week - so far so good. In the mean time we've taken the chance to introduce a small safety constraint to the SimpleDynamicImportDiscovery (SDID) endpoint.

You'll be aware that the pattern used by the SDID is to search all spaces for a "marker resource" with the identifier res:/etc/system/SimpleDynamicImportHook.xml. If the hook is present (and it contains the correctly named hook token) then the space is added to the list of those to be imported.

The list of discovered spaces is then used as the resource specifying what the true DynamicImport (DI) endpoint should import. The SDID and DI work together as a matched pair using the resource address space to provide the contextual logical coupling.

Max Version Change

The DI is an unconstrained endpoint, by which we mean it will import any space that it is told to.

However, it recently came to light that, given the new ability for modules to be discovered and loaded through the etc/modules.d/ path, it is now potentially a little too easy (perhaps by accident or neglect) to have multiple generations of modules deployed simultaneously.

Now NK doesn't mind having different generations of spaces deployed - since legacy can co-exist. But what happens if two (or more) generations of a space all have the same dynamic import hook? Answer: they all get imported and there can be no guarantee of the order of which generation will acquire resolution precedence.

Clearly this is not ideal since if you were to accidentally deploy several versions of your application you're potentially going to see ambiguous behaviour. Even worse, from a system perspective, if you were to have several generations of the NK system modules you might end up with a bust system altogether.

Therefore to limit any potential for accidental overlaps, we've introduced a constraint to the SDID such that it will now only search for and discover the highest versioned space with a hook. This is in effect replicating the pattern used by the regular import endpoint when no version limits are specified. So now the SDID can only present a normalized "most recent" list of import spaces to the DI endpoint.

This change makes absolutely no difference to the operation of a regular system without repeat copies of spaces (modules) but will potentially save confusion and inconsistency should you accidentally end-up with more than one copy of your modules deployed.

Since, we've still not shipped the kernel, and layer1 has the active:java updates pending from last week, we've provided the SDID update for manual install again in this preview layer1 jar...

• urn.org.netkernel.ext.layer1-1.41.26-preview.jar

(For details how to manually deploy this jar see last week)

Please take the time to give this a go and let us know how you get on.

On Extrinsic Constraint

The change to the SDID outlined above is an example of how ROC allows for extrinsic constraint. The DynamicImport endpoint remains unconstrained - since it is conceivable that importing multiple similar spaces may be a pattern that is required - and it would be wrong and would complicate the implementation of the DI endpoint to have it be hard-coded with a constraint model.

Much better to apply the constraint to the set of resources that drive the endpoint - that is, the list of target spaces which is generated by the SDID tool. Since in this case, the constraint is extrinsic to the DI and offers a "limitation by convention" that adds some safety to the default system behaviour, but which does not limit the potential of the overall system to do more sophisticated patterns if that is required.

I call this is an extrinsic constraint since it is a federated constraint with no central authority. Indeed a core tenet of the ROC abstraction is to be decentralised and federated - command and control architectures are innately brittle and cannot be evolved or scaled.

NKEE Cache Cost Threshold - Default to Zero

One of the performance tuning capabilities we added in NKEE 5.1.1 is the ability for NK to automatically determine a minimum computational cost for a representation below which it may not make sense to cache the state. To date, the NKEE download would work this out after install based upon the physical capability of the deployed platform.

However, whilst this is potentially a valuable production-time optimisation, it can cause confusion at development time where something you thought ought to cache was in fact too cheap to clear the system-determined threshold.

Therefore, to eliminate this development-time ambiguity we've changed the default out-of-the-box configuration to have zero for the threshold - ie to never try to second guess the cacheable value but to always just cache things no matter how cheap.

If you download a copy of NKEE this is now the default. If you're already using an NKEE installation you can set your cache threshold to zero manually with the http://localhost:1060/tools/kernelconfig tool like this...

Its probably a good idea to do this for development but when you move out of development into stage, test and production you are still able to try setting this threshold to decide if, as a tuning factor, it provides you with systemic benefit for your application.