Scripted development April 03, 2011 15:25 about 1 year ago
Du er lige logget ind på en webside og er ved at editere en tekst. En canal fortæller dig at du ikke kan gemme dine data og at du må logge på igen. På serversiden var det blot et skifte mellem to server i en clusterløsning. Problem, cluster session replikering fungere ikke efter hensigten.
For kunden og hans bruger oplevelse er dette rigtig dårligt men desværre en ret almindelige fejl. På backend serveren er det også en skidt ting og applikations loggen bliver fyldt med tusindvis at sanity check fejl linjer der indikere at det er umuligt at sterilisere nogle objekter. Denne slags af fejl lever kun i produktion miljø med mange kunder og al isenkrammet sat op, det er sikkert samme grund der gør at de aldrig bliver udbedret.
En udvikler med mellem til lang erfaring skal ikke bruge mere en time til at præcisere hvor og hvorfor denne type af fejl forkommer. I denne situation er det helt basalt. En række objekter kan ikke replikeres mellem de enkelte noder fordi de objekter skal forsøges sat på server sessionen er Java klasser, og de implementerer ikke interface Serializable.
At være serialiserbar som egenskab svare til at have 1 rød og 99 hvide bordtennisbolde i en spand, hælde dem gennem et vandrør ned i en anden spand, og forvente at den røde ligger præcis på samme sted som før. Serialisering bruges når serverne kopierer/replikere objekter mellem dem for at en kunde skal være i synkront tilstand over flere maskiner ved failover eller krav om high-availability. Endelige er det kun objekter der implementere denne egenskab som kan overleve et crash og starte op i samme tilstand da objem
For must cases er det et ret almindelige problem i Java’s kodebase og løsningen er også enkelt. Tilret alle sessionsobjekter til at implementere interfacet. I nogle tilfælde ville jeg nok ha åbnet min Netbeans eller IntelliJ for at rette direkte i kildekoden på den manuelle måde. Met det er for nemt og kodebasen består af 10 tusindvis af klasser og mindst flere hundrede er årsagen til en masse advarsler i containeren logfiler.
Jeg er ikke kendt for min store tålmodighed og jeg hader rutineprægede gentagelser så denne opgave vil jeg løse med automation og i tæt harmoni med operativsystemet.
Først skal alle implicerede filer lokaliseres.Ved editering af en enkelt fil kan jeg se at GUI komponenter extender klassen Validatable fra et tredieparts bibliotek. Hmm så er det højst sansynligt at den aldrig skulle påføres sessionen.
grep -rl "Validatable" *
Denne søgning gav flere tusind filer, måske lidt for mange. Næste ting jeg lægger mærke til at filerne har alle samme endelse “Controller.java”. Hmm så er det højst sansynligt at de aldrig skulle påføres sessionen. Jeg kan nu forfine søgningen og editere indholdet i hver enkelt fil med sed, print af hver berørt linje.
find . -name '*Controller.java' -exec sed -n '/class .*Validatable, /p' {} \;
Denne søgning var meget bedre, nu kan jeg visuelt validere at den fremtidige retttelse vil bliver udført på en korrekt måde. Bemærk kommaet efter ‘/class .*Validatable, /p’. Ved at fjerne eller tilføre komma kan søge de klasse som allerede har korrekt implementeret interfaced. Lad mig prøve at indsætte min ændring med substitution. Jeg udføre jeg ikke selve substiutionen men printer linjen ud til stdout for at se om pattern bliver korrekt.Commandoen sed tager et -n for at være stille og flaget /p til sidst vil printe den nye tilrettede linje ud til stdout.
find . -type f -name '*Controller.java' -exec sed -n 's/implements Validatable, /implements Validatable
, java.io.Serializable /p' {} \;
Indtil videre har jeg ikke rørt filen og det kan jeg heller ikke fordi arkiv bitten er sat. Det er fden fordi filen er under ClearCase beskytelse. Men det er ikke noget problem når vi har et fantastisk tool til commandlinen som cleartool. Først skal vi op på seneste baseline og sikre at vi er på den rigtge activitet.
ct rebase -recommended ; cl rebase -complet; cl lsco
Den sidste linje med lsco betyder at CL lister alle checkouts. Hvis der er mange kan jeg se mine egne med -me flaget. Lad mig lige understrege at jeg har det med ClearCase som en gamle venner fra den tid hvor farven blå og bank var næsten det samme. Dette er sikkert mere end de fleste kan forestille sig at CL kan gøre for dem men i forbindelse med batch/script operationer og store projektet er CL fortræffeligt. En clearcase kontrolleret fil kan ikke rettes uden at lave et gyldigt checkout på en etableret cl aktivitet.
#find.sh
find . -type f -name '*Controller.java' -exec edit.sh {} \;
#edit.sh
ct co -c "Batch update, java.io.Serializable" $1
sed -n 's/implements Validatable, /implements Validatable, java.io.Serializable /p'
ct ci -ide -c "Batch update, java.io.Serializable" $1
Hvis du bruger den grafiske brugergrænseflade ClearCase Exploring skal man checke et “overskriv selvom filerne er identiske” flag.. Samme ting kan man opnå med -ide kommando linje argumentet.
Nu kan du se differencen mellem din nye version og den forrige med
ct diff -pred file
Hvis alt er som ønsket er det bare at levere.
By Frank Vilhelmsen - 3 tags: bash sed clearcase - Add comment