1. Towards a Reconfiguration Service
for Distributed Real-Time Java*
Pablo Basanta-Val
Marisol García-Valls
DREQUIEM LAB.
Universidad Carlos III de Madrid
* This work has been presented at REACTION Workshop 2012.
Collocated with IEEE RTSS 2012 Symposium at Puerto Rico

2. Outline
• Context & contribution
▫ Online scheduling & open systems
• The reconfiguration service
▫ Distributed Java approach
 Overview of real-time parameters
 Reconfiguration points
▫ Contributed Reconfiguration service
 Proposed Extensions
 Evaluation of a policy
• Conclusion and future work
2
REACTION WORKSHOP

3. Context & Introduction
• Many real-time systems consider admission control as a
offline line feature
▫ Clear advantages like exact algorithms
• However more and more systems are dynamic and
applications may appear and disappear
▫ Real-time CLOUD computing or real-time Open Systems
▫ How to make dynamic admission control efficient !
• Admission control for real-time performance
▫ Exact algorithms tend to be very costly !
3
REACTION
WORKSHOP

4. Context & Introduction
A real-time reconfiguration service in a
nutshell
• A Real-Time Reconfiguration Service for Distributed Real-
Time Java
▫ Idea:
 To define a template for reconfiguration in distributed real-
time Java applications
 It may customized for different applications
▫ Benefits:
 Real-time Java community, and DRTSJ (The Distributed
Real-Time Specification for Java)
▫ Contribution:
 Extensions to current APIS
 Real-time Reconfiguration Service
 Example global partitioner algorithm
 with some performance results
REACTION
WORKSHOP
4

5. Distributed Real-Time
Java middleware
• Based on DREQUIEMI
▫ Layered approach for Distributed
Real-time Java
 Infrastructure
 Distribution
 Common Services
 Applications
• Currently, it consists of three main
technologies extending RTSJ
▫ Based on Java’s RMI, {RT}-CORBA ,
and TT tenets
5
REACTION
WORKSHOP

6. Distributed RT Java
QoS/RT configuration parameters
• Based on the model proposed by
RTSJ
• They characterize
▫ Application release pattern
▫ Scheduling specific parameters
▫ Memory parameters
▫ Processing group options
▫ Other internal decisions
 Thread-pool
 Connection Pool
 Memory Area pool
QoS parameters in
distribution layer Meaning in DREQUIEMI
Scheduling Parameters
«Priority»
Priority used during the up-call at the
server
Release Parameters
«Release Time, Period,
Deadline, and Cost»
Invocation pattern at the server
according to the real-time scheduling
theory
Processing Group
Parameters
«Release Time, Period,
Deadline and Cost»
Group patterns at the server according
to the real-time scheduling theory
Memory Parameters
Parameters used by the garbage
collector at the server
Thread Pool
Thread pool used at the sever to
manage remote invocations
Connection Pool
Connection pool used at the client to
carry out the remote invocation
Memory Area Pool
Memory area pool used at the server to
accept remote invocations
port
The IP port on which the remote object
is accepting incoming messages
RemoteStub
The stub with the remote reference to
the remove object
EventCommonInt.
A remote object which allows
subscriptions and may be remotely
triggered.
6
REACTION
WORKSHOP

7. Reconfiguration
points
• Three reconfiguration points in
Distribute RT Java
▫ Resources, distribution, and
components
• Contributed reconfiguration applies to
resource management/rescheduling:
▫ Location of tasks in Remote Nodes
▫ Processor, network, and memory
REACTION
WORKSHOP
7
reconf

8. Reconfiguration Service
Introducing Network parameters
• RTSJ does not support the
network
▫ Centralized systems only!
• But it could be extended with it
▫ Adding new classes to the RTSJ
• Network parameters example:
▫ Priority for the IP packet (router)
▫ A maximum bit rate
▫ A complete RSVP stack, etc.
Scheduler
DistributedScheduler
Real-time Java
Distributed Real-time Java
uses MemoryParameters
SchedulingParametersuses
3ResourcesScheduler
NetworkParameters
uses
Serializable
ReconfigurationService
uses
Schedulable
RemoteSchedulable
8
REACTION
WORKSHOP

9. Reconfiguration Service
Distributed Scheduler
• Based on RTSJ’s
scheduler
• It allows invokers to
assign schedulables to
the task set
▫ Allocation
▫ Deallocation
• Each schedulable
defines:
▫ Release parameters,
▫ memory parameters
▫ Processing parameters
▫ Network Parameters
▫ Scheduling Parameters
01: public interface DistributedScheduler
02: extends java.rmi.Remote {
03: boolean addIfFeassible(
04: Schedulable s,
05: ReleaseParameters rs,
06: MemoryParameters mp,
07: ProcessingGroupParameters pgp,
08: NetworkParameter np )
09: throws RemoteException;
10: boolean removeIfFeassible(Schedulable s)
11: throws RemoteException;
12:}
9
REACTION
WORKSHOP

10. Reconfiguration Service
Reconfiguration Service
• To introduce reconfiguration on
the previous system
▫ The reconfiguration process is
modelled as a real-time
schedulable
• Based on that, the
reconfiguration service
▫ reconfiguration service =
DistributedScheduler
+ scheduling info for
DistributedScheduler
▫ The ReconfigurationService executes
on top of a scheduler.
01: public interface ReconfigurationService extends
02 DistributedScheduler, Schedulable{
03: MemoryParameters getMemoryParameters()
04: throws RemoteException;
05: ProcessingGroupParameters
06: getProcessingGroupParameters()
07: throws RemoteException;
08: ReleaseParameters
09: getReleaseParameters()
10: throws RemoteException;
11: Scheduler getScheduler();
12: throws RemoteException;
13: SchedulingParameters getSchedulingParameters();
14: throws RemoteException;
15: NetworkParameters getNetworkParameters();
16: throws RemoteException;
17: void setMemoryParameters(MemoryParameters mp)
18: throws RemoteException;
19: void setProcessingGroupParameters(
10
REACTION
WORKSHOP

11. Tested Scheduling Policy (1/4)
End-2-End Flow-Shop
• Flow-Shop
▫ Defined as a sequence of subtasks that execute in order (i.e. with
precedence constraints).
• Each end-to-end transaction (Γj | j 1..M) is defined as follows:
▫ Global deadline (Dj)
▫ A global period (Tj)
▫ A set of j
n schedulable segments {Sj
1….Sj
n}
 A local execution priority (Pj
n) for each end-to-end transaction segment
(Sj
n).
 A local worst-case execution time (Cj
n) for each segment (Sj
n).
11
REACTION
WORKSHOP

12. Tested Scheduling Policy (2/4)
Some simplifications
Client1/
2
Net1 serv1 Net2
Client
2/2
client router server
Local Priority (P)
and Cost (C)
Global Deadline (D) and period (T)
Local Priority (P)
and Cost (C)
Local Priority (P)
and Cost (C)
Local Priority (P)
and Cost (C)
Local Priority (P)
and Cost (C)
• Utilization based test
• The evaluation assumes
T=D and fixed priority (RMA)
assignment
▫ Each local deadline is calculated
• Each node runs a periodic
enforcer
▫ It allows analyzing each flux in a
node as local.
REACTION
WORKSHOP
12

13. Tested Scheduling Policy (3/4)
Partitioning tasks on different JVMs (T=D)
1. Global check based on global utilization
To check if it fits or not in advance
2. Sort all your tasks according to utilization
To avoid allocation anomalies
3. Assign a task to a Node (bin packing)
To select a node
4. Calculate your effective priority
To use the RTSJ 28 priorities only
5. Deploy tasks in each different node
Using a distributed scheduler
13
REACTION
WORKSHOP
1.Feasibility
2.Sort
3. Assign.
5. Remote
Deploy
4. Priority
calculus
Fail
Ok

14. Tested Scheduling Policy (4/4)
Additional code to be added to the policy
01: interface FlowShopSchedulables extends Schedulable{
02: Vector getAllShedulable(); //It returns all sch.
03: }
01: interface PriorityBasedReconfigurationService
02: extends ReconfigurationService{
03:}
• The tested policy requires:
▫ A new subclass for a schedulable entity
▫ A new subclass for the reconfiguration system
• In this article we provide:
▫ FlowShopSchedulables for each transaction
▫ PriorityBasedReconfigurationService to encapsulate the scheduler
REACTION
WORKSHOP
14

15. Evaluation
Infrastructure
• One central node to deploy
the system
▫ In charge of the
reconfiguration service
• DREQUIEMI
▫ For execution
• A real-time router
▫ IP priority enforcement
Manager
router
JVM1
JVM2
JVM N
A1 A2
...
796 Mhz
796 Mhz
Node 1
796 Mhz
300 Mhz
100 Mbps
DREQUIEMI
Jtime (TimeSys)
PriorityBased
ReconfigService
DREQUIEMI
Jtime
(TimeSys)
Distributed
Scheduler
addIfFeasible( )
796 Mhz
Node 2
Node N
A1
A2addIfFeasible( )
Tester Node
DREQUIEMI
Jtime (TimeSys)
PriorityBased
ReconfigService (stub)
DREQUIEMI
Jtime
(TimeSys)
Distributed
Scheduler
DREQUIEMI
Jtime
(TimeSys)
Distributed
Scheduler
15
REACTION
WORKSHOP

16. Cost tributaries
Tasks and VMs
• Cost increases with the number of
tasks and the number of processors
• Utilization, sorting, and assignment
(no deployment)
16
REACTION
WORKSHOP
1,E+00
1,E+01
1,E+02
1,E+03
1,E+04
1,E+05
1,E+06
1,E+07
64
32
16
8
4
2
1
Timeconsumed(us)
Processors (JVMs) and
Network available
Feasiblity test algorithm costs
4096Tasks
1024Tasks
64Tasks
1Task
796Mhz-100 Mbps

17. Cost tributaries
Type of schedulable entity
• Schedulable entities
▫ Real-time threads, remote objects, and
async-event handlers
• Each schedulable offers different
performance
▫ Asynchronous event handlers have the
worst allocation time
• Remote allocation adds an extra cost
17
REACTION
WORKSHOP
1,E+03
1,E+04
1,E+05
1,E+06
1,E+07
1,E+08
4096
1024
256
64
8
1
Timeconsumed(us)
Schedulable Segments (tasks) to deploy
Allocation costs depending on the kind
of schedulable
AsyncEvent
Handler
RtRO
Rthread
1,E+03
1,E+04
1,E+05
1,E+06
1,E+07
1,E+08
4096
1024
256
64
8
1
Timeconsumed(us)
Schedulable Segments (tasks) to deploy
Remote allocation of remote entities
AsyncEven
tHandler
RtRO
Rthread
796Mhz-100 Mbps

18. Total reconfiguration time
• Some interesting values
▫ A 1 seconds reconfiguration allows
reconfiguring 64 distributed tasks
• It depends on the number
▫ Of tasks
▫ Number of JVMs
• All schedulables are supposed to be event
handlers
▫ They bound the worst time of a thread and a
remote object
REACTION
WORKSHOP
18
1,E+04
1,E+05
1,E+06
1,E+07
1,E+08
4096
1024
256
64
8
1
Timeconsumed(us)
Schedulable Objects to allocate
Total {re}configuration time
32JVM
16JVM
4JVM

19. Conclusions
• Next generation Java-based distributed real-time
systems may benefit form having an embedded
infrastructure with reconfiguration facilities
▫ Similar to the one described in the article
• However, one may choose the reconfiguration policy to
suit specific application domains
19
REACTION
WORKSHOP

20. Ongoing work
• To address other reconfiguration policies
▫ Different scheduling algorithms
▫ Mode change protocols
 As a way to introduce adaptation in DRTJava
 Impact of multi-core policies
• Use of real-time OSGi platforms for reconfiguration
▫ Higher level adaptation closer to application
20
REACTION
WORKSHOP

21. 21
REACTION
WORKSHOP
Distributed Real-Time Systems Laboratory (Drequiem Lab)