čtvrtek 2. září 2004

Živá Jakarta: Tomcat 5.5 a Struts 1.2.2 venku

Na Apache Jakarta Project je tento týden velice rušno. Včera byly oficiálně vypuštěny Struts 1.2.2, o kterých informoval Pavel Kolesnikov ve spotu Struts 1.2.2 jsou na světě, neuběhlo ani pár hodin a diky chybám ve verzi 1.2.2 byli nuceni vypustit verzi 1.2.3.

Aby těch novot nebylo dost, byla poprvé uvolněna verze 5.5 populárního servletového kontejneru a web serveru Tomcat. Mezi novinkami rozhodně překvapí fakt, že vývojáři tuto verzi připravovali a ladili pro Javu 5.0 (dříve 1.5). Naštěstí by měla verze 5.5 běžet i na starších verzích Javy.

Z dalších novinek bych vybral přibalený kompilátor ( Eclipse JDT), díky němuž už Tomcatu postačuje prachobyčejné JRE. V diskusi Tomcat 5.5 is on the Prowl je zmíněno vylepšené logování, diagnostika a cluster funkcí.

středa 1. září 2004

Java: reálný dopad vyhození výjimky na rychlost programu

Kdysi dávno jsem četl nebo možná slyšel názor, že výjimky lépe řečeno jejich vyvolání je systémově náročné a zdržuje. Včera jsem našel v nástrojích jednoho našeho projektu třídu, která sloužila k zjištění aktuálního execution kontextu. Tato třída má statickou metodu, která vyvolá výjimku, zpracuje její stacktrace a vrátí jméno třídy a metody, která tuto metodu volala.

Protože se třída pro určení contextu volá docela často napadlo mě onu poučku si ověřit a změřit rychlost vykonávání programu s vyhazováním výjimky.

Jak jsem měřil

Připravil jsem si objekt Dummy, který má statickou metodu, ve které se vyvolá výjimka. Zároveň tato metoda obsahuje výpočet pí, což slouží pouze k simulaci reálné operace.

 
  public class Dummy {	
      public static void doSomethingFishy(boolean withException){
	   if(withException){ 
		try{
		    throw new Exception();             
		}catch(Exception e){
		    //do nothing
		}
	   }
	   double currPi = 0;
           double i = 1;
           do {
               currPi += 4/i - 4/(i+2);
               i+=4;
           } while (Math.abs(Math.PI - currPi) > 1E-7);	
     }
  }
 

Dále jsem si připravil vlákno, které volá statickou metodu doSomethingFishy a cyklus, který vytvoří specifikovaný počet vláken a spustí je.

 
 .
 .
 .
 boolean exception = Boolean.valueOf(args[0]).booleanValue();
 int threadCount = Integer.parseInt(args[1]);
 for(int foo = 0; foo < threadCount; foo++){
    new Thread(new MyThread(exception)).start();
 }
 .
 .
 .

 class MyThread implements Runnable{
    private boolean exception = true;
	    
    public MyThread(boolean exception){
        this.exception = exception;
    }
       
    public void run() {           
        Dummy.doSomethingFishy(exception);
    }
 }	 	
 

Proměnná exception řídí jestli se bude výjimka vyhazovat a threadCount počet spouštěných vláken.

Výsledky měření

Provedl jsem vždy tři měření na 100 vláknech s výjimkou a bez výjimky. Měřenou hodnotou byla doba běhu testu v sekundách, jako časomíra sloužila funkce operačního systému pro vrácení aktuálního času.

S výjimkou (s) Bez výjimky (s)
15,15 15,12
15,16 15,15
15,17 15,23

Z výsledků vyplívá, že vyhození výjimka má nepatrný či spíše žádný vliv na rychlost vykonávání programu. Vzhledem k tomu, že jsem zkoušel proměnlivý počet vláken a výsledky se lišily minimálně, lze prohlásit, že počet vláken má pouze minoritní vliv.

Důležitý dodatek

Cílem tohoto měření bylo prozkoumat reálný dopad vyhození výjimky na rychlost programu, i když se ukázalo, že vliv na rychlost je zanedbatelný, měly by se výjimky používat k signalizaci výjimečných situací. Mezi výjimečné situace rozhodně nepatří řízení běhu programu a nebo zjištění akt. kontextu s každým http požadavkem.

Testovací prográmek obsahuje kromě binárních a zdrojových souborů i spouštěcí dávku pro Windows. Argumenty tvoří true|false - s nebo bez výjimky a počet vláken např. run.bat true 10.

úterý 31. srpna 2004

XAML + Avalon na Windows XP a 2003

Tak nevím jestli je to hřebík do rakve nebo radostné oznámení? Na jednu stranu mě oficiální oznámeni (via. Bonzblog Michaela Juřka), ve kterém je zmíněna integrace renderovacího jádra Avalon do Windows XP a 2003 potěšila, na druhou stranu trochu rozesmutněla.

Potěšující fakt na této zprávě představuje konečně možnost tvorby Rich Internet Application v dohledné době na stávajícím lépe řečeno inovovaném programovém výbavení. Negativa vidím v tom, že se jedná o proprietární řešení Microsoftu, takže žádné standardy a tím pádem přenositelnost.

Související články

Vzor POST-REDIRECT-GET

Vzor POST-REDIRECT-GET zkráceně PRG jsem objevil v článku Michaela Jouravleva Redirect After Get. PRG pattern se snaží najít cestu jak udržet aplikaci "svěží".

Článek naráží na známý problém s dvojitým odesláním požadavku. Uživatel například odešle formulář a na výsledné stránce použije klávesu F5, což má za následek znovu odeslání formuláře a provedení té samé akce. Cest jak dostat aplikaci do nekonzistentního stavu díky akcím back, forward, reload je vícero.

Abych se přiznal, tak jsem článek Redirect After Get nedočetl dokonce, ale téma mi přijde tak zajímavé, že jsem na něj chtěl co nejdříve upozornit. Pokud vás článek a téma oslovuje pak doporučují pročíst i příslušnou diskusi, která bývá velice plodná.