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ů.