Znovuzrození Obnoveného řádu

Wesnothu Zdar!

Tak už je to tady. Po dalších dlouhých měsících a letech jsem zase něco malého udělal pro komunitu nás Wesnoťáků. Jedno z nejzajímavějších tažení, Obnovený řád (v originále A New Order) od Arkadiusze Danielckiho, které napsal pro Wesnoth verzi 0.9.3 a které bylo naposledy funkční pod Wesnothem 1.2, je spravováno a je hratelné v nejčerstvějším vydání (nyní 1.8.2) této naprosto báječné a jedinečné strategie. Ano, milí přátelé, zajisté jste pochopili, spravuji je já a mám na svědomí jeho vzkříšení.

Hrajte, jak je vám libo. Nechte se vtáhnout do děje, zabíjejte, kecejte, vyslýchejte, mučte, zkrátka kochejte se.


Aktuálně je vydána verze 1.1.98 . Verze, která by měla beze zbytku fungovat a být v plné míře naportována na jedna-osmičkový stroj, bude 1.2 . Do té doby sháním všechny možné i nemožné beta testovače.

Užijte si to ve zdraví.

Jak vyřešit ORA-01591: zámek uplatněný spornou distribuovanou transakcí

Tak jsem si jednou hrál s Hibernate a automatickým vytvářením tabulek nad skoro produkční databází Oracle 10 a dostal jsem se do jedné poněkud choulostivé situace. Při deployi earu jsem dostával

ORA-01591: zámek uplatněný spornou distribuovanou transakcí

Chvíli jsem si myslel, že to má na svědomí špatně navržený deployment Hibernate. Po čase jsem začal Gůglit ve vodách mimo Javu a dostal jsem se k jednoduchému řešeni:

Jedná se o problém, kdy transakce selhala v okamžiku, kdy se dostala do stavu prepared. Jediné řešení je ji odstranit. A řešení jsou dvě: buď se k ní připojit a rollbacknout, nebo ji smahnout přímo v databázi.

Druhé řešení je poměrně elegantní. Oracle definuje SQL příkaz ROLLBACK FORCE a jemu odpovídající PL/SQL funkci dbms_transaction.rollback_force(xid). V tabulce "SYS"."PENDING_TRANS$" je uložen záznam o všech čekajících transakcích. Ve sloupci LOCAL_TRAN_ID je XID.

Stačí se tedy přihlásit jako uživatel SYSTEM s funkcí SYSDBA (například v sqlplus), spustit

exec dbms_transaction.rollback_force(moje_xid)

a je vymalováno.

Hibernate error - identifier altered from 1 to 1

Nějakou dobu jsem laboroval s toto poněkud podivnou hláškou - jak může změna z 1 na 1 vygenerovat chybu? A kde se vůbec ta změna bere, když jedinou operaci, kterou dělám, je session.save()?

Nakonec jsem chybu našel. Při laborování s formátem dat v databázi a ručním copy&paste psaní hbm.xml jsem zavlekl typovou nekonzistenci do dat. V databázi (PostgreSQL) jsem měl u ID Integer (což onu chybu ale nevyvolá), v hbm.xml java.lang.Integer, ale ve třídě java.lang.Long. No a protože long nelze bez přetypování uložit do intu, ona alterace byla na světě.

Řešení tohoto problému je tedy prosté. Zkontrolujte si, že vám PŘESNĚ sedí jednotlivé typy v Javě a v hbm.xml

Kéž to někomu pomůže.

Jak ignorovat skryté adresáře v doplňování v bashi

bash completion, neboli inteligentní doplňování v bashi, je strašně mocná zbraň. Poměrně hodně mi ale vadilo, že mi bash při průchodu zdrojáků uložených v Subversion permanentně nabízel v možnostech pro příkaz cd i adresář .svn . Tak jsem Gůglil, až jsem zjistil, jak se s tím vypořádat.
Nabízení skrytých adresářů je vlastnost knihovny readline, která je v bashi použita. A tu lze vypnout jednoduše pomocí nastavení readline. Do ~/.inputrc přidáte
set et match-hidden-files off
a je to. Eqivalentem pro právě běžící bash je použití interního příkazu bind:
bind 'set match-hidden-files off'
Třeba to někomu pomůže.

Valná Hromada TJ Sokol Přílepy

Výbor TJ Sokol Přílepy zve všechny své členy na valnou hromadu Tělocvičné Jednoty, která se koná ve čtvrtek 11.3. 2010 v 18:00 v budově obecního úřadu v Přílepích.

Program Valné Hromady

1) Zahájení a volba předsednictva

2) Volba mandátové komise

3) Volba návrhové komise

4) Volba volební komise

5) Schválení programu

6) Zpráva starosty

7) Zprávy cvičitelů

8) Zpráva hospodářky o hospodaření jednoty za rok 2009

9) Volba starosty

10) Volba členů výboru

11) Volba kontrolní komise

12) Volba delegátů na župní valnou hromadu

13) Diskuse

14) Závěr

Navrženou kandidátkou na post starostky je Anna Petrášová, na jednatele Ivana Sehnalová, hospodářky Růžena Staňková, na další členy výboru Helena Kuchařová a .

Za výbor Oto Buchta, starosta TJ Sokol Přílepy

Blokování nájezdů na server přes SSH

Dnes jsem řešil, jak více zabezpečit SSH před možným průnikem. Po chvilce Gůglení jsem narazil na podrobný popis, jak to zařídit na OpenSuSE 11.1 .
Použití sshguardu je rychlé, pěkné a účinné. K danému odkazu ještš přidám, že existuje OpenSuSE repository csbuild, které sshguard obsahuje.
Stačí tedy

sudo zypper ar http://download.opensuse.org/repositories/home:/csbuild/openSUSE_11.1/ csbuild

sudo zypper in sshguard

a nakonfigurovat podle onoho návodu na stránkách OpenSuSE.

POZOR! Pokud nemáte korektně rozchozený AppArmor, nechejte jej být. Při jeho nastartování vám syslog-ng zařve "Broken Pipe" na odeslání dat do roury sshguardu, takže Vám to nebude fungovat.

Snad to někomu pomůže

JBoss 4.2 a kumulující se instance Stateless EJB

Asi týden jsem si hrál s J2EE aplikací Westico Visibility Platform a každou chvíli mi aplikace sletěla na OutOfMemoryError. Asi memory leak, řekl jsem si.
Stáhl jsem si tedy NetBeansy (qůli profileru) a začal hledat, kde tesař nechal v paměti díru. Zjistil jsem, že mi permanentně narůstá počet instancí dvou Session Stateless EJB, které volám z MDB ihned po sobě, těsně před ukončením zpracování zprávy. Protože provádím JMS ack ihned po příchodu zprávy, říkal jsem si, že si asi lookup vytvoří nové instance fazolí, ale požadavek neskončí a proto to bobtná. Dlouho jsem trasoval onu Message Driven Beanu, dokud jsem si opravdu nebyl jistý, že požadavek skončil a tudíž GC by měl odstranit "nepotřebné" instance a v poolu by měly zůstat jenom "potřebné". Tak jsem se zaměřil na pool a zjistil následující:
JBoss má oddělené pooly pro MDB a stateless EJB. Pro obejítí klasické Javovské synchronizace používá JBoss ThreadLocal pool. A v tom je právě šutr úrazu. Díky klasickému implicitnímu chování MDB se stane, že každý požadavek je zpracován jiným vláknem a tedy pool pro bezestavové fazole bobtná, přestože má nastaven maximální počet instancí v poolu.
Pokud tedy chcete v JBossu volat stateless EJB z MDB, musíte patřičné bezestavové fazoli nastavit jiný typ poolu. Ideálně org.jboss.ejb3.StrictMaxPool, a to třeba pomocí JBossí anotace @PoolClass, jak je popsáno zde.

Třeba to někomu zachrání kupu nervů.