Autor: Petr Ferschmann

Firemní jabber server

V poslední době jsme začali mít celkem problémy s ICQ – od změny protokolu po velmi časté odhlašování ze sítě. Proto jsme se rozhodli, že nasadíme vlastní firemní jabber server.

Použili jsme ejabberd. Instalace byla poměrně jednoduchá.

Tím jsme získali tyto výhody:

  • bezpečná komunikace po firmě – vše je šifrované a komunikace po firmě putuje jen přes náš server
  • snadnou integraci s firemním LDAP serverem – ověřování, seznam účtů a další informace z adresáře
  • sdílený seznam kontaktů – ejabberd umožňuje editovat seznam kontaktů na serveru a tak centrálně přidat nového zaměstnance.
  • JID schodné s emailovou adresou

A protože dnes používá jabber stále více lidí (také díky Google Talk), začali jsme používat jabber i na komunikaci s našimi zákazníky.

Java: Too many open files

Nedávno jsme narazili na chybu „Too many open files“ v tomcatu běžícím na našem produkčním Linuxovém serveru.

Jak jistě všichni víte v Javě se o správu paměti stará GC. Ten spustí svoji činnost ve chvíli, kdy je spotřebována paměť a je potřeba další.
Při vytvoření FileInputStream se otevře soubor (a vytvoří tzv. file descriptor). K zavření souboru dojde až ve finalizeru tohoto objektu. Finalizer je ovšem volán až ve chvíli, kdy je objekt uvolnění pomocí GC.

Pokud máte pro program přiděleno hodně paměti, nemusí být GC spuštěno dostatečně často a vyčerpá se limit současně otevřených souborů pro JVM/proces. Záludností tohoto problému je, že se objeví zčista jasna třeba i po roce provozu.

Řešení problému existuje několik:

  • explicitně volat metodu close() na FileInputStream a podobných objektech
  • zvýšit limit současně otevřených souborů příkazem ulimit -n 4000 .
    Pozn.: jádro 2.6.x má maximální zakompilovanou hodnotu 1 000 000. Případně je nutno zvýšit i celkový počet otevřených souborů v celém systému echo 512000 > /proc/sys/fs/file-max
  • docílit častější spouštění GC – třeba tak, že snížíte max heap size. Tato třetí varianta je ve většině případů nepoužitelná.

O limitech operačních systému na počet otevřených souborů se více dočtete v kapitole „Appendix A – Operating system limits“ v mé diplomové práci.

CVS nebo SVN

U nás ve firmě používáme program Subversion. Chtěl bych vám popsat několik výhod, které nás vedly k jeho použití namísto zatím běžnějšího CVS.

  • bezpečný síťový přístup i při zápisu – pro šifrovaný spojení k CVS musíte použít tunelování přes ssh a je tedy nutné, aby uživatelé měli konzolový přístup. Rozchodit takové řešení z windows lze, ale není nejsnadnější.
  • omezení přístupu – pokud chcete omezit přístup některým uživatelům nebo zamknout větev (branch) pro zápis, musíte „opatchovat“ CVS. U SVN můžete použít integrované ACL
  • hooky – volání akcí (hooků) je jasně definované a vždy běží pod stejným uživatelem jako běží server. U CVS jsme s tím občas měli problémy.
  • výpis větví a tagů – je možné se podívat na seznam větví a je dále je i strukturovat. U CVS se musíte dotazovat na soubor, který byl ve všech verzích (a přesto nemusí obsahovat některé značky a větve) a nebo používat externí nástroje jako je např. CVSQuery.
  • commity jsou atomické – commity se uloží celé a nebo vůbec. Je možné snadno získat seznam zněnených souborů při commitu.
  • TortoiseSVN – jedná se o klienta integrovaného do windows. Ten je tak snadný na používání, že jej používá i naše obchodní oddělení a všechny dokumenty tak ukládá do SVN.
  • offline přístup – i když nejste připojeni k síti, můžete zjišťovat seznam změněných souborů, seznam změn (diff) nebo se vrátit k verzi v repository.
  • jednodušší mergování – aby jste mohli mergovat u CVS, musíte vytvořit nejen větev (branch) ale i značku (tag). To vám umožňí pozdější sloučení změn zpět. Navíc před a po každém mergování je potřeba udělat další dvě značky – jedině tak můžete dohledat seznam namergovaných změn. U SVN nic takového dělat nemusíte. Jasně vídíte, kdy byla větev vytvořena a také seznam změn, které byly udělány při merge.

    Děláme jen jednu věc – při commitu namergovaných změn přidáváme komentář „merge -r 1000:2000“ (1000 až 2000 jsou čísla verzí, které mergujete). Do příštích verzí svn slibují i lepší podporu mergování (např. automatické sledování sloučených změn)

  • použítí WebDAVu – toto je jedna z méně důležitých přesto příjemných věcí. Někteří naši zákazníci neví co to repository je. Stačí jim webový přístup k souborům v SVN. Někteří ovšem SVN používají. Pro obě tyto skupiny můžeme používat stejné URL.
  • modularita ověřování – protože SVN umí fungovat přes apache, je možné využít všechny ověřovací metody, které apache podporuje. Takže můžete ověřovat oproti passwd, LDAPu, kerberovi, databázi, … Můžete si tak sjednotit ověřování a přístup ke všem podpůrným prostředkům pro vývoj ve vaší firmě.

Jako další podpůrné nástroje používáme WebSVN, ViewSVN a vlastní „hooky“ pro propojení s bug tracking systémem.

Toto jsou mé hlavní důvody proč používat SVN.