Re: Entries, ServiceTemplates, and JavaSpaces

> We do have a base Entry class with some always-present values. From
> there, though, it's possible for the user to configure the build
> master with entries that don't have corresponding build agents. These
> build requests should languish and eventually get cleaned up (would
> love to use http://autot.jini.org to boot a new machine with the
> correct features--that'd be awesome) and logged as unbuildable. The
> agents should usually have many properties describing their features
> (e.g. "os.name=Windows XP", "fixpack=1.1", "service.pack=SP2"), most
> of which won't matter for most builds. (For instance, most of the time
> with our Java projects we don't care if they are built on Linux or
> Windows.) So, in summary, the build master's property requirements
> MUST be met and the agent must not have any conflicting properties.
> With the entries of service registration this worked fine.
>
> Incidentally, I don't think I made clear that the point of the whole
> project is to run unit tests every time a change is committed to CVS.
> CruiseControl currently can't distribute its builds and subsequent
> unit tests, so if CVS has been busy there could potentially be enough
> simultaneous builds going on to dog the build machine. We hope to be
> able to distribute the work and accumulate the results on the build
> master.
>
> Hope that at least clears up our use-case!

Going off at a tangent for a moment,a lot of this environment
suitability stuff could be done using Neon. Essentially the master
node could attach to agents running on other nodes and call methods on
the agents that are spread across the network.

There are a couple of possibilities for dynamic properties - one a
hashmap asa field in your entry where the keys are recognised by the
masters, or add a reference to something like a configuration file,
that can be parsed and evaluated by the worker. As an issue, you have
to deal with the case that no worker on your network fits your
requirements and thus the entry may remain in the space

From what it looks from your use cases, you want to use some form of
asynchronous request-reply, using ID's in the entries to re-establish
context in your master, when a reply from your workers arrive. Is the
order important - for instance if two changes are placed into CVS for
the same file, is it important to get back the test result for the
first CVS change, prior to getting the result for the second change?

--Calum

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/