• Aucun résultat trouvé

Observation of Distributed Computations: A Reflective Approach for CORBA

N/A
N/A
Protected

Academic year: 2021

Partager "Observation of Distributed Computations: A Reflective Approach for CORBA"

Copied!
11
0
0

Texte intégral

(1)

HAL Id: inria-00489477

https://hal.inria.fr/inria-00489477

Submitted on 4 Jun 2010

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Observation of Distributed Computations: A Reflective

Approach for CORBA

Laurence Duchien, Lionel Seinturier

To cite this version:

(2)

OBSERVATION OF DISTRIBUTED COMPUTATIONS: A REFLECTIVE

APPROACH FOR CORBA

L.Du hien 

andL.Seinturier y

Abstra t

Thispaperdes ribessomere e tiveprogramming te h-niquestoobserveadistributed omputationina COR-BA environment. First, we propose a new order re-lation to translate ausal dependen iesin a distribut-ed program. We generalize Lamport's Happened be-fore relation de ned for messagepassingappli ations, toanobje t ausalrelationbetweendistributedevents inanenvironmentwithsyn hronousandasyn hronous method alls, method syn hronizations and variable sharings. Se ond, weproposeare e tiveapproa hto observethisrelation. Finally,atoolisprovidedto dis-playthe ausaldependen iesgraphofadistributedrun.

Key Words

Causality,CORBA,Re e tion,OpenJava,Observation

1 Introdu tion

Withnumerousentitiesdistributed overanetwork, o-operativesystemsandappli ationswritten with COR-BA [1℄ are quite omplex and often generate a high volumeof ommuni ation,numerous on urrent a tiv-ities,and omplexsyn hronizations hemes. Program-mershavetomastermanydi erentsoftwarete hniques andthedesign,thedevelopment,thedebugandthe ob-servation oftheseappli ations be omemoreandmore omplex.

In this paper, we fo us our attention on the ob-servationofdistributedrunsinCORBAenvironments. Likein most existing studies, we do notassume that the system provides a global lo k or some perfe tly syn hronizedlo al lo ks. Hen e,theobservation ofa run requires some additional te hniques to order dis-tributed events. The partially ordered set approa h usedbyLamport'sHappenedbeforerelationprovidesa goodsolutionforsu hawork.Basedonthis,numerous studies[2, 3,4,5,6℄ addressedtheissue ofthe obser-vation of onsistent global states. Nevertheless, this relationmainlytranslatesdependen iesthatare gener-ated by asyn hronous ommuni ations. First, we an argue that environments su h as CORBA rather use



CEDRIC-CNAM, 292rueSaint-Martin, 75141Paris edex03, Fran e;email:Lauren e.Du hien nam.fr

y

Univ.Paris6,Lab. LIP6,4pla eJussieu,75252Paris edex05, Fran e;email:Lionel.Seinturierlip6.fr

syn hronous ommuni ation s hemes. Se ond, many other sour es of dependen iesexist in distributed ap-pli ations. For instan e, the syn hronization of on- urrentmethodsintrodu esomedependen iesthatare not aptured by theHappenedbefore relation. In this paper, we present an order relation alled the obje t ausalorder.Itsgoalisto apture,notonly ommuni- ation dependen ies, but also dependen ies generated bysyn hronizations,dynami reationsofthreads,and transa tions.

This paper extends previous works [7, 8, 9℄. [7℄ addressed the issue of the observation of a distribut-ed omputation fortheGUIDE [10℄language. [8℄ was a rst study for CORBA/Java environments. [9℄ in-trodu ed re e tion, and proposed a post-mortem ob-servation tool. This paper ta kles the issue of online observation, enhan es our system model of distribut-edevents, andreportsonsomeperforman e measure-ments. Our target environment is based on the free CORBAORBJa ORB[11℄,andontheOpenJava[12℄ re e tive language. OpenJava is an extension of the Javalanguagethat providesfeatures (i.e. meta lasses) to introspe t and to rede ne thedefault semanti s of aJavaprogram. Weuseitto transparentlyaddsome odeto observetheobje t ausalorder.

Thepaperisdividedasfollows. Se tion2presents theba kgroundandthe ontextofourstudy. Se tion3 de nes theobje t ausalorder. Next, Se tion 4gives thear hite tureof ourtool. Se tion 5brie y presents thestampingalgorithmandthegeneratedgraphs. Se -tion 6provides someperforman e measurements, and Se tion 7 ompares our toolwith existing works. Fi-nally,Se tion 8presentsour on lusions and some di-re tionsforfutureworks.

2 Ba kground

2.1 Order Relations

The eldoforderrelationsfordistributed omputations has been thoroughly studied. In [13℄, Lamport intro-du es a model of sequential pro esses ommuni ating by asyn hronous point-to-point messages. The Hap-penedbeforerelationtranslates ausaldependen iesin su hamodel. Itisusedforinstan e,for he k-pointing, replayingordebuggingdistributed omputations.

(3)

smallesttransitive relationsatisfying:

 if a and b are events in the samepro ess, and a wasexe utedbefore b,thena!b,

 if a is asend event by one pro ess and b is the orresponding re eive event by another pro ess, thena!b.

Thenotionsof on urrenteventsandof onsistent uts anbede neda ordingtothisrelation(the read-er should refer, for instan e, to [5℄ for more details). Mostofthe existingte hniquesto ompute ausal de-penden ies and onsistent utsuse ve torstamps[14, 15℄.

2.2 CORBA

CORBA[1℄,thestandardObje tRequestBrokerfrom the OMG, proposes an ar hite ture that enables ob-je tstotransparentlyperformrequestsinadistributed environment. Itprovidesasyn hronous(one-way)and syn hronousremotemethodinvo ationsonobje tsvia theORB. Ea h obje townsan interfa e des ribed in theInterfa eDes riptionLanguage(IDL).On the ob-je tserverside,theObje tAdapter(OA)performstwo tasks: (1) it dispat hes the in oming method alls to theirserverobje tsand, (2)it provides severalobje t a tivationpoli iesthatmodifythewaymethodsare ex-e uted. Forinstan e,multiplea tiveobje ts anshare thesameservant,or onlyoneobje tat atime anbe a tiveononeservant,or ea hmethod invo ationmay beexe utedbyaseparateservant.

2.3 Re e tion

P.Maesin[16℄,de nesre e tionastheabilityofa sys-tem"toreasonandtoa tuponitself". Re e tive pro-gramminglanguagessu hasCLOS[17℄,OpenC++[18℄, OpenJava[12℄ orIguana[19℄ distinguish twolevels of ode: thebase levelthat de nesthe basi fun tionali-tiesofanappli ation,andthemetalevelthatprovides away to introspe t the base level ode and to modi-fy its default semanti s. Thebase and the meta lev-elsintera t throughinterfa es and aproto ol alled a metaobje t proto ol (MOP for short). The elements ofthebase levelthat an bea essed andmodi edat themetalevelaresaidtoberei ed. Most existing re- e tivelanguagesreifymethod alls. Theirdefault be-haviors anthen be extendedto support forinstan e, lo al and remote alls. The extension is transparent to the base level whi h is un hanged. MOPs an be lassi edintwo ategories: ompiletimeandruntime. Intheformer ase,thesemanti sextensionde ned by the meta levels o urs during the ompilation of the program, while in the latter ase,it o urs during its

1

i.e.ifa!bandb! thena!

exe ution. Compile timeMOPssu hasOpenC++v2 or OpenJava provide better performan es, while pro-grams developedwith run time MOPs su h as CLOS orIguanaaremoreadaptableand exible.

In thelast few years re e tion has be ome popu-larin distributed omputingasitprovidesa learway to handle separation of on erns. Indeed, the numer-ousfun tionalitiesofadistributedprogram(e.g. om-muni ation, on urren y,repli ation, mobility) anbe addressed separately in di erent meta levels. In this paper,weusere e tiontotransparentlyimplementan observationservi eforCORBAappli ations.

3 Obje t Causal Order

As pointed outin theintrodu tion, wede ne the ob-je t ausal order (denoted by !

o

) as an extension of Lamport'sHappenedbeforerelation. Theobje t ausal ordertranslatesdependen iesgeneratedby(1) sequen-tial exe utions of operations, alled lo al dependen- ies, (2) syn hronous and asyn hronous ommuni a-tions, alledintera tiondependen ies,(3)dynami re-ationsofthreads, alledthreadmanagement dependen- ies, (4) method syn hronizations, alled intra-obje t dependen ies, and (5) transa tional orderings of read and write operations, alled transa tional dependen- ies. Paragraph3.1presentsoursystemmodel. Next, Paragraph3.2de nesthe ausaldependen iesthat we onsiderin su hasystem.

3.1 Model of DistributedEvents

We onsiderasystemmodelofmulti-threadedobje ts ommuni atingthrough a CORBA ORB. We assume that these obje tsdo notshare any memory. Wealso assume that the system does not provide any global lo k,noranyperfe tlysyn hronizedlo al lo ks. The events that may be generated by su h a system are listedbelow:

1. ommuni ation events: obje ts intera t through remotemethod alls,eithersyn hronous (two-wa-ys,blo king),orasyn hronous(one-way,non blo- king). Six eventsare asso iated with these op-erations: method all, send, return, arrival, st-art, and end. The method all event is the syn- hronous all of a method. The method return event is the return asso iated with su h a all. Themethod send event is the asyn hronous all ofamethod. Themethodarrivaleventis generat-edwhenamethodisre eivedonthe alledobje t side. Finally,themethodstartandendeventsare generatedrespe tively,whenamethodstartsand ends.

(4)

theseoperations: threadstart,run,end,andjoin. Thethreadstarteventisgeneratedwhenathread is reated. The thread run event is generated when a thread run begins. The thread end ev-entisgeneratedwhenathread ends. Finally,the thread joineventisgenerated whenathreadjoin operationisperformed.

3. syn hronizationevents: multi-threadedobje ts mayperformsyn hronizations. Forinstan e,when Java obje ts are onsidered, these syn hroniza-tions o urwhen athread enters a syn hronized method, a syn hronized blo k of ode, or when waitandnotifymethodsare alled. Inour urrent model,only the rst ase(syn hronizedmethod) is addressed. Weleavetheother asesforfuture works. Three events (already mentioned above) are asso iatedwith theseoperations: method ar-rival,start,andend. Paragraph3.2.4de neshow dependen iesgeneratedbysyn hronizedmethods anbedete tedwiththesethreeevents.

4. read/write events on shared variables: ea h of these operationsisasso iatedwithanevent.

3.2 Causal Dependen ies

Causaldependen iesre ordorderrelationsbetween eve-nts. These relationsare needed when, for instan e, a replay servi e is to be applied to a distributed run. They are also used to onstru t a logi al time for a distributed system. As we do not assume any global lo k,thislogi al lo kstampsdistributedevents. The Happenedbeforerelationperformssu hawork,butwe arguethat other ausal dependen iesare needed. For instan e, onsider the ase when two exe utions of a syn hronizedmethod are performed on urrently, and whenoneoftheseexe utionsisdelayedduetothe oth-er. Ifareplayservi eneeds torerun these exe utions inthesameorder,the ausaldependen ygeneratedby thedelaymust bere orded.

The obje t ausal order, denoted by ! o

, is the smallesttransitiverelationsatisfyingthenext ve def-initions.

3.2.1 Lo al Dependen ies

This rst sour e of dependen ies omes from the se-quentialexe utionofeventswithin athread. The de -nitionisthesameasin Happenedbefore.

De nition1

 Ife 1

ande 2

aretwoeventsthatbelongtothesame thread,ande 1 isexe utedbefore e 2 , then e 1 ! o e 2 .

Theintera tionsour eofordertranslatesdependen ies reatedbysyn hronousandasyn hronous ommuni a-tions between lo al and remote obje ts. It de nes a propertysimilartoLamport'sHappened-beforerelation whi hassumesthat"amessage annotbedelivered be-foreitssending"[13℄. Here,theideaisthatea hevent that isexe uted beforeamethod all,happensbefore theexe utionofthe alledmethod. Onthesameway, ea heventthatisexe utedafterasyn hronousmethod all,happensaftertheexe utionofthe alledmethod.

De nition2

 Ife s

isasyn hronousmethod allevent,ande ma its orresponding methodarrival event,

thene s ! o e ma .  If e a

is an asyn hronous method all event,and e

ma

its orresponding methodarrival event, thene a ! o e ma .  If e me

is amethod end event,and e mr

its orre-spondingmethodreturnevent,then e

me ! o e mr .

3.2.3 Thread Management Dependen ies

Threadmanagementdependen ies reatelinksbetween aparentthread andits hildthreads.

De nition3

 Ife ts

isathreadstarteventande tr

its orrespond-ingthread runevent,thene

ts ! o e tr .  If e te

isa thread end event and e tj

athread join eventwaitingfor this thread endevent,

thene te ! o e tj . 3.2.4 Syn hronization Dependen ies

Syn hronizationdependen iesre ordlinksbetween ex-e utions of a syn hronized method. A syn hronized methodisgrantedanex lusivea esstoitsobje t. Any otherthreadthattriesto a essthisobje twillbe de-layed until the previous exe ution exits the method. This syn hronization s heme introdu es a ausal de-penden y between two exe utions. The dependen y an be dete ted when a method start event an not be performed until an end event asso iated with the samesyn hronizedmethod isgenerated.

De nition4

 If e me

is a method end event of a syn hronized method,ande

ma ande

ms

methodarrivaland me-thodstarteventsofthesamemethod,andif,inthe lo al obje twherethemethodsareperformed, e

(5)

Thelast sour e of dependen ies omesfrom the shar-ingofvariables. Thebasi ideais that readandwrite operationsonasharedvariable reatedependen ies be-tweenthe threads thatperformthem. Forinstan e, a read operation an be said to "observe" the e e t of thepreviouswrite operation. Indeed,theresultofthe exe ution would not have been the same if the read hadbeenperformedbeforethewrite. The transa tion-alrelationtranslatesthefollowingdependen ies: read-write, write-read, and write-write. As pointed out by theserializabilitytheory(seeforinstan e [20℄), a on- urrentexe utionislegal,i.e. isequivalenttoa sequen-tialone,ifandonly if,thetransa tional dependen ies graphdedu edfrom theserulesisa y li .

De nition5

 If e r

is aread event and e w

the next write event on the samevariable,thene

r ! o e w .  If e w

is a write operation and e r

the next read operation onthe samevariable, thene

w ! o e r ,  If e w1

isawriteoperation ande w2

the nextwrite operation onthe samevariable,thene

w1 ! o e w2 . 4 Observation Servi e

Inthis Se tion wepresent theprototypeofour re e -tiveobservationservi eforCORBA/Javaappli ations. Thetarget ORB is Ja ORB [11℄, and theobservation is implemented with the OpenJava[12℄ re e tive lan-guage.

4.1 Ar hite ture

Our ar hite ture ontains two basi omponents: an observerobje t,andanobservermetaobje t(see g.1).

observer

metaobjects

objects

observed

observer

object

CORBA ORB

COSNaming

server

Figure1: Ar hite tureoftheobservationservi e

Theobserverobje tisastandardCORBAobje t. Thereisonesu hobje tforea hobservedappli ation.

whereea hmethodre ordsoneoftheeventsmentioned inParagraph3.1. TheobserverisimplementedinJava and stores ea h re eived event in a hashtable of ve -tors. Thereis oneve torperobservedobje tand per observedvariable.

An observermetaobje t is asso iated to ea h ap-pli ation level obje t that needs to be observed. It rei eselementsneededtograbthe11abovementioned events. On eaneventisgrabbed,theobserver metaob-je tsendsittotheobserverobje t.Thebindingpro ess betweentheobservermetaobje tsandtheobserver ob-je tiskeptassimpleaspossible: theobserverregisters awell-known namewith theCORBA naming servi e, andea hobservermetaobje tlookupsthisname. The ommuni ationbetweenthe observermetaobje tsand theobserverobje tisperformedbysomeasyn hronous method alls. UnlessCORBA spe i ationsstatethat thesemanti sofsu h allsis"beste ort"(i.e. the alls maynotbedelivered),thisme hanismisfasterandless intrusivethansyn hronousmethod alls.

Transmitted data

Whenanobservermetaobje tnoti estheobserverthat anevento ured,ittransmitstheCORBAreferen eof theobservedobje t,theindex ofthiseventin the ob-servee,andtheindexofthemethodexe utioninwhi h this event o urred. Ea h observermetaobje tstores thenumberofeventsandthenumberofmethod exe u-tionsthathavebeengeneratedsofar. Theobserver ob-je tneedsthe rstindextore onstru ttheobje tlo al order,andthese ondonetoasso iateea heventtoits method exe ution (as obje tsare multi-threaded sev-eralexe utionsofthesamemethod maybeperformed on urrently). Furthermore,forsomeevents, addition-al parametersare transmitted to the observerobje t. Table1summarizestheeventtypesre ordedandtheir additionalparameters.

1. Aninvo ationkeyisre ordedforea hmethod a-llandarrivalevent. Thiskey,whi h ontainsthe allerobje treferen e,the allermethod identi -er,andaninvo ationnumber,allowstheobserver obje t to generate the dependen y between the alland thearrival. This keyneeds to be piggy-ba kedonea happli ation levelmethod all (in-deed,when themethodarrivaleventisgenerated attheserverside,thiskeyneedstobesenttothe observer). OurtoolprovidesanIDLprepro essor toautomati allyperformthistask.

(6)

Method all A methodis alled Invo ationkey Methodreturn A method allis returned

Methodarrival A methodisdelivered Invo ationkey Methodstart A methodbegins

Methodend Themethod exe utionends

Threadstart A threadstartisperformed Threadjoin A threadjoin isperformed

Threadrun A threadbegins Parentthread id Threadend A threadends

Read operation Read ofasharedvariable Idandobjrefofthesharedvariable Writeoperation Writeofasharedvariable Idandobjrefofthesharedvariable

Table1: Grabbedevents

3. Finally, the sharedvariable identi erand its ob-je treferen earetransmittedto theobserver ob-je t ea h time a read or write operation is per-formed onasharedvariable.

4.2 Observer Metaobje ts

4.2.1 OpenJava Meta Features

The ode needed to observe the 11 eventsof Table 1 is automati ally added by some OpenJava [12℄ meta- lasses. Like the Java re e tion API [21℄, OpenJava providesawaytointrospe tthe omponentsofabase level program. As shown in g. 2, theroot meta lass ofOpenJavais OJClass. The instantiateskeyword istheonly modi ationneededto spe ifyameta link betweenabaselevel lassandameta lass.

elements

reification of

language

source-to-source

modifications

meta

link

class fooBaseLevel

{ ... }

instantiates myMeta

extends OJClass

{ ... }

class myMeta

Figure2: OpenJavameta link

Amongotherthings, theinterfa eofOJClass(see g.3) providesagetDe laredMethods method that re-turnsades riptionofthebaselevelmethods. OpenJa-vagoesastepfurtherthantheJavaRe e tionAPIand provides a way to add methods or elds (addMethod and addField), to modifythe methods body, orto

al-ter the default semanti s of any element in the base level lass (translateDe nition). Finally,expand meth-ods (expandFieldRead, expandFieldWrite and expand-MethodCall),areautomati ally alledea htime respe -tively,a eldvariableisread,a eldvariableiswritten, andamethodis alled. Bythisway,OpenJava anbe seenasaJavalanguagesour e-to-sour etranslator.

lass OJClass f

OJMethod[ ℄ getDe laredMethods(); void addField( OJField field ); void addMethod( OJMethod field ); void translateDefinition(); Expression expandFieldRead( ... ); Expression expandFieldWrite( ... ); Expression expandMethodCall( ... ); ::: g

Figure 3: Sele tedmethodsfrom OJClass

4.2.2 ObservationPro ess

Ourmainmeta lass(Observer)isthemeta lassofany observedbaselevel lass. Itextends OJClassand us-tomizesitsdefaultbehaviorby,(1)re ordingthemethod start and end events(translateDe nition), (2) re ord-ing the read operation events (expandFieldRead), (3) re ordingthewriteoperationevents(expandFieldWrite), (4) re ording the method all and return events (ex-pandMethodCall). Themethod arrivaleventis re ord-ed with awrapperaround any syn hronized method. Thethreadrelatedeventsarere ordedwithawrapper lassaroundthestandardjava.lang.Thread lass.

(7)

pro-by spe ifying at ompilation time, some relevant ele-mentstotra e. Fig.4givestheexampleofanobserved lasswhereonly eldsvariablesf1andf3,andmethod m2 are tra ed. Events related to the other variables andmethodsarenotgrabbed.

lass fooToBeObserved

instantiates Observer f tra ed prote ted float f1; float f2;

tra ed stati int f3; void m1( float x ); tra ed int m2( float x ); g

Figure4: Fieldsandmethods taggedwith thetra ed modi erareobserved

The ompiletimere e tivefeatureofOpenJavais oneofitsbene ts. AsstatedinParagraph2.3, metaob-je tsinsu hlanguagesdonotexistduringprogram ex-e utions,butonlyduring ompilations. Theadvantage is that there is no exe ution overhead due to the use ofare e tivelanguage. Theonlyoverheadintrodu ed omesfromtheexe utionofasyn hronousmethod alls totheobserverobje tea htimeaneventisgenerated.

5 Stamping Pro ess and Graphs

The ausaldependen iesofadistributed runare om-putedusingve tortimestamps. Ea helementina ve -tor translates the ordering of events within an a tiv-ity. In our model, an a tivity is an appli ation lev-el distributed thread of ontrol that an be stret hed on several serverswhen remote method alls are per-formed. A tivitiesare reatedwhenappli ations reate threadsto arryoutnewjobsorperformasyn hronous method alls. Asdistributedappli ationsare inherent-lydynami ,thenumberofa tivities,andthusthesize oftheve tortimestamps,areunknownuntiltheendof therun.

Nextparagraphdes ribesthewaytimestamp ve -tors are onstru ted. Paragraph5.2 gives theupdate rulesfortheseve tors. Finally, Paragraph5.3givesan overviewofthegeneratedgraphs.

5.1 Timestamp Ve tors

We de ne a timestamp ve tor TE for an event e as TE j i = (te j i;1 ;:::;te j i;n

), where n is the total number of a tivities, i the identi er of the a tivity and j the identi er of the event. This ve tor is updated ea h timeaneventisgeneratedin a tivityi.

TW and TR : TW x = (tw x;1 ;:::;tw x;n ) and TR x = (tr x;1 ;:::;tr x;n

). Thesearerespe tively,thetimestamp ve torofthelastwriteandthetimestampve torofthe lastreadonvariablex.

5.2 Rules to Update Timestamp Ve tors

This paragraph gives the rules to update timestamp ve tors. We assume that the exe ution order of ea h a tivityandthesequentialorderofreadandwrite op-erationsonea hsharedvariableareknown.

Rule 1 thread start event and asyn hronous method allevent: lete,athreadstarteventoranasyn hronous method allevent,bethej-th eventina tivityi. Let qbetheidenti erofthe reatedthreadormethod all a tivity. Theq-thelementofTE

1 q

issetto1. To trans-latethedependen ytheotherelementsofTE

1 q

areset

tothevaluesof orrespondingelementsofTE j i . 8q2[1;:::;p℄;8k2[1;::;n℄  k=q:te 1 q;k =1 k6=q:te 1 q;k =te j i;k

Rule 2 thread join event: let e, a thread join event, bethej-th eventin a tivityi. Let q be theidenti er ofthe thread,iis waiting forto die. Thedependen y generatedby thelasteventof threadq mustbetaken intoa ount. 8k2[1;:::;n℄ ( k=i:te j i;k =te j 1 i;k +1 k6=i:te j i;k =Max(te last q;k ;te j 1 i;k )

Rule 3 methodstart event: let a,a method start ev-ent, be the j-th event in a tivity i. If the onsidered method is syn hronized, and if there exists amethod end evente

me

whosetimestamp ve toris TE p q

, anda method arrivalevent e

ma

of the samemethod, and if for the lo al obje ts where the events are generated, e

me

o urs between e ma

and e, then thei-th element of TE

j i

is in reased, and its otherelements areset to themaximumofthe orrespondingelementsofTE

j 1 i andTE p q . 8k2[1;:::;n℄ ( k=i:te j i;k =te j 1 i;k +1 k6=i:te j i;k =Max(te j 1 i;k ;te p q;k )

Rule 4 read event: let e, a read event on variable x, be the j-th event in a tivity i. The i-th element of TE

j i

is in reasedand itsother elementsare setto the maximumof orrespondingelementsofve torsTE

j 1 i and TW x . TR x

is also updated to re ord the read dependen yforthenextwriteoperation.

(8)

x, bethe j-th event in a tivity i. Thei-th element of TE

j i

is in reasedand itsotherelementsareset to the maximumof orrespondingelementsofve torsTE

j 1 i , TW x andTR x . TW x

re ordsthetimestampofthelast writeoperationandTR

x

is learedtoavoidredundant transitivedependen ies. 8k2[1;:::;n℄ 8 > > > < > > > : k=i:te j i;k =tw x;k =te j 1 i;k +1 k6=i:te j i;k =tw x;k = Max(te j 1 i;k ;tw x;k ;tr x;k ) tr x;k =0

Rule 6 other events: letE bethej-theventin a tiv-ityi. Wein reasethei-thelementofTE

j i . 8k2[1;:::;n℄ ( k=i:te j i;k =te j 1 i;k +1 k6=i:te j i;k =te j 1 i;k 5.3 Graphs

Basedontheinformationsentbytheobserver metaob-je ts,a ausal dependen iesgraphis generated online bytheobserverobje t. Itis thendisplayedwithVGJ [22℄whi hisagraphviewerappli ation. VGJprovides a framework to plug ustomized graph manipulation algorithms. Wedesignedsu hanalgorithmforour ob-servationpro ess: itinstantiatestheCORBAobserver obje t, re ords the events, and generates the graph. The graph is updated as new events are sent to the observerobje t,andassomenewdependen iesare de-te ted. Whenanewa tivityisdete ted,eitherthrough a thread start event or an asyn hronousmethod al-l, the timestamp ve tor size of all previouslyre eived eventsisin reasedbyone.

Ourtool 2

providesapanelwithbuttonsto ontrol the display of the graph. It an be paused, resumed andmovedforwardorba kward. Notethatthis panel only ontrols the display, not the omputation itself. Even if the display is paused, the omputation keeps running. Fig.5givesas reen snapshotof ourtool. A textdes riptionofthe graphs anbegeneratedin the GML [23℄ markup language(this is a built-in feature ofVGJ).

6 Performan e Measurements

This Se tion presents someperforman eanalysis on-du ted with our tool. We provide some evaluations oftheoverheadintrodu edbytheobservationpro ess. Thetestbed platform in ludes two SunSpar Ultra5 ona10Mbits/sEthernetnetwork. Bothma hinesare

2

Ourtool anbedownloadedfromourWebpage: http://www-sr .lip6.fr/homepages/Lionel.Seinturier/RCO/.

ORB 1.0b7, and OpenJava 1.0. Table 2 summarizes ourresults.

The rstsetoftestsevaluatesthe ostofgrabbing events. As stated in Paragraph4.1, ea h distributed eventissentbyanobservermetaobje ttotheobserver obje tthroughan one-waymethod all. In theworst ase, the ost of one sending is 1.7 ms, and 1.5 ms in the best ase. This di eren e omes from the fa- t that the amountof data sent di ersfrom one type of event to another one. These results orrespond to themeantimeof10sequen esof1000grabbedevents. The same test performed when the observerand the observeeare olo atedon thesamema hine, gives re-spe tively1.5msand1.3ms. Thisshowsthatmostof thetimeisspentinthe lientstubandserverskeleton oftheCORBAenvironment,notinthenetwork.

These ondtestevaluatesthe ostofpiggy-ba king parameters to the appli ation level method alls. As stated in Paragraph4.1, we piggy-ba k an invo ation key to re orddependen iesbetween method alls and method arrival events. Our tests show that a stan-dard CORBA two-ways method all between remote ma hinestakes2.6ms. Theoverheadintrodu edbythe extraparameteris0.3ms. Theseresults orrespondto themeantimeof10sequen esof1000two-waysmethod alls.

7 Comparison with Other Works

This Se tion reviews some existing observation tools, and omparesthemtoourwork.

[24℄proposesometoolstoobserveparallel appli a-tionsdevelopedwiththePVMlibrary. Theirapproa h usesqueriesasadevi eforsear hingthestatespa e, vi-sualpresentationte hniquesadaptedfromprogram an-imation, and providesthe abilityto navigatethrough the state spa e using some visual intera tions. Both thisworkand oursuseLamport'sHappenedbefore re-lation. Nevertheless,wethinkthatthetargetaudien e ofourtoolisbroaderaswetakeadvantageofCORBA and Javawhi h are widelyused for distributed appli- ations.

[25℄ des ribesanIIOPproto olanalyzerbasedon t pdump. It displaysIIOPmessagesthat aresentand re eivedbyCORBA obje ts. Inprise'sAppCenter [26℄ performs quite a similar task at the request level (a CORBA request may be split in several IIOP mes-sages).Bothtoolsarelimitedtoproto olrelatedevents, and does not onsider, asourtool does, JVMrelated events(su hasthread reations),orappli ationrelated events(su hasmethodsyn hronizations).

(9)
(10)

mon-network CORBAORB Eventgrabbing Worst ase 1.7ms 12% 88%

Best ase 1.5ms 13% 87%

Piggy-ba king 0.3ms

Table2: Performan emeasurements

itor the a tivityof ore CORBA omponents. Good-eWat hprovidesme hanismsto grabeventso urring at the ORB level. Our tool goes a step further and, notonlygrabsORBrelatedevents,butalsoprovidesa smartdisplaythroughthe dete tionsof ausal depen-den iesbetweentheseevents. Asfarasweknow,none oftheabovementionedtoolsperformsu hawork.

8 Con lusion

Thispaperpresentsa ausalityrelation alled the ob-je t ausalorder,fordistributedappli ationsina COR-BAenvironment. ThisrelationextendsLamport's Hap-penedbefore relationby(1) onsidering both syn hro-nousandasyn hronous ommuni ations(Lamportonly onsidersasyn hronousones),and(2)in orporating de-penden iesgeneratedby ommuni ations,method syn- hronizationsandvariablesharings(Lamportonly on-siders ommuni ations). Bythisway,wethinkthatthe obje t ausal relationprovidesabetter understanding ofthesemanti sofdistributed appli ations.

These ondmainpointofourpaperisthatthe re-lationisobservedbytakingadvantageofthefeaturesof are e tivelanguage.AsstatedinSe tion4,ourtarget CORBAORBisJa ORB[11℄andourtargetre e tive languageis OpenJava[12℄. Wedevelopedsome Open-Javameta lassestotransparentlyaddthe odeneeded to re ordour ausaldependen ies. These meta lasses reify events related to method alls, thread manage-ment and read/write operations on shared variables. Eventsgenerated bythe appli ation aresentbythese meta lassestoaglobalobserver. Next,wede neve tor timestampsforthegeneratedeventsandweprovidean algorithm to ompute the ausal dependen ies graph. Finally, our tool, whi h is an extension of the exist-ingVGJ[22℄viewer,displaysthisgraph. Itisupdated onlineasneweventsaresentto theobserver.

Severalextensions anbe onsideredforthiswork. First,algorithms ouldbeaddedto he kglobal pred-i ates (with te hniques des ribed for instan e in [29℄ and[30℄). Se ond,sometools ouldbedevelopedto l-terandanalyzemorepre iselythetra es. Bythesame way,notionssu hasabstra tevent[31℄,whi harenon emptysetsofprimitiveevents, ouldalsobe investigat-edinorderto redu ethevolumeoftra edata.

Referen es

[1℄ OMG. The ommonobje trequestbroker: Ar hi-te tureandspe i ation. OMG,February1998.

[2℄ T. Leblan and J. Mellor-Crummey. Debug-gingparallel programswith instantreplay. IEEE Transa . on Computers, 36(4):471{482, April 1987.

[3℄ B.MillerandD.Choi. Breakpointsandhaltingin distributedprograms.InPro .ofthe 8thIntl. Co-nf.onDistributedComputingSystems,pages316{ 323,1988.

[4℄ K. Chandy and L. Lamport. Distributed snap-shots: Determining global states of distributed systems. ACM Transa . on Computer Systems, 3(1):63{75,February1985.

[5℄ R.S hwarzandF.Mattern.Dete ting ausal rela-tionshipsindistributed omputations: Insear hof theholygrail. Te hni alReportSFB124-15/92, Univ.ofKaiserslautern,De ember1992.

[6℄ M.Ahuja,T. Carlson,A.Gahlot,andD. Shands. Timestampingeventsfor inferringa e ts relation andpotential ausality.InPro .ofCOMPSAC'91, pages606{611,1991.

[7℄ P.Pla ide,L.Du hien,G.Florin,andL. Seinturi-er. A onsistent global state algorithm to debug distributed obje t-orientedappli ations. In Pro . ofAADEBUG'95,May1995.

[8℄ L. Du hien and E. Jeury. Observation in COR-BAJavaappli ations. InPro . of the Session on CoordinationatPDPTA'99,June1999.

[9℄ L.Du hien and L.Seinturier. Re e tive observa-tionofCORBAappli ations. InPro .of IASTED PDCS'99,pages311{316,November1999.

[10℄ R.Balterandal.Ar hite tureandimplementation ofGUIDE,anobje t-orienteddistributed system. ComputingSystems,4(1):31{67,1991.

(11)

Spe i ation. ProgrammingLanguageLab.,Univ. ofTsukuba,1998.

http://www.softlab.is.tsukuba.a .jp/ ~mi h/ openjava.

[13℄ L. Lamport. Time, lo ks, and the ordering of eventsinadistributedsystem.CACM,21(7):558{ 565,July1978.

[14℄ C.Fidge.Timestampsinmessage-passingsystems thatpreservethepartialordering. InPro . of the 11thAustralian ComputingConf.,February1988.

[15℄ F.Mattern. Virtualtimeandglobalstatesin dis-tributed systems. In Pro . of the Intl. Conf. on Parallel and Distributed Algorithms, pages 215{ 226,1988.

[16℄ P. Maes. Con eptsand experiments in omputa-tional re e tion. In Pro . of OOPSLA'87, pages 147{155,De ember1987.

[17℄ G.Ki zales,J.desRivieres,andD. Bobrow. The Artof theMetaobje t Proto ol. MITPress,1991.

[18℄ S.Chiba.Ametaobje tproto olforC++.InPro . of OOPSLA'95, volume 30 of SIGPLANNoti es, pages285{299,O tober1995.

[19℄ B. Gowing and V. Cahill. Meta-obje tproto ols forC++: The Iguanaapproa h. In Pro . of Re- e tion'96,1996.

[20℄ P. Bernstein, V. Hadzila os, and N. Goodman. Con urren y Control and Re overy in Database Systems. Addison-Wesley,1987.

[21℄ SunMi rosystems.JavaCoreRe e tion,APIand Spe i ation,February1997.

http://www.javasoft. om.

[22℄ C.M Creary. DrawingGraphswithVGJ.Auburn Univ.,1998.

http://www.eng.auburn.edu/department/ se/ resear h/graphdrawing/graphdrawing.html.

[23℄ M. Himsolt. GML: A portable graph le for-mat. Univ. Passau, 1997. http://www.fmi.uni-passau.de/Graphlet/GML/gml-tr.html.

[24℄ D. Hart,E.Kraemer, andD. Roman. Intera tive visualexplorationofdistributed omputations. In Pro of the 11th Intl. Parallel Pro essing Sympo-sium,April1997.

[25℄ C.Treanor. IIOP Proto olAnalyser.

http://www-rst.int-evry.fr/~defude/analyseur-iiop.html,1999.

[26℄ Inprise. InpriseAppCenter.

http://www.inprise. om/app enter, 1999.

20804. Whitepaper,May1997. http://www.esrin.esa.it/MAS OTTE.

[28℄ C. Gransart, P. Merle, and J.M. Geib. Goode-Wat h: Supervision of CORBA appli ations. In ECOOP'99 Workshop on Obje t-Orientation and OperatingSystems, June1999.

[29℄ C.Chaseand V.Garg. Dete tionofglobal predi- ates: Te hniquesandtheirlimitations. Distribut-edComputing,11,1998.

[30℄ V.K. Garg. Observation and ontrol for debug-gingdistributed omputations.InPro .of AADE-BUG'97,1997.

[31℄ T.Basten,T.Kunz,J.Bla k,M.CoÆn,andD.J. Taylor.Ve tortimeand ausalityamongabstra t events in distributed omputations. Distributed Computing,11:21{39,1997.

Biographies

Lauren eDu hienisanasso iateprofessorinthe Com-puterS ien eDepartmentattheConservatoire Nation-aldes Artset Metiers, Paris, Fran e, sin e 1990. She re eivedherPh.Ddegreein omputers ien efrom Uni-versity Pierreet Marie Curie, Paris, Fran e, in 1988. Her resear h interests in lude distributed algorithms for ooperativeappli ations,designmethodologies,and proof systemsfor distributed obje t-oriented appli a-tions.

Références

Documents relatifs

En Francel'idée selon laquelle'lepaysserait entré dans une phasede déclin est désormaistrès répandue, Il est vrai que les signes d'inquiétude ne manquent pas, notamment - malgré

Recofier et compléter chaque case vide par lafraction qui convient de façon que chaque égalité horizôntare et verticale soit

In RACA design, the information on treatment assignments, covari- ates, and available responses of previous patients as well as the covariates of the current patient are used in the

This pipeline can be used to model a robot in a high-fidelity simulated environment (Sandbox), and cap- ture the physics of both the robot’s movement as well as the deformation of

However, unlike the spacelike null bounce model where the µ = 0 surface is the only choice in which energy conditions are fully satisfied throughout the hybrid spacetime, there

In Chapter 5, we discuss testing for the presence of parallel carryover effects in redundant systems, which are subject to monotonically increasing time trends in the rate of

Before studying a system with many particles interacting indirectly, first one should study the entanglement of two subsystems interacting indirectly via a

More  research  is  needed  to  explore  the  depiction  and  reading  of  masculinity  in  other  young  adult  novels.  Other  aspects  of  social