river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject Re: Real Time Java
Date Wed, 24 Feb 2010 08:52:45 GMT
Peter Firmstone wrote:
> Nope be interesting to see though, if it exists.  GCJ 4.0 compiles to 
> native code.  Not sure how to do dynamic class loading for service proxy's.

It will be fed to the interpreter.

> I'm looking at Sun's RTSJ and Embedded Industrial x86 at the moment. My 
> guess is that Oracle wont open it, even though Sun originally intended 
> to.  Java looks ideal for embedded.  Although at this stage I have no 
> intent of utilising Jini on real time threads.

I can imagine. I found it particularly a stress-reducer that the main 
control loop was done by a PLC. I cannot imagine that a customer would 
accept a solution without. The marriage of a PLC and a non-cyclic 
controller is a scenario i like. But a Java system for monitoring, 
datamining, recipe loading etc, would be perfect. The PLC-CPU combo 
could provide for reading the datapoints in the PLC memory via an Java 
API and the datapoints be exposed in the registry.

Still realtime java would be a benefit. Altough all data should be 
timestamped, the datarates can be such that starvation could be a real 
problem.

> Jini Services and clients wouldn't need to be run on real time threads 
> unless they were part of real time software implementations.  For 
> classes on real time threads (RTSJ) , there is an initialisation stage 
> where all bytecodes for class files will be pre compiled to avoid 
> hotspot, so a service could potentially run on a real time thread.  
> Simple proxy's could be pre compiled in the initialisation stage,  
> limiting the client to the services determined at initialisation.

It all revolves about the moment of compilation. Either at deployment 
(GCJ), start, verifier (classloader) or runtime. I think sensors will go 
for early instead of late compilation (maybe even interpreted). You 
could state, if the sensor has idle time in which it can do background 
compilation, the sensor has been too expensive.

> A person might rightly suggest the 8 fallacy's of distributed computing 
> as being a problem.  One would tackle this by providing a time guarantee 
> for service discovery.  So in a redundant network topology utilising 
> EtherCAT, one could have realtime services and simple proxy clients pre 
> determined at initialisation time,  the service would actually form part 
> of the redundancy system, upon catching an exception, the lookup service 
> would provide the location of an alternate service, utilised in 
> instances where redundant sensors or functions were in place, made 

But, that would mean a departure from 'let the client decide' isn't it? 
The registry provides all redundant sensors in one query (if i had the 
benefit of redundant sensors, i would read them both all the time, and 
provide a conflict resolution strategy, but still record both of the 
separate).

> available through Jini services.  The real time service might remove its 
> entry from lookup once it has reached a load level that limits the real 
> time guarantees.  There are a number of time guarantees that need to be 
> considered, such as network latency (according to the doc's EtherCAT has 
> low latency, distance and load are limiting factors) and Service load.

Thats a particular nice thought, but if a service cannot comply with its 
realtime constraints, how can we make sure it has the capacity to remove 
itself?

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397

Mime
View raw message