[DEECo] design decisions for scheduler and DEECo "realm"

Tomas Bures bures at d3s.mff.cuni.cz
Sun Feb 15 18:36:44 CET 2015


Dear Ilias and all,

thank you. You are right, this point is not clear. I myself don't have 
good enough clarity about it because it is even a bit larger than 
described below. The main question is - what out of the scheduling is 
shared when running the simulation?

Further, I have some simplifications I would like to suggest, but that 
will be relevant only after we answer the question above. With that I 
would suggest not to go on with the classes DEECoRun and related 
interfaces and the interfaces around scheduler notifier. I believe a 
half of it can be dropped.

Let's discuss it tomorrow.

Thank you very much,
Tomas



On 14. 2. 2015 19:20, Ilias Gerostathopoulos wrote:
> Hi all,
>
> with Filip, we made a first iteration on the scheduler and the support 
> for "DEECo realm".
> After several discussions also with Michal and Vlada on Friday, we 
> decided to change the way a deeco run (or "simulation") is assembled 
> and started.
> The results are pushed to the "plugin-architecture" branch (still 
> several javadoc and tests missing...), also see the attached class 
> diagrams.
>
> The main idea is that a scheduler cannot be started anymore. Instead, 
> the "scheduler notifier" is started, ie it becomes the "active" 
> entity. This can be implemented either as a discrete event notifier, a 
> wall-time notifier, or an OMNET-based one.
>
> About "DEECo realm", this becomes a class that is
> (i) a factory for "DEECoNode"s (previously called just "DEECo", it is 
> basically the main deployable entity with its own runtime, runtime 
> model, components and ensembles)
> (ii) the main entry to start the application. Upon startup, it passes 
> the control to the scheduler notifier. The scheduler notifier has to 
> be created outside of the realm and injected through the realm's 
> constructor.
> We prepared 2 implementations of the realm, one for running deeco in 
> "real" deployment ("DEECoRun"), one for simulation runs 
> ("DEECoSimulation").
>
> We would like to ask your opinion on these changes before we go on to 
> finalize the classes and update the tests.
> Maybe we could have a short meeting on Monday about this. I won't be 
> available from 10:00 to 14:00 (2nd phase of the IRM experiment), but 
> any other time is OK for me.
>
> Thanks,
> Ilias
>
>
>
>
> _______________________________________________
> DEECo mailing list
> DEECo at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/deeco

-- 
Tomas Bures, Ph.D.
Associate Professor
Department of Distributed and Dependable Systems
Charles University
Malostranske nam.25
11800 Prague 1, Czech Republic
http://d3s.mff.cuni.cz
Phone: (+420) 2 2191 4236
Fax:   (+420) 2 2191 4323

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/deeco/attachments/20150215/e5f3d8e3/attachment.html>


More information about the DEECo mailing list