streamalism.org

1. Áttekintés

Alapértelmezés szerint a tavaszi kötegelt feladat sikertelen a végrehajtása során felmerült hibák miatt. Időnként azonban érdemes lehet javítani alkalmazásunk rugalmasságát az időszakos hibák kezelése érdekében.

Ebben a gyors bemutatóban feltárjuk, hogyan konfigurálható az újrapróbálkozási logika a Spring Batch keretrendszerben.

2. Példa felhasználási esetre

Tegyük fel, hogy van egy kötegelt feladatunk, amely beolvas egy CSV-fájlt:

felhasználónév, felhasználói azonosító, tranzakció_dátum, tranzakció_összeg sammy, 1234, 2015.10.31., 10000 john, 9999, 2015.12.3., 12321

Ezután minden rekordot feldolgoz egy REST végpont elütésével a felhasználó beolvasásához kor és postCode attribútumok:

public class RetryItemProcessor implementálja az ItemProcessor {@Orride nyilvános tranzakciós folyamatot (Tranzakciós tranzakció) dobja az IOException {log.info ("RetryItemProcessor, kísérlet a feldolgozásra: {}", tranzakció); HttpResponse response = fetchMoreUserDetails (tranzakció.getUserId ()); // a felhasználó életkorának és postCode-jának elemzése a válaszból és a tranzakció frissítéséből ... return tranzakció; } ...}

És végül konszolidált kibocsátást generál XML:

  10000.0 2015-10-31 00:00:00 1234 sammy 10 430222 ... 

3. Újrapróbálkozások hozzáadása ehhez ItemProcessor

És mi van akkor, ha a REST végponttal való kapcsolat valamilyen hálózati lassúság miatt elévül? Ha igen, a kötegelt munkánk sikertelen lesz.

Ilyen esetekben azt szeretnénk, ha a sikertelen elem-feldolgozást próbálnánk újra néhányszor. És aztán, konfiguráljuk a kötegelt feladatunkat legfeljebb három újrapróbálkozásra hiba esetén:

@Bean public Step retryStep (ItemProcessor processzor, ItemWriter író) dobja a ParseException {return stepBuilderFactory .get ("retryStep") .chunk (10) .reader (itemReader (inputCsv)) .processzor (processzor) .writer (író) .faultTolerant ( ) .retryLimit (3) .retry (ConnectTimeoutException.class) .retry (DeadlockLoserDataAccessException.class) .build (); }

Itt van egy hívásunk hibatűrő() az újrapróbálkozási funkció engedélyezéséhez. Ezenkívül használunk próbálja újra és próbálkozzon újra az újrapróbálásra jogosító kivételek és a maximális újrapróbálkozások számának meghatározása egy tételre, ill.

4. Az újrapróbálkozások tesztelése

Legyen egy tesztforgatókönyv, ahol a REST végpont visszatér kor és postCode csak egy darabig volt lent. Ebben a teszt forgatókönyvben a ConnectTimeoutException csak az első két API-hívás esetében, és a harmadik hívás sikeres lesz:

@Test public void, amikor azEndpointFailsTwicePasses3rdTime_thenSuccess () dobja a {FileSystemResource várhatóResult = új FileSystemResource (EXPECTED_OUTPUT) kivételt; FileSystemResource actualResult = új FileSystemResource (TEST_OUTPUT); mikor (httpResponse.getEntity ()) .thenReturn (új StringEntity ("{\" age \ ": 10, \" postCode \ ": \" 430222 \ "}")); // az első két hívásnál meghiúsul, és harmadszor is továbbhalad, amikor (httpClient.execute (any ())) .thenThrow (új ConnectTimeoutException ("Timeout count 1")) .thenThrow (new ConnectTimeoutException ("Timeout count 2")). thenReturn (httpResponse); JobExecution jobExecution = jobLauncherTestUtils .launchJob (alapértelmezettJobParameters ()); JobInstance actualJobInstance = jobExecution.getJobInstance (); ExitStatus actualJobExitStatus = jobExecution.getExitStatus (); assertThat (actualJobInstance.getJobName (), is ("retryBatchJob")); assertThat (actualJobExitStatus.getExitCode (), van ("TELJES"); AssertFile.assertFileEquals (várható eredmény, tényleges eredmény); }

Itt a munkánk sikeresen befejeződött. Ezenkívül a naplókból is kiderül, hogy az első lemez id = 1234 kétszer kudarcot vallott, végül a harmadik próbálkozáson sikerült:

19: 06: 57.742 [main] INFO osbatch.core.job.SimpleStepHandler - Végrehajtási lépés: [retryStep] 19: 06: 57.758 [main] INFO obbatch.service.RetryItemProcessor - Felhasználó megkísérlése feldolgozni id = 1234 19: 06: 57.758 [main] INFO obbatch.service.RetryItemProcessor - Felhasználó megkísérlése feldolgozni id = 1234 19: 06: 57.758 [main] INFO obbatch.service.RetryItemProcessor - Megpróbálta az id = 1234 19:06 felhasználót feldolgozni: 57.758 [main] INFO obbatch.service.RetryItemProcessor - Felhasználó megkísérlése feldolgozni id = 9999 azonosítóval 19: 06: 57.773 [main] INFO osbatch.core.step.AbstractStep - Step: [retryStep] 31 ms alatt végrehajtva

Hasonlóképpen legyen egy másik teszteset, hogy megnézzük, mi történik, ha minden új próbálkozás kimerül:

@Test public void, amikorEndpointAlwaysFail_thenJobFails () kiveti a Kivételt {mikor (httpClient.execute (any ())) .thenThrow (új ConnectTimeoutException ("A végpont leállt")); JobExecution jobExecution = jobLauncherTestUtils .launchJob (alapértelmezettJobParameters ()); JobInstance actualJobInstance = jobExecution.getJobInstance (); ExitStatus actualJobExitStatus = jobExecution.getExitStatus (); assertThat (actualJobInstance.getJobName (), is ("retryBatchJob")); assertThat (actualJobExitStatus.getExitCode (), van ("SIKER"); assertThat (actualJobExitStatus.getExitDescription (), tartalmazString ("org.apache.http.conn.ConnectTimeoutException")); }

Ebben az esetben, háromszor próbálták meg az első rekordot, mielőtt a munka végül kudarcot vallott volna a ConnectTimeoutException.

5. Újrapróbálások beállítása XML használatával

Végül nézzük meg a fenti konfigurációk XML megfelelőjét:

6. Következtetés

Ebben a cikkben megtanultuk az újrapróbálkozási logika konfigurálását a Spring Batch-ben. Megnéztük mind a Java, mind az XML konfigurációkat.

Egységes tesztet is alkalmaztunk, hogy lássuk, hogyan működtek az újrapróbálkozások a gyakorlatban.

Mint mindig, az oktatóanyag példakódja elérhető a GitHubon.