Myšlenky dne otce Fura

V rámci zátěžových testů, které jsem v minulém týdnu prováděl jsem přišel na jednu zajímavou věc. Při velké zátěži došlo k “zaseknutí” Tomcatu, ze kterého se systém již nedokázal zotavit. Průvodním jevem byly otevřené konekce na databázi, přes které neprocházely žádné dotazy (tj. databáze nic nedělala), nulové zatížení procesoru Tomcatem, žádné Exception v logu. Příznaky nasvědčovaly tomu, že problém vězel v nějakých deadloccích – buď při práci s konekcemi do databáze nebo mezi aplikačními vlákny.

Po nějaké době nikam nevedoucího pátrání v našem kódu jsem si napsal jednoduché wrappery nad DBCP DataSourcem a vracenou Connection, ve kterých jsem si ukládal stacktrace threadu i odkaz na vlastní thread, který si konekci z DataSourcu vybíral. Dál jsem zavedl monitor toho, zda thready používají vždy pouze jedinou connection a nesnaží se získat další, pokud ještě tu původní nevrátily (to by mohla být cesta k deadlockům).

Při opětovném nasimulování problému mi monitor vypsal krásných 50 (tj. maximum poolu) vláken čekajících na uvolnění zámku s nasledujícím stacktracem (uvádím pouze pár nejdůležitějších řádků):

at org.apache.commons.pool.impl.GenericKeyedObjectPool.returnObject (GenericKeyedObjectPool.java:870)
at org.apache.commons.dbcp.datasources.KeyedCPDSConnectionFactory.connectionClosed (KeyedCPDSConnectionFactory.java:268)
at com.mysql.jdbc.jdbc2.optional.MysqlPooledConnection.callListener (MysqlPooledConnection.java:209)
at com.mysql.jdbc.jdbc2.optional.ConnectionWrapper.close (ConnectionWrapper.java:857)
at com.mysql.jdbc.jdbc2.optional.ConnectionWrapper.close (ConnectionWrapper.java:480)

Přečtěte si zbytek tohoto záznamu »

Je to asi rok co jsem psal článek o implicitních commitech při provádění DDL příkazů. Řešil jsem tehdy problém velmi složitého selectu, který se výrazně zjednodušil, pokud jsem jej rozdělil na dvě části s uložením mezivýsledků. Jelikož jsem potřeboval zachovat transakčnost, nemohl jsem využít temporárních tabulek a šel jsem cestou stálé tabulky s aplikačním hashem rozlišující mezivýsledky jednotlivých transakcí mezi sebou. To jsem ještě netušil, jaké mi to přinese komplikace …

Přečtěte si zbytek tohoto záznamu »

Před lety jsem psal článek o debugování aplikací v Javě. K mému překvapení jsem se totiž setkal s programátory, kteří v Javě k debugování kódu používali System.out(…) místo debug režimu. Po letech otvírám stejné téma z jiného pohledu. Jak efektivně používáme nástroje debug režimu, které nám naše IDE nabízí? Je totiž plno situací, kdy se můžeme s debugováním dost nadřít, nebo … vědět co a jak v daném okamžiku nastavit tak, abychom se k výslednému pochopení problému dostali zkratkou. IntelliJ Idea těchto nástrojů nabízí celou řadu a v tomto článku bych rád rozebral několik z nich, které sám rád používám.

Přečtěte si zbytek tohoto záznamu »

Tradic je nutno se držet – i když je to jen tradice dvouletá. Proto i letos rekapituluji dění na mém blogu výtahem několika málo statistik, které mám k dispozici a také informacemi z mého osobního života, které mají s blogem souvislost. Doufám, že tím milé čtenáře neurazím, že v mé závěrečné rekapitulaci (kterou dělám i kvůli sám sobě) najdou pár zajímavých informací.

Přečtěte si zbytek tohoto záznamu »

Znát velmi dobře IDE, se kterým pracujete deno denně, je pro vaši produktivitu zcela zásadní. Poslední rok mne utvrdil v tom, že přesto že IntelliJ Ideu používám už několik let, přesto je plno věcí, které nevím a které mi nakonec ušetří plno práce. Příkladem budiž pár klávesových zkratek o kterých jsem absolutně nevěděl a které jsem se dozvěděl teprve z DZone IntelliJ Cheatsheetu od Hamleta D’Arcyho – kupříkladu:

• Ctrl+Shift+Insert – vertikální výběr oblasti (skvělé pro hromadné úpravy CSV souborů, SQL apod.)
• Ctrl+Shift+U – změna case vybraného textu (tzn. na upper-case nebo lower-case)
• Ctrl+Alt+Left, Ctrl+Alt+Right – posun na předchozí / následující lokaci kurzoru (používal jsem ikony) – skvělé pokud si prohlížíte jinou část třídy, včetně přesunutí kurzoru a pak se chcete vrátit rychle zpět
• F11 – vložení rychlého bookmarku do kódu, který se vám ukazuje po pravé straně a je možné se na něj rychle vrátit

Možná, že teda i já vím pár věcí, které tak úplně známé nejsou, a třeba někomu z vás pomůžou.

Přečtěte si zbytek tohoto záznamu »

In the last post I described the basic principles I found behind the scenes of GroovyScript refresh. Now imagine that you want to create your own long living Groovy instances with auto-refresh behaviour when source code changes. You can use out-of-the-box Spring support – but there are some limitations I stated in the previous article.

In this post I am going to present an alternative solution that addresses some of the painful issues I noticed. As I stated before, key is to wrap the reference to Groovy instance into an another object managed by the Java class loader and that is exactly the main point of the solution presented.

Přečtěte si zbytek tohoto záznamu »

The first thing one should undestand before he tries to integrate scripting support into his application / framework are class loading issues. One of the main reasons (next to the ability to easily switch from Java) why we have chosen Groovy as our primary scripting language is very good support for live refresh of Groovy classes when source file has changed. But what does Groovy exactly do when it “refreshes” its loaded classes to conform to a newly modified source file? What about existing instances referencing to this class? Is it even possible in JVM to change class structure in runtime? Yes JavaRebel can do this, but it needs special setup and debug mode for hotswap. And how does all this fit into the existing Spring support? From the documentation it seems, that it all just magically works! Dozens of questions ran in my mind when I started to strive for Groovy integration in our product. Those questions gets answered in this article.

Přečtěte si zbytek tohoto záznamu »

Ještě něž jsem zahájil svou dovolenou, jsme při dokončování projektu narazili na výkonnostní problém při velkém importu dat do MySQL databáze. V našem případě se jednalo o cca 30 tisíc záznamů do tří tabulek navzájem provázaných cizími klíči. Úvodní verze importního algoritmu trvala cirka 50 minut, po dvou dnech jsme se dostali na jednotky minut. Nedalo mi to, a udělal jsem pár testů, které snaží tento problém rozkrýt do většího detailu, tak abych pro příště věděl, co a především jak významně ovlivňuje rychlost importu takto rozsáhlých dat.

Přečtěte si zbytek tohoto záznamu »

V předchozím článku jsme si ukázali vylepšení iBatisu v souvislosti s XML deklaracemi. Tento navazující článek rozebírá novinky v oblasti Java API. Základem pro toto rozšíření se staly vlastnosti dostupné od verze Javy 1.5 – tedy generiky a anotace. Jednou z velkých kritik původního iBatisu bylo množství XML, které bylo nutné psát. Našlo se mnoho lidí, kterým tento přístup vadil a kteří by spíše uvítali mít vše na jednom místě v kódu. Autoři tyto kritiky vyslyšeli a vytvořili plnohodnotné API, před které je možné využít libovolnou funkcionalitu iBatisu.

Před tím, než se pustím do rozebírání detailů bych se s Vámi rád podělil o jeden velmi zajímavý úryvek z dokumentace, který má s výše uvedeným souvislost:

Java Annotations are unfortunately limited in their expressiveness and flexibility. Despite a lot of time spent in investigation, design and trials, the most powerful iBATIS mappings simply cannot be built with Annotations – without getting ridiculous that is. C# Attributes (for example) do not suffer from these limitations, and thus iBATIS.NET will enjoy a much richer alternative to XML. That said, the Java Annotation based configuration is not without its benefits.

Zdá se mi to jen nebo se povzdechy nad rigiditou Javy stávají normálním trendem?

Přečtěte si zbytek tohoto záznamu »

Po letech jsme se konečně dočkali třetí verze populární knihovny iBatis. Nová verze přináší velkou řadu novinek a jedná se o kompletní rewrite, který využívá generik, anotací a dalšího API Javy 1.5. iBatis je prozatím ve verzi Beta 1 (doposud ještě není dostupný ani v Maven repository), ale doufejme že nebude dlouho trvat a dočkáme se verze stabilní.

Společně s iBatisem vychází i úplně nový produkt iBATIS Schema Migration System inspirovaný Rails Migrations. Migrations představují podporu pro konzistentní úpravy databázových schémat s důrazem na: konzistenci, opakovatelnost, reverzibilnost, verzování, auditovatelnost a automatizaci. Jedná se o nástroj pro příkazovou řádku, s jehož pomocí je možné systémově vytvářet a spravovat databázové change skripty, které jsou přehledné, dají se kdykoliv revertovat a měly by výrazně ulehčit práci v týmu (pro čtenáře z Forresta: pokud vám to připomíná náš DbAutoupdater, jste doma ).

V této sérii článků se ale soustřeďme na iBatis 3.0 a co nového nás v něm čeká. Sérii zmiňuji pro to, že novinek je příliš mnoho na to, aby se vešly do jediného článku a proto jsem jej rozdělil na dvě části, které vyjdou s týdenním postupem. Těšte se tedy ještě na jeden článek příští pondělí.

Přečtěte si zbytek tohoto záznamu »