Bizim gözümüzden açık kaynak...

Yaklaşık bir hafta süren Mersin-Ankara tatilimden yeni döndüm, gayet güzel geçen bir aile ziyaretleri silsilesinden sonra insan açıkçası kendini pek bir toplamış olarak buluyor... Annenin yemekleri, kayınvalidenin börekleri ve sonu gelmez tek yönlü kalori alışverişi... En nihayetinde ayağımın tozuyla toplulukta ne var ne yok diye RSS'lerimi karıştırırken daha önceleri de canımı sıkan ve yeniden aklıma gelen bir konu oldu ve birkaç kelimeyi bu konu ile ilgili olarak yazma ihtiyacı hissettim.. Açık kaynak uygulamalara nasıl bakıyoruz?...

Açık Kaynak mı? Muhakkak bedavadır alalım...

Başlamadan önce Açık Kaynağın ne olduğunu/olmadığını anlamamız gerekiyor. Birincisi açık kaynak bedava olmaktan öte özgürlük ile daha çok bağdaşır.Yani kod geliştirirken, dağıtırken veya kullanırken özgür olabilmek açık kaynağın getirdiği fırsatlardır. Bunun getirdiği bir sürü avantaj vardır ki, bunlar için ayrı ayrı bir sürü yazı yazılmıştır. Yani bu yazıyı okumaya devam etmeden önce kafanızdaki açık kaynak=bedava eşitliğini bir süreliğine bırakmanız veya kafanızda biraz gerilere itelemeniz gerekiyor.

Hayır!! Açık Kaynak bu şirketin kapısından içeri adım atmayacak!! Bu kadar...

Zaman zaman etrafımızda, çalıştığımız yerde görürüz, Açık kaynak öcüymüş gibi bir tavır sergilenir.Bu tavır genellikle büyük ölçekli, kurumsal şirketlerde gösterilir. Ve en temelde iki sebebi (ya da öyle olduğu söylenir) vardır. İlki, güvenlik açıklarından dem vurulur.. İkincisi, destek ve dokümantasyon olmadığından yakınılır.

Öncelikle güvenlikten bahsedelim. Güvenlik açığı heryerde olabilir. Sisteminin mükemmel işlediğini düşünen bankalarda dahi güvenlik açıkları vardır. Her programda olduğu gibi açık kaynak uygulamalarda da güvenlik açıkları vardır. Ama uygulamada geliştirme/kullanma olarak katılımcı sayısı (ki bu açık kaynak topluluğu oluyor) fazla ise güvenlik açıkları zaman içerisinde bulunmuş ve düzeltilmiş/düzeltiliyordur. Eğer bundan yana çok şüphe duyuluyorsa kodlar nasıl olsa elimizde bakabiliriz değil mi? Bu noktada sanki kapalı kaynak kodlar biraz daha güvensiz gibi duruyor (içeride ne olup bittiğini bilmememiz açısından).

Destek ve dokümantasyona gelirsek, açık kaynak uygulamalar ölçeklerine bağlı olarak ücret karşılığında destek ve dokümantasyon sağlarlar. Tabi açık kaynağı bedava olarak niteleyip, ardından "nereden çıktı bu masraf" dersek afallarız tabi... Yukarıda da belirttiğim gibi açık kaynak her zaman bedava anlamına gelmez. JBoss lisans ücreti ödemezsiniz, ama JBoss ON için CPU başına bir lisans ücreti ödemek zorundasınızdır...

Nasıl yani açık kaynak hiç mi para kazanmıyor?

Açık kaynak uygulamalar Microsoft'un aksine lisans ücreti talep etmezler, bunun yerine dokümantasyon ve destek, zaman zaman da yardımcı entegre modüller asıl para getiren kısımlardır. Bununla ilgili Matt Asay'in Open Road'daki "Why Microsoft fears open source more than other proprietary vendors do" yazısı lisanslama ve dokümantasyon/destek arasındaki farkı ve bununla ilgili Microsoft ve Açık Kaynak arasındaki görüş farklılıklarını çok güzel anlatmış. Bir göz atmakta fayda var.

Eee iyiymiş bu açık kaynak

Açık kaynak trendi özellikle Sun CEO'su Jonathan Schwartz'ın katkıları ve vizyonu ile önce OpenOffice, sonra OpenSolaris ve ardından OpenJDK ile ivme kazandı. Sun'ın bu çabasına yakın zamanda IBM de OpenOffice.org topluluğuna katıldığını açıklayarak bir anlamda destek oldu. Sonra sırası ile birçok geniş ölçekli program trend değiştirip kodlarını açma kararı aldılar. Bunun en son örneği ise VMWare oldu. RedHat Fransız Eğitim Bakanlığı ve İsveç'te büyük ölçekte bir ilaç portali olan Fass.se'nin tüm server'larını (IBM ve Solaris'ten) RedHat Linux'e geçirdi.

Biz ne yapıyoruz peki?

Bu kadar yazıdan sonra etrafımda neler olduğunu bir toparlarsam, sırasıyla aşağıdaki sonuçları çıkarabilirim.

1.Hala açık kaynak bir uygulama gördüğümüzde kalitesiz ve ucube muamelesi yapıyoruz (Ve hatta lisanslı ürünlerin web sayfalarını inceleyip, aynı ürünün açık kaynak bir şekilde yapılamayacağına kendimizi inandırıyoruz)
2.Açık kaynağın bedava olmaktan öte paylaşımcı, sürekli geliştiren ve öğretici bir topluluk olduğunu anlamakta zorlanıyoruz.
3.Biz geliştirdiğimiz uygulamaları sanki dünyada kimse yazamazmış gibi, kodları kapalı ve lisanslı satmaya çalışıyoruz. (Tamam bu biraz fazla oldu, ama öyle)

Yukarıda yazdığım sonuçlar ile kimseyi suçlamıyorum..Sadece dünyanın yöneldiği trendi hala görmemekte ısrar ediyoruz. Benim vurgulamak istediğim nokta bu.

Hmm tabi bunları söyledikten sonra şunları da ekleyeyim, OpenOffice kullanıyorum, Sun Server'lar üzerine Solaris 9 yerine OpenSolaris veya RedHat kuralım diye her fırsatta ısrar ediyorum. Firefox favorim. Eclipse'ten daha iyi bir IDE tanımıyorum. Konfigürasyon Yöneticiliğini yaptığım projenin Kaynak Kodları Subversion'da (Starteam'den geçtik) tutuluyor. Sürüm sistemi Hudson/CruiseControl ve Ant kullanılarak yapılıyor. Vesaire, vesaire, vesaire...

Sistem-Sistemci-Alt Sistem üçgeninde yaşananlar...

Daha önce yazdığım Developer sadece kod mu yazar? adlı yazıda daha önceden kod yazma geçmişimin avantajlarını kullanarak piyasanın istediği, beklediği veya önem verdiği developer modeli ile ilgili tüyolar vermeye çalışmıştım. Ya da en azından benim gözümden faydalı developer nasıl olabiliri anlatmayı denemiştim.

Şimdi ise developer'ların kodlarını gerçek sisteme alırken karşılarına çıkan ve kodları gerçek sisteme çıkana kadar yanlarında yürüyen, daha sonra onlar kodlarını orada bırakıp ayrıldıklarında bu kodların asayişini , sistemle iyi ilişkiler içinde yaşamasını sağlayan, sorun olduğunda bu sorun ile developer'ı ilişkilendirebilen bir grup insandan bahsedelim. Sistem yöneticisi veya sistemci olarak tabir edilen bu insanlar, bir sistemin vazgeçilmezleridir. Developer'lar şöyle olmalı, böyle olmalı diye ahkam kestik ama sistemcilerin de sahip olması gereken bazı özellikler olmalıdır.


Buzdağının suyun altında parçası mı var?...

Bunların en başında üzerinde uzman olduğu, yönettiği sistemi en kuytu köşesine kadar bilmeli, veya öğrenmeye azimli olmalıdır (yazının bazı yerlerinde bu tür esnemeler olabilir, eğer sadece bilmeli deyip bıraksa idim olmazdı, çünkü hiçbirimiz herşeyi bilmiyoruz, ve daha okuyacak, öğrenecek çok şey var). Sistemin özelliklerini ve yapılabilecekleri bilmek sorunları çözebilmek ve kavrayabilmek adına çok önemlidir. Sistem buzdağı gibi tabir edilebilir, sistemin herkesçe bilinen bazı özellikleri, bazı işlevsellikleri vardır. Sistemci bunları bilmez ise kendini kötü hissetmesi sağlanır!?!?! Ama iş sadece bunları bilmek ile kalmaz. Bu yüzeydeki kısımları bilmesi, sadece günü kurtarmasını sağlar. Ama buzdağının suyun altında kalan kısmını bilir ise kütlenin büyüklüğüne ve yoğunluğuna bakarak, ne tarafa gidebileceğini, ne kadar sürede eriyeceğini veya kaç kişiyi taşıyabileceğini anlayabilir.

Sistem-Alt sistem ilişkisi...

Sistemcinin bilmesi gereken konulardan birisi de yönettiği sistem üzerinde çalışan (üzerinde çalışsın diye programlanmış olan) alt sistemlerin (uygulama sunucusu üzerinde bir uygulama olabilir, oracle üzerindeki SP'ler olabilir, SQL Server üzerinde tablolar olabilir, IBM P575 üzerinde Oracle 10g olabilir, olabilir de olabilir) sistemi üzerinde nasıl çalıştığını, eğer yanlış çalışıyorsa alternatif çalışma yöntemlerinin ne olabileceğini bilmelidir. Örneğin Oracle IBM üzerinde performanssız çalışıyorsa, hem Oracle tarafı; alt sistemini, ana sistem üzerinde çalıştırmak için ince ayar yapar, hem de IBM ana sistemi Oracle alt sisteminin daha performanslı çalışması için ince ayar yapar. Bu profesyonel bir sistem-alt sistem örneğidir. Windows makinenize kurduğunuz Eclipse IDE'sinin çok yavaş çalıştığını düşünürseniz, önce Eclipse IDE'sinin VM ayarlarını artırmayı veya azaltmayı denersiniz, sonra Windows'unuza biraz daha sanal bellek ayırırsınız. Bu çok daha amatör bir sisem-alt sistem örneğidir.

Sonuç olarak, sistem ve alt sistem arasında bir performans kaybı var ise hem sisteme, hem de alt sisteme aynı özenin gösterilmesi lazımdır, ve bu özenin gösterilebilmesi için de sistem yöneticisinin kendi ana sistemini yüzeysel bilginin ötesinde tanıması gerekir.

Bugün olmaz randevum var...

Sistemci olmanın getirdiği en ironik durum ise tüm sorumluluğun size ait olduğu bir sisteme istediğiniz zaman müdahele edemeyecek olmanızdır. Sistemde bir operasyon yapmanız gerekiyorsa, öncelikle bu sistemle uzaktan yakından, az ya da çok ilişkisi olan herkese en müsait zamanın ne olacağını sorup, teyit aldıktan sonra bu işi yapmanız gerekiyor. Bu durumda da operasyonu yapabileceğiniz bir Cumartesi gecesi saat 01:30 için "bugün gelemem, çok önemli bir randevum var, evlenmem gereken birisi ile buluşacağım" diyemezsiniz.

Yedekleme mi? Neyi? Niye?...

Sistemci iseniz yapmanız gereken ilk şey her tür değişiklikten önce sistemin kendinize özgü bir yedeğini almanızdır. Yedek alınmadan yapılan operasyonlar, herhangi bir güvenlik ipi olmadan 400 metre yükseklikte, yağlanmış bir ip üzerinde saatte 20 km hızla koşmaya çalışmaya benzer.. Anlayacağınız, yedek alınmadan yapılan ve başarı ile tamamlanan tüm operasyonlar, meleklerden tarafından korunmuş, ermişler tarafından okunmuştur, ya tamamiyle şans işi, veya dünya dışı varlıkların bir ürünüdür. Abartı bir tarafa, işini bilen sistemciler, daima yedekleme yaparak çalışırlar, hiçbirimiz borsada değiliz, riskin bize kazandıracağı herhangi birşey yok...

Hani Alkış...

Bir sistemin bu kadar çok cefasını çeken, gecesi gündüzü olmayan, ve sistemlerinin alt sistemlerle mürüvvetini görmekten mutluluk duyan sistemcileri hatırlamak... Bununla ilgili olarak System Administrator Appreciation Day sayfası bu tür bir işi görüyor, 9. senesini kutladığımız Sistem Admin'lerini Koruma, Kurtarma ve İyi Bakma günü (bir miktar geçmiş olsa da) hepimize hayırlı uğurlu olsun.

Son Söz..

Sistemci olmak büyük özveri gerektirir. Mesai saati kavramı sistemciler için yapılmamıştır. Aynı zamanda saat gibi tıkır tıkır çalışan bir sisteminiz varsa, sakın böyle bırakmayın, inanın sisteminiz ile ilgili bilmediğiniz daha bir sürü şey var (çok iddialı oldu). Eğer herşeyi bildiğinizi düşünüyorsanız, sizin sisteminizin benzeri daha bir sürü sistem var, dostu/düşmanı iyi tanımak lazım.

Hudson ve JBoss

Hudson kullanım kolaylığı, göze hoş görünebilmesi ve bir çok diğer nedenden dolayı (Hudson ile Sürekli Entegrasyon) açık kaynak topluluğu içerisinde sık kullanılır oldu. Uzun süredir Hudson kullanan JBoss, hudson sayfasında sürümlerini herkesin göreceği hale getirdi. Bu da bir anlamda Hudson'a yapılmış bir jest. Ne de olsa JBoss açık kaynak topluluğu içerisinde gayet iyi bir şöhrete sahip. Bu linke tıklayarak JBoss'un hudson sayfasını görebilirsiniz.

Hudson ile ilgili gelişmeleri Kohsuke Kawaguchi'nin blog'larından bulabilirsiniz.

Confluence içerisinde WYSIWYG Editör sorunu

Geçenlerde düşünüyordum da Blog yazmak ile Wiki sayfası hazırlamak birbirine o kadar yakın gibi görünen iki kavram ki... Zaman zaman bunların içeriklerini birbirine karıştırabiliyoruz. Ben de düşündüm ve bir confluence kurup diğer referanslarımı buraya atmaya karar verdim.

Confluence ile ilgili daha fazla bilgiyi Mustafa Tan'ın "Confluence-I" adlı yazısında bulabilirsiniz.

Biraz download biraz uğraşıdan sonra Confluence hazırdı. Tomcat'i çalıştırdım, ve confluence'a ilk adımımı attım.. Karşıma çıkan adım adım kurulumdan sonra admin hesabı yaratılmış bununla sisteme girilmiş demo bir space üzerinde bulunuyordum. Birkaç gün editledim, karıştırdım, ama bir süre sonra birşeylerin yokluğunu hissetmeye başladım. Sonra farkettim ki WYSIWYG (What You See Is What You Gain) editörüm yoktu, sadece wiki markup language ile editleme yapıyordum. Garip olan buna yabancı olan birinin bunu bir hata olarak görmeyip devam edebileceği ihtimali idi.

Neyse, biraz araştırmadan sonra bununla ilgili bir forum kaydı buldum (okumak için tıklayın). Burada dediğine göre kurulum esnasında oluşan bir problemden dolayı atlassian-bundled-plugins.zip dosyasını açması gereken yere açmıyormuş, hatta bununla ilgili bir de issue varmış (CONF-7750). Tabi bu dosyayı bulmak zor olmadı, çünkü confluence'i download ederken war/ear şeklinde olanı indirmiştim ve unzip ettiğim klasör içerisinde buldum. Bunu alıp Confluence'in data klasöründe bundled-plugins klasörüne açtım (bir hayli jar var) ve tomcat'i restart ettiğimde artık confluence wiki sayfalarımı Ne Görüyorsan Odur editörü ile editliyebiliyordum.

Başka daha garip bir durum ise o kadar jarı bundled-plugin'ine açamadığına göre acaba daha başka neleri göremiyordum.

Apache HTTP Server üzerinde Subversion : can't locate API module structure "dav_svn"

Subversion, CVS'in açık kaynak topluluğunun ihtiyaçlarına artık yetmediği bir zamanda sanki bir anda CVS'in küllerinden doğmuş (biraz abartılı oldu değil mi? Ama güzel oldu) ve açık kaynak topluluğunun yardımına yetişmiştir. Tabi birkaç yerde (Mozilla, OpenSolaris) CVS'ten SVN'e değil de Mercurial'a geçiş olmuşsa da sanırım bir süre daha Subversion dominanat olacak. Neyse, bu şekilde bir toplulukta Subversion'ı her şekilde çalışır hale getirebilmeyi tüm konfigürasyon yöneticilerinin bilmesi gerektiğinden hareketle Subversion'ı birkaç şekilde ayağa kaldırmayı deniyordum.

Svnserve ile herhangi bir sorun yaşamaksızın Subversion'ı hayata geçirdim, sonra sıra Apache üzerinde çalışır hale getirmeye geldi. Bu arada belirteyim ilk önce Subversion 1.4.4 ve Apache Web Server 2.2.4 ile çalışmaya başladım. Adım adım httpd, the Apache HTTP server linkinde istenilenleri yapmaya başladım.

httpd.conf'a gir
LoadModule olarak svn dav zımbırtılarını ekle

Ekledikten sonra devam etmeden önce bir bakmak istedim so dosyalarını yükleyecek mi? Apache server'ı restart ettim ve çat, bahsettiğin so'yu bulamıyorum, yok öyle bir so, bana yalancı mı diyorsun (can't locate API module structure).

Garip geldi, iki üç kere kontrol ettim, dosya orada.. httpd.conf dosyasına eklemem gereken satıra baktım önce LoadModule diye bir keyword, sonra so dosyasını verilecek isim ve sonra so dosyasının yeri. Sonra Subversion'ın Apache ile uyumsuz olup olmayacağı sorusu geldi aklıma, adamlar ön yüzde yazmışlar.

If you plan to install the mod_dav_svn Apache module, note that Apache 2.0 and Apache 2.2 are not binary-compatible. Thus there are two types of Subverison...

Tamam dedim, Apache 2.0 kurdum, denedim cık, aynı hata, Subversion'ı yeniden indirdim onu kurdum. Aynı hata, delirmek üzereyim. Sonra yeniden Apache 2.2 kurdum ve son kez httpd.conf dosyasını açtım, şöyle bir göz atmak için, gözüme birşey takıldı... LoadModule olan tüm kısımlarda benim so ismi dediğim kısım da module ile biterken benimkiler (son iki satır) normal bitiyor.


LoadModule include_module modules/mod_include.so
#LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/modPublish Post_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_svn modules/mod_dav_svn.so
LoadModule authz_svn modules/mod_authz_svn.so

sonlarına _module yazdım ve restart ettim. Evet ondan sonra çalıştı.

Bu durumda ortaya bir kaç tane yorum ve sonuç çıkıyor.

1. Gözden kaçırdığım bir ayrıntı birkaç saatime mal oldu.
2. Tamam SVN kitabında istenenleri birebir yapsaydım bu hata da olmayacaktı. Ama yaptığımız iş nedeniyle hiçbir zaman yazılanları birebir yapma imkanımız ya da birebir yaptığımızda çalışırsa "hah tamam" diyebilme lüksümüz yok.
3. Hataya baktığımda dav_svn'in bağlı olduğu so dosyasının yerini bulamıyorum diye algılamıştım.
   
4. Eğer bu "_module" postfix'i bu kadar önemli ise bir yerlere "bak bunu yazmayı unutursan Oğuz gibi olursun" denmeli

Sun nohup script

Unix/linux makinelerde çoğu aracı çalıştırmak için shell scriptleri kullanırız. Mesela JBoss'u açmak için run.sh veya CruiseControl'ü çalıştırmak için cruisecontrol.sh, veya kendi yazdığımız ve loglarını takip ettiğimiz shell scriptleri.

Bu scriptleri kullanırken ben en çok nohup komutunu kullanırım gerek arkaplanda çalışsın diye gerekse scriptin outputunu herhangi bir dosyaya almak istediğim için. BigAdmin'deki amcalardan bir tanesi bu işi biraz düzene sokmak adına bir tane nohup.sh yazmış. Automatically Saving Program Output With a nohup Script linkinde belirtilen yöntemleri izleyip nohup.sh ile scriptinizi çalıştırırsanız. /var/ klasörü altında scriptinizin adı ve o günün tarihi ile kombine edilmiş bir log dosyası hazırlayıp saklıyor. İnanın bu tür bir işlem çok faydalı olabiliyor.

Hudson ile Sürekli Entegrasyon

Sürekli Entegrasyon (Continuous Integration) konusu herkesin dikkatlice üzerinde durması gereken hayati bir konudur. Geliştirdiğiniz proje eğer Agile Development tarzında bir proje ise sürekli entegrasyon daha bir önemli hale gelir. Çünkü bulunduğu yer, developer ile client arasında, proje için olmazsa olmaz bir pozisyon olacaktır.

Sürekli entegrasyonu sağlamak adına en çok kullanılan araç CruiseControl'dür... Biz de açıkçası projemizde yaklaşık 3 yıldır CruiseControl kullanıyoruz. Ama bu yazıda size birçok açıdan daha avantajlı, kullanımı kolay başka bir araç olan Hudson'dan bahsedeceğim.

Hudson'ın en göze çarpan ve beni bu yazıyı yazmaya iten özelliği kurulumunun ve hayata geçirilmesinin çok kolay olması. Yani sadece bir web server üzerine deploy etmeniz çalışmaya başlamanız için yeterli. Bu yazıda basitçe hudson'ı Tomcat üzerinde nasıl hayata geçireceğimizi ve yapılabilecek bazı ayarları anlatmaya çalışacağım.

Kurulum

Çalışan bir Tomcat'e (5.0 ve üstü) sahip olduğunuza emin olduktan sonra, hudson'ı bu linke tıklayarak indirmeniz gerekiyor. Aynı Tomcat üzerine birden fazla hudson çalıştırmak isteyebilirsiniz, farklı iş türlerini gruplamak için olabilir, her ne kadar hudson'ın tab sistemi buna benzer bir yapıya sahip olsa da, gruplamanın dışında CI Server'ı restart, redeploy etmeniz gerekebilir. Bu durumda yapmanız gereken iki iş var

• hudson.war dosyasının ismini değiştirmeniz,
• Değiştirdiğiniz war dosyasının web.xml'ini açıp HUDSON_HOME değişkenine bir değer atamanız gerekiyor.

Bu şekilde birden fazla hudson'ı aynı Tomcat üzerinde çalıştırabilirsiniz.

Konfigürasyon ve Püf Noktaları

Eğer hudson'ı kapsamlı bir projede kullanacaksanız, Tomcat üzerine hudson'dan başka bir uygulama deploy etmeyin, böylece Tomcat'in JVM ayarlarını hudson için özel olarak ayarlayabilirsiniz.

Güvenlik : Hudson ile ilgili yapabileceğiniz önemli konfigürasyon ayarlarından bir tanesi de güvenlik ile ilgili olan ayardır. Her ne kadar çok gelişmiş bir güvenlik sistemi olmasa da, hudson'a yapacağınız birkaç ayar ile developer'ların job'ları (Hudson içerisinde iş için kullanılan kavram) sadece görebilme ya da konfigüre edebilme yetkisine sahip olabilmesini sağlayabilirsiniz. Bunun için sırasıyla

• Tomcat üzerinde hudson'ı yönetebilmesini istediğiniz kullanıcıları tanımlayın ve bunları "admin" rolü ile bağlayın
• Son olarak hudson'ın web sayfasını kullanarak Manage Hudson >> System Configuration linkini kullanın ve Enable Security kısmını tikleyin.
  

Hudson default olarak güvenlik opsiyonu açık bir şekilde gelir (herkes herşeyi yapabilir), yukarıdaki ayarları yaptığınızda sadece sizin hudson rolüne uygun görüp tanımladığınız kullanıcılar job'ları çalıştırabilir/konfigüre edebilir veya hudson'ı konfigüre edebilir, diğerleri sadece job'ların ne durumda olduğunu görebilir. Daha çok bilgi için buraya tıklayın.

Yedekleme : Hudson'ı yedeklemek istiyorsanız yapmanız gereken sadece web.xml içerisinde HUDSON_HOME klasörü için belirlediğiniz klasörü yedeklemektir. HUDSON_HOME>jobs klasörü altında bulunan tüm klasörler birer job'dır, bu job'ları kopyala/yapıştır ile başka hudson'lara aktarabilirsiniz.

Haydi işe koyulalım...

Konfigürasyon ayarlarını kurcaladıktan sonra sıra geldi birşeyler üretmeye. Daha önce de belirttiğim gibi hudson kurulumu ve yönetimi kolay bir sürekli entegrasyon aracı. Bunun en iyi örneğini job tanımlama ve yönetme esnasında görebilirsiniz. Hudson ana sayfasında New Job linkine tıkladığınızda 4 değişik job türü yapabilme ve bir tane de varolan bir job'ı kopyalayabilme opsiyonunu göreceksiniz. Bu job türleri kısaca

Maven2 : Maven2 ile geliştirdiğiniz projelerinizi kolayca entegre edebilirsiniz.
Matrix Build : Aynı sürümü birden fazla ortamda birden fazla parametre ile denemek isterseniz.
External Job Monitoring : Sistemde çalışan cron job'ları da takip edebileceğiniz kullanışlı bir job
Free-Style Software : Ayarlarını istediğiniz gibi değiştirebileceğiniz job tipi, benim üzerinde duracağım job da bu.

Free-Style Software'i seçtiğinizde karşınıza bir sürü ayar çıkacak, bunlardan birkaç tanesini anlatmaya çalışacağım, diğerlerini yanlarında bulunan soru işareti ikonuna tıklayarak siz bulabilirsiniz. Build kısmında shell, windows bat, ant build veya maven build'leri çalıştırabilirsiniz. Ant scriptlerini çalıştırmak için Build kısmında invoke top-level Ant targets'ı seçmeniz ve Targets kısmına ant'a girdiğiniz parametreleri yazmanız gerekiyor (mesela ant -f build_deneme.xml için targets kısmına -f build_deneme.xml yazmanız gerekir) Bunu yaptığınız zaman job'ınız bu scriptinizi çalıştıracak durumda beklemeye başlar. Bundan sonra job'lar kısmında bu projenizi göreceksiniz. Yanında "Schedule a build" ikonu ile birlikte.

Sürekli Sürüm (Gecelik, Saatlik)

Ama asıl önemli olan bunu nasıl zamanlanmış iş olarak ayarlayıp, gecelik sürüm, saatlik sürüm haline getirebileceğinizdir. Hudson burada da işimizi çok kolaylaştırıyor. Build Triggers kısmında Build Periodically kısmına tıkladığımızda önümüze free text bir alan açılıyor (Schedule). Buraya yazacağınız syntax ile birlikte bu job'ı zamanlanmış hale getirebilirsiniz. Yan yana yazılan 5 alan bize zamanlama yapma olanağı verir.

MINUTE(Dakika) HOUR(Saat) DOM(Gün) MONTH(Ay) DOW(Haftanın Günü)

Bu alanlar sırasıyla

Dakika : 0-59
Saat : 0-23
Gün : 1-31
Ay : 1-12
Haftanın Günü : 1-7

Mesela her gece saat 21:00'de çalıştır diyebilirsiniz,

0 21 * * *

veya hem gece saat 21:00'de hem de pazartesi-çarşamba öğleden sonra çalıştır diyebilirsiniz,

0 21 * * *
30 12 * * 1,3

Ya da sadece pazartesi akşam 18:00'de çalıştır diyebilirsiniz.

0 18 * * 1

Bahsettiğim ayarları yaptığınızda artık sürekli sürüm sistemine sahip olmuş oluyorsunuz. Bunun yanında isterseniz sürümü manuel de başlatabilirsiniz.

Bunların yanında hudson'ın bize sunduğu daha bir dolu özellik var. Bunlardan biri de plugin ekleyebilme özelliği. Şu anda JIRA, FindBugs gibi önemli olabilecek pluginlerin yanında irili ufaklı bir sürü plugin var ve geliştiriliyor. Pluginleri bu linkte bulabilirsiniz. Bu pluginlerle birlikte sürüm ve entegrasyon sisteminizi daha güçlü ve daha efektif hale getirebilirsiniz.

Ölçek farketmeksizin; eğer sürüm sisteminizi, bir issue tracking tool'u ve file versioning system ile entegre ederseniz , hatırı sayılır bir sisteme sahip olursunuz.

JConsole ile Performans Gözlem - Part 2

JConsole'un en önemli ve en kullanışlı tablarından birisi Memory tabı.. Memory'nin grafiği size durumun nasıl gittiğini anlatır. Neler olabileceğine dair fikirler verir. Figure 3'te gördüğünüz grafik sıradan bir Heap Memory'nin yaklaşık yarım saatlik süreçteki akışını göstermektedir. Grafiğin hemen altında yeşil renkle gördüğünüz sütunlar, değişik memory kısımlarını göstermektedir. Sırasıyla Survivor Space, Young Space, Old Space, Permanent Space, Code Cache Space'tir. Altlarındaki yatay çubuklar ise üzerlerindeki sütunların toplamlarını göstermektedir. Eğer JVM tune ediyorsanız, bu parçalar hakkında bilgili olmanızda fayda olacaktır. Bu parçalar hakkında yüzeysel birer açıklama yapayım.
Survivor Space : Swap Space gibidir, hafıza içerisinde yeri değiştirilecek nesneler için kullanılır.
Young Space : Hafızada süre olarak yeni olan objelerin tutulduğu yerdir. Minor GC bu kısımda yapılır.
Old Space : Göreceli olarak hafızada daha uzun süre yer alan nesneler burada tutulurlar. Major GC dediğimiz ve yapıldığı sürede JVM'in başka birşey yapamadığı Garbage Collection burada yapılır.
Permanent Space ve Code Cache Space : Bu kısımlar JVM için ayrılan yerin dışında yer kaplarlar ve mesela statik yüklenen class'lar burada tutulur.
Bu kısımların nasıl efektif kullanılacağı ile ilgili bilgileri
Tuning the Java Runtime System
tagtraum industries
A Collection of JVM options
linklerinde bulabilirsiniz.

Bu bilgilerin yanında kolonlara tıkladığınızda o kolonlarla ilgili bilgileri JConsole'u çalıştırdıktan sonra geçen zamana ait olarak görebilirsiniz. GC Time kısmında kaç kere Major GC (Yukarıdaki) yapıldığı ve ne kadar sürdüğü ve kaç kere Minor GC (Aşağıdaki) yapıldığı ve ne kadar sürdüğü görülebilir. GC'nin ne olduğu, nasıl izlendiği ile ilgili arkadaşım ve meslektaşım Mustafa Tan'ın Java Hafıza Problemleri ve GCViewer yazısı iyi bir kaynak olabilir.

Figure 3

Threads tabı bir diğer hayat kurtaran tabdır. Yani en azından bizim için öyle olmuştur. Figure 4'te gördüğünüz ekranlarda JVM içerisinde yer alan thread listesini ve bunun tomcat ile ilgili olan (yani web servlet aracılığı ile gelen) thread listesini görebilirsiniz. Aşağıdaki filter kısmına thread ile ilgili belirleyici bir kaç harf giriyorsunuz ve ta-tam, thread'leriniz listeleniyor. Bundan sonra yapmanız gereken sadece hangi threadin detayını görmek istiyorsanız ona tıklamak. Eh artık biraz da stack trace'den neler çıkarabileceğimize kalıyor iş.

Figure 4

MBean'ler ve invocation'ları ile ilgili bilgileri Figure 5'teki MBeans tabında bulabilirsiniz. Bu tab içerisinde soldaki navigasyonda erişebildiğiniz mbean'leri ve bu mbean'lerin metodlarını bulabilirsiniz. Eğer az çok JBoss'un JMX console'una aşina iseniz, bu ekran sizin için hayli güzel şeyler içerebilir. Ben örnek olarak Threading'i seçtim. e

Figure 5

Son tabımız ise Figure 6'da da gördüğünüz gibi VM tabı, biraz summary tabına benzesede burada bulacağınız bilgiler de gayet kullanışlı olacaktır. Bu bilgiler sırasıyla, JVM'in hangi Java versiyonu ile çalıştığı bilgisi, çalışan JVM'in process numarası (name kısmında @ işaretinden hemen önce), kullandığınız JVM argümanlarının tam bir listesi, çalışan JVM'in classpath'i boot classpath'i gibi faydalı bilgiler bazı diğer makine konfigürasyonu bilgileridir.

Figure 6

Bu yazıya ek olarak belirtmekte fayda göreceğim birkaç nokta var. JDK 6.0 ile birlikte gelen JConsole içerisinde JVM'in makine üzerinde yarattığı CPU yükünü takib edebiliyorsunuz. Yani yeni bir özellik olarak CPU izleyebilme eklenmiş. Summary tabı ile VM tabı birleştirilmiş. Bunun yerine ilk açtığınızda karşınıza Memory, Threads, CPU ve Classloading'den oluşan dörtlü basit bir monitor geliyor. Hmm bir de JDK 6.0 üzerindeki JConsole'a yazılmış birkaç tane eklenti gördüm. JDK 5.0'daki JConsole'da yoktu, ya da ben rastlamadım.

Bu kadar kolay ve rahat kullanılabilen bir aracın neler yapabildiğini anlatmaya çalıştım. Bu durumda şunu söyleyebilirim, ne şekilde olursa olsun, sistemleri gözlemlemek, hem sistemin doğasını anlamanıza yardımcı olur, hem de sistemi mevcut durumundan daha iyi bir düzeye getirmek için elinizde bulgular olmasını sağlar.

JConsole ile Performans Gözlem - Part 1

Performans Gözlemlemek sistemler için vazgeçilmez bir kavramdır. Bir sistemde oluşan sorunlar kadar, oluşabilecek sorunları önceden tahmin edebilmek de hayati bir aksiyondur. Sorun oluştuğu esnada sistemin parametrelerini gözlemleyebilmek ve sorunun sebebini bulmak hayat bile kurtarabilir.

İşte JConsole, eğer java tabanlı uygulamalar geliştiriyorsanız, işinize yarayacak güzel bir araç. En büyük özelliği JDK (5.0 ve sonrası) ile birlikte bedava geliyor olmasına rağmen boyundan büyük işler yapıyor olması. Geliştirdiğimiz projede yaklaşık 1 yıldır JConsole'dan faydalanıyoruz. Kullanımı çok basit, ama söylediğim gibi yaptıkları çok büyük.

Avantajları ve Dezavantajları

• En büyük avantajı, izlenilmek istenilen sistemler üzerine yük getirmiyor olması. Performans gözlem araçları, genellikle, izlenilmek istenen uygulamanın yanına bir agent kurarlar. Bu agent aracılığı ile merkezi bir server'a bilgi gönderirler. Ve izlenilen uygulamaya yük getirir.
• Bir diğer avantajı, kurulumunun ve hayata geçirilmesinin çok kolay olmasıdır.
• Bunun dışında belli bir süre gözlemledikten sonra (yaklaşık 7-8 saat) merkezi izlemenin yapıldığı sistemde (Genellikle PC olur bu) performans sıkıntısı yaratabilir.
• Verdiği bilgiler, çok detaylı bilgiler değildir. Yani memory ve cpu (JDK 6 ile birlikte) gözlemlenebilir, ama response time ve throughput değerleri gözlemlenemez (en azından eklentiler olmadan).
• JDK 6.0'dan sonra JConsole'a eklenti yazılabilme esnekliği getirilmiştir.

Bu avantaj ve dezavantajlar daha detaylandırılabilir.

JBoss üzerine nasıl JConsole'un yerleştirilebileceğini ve gözlemlediğimiz bilgilerin ne anlama geleceğini aşağıda anlatmaya çalışacağım.

Kurulumu ve Çalıştırılması

1. JVM argument'larının java satırına eklenmesi

Öncelikle, java ile çalıştırılan komuta bazı eklentiler yapmamız gerekiyor. Bunun için run.sh içerisinde JAVA_OPTS değişkenini bulup bunun sonuna

-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

attribute'larını eklememiz gerekiyor. Bu attribute'lardan bizi ilgilendiren ve ileride kullanacağımız jmxremote.port, yani 9000.. Bu, merkezi açtığımız jconsole'un remote olarak bağlanacağı makinenin hangi porttan bilgileri vereceğini gösteriyor. Sonra tabi ki sunucuyu restart etmemiz gerekiyor. Açılırken herhangi birşey yüklemiyor. Bu konuda kafanız rahat olsun, sadece verdiğimiz porttan JConsole isteklerini dinleyip, bunlara response verecek.

2. Local'den JConsole'un çalıştırılıp remote sunucuya bağlanması

${JDK5_HOME}/bin altında jconsole.exe var. Bunu çalıştırıyoruz ve bitti, evet bu kadar. Ne kurulum yaptık, ne de konfigürasyon ayarladık. Dediğim kadar basitmiş değil mi? Karşımıza aşağıdaki Figure 1'deki ekran geliyor. Host or IP kısmına incelemek istediğimiz IP'yi, port kısmına jmxremote.port attribute'unda verdiğimiz port numarasını yazıyoruz...

Figure 1

Login işlemi sona erdiğinde önünüze gelen Figure 2'deki ekranda JVM ile ilgili genel bilgileri görebilirsiniz. Bu ekranda en çok kullandıklarımı ve zaman zaman sorun çıktığında başvurduğum bilgileri aşağıda kısaca açıklamaya çalışacağım.

Uptime = Server'ın ne kadar süredir çalıştığını gösterir. Bunu availability ile ilgili birilerine birşeyler kanıtlamam gerektiğinde kullanırım. Mesela bu ekranda server'ın yaklaşık 6 gündür ayakta olduğu görünüyor.
LiveThreads = JVM içerisindeki aktif thread sayısını görürsünüz. Bu sayı sistemin çalışması esnasında belli bir sayı aralığında dolaşır. mesela 60-90 arasında. Ama bunun üzerine çıkmaya başlarsa sistemde bir sorun başgösteriyor olabilir.
Memory ve classes için ayrı bir tab mevcut dolayısıyla bundan sonra bahsedeceğim, fakat JVM instance'ının üzerinde çalıştığı makinenin fiziksel memory'si ile ilgili birkaç bilgiyi Operating System kısmında bulabilirsiniz.

Figure 2

Bir sonraki yazımda JConsole ile memory grafiklerinin takibi, JVM thread'lerinin incelenmesi, Remote MBean Invocation ve JVM ile ilgili diğer bilgilere nasıl ulaşacağımızı, bunların yanında bunların nasıl kullanılırsa hayat kurtarabileceğini anlatmaya çalışacağım.

Developer sadece kod mu yazar?

Bundan 7-8 sene önce Kıbrıs'ta bir grup arkadaş program yazdığımız sırada, ya da ondan bir kaç sene sonra yine bir grup arkadaş, İsrail'e bir proje geliştirdiğimiz sırada, yaptığımız tekşey kodlama idi. Yani, kodumuzun nasıl çalıştığı, nerede çalıştığı ile ilgilenmez, sadece ne yaptığı ile ilgilenirdik. Sonra okul bitti ve şimdiki işyerimde çalışmaya başladım. Burada bir iş akış sistemi geliştiriyorduk. Burada da kod yazıyorduk, ama zaman zaman IIS'i restart etmemiz gerekiyordu. Sonra, kodumuzda bir açık olduğunu ve sistem performansında darboğaz oluştuğunu farkettik, bu sefer yavaş yavaş yazılan SQL cümlelerini analiz etmeye başladık. Sonra MS SQL Server üzerinde Performance Tuning olayları ile ilgilenmeye başladım. Bu bahsettiğim olay ise tam 3 sene önce idi.

Yukarıda kendi programcılık deneyimim ile ilgili yazdığım paragraf bile, bir developer'ın on senelik sürede nasıl değiştiğini, nasıl değişmesi gerektiğini sanırım ifade etmiştir. Yani bundan 10 sene öncesinde bir developer sadece kod yazıyordu, ama aradan geçen zaman ve proje yönetimi kavramındaki pozitif değişiklikler beraberinde Agile Development ve Extreme Programming kavramlarını getirdi. Ve bu kavramlar da developer'ın yapması gereken işleri ve sorumluluğunun çerçevesini genişletti.

Şimdi birazda şu anda geliştirilen uygulamalara bakalım. Örneğimiz de benim üzerinde çalıştığım proje olsun. Kapsamlı ya o bakımdan.. Geliştirdiğimiz projede developer'lardan ilk beklentimiz darboğaza yol açmayacak kodları sürüm sistemine dahil etmeleridir. Bunu yapmak için developer'lar (isterlerse 3rd party tool'lar kullanarak) kodlarını analiz edip, olası bug'ları ve leak'leri temizlemek zorundadırlar. Bu da onlara kod yazmanın yanında kodlarını analiz etme yükümlülüğünü de getirmiştir. Sürüme katılan her bileşen veritabanı ile ilgili yaptığı operasyonlardan sorumludur, mesela bir tablo yaratılacaksa, uygun index'ler ile yaratılmalı ve gerekli key'ler verilmelidir. Bu da veritabanı bilgisi ve performans iyileştirme kavramlarını getirmektedir. Kodlama içerisinde bir SQL cümleciği sorun yaratıyorsa, bunu TOAD veya SQL Navigator'da açıp SQL'in nerede takıldığını bulmak zorunda olabilir, bu da yine performans iyileştirme kavramını beraberinde getirmektedir. Büyük ölçekli sistemlerde çıkabilecek hataları önceden tahmin etmek için kodlarını lokalde çalıştırıp Memory ve CPU değerlerini gözlemlemelidir, bunun içinde etrafta bir sürü araç mevcut. Sakın gözünüz korkmasın, bu bahsettiğim işler yapılan işler. Yani çalıştığım projede zaman zaman bu tür voltranlar oluyor. Arada sırada ışın kılıcını falan çıkarıyorlar.

Evet Voltran, bundan sonra developer değil Voltran diyeceğim. Çünkü yazdıklarımdan sonra Developer kavramı Voltran'a benzedi değil mi? Ama doğal eleksiyon sadece doğada yok, iş piyasasında da var. Yani bunları yapabilen developer'ın yaşama şansı daha yüksek.. Çünkü bu tür yeteneklere sahip developerlar geliştirilen projeye daha çok katkıda bulunurlar. Yani bir programlama dilinde mükemmel kod yazıyor olabilirsiniz, ama artık sadece mükemmel kodlama yapmanın yanında yazdığınız kodun sistem ile entegrasyonunu anlamak, iş mantığını çözmek ve sistemi bir bütün olarak düşünebilmek yavaş yavaş ağır basmaya başladı.

Developers' Changing Roles linkinde bulduğum bir röportaj bayaa ilgimi çekti. Can alıcı ve hakikaten gözümüzün önünde olduğu halde, bize sıradan gelen bir değişimin hikayesi..

Performans Gözlemin Önemi

Çalışan uygulamaların ve uygulama sunucularının sürekli gözlemlenmesi gerekir. Sorunun ne zaman ve nereden geleceğini bilemeyiz, eğer biliyorsak sorun bizdedir, bu durumda "tembel ne duruyorsun? madem sorunu biliyorsun, çözsene!!!" derler, demezler mi?!?

J2EE uygulamalarının üzerinde çalıştıkları Uygulama Sunucuları, birçok özellikleri ile bu tür dikizlenmeye (monitor edilebilmenin argosu) müsaittirler. Birçok uygulama sunucusu kendi üzerinde MBean'lere sahiptir ve bu MBean'lerin remote çağrılması ile kendilerine ait bazı bilgileri çağırana iletir. Etrafımızda Uygulama Sunucusu izleme için birçok araç vardır. JConsole, JBoss ON, Tivoli ITCam, Hyperic, Applications Manager, JProfiler gibi. Bunların hepsini bilmenize veya kullanmanıza imkan yok. Ama hepsi ile ilgili kısa birer açıklama faydalı olacaktır.

JBoss ON - Uzunca hali JBoss Operation Network, adından belli JBoss için yapılmış olan bu uygulama JBoss'un CPU bazında lisans ücreti talep ettiği bir uygulama. Sadece performans monitoring değil, aynı zamanda uygulama sunucusu yönetimi de sağlıyor. Hepsi bir arada, fiyatı 30 CPU ve fazlası için yanlış hatırlamıyorsam 80,000 € civarındaydı.

JProfiler - İşte JVM'in process'ine yapışıp, hayatını sömüren uygulamalardan birisi. Sistemde acaip bir yük yaratıyor. Çok kullanışlı bulmadım. En son 5.0 versiyonunda birçok düzeltme olduğunu duydum.

Hyperic - Durum biraz daha kaliteli hale geliyor. Linux'te kendi kullanıcısını yaratıyor, Database'de şema istiyor. Ama hala yeterli değil.

Applications Manager - Kurulumu ve kullanımı çok kolay, 5 sistemi ücretsiz monitor edebiliyorsunuz, ama fazlası için para ödemeniz gerekiyor. Local'inize kuruyorsunuz, servisi başlatıyorsunuz, istediğiniz sistemi monitor edebiliyorsunuz (JBoss, Tomcat, Oracle ve hatta Linux)

JConsole - Yaklaşık 1 senedir kullanıyorum, neredeyse tüm sorunlarımı çözebiliyorum, memory leak'leri, bu leak'lere yol açan thread'leri bulabiliyorsunuz, JDK ile birlikte geliyor, sisteme yük getirmiyor. JConsole ile ilgili detaylı bir guideline ve gerçek hayat uygulamasını avantajlarını ve dezavantajlarını daha sonraki yazılarımda yazacağım.

Tivoli ITCam - Bu da IBM'in WAS'ları dikizlemek, ve üzerlerinde tam hakimiyet kurup sorunları tespit etmek için kullandığı bir ürün. 2004'te IBM ailesine katılmış. Tivoli başlı başına bir gözlem canavarı, ama bizi sadece ITCam ilgilendiriyor. Bunun kurulumunu yaptık, bununla ilgili de gözlemlerimi ilerleyen yazılarımda paylaşacağım.

Farkındaysanız, çalışan uygulamaların ve uygulama sunucularını gözlemlemek ne kadar önemli, ne kadar hassas yapılması gereken ve ne kadar sorun çözen bir işlem. Tabi memory, CPU gözlemlemek, hani derler ya "Ağaç yaşken eğilir", o hesapta taa Development'tan başlatılabiliyor. Bunun için de çeşitli IDE plugin'leri mevcut. Yukarıda listesini verdiğim gözlem araçlarının dışında tonla gözlem aracı mevcut, ben sadece deneyim yaşadıklarımı veya en azından duyduklarımı yazıyorum.

Gant (Groovy Ant)

Çoğu sürüm sisteminin temelini Ant scriptleri oluşturur. Ant scriptlerinin üzerine CI (Continuous Integration) Server'lar yerleştirilir. Otomatik ve manuel çalıştırılan scriptler ile hayat daha da güzelleştirilir. Ama benim gibi programcılık kökenli iseniz, Sürüm Sistemi'nin her katmanını sorgulayıp, "daha programlanabilir veya daha esnek olamaz mıydı?" diye sorabilirsiniz.

Gant ise bu noktada kısmen düşüncelerimize yanıt verecek bir yapı sağlıyor. Kısmen dememin sebebi ise Gant'ın Ant'a değil, Ant scriptlerini yazma şekline bir alternatif olması. Gant, Groovy script'den başka birşey değil. Ama Ant gibi XML'in kısıtlamaları ile çevrili değil. Yazdığınız bir target içerisinde diğer target'ları aynı kodlama yapıyormuş gibi birer altmetod olarak çalıştırabiliyorsunuz.

target ( altmetod : 'Aciklama alani' ) {
Ant.echo ( message : 'altmetod calisti' )
}
target ( metod : 'Aciklama alani' ) {
altmetod ( )
Ant.echo ( message : 'metod calisti' )
}

Uzun süredir, ant scriptleri ile çalışıyorsanız, yukarıdaki gibi ant scriptleri yazabilmenin yanında neleri yapabilmeyi getirebileceğini hayal edebilirsiniz. Bu arada Gant'ın tüm Ant Core Task'larını desteklediğini söylemekte fayda var. Kullanması çok basit, "Ant." deyip, ardından task'ın adını yazıyorsunuz, attribute'ları da yukarıdaki formatta "attr_name : value" şeklinde verebiliyorsunuz.

Gant'ın dezavantajlarından birisi Groovy öğrenmenizin gerekmesi, bir diğeri henüz yeni olduğu için tüm CI Server'lar ile çalışamıyor olması (mesela Hudson, ama CruiseControl'a bakmadım).

Ama Gant ile birlikte kimbilir belki birgün Java'da bir scripting dili ile Ant'a yardımcı-rakip olmaya çalışır.

Websphere, Weblogic, JBoss - Part 2

Altyapı değişikliği çok hassas karar verilmesi gereken bir konudur. "Gelen gideni aratır"sa altyapı değişikliğinin pek bir anlamı olmaz. Dolayısıyla, öncelikle ideal bir topoloji düşünülmeli, ardından yeni altyapının bu topolojiyi destekleyip desteklemediği araştırılmalıdır.

Peki bizim sistem olarak yeni altyapı ile ne gibi avantajlarımız olacak?


Support and Documentation

Eğer alınan ürün için lisans ücreti ödeniyorsa, en az 1 yıllık bakım ve destek anlaşması da yanında gelir. Dolayısıyla doküman ve destek ile ilgili sıkıntılarımızda karşımızda bir muhattap olması her zaman bir avantaj olarak değerlendirilir. Mesela, Open Source dünyasında para eden kısım budur. Düşünün ki, bir akşam sistemin bir sorunu ile uğraşırken yalnız olmayacaksınız. Sizinle birlikte kafa patlatan başka biri daha olacak ve bu kişinin size o konuyla ilgili yardım etmek gibi bir sorumluluğu olacak. Biraz tembelce, ama 7/24 sistemler için çok önemli bir konu.

References

Bir ürün alırken aslında en önemli konu referanslardır. O ürün daha önce kimler tarafından kullanılmış? Acaba bizimle aynı şekilde mi kullanmışlar? Ne kadar uzun süredir kullanıyorlar? Bu referansların en önemli avantajı, karşılaşabileceğimiz herhangi bir problem, eğer daha önce aynı ürünü kullanan başka bir firmaya sorun çıkarmışsa ve çözülmüşse; bizim sorunumuz da aynı yöntemlerle daha kısa zamanda çözülebilir. Dolayısıyla Amerika zaten keşfedildi, yeniden keşfetmeye çalışmanın bir alemi yok.

Product Family

Her ne kadar open source dünyasını sevsem, implementasyon olayına bayılsam da, şunu unutmamak lazım ürün ailesi kavramında her zaman için aile üyeleri birbirleriyle iyi anlaşırlar. Yani aldığınız ürün bir ürün ailesi ise daha önce yaşanılan sorunlardan ve problemlerden dolayı muhakkak beraber daha performanslı ve daha iyi yaşamak ve çalışmak için optimize edilmişlerdir. Düşünsenize, elinizin altında bir JVM ve bu JVM'i monitor etmeye yarayan bir araç var. Ve siz, bu entegrasyon için endişe etmiyorsunuz, çünkü zaten bu ikisi birbirine entegre olabilsin diye optimize edilmiş, bunun yanında belki binlerce kez de entegre edilmiş. Yani siz bunu yapmaya çalışan ilk araştırmacılardan biri olmayacaksınız.

Bunların dışında gruplayamadığım bir sürü avantaj var. Bunları da yıllardır her bir bileşene ayrı ayrı kafa yorduğum için biliyorum.


Bütün bu değerlendirmeler ışığında son olarak yapılması gereken yük ve performans testi değerlendirmesidir. Bu da en güzel kendi uygulamalarınızla yapılır.

Ben de üç ayrı uygulama sunucusunu (JBoss 4.0.5, Websphere 6.0, Weblogic 9.1), iki ayrı makine/işletim sistemi konfigürasyonunda (AIX 5.3L-IBM, Solaris 9-Sun) iki ayrı senaryo ile test ettim. Testi IBM Rational Performance Tester kullanarak yaptım. Herbir sunucuyu kendi bilgi birikimim ile tune etmeye çalıştım. Testleri yaparken, 5, 20 ve 50 eş zamanlı kullanıcı ile yük yarattım. Çıkan sonuçlar ilgi çekici idi. Özellikle JBoss'un gösterdiği performans gayet ilgi çekici ve başarılı oldu. Tabi içimden keşke bu versiyon ile Distributed Transaction desteği tam olsaydı dedim.

Uzun lafın kısası biz sistem olarak karşılaştırmayı yaparken, uygulama mimarisini de işin içine kattık, performans testinden çıkan sonuçlar sadece kararın bir ayağını oluşturuyor. Kararı vermeniz için uzun vadede tüm ayrıntıları göz önüne almanız gerekir.

Ant Utility (Ant yardımcısı)

Ant scriptleri, neredeyse tüm sürüm sistemlerinin temelini oluşturuyor. Her tür J2EE projesi ant scriptleri yardımı ile sahne alıyorlar. Buna rağmen ant ile ilgili hergün yeni birşeyler öğrenme fırsatımız oluyor. Ant Utility de bu yeni örneklerden birisi (en azından benim için). Bize ne faydası var? Eğer uzun ant scriptleriniz varsa ve bunların çalışma süreleri ile ilgili sıkıntıların varsa; aşağıdaki yolu izleyerek Ant Utility'yi devreye alıp, her target'ın içerisindeki her task'ın ne kadar sürede bittiğini görebilir, ve gerekirse bunlar üzerinde çalışabilirsiniz.

Yapmanız gerekenler çok basit,
1 - Ant Utility web sayfasına girip antutility.jar'ı indirin,
2 - Bu jar'ı ant lib'in altına atın
3 - ant komutunun hemen yanına "-listener net.java.antutility.BuildMetricsListener" ifadesini ekleyin

Sonuçta ekrana aldığınız çıktının sonunda BUILD METRICS diye yeni bir kısım göreceksiniz, burada tasklar ve target'lar çalışma sürelerine göre sıraya sokulmuş bir halde yer alacak. Ee bundan sonrası çok basit tabi, text virgüllerle ayrılmış. Açıp excel'i içerisine import edeceğiz.

Bu arada Ant Utility open source dolayısıyla download edip, çıkaracağı output'un formatı ve hatta değerlerini bile değiştirebilirsiniz. Topu topu dört tane java dosyası var.

Websphere, Weblogic, JBoss - Part 1

Altyapı değişikliği yapmak, hem de uzun bir süreden sonra, hem de çok kapsamlı. Acaip riskli bir iş, riskli olduğu kadar zevkli de. Neden zevkli, çünkü her zaman göremeyeceğin şeyleri görme fırsatın oluyor. Ve yeni şeyler öğreniyorsun. Neyse bizim şirkette de bu tür bir çalışma yapılıyor..

Altyapı değişikliği yapmamızın sebeplerinin başında mevcut sistemin yetersizliklileri ve düşünülen ideal yapının getireceği avantajlar var. Bu seride sırasıyla mevcut sistemin dezavantajları, düşünülen sistemin avantajları, ve bu sistemlerle ilgili karşılaştırma yorumlarımı yazacağım.

Kısaca Mevcut yapı : JBoss ve Weblogic ortak kullanılıyor. Ürün ortamında yaklaşık 12 tane JBoss instance'ı ve 7 tane Weblogic instance'ı var. JBoss instance'larının her biri yaklaşık 3 GB, Weblogic'ler ise 2 GB JVM ile çalışıyorlar.

Support and Documentation

Yetersizliklerin en başında JBoss'un open source olmasından dolayı, sorunla karşılaştığımızda buna müdahele ederken kaynak ve destek konusunda çektiğimiz sıkıntılar geliyor. Bunu da şu şekilde anlatayım.

Şanslıysam, daha önce birisi daha JBoss'ta aynı problemle karşılaşmıştır.
Daha şanlıysam, bu problemini internette forumlarda paylaşmıştır.
Daha daha şanslıysam, bu problemi çözmüştür.
Hepten şanslıysam, çözümü internette biryerlere yazmıştır.

Yani nasıl bir şansa ihtiyacım olduğunu siz düşünün. Bu durum bana hatırı sayılır bir deneyim kazandırdı, bunu inkar edemem. Ama bunun yanında eğer bir sistem 7/24 çalışmak zorunda ise ve size kalan mini minnacık kısıtlı zamanda bu tür bir araştırma yapmanız gerekirse, sanırım yeterince terlersiniz. Projemiz henüz bu aşamada değil, ama çok yakın bir zamanda 7/24 çalışması gereken bir sistem haline gelecek. Bu da sorunlara müdahele şeklimizi değiştirmemizi gerektirecek.


Scalability

Ölçeklenebilirlik, aslında bizlere mühendislik eğitiminde neredeyse sürekli anlatılan bir kavramdır. Ama nedense iş pratiğe geldiğinde günü kurtarma adına verilen kararlar, hem ölçeklenemeyebilirlik yaratmakta, hem de ileride çözümü çok çok zor olan sorunlara yol açmaktadır. Ölçeklema kavramında işin büyük kısmı tasarım ve geliştirmeye düşse de, uygulama sunucusunun da ölçek büyüdükçe buna dayanabilmesi gerekmektedir. Ve hatta daha iyi performans gösterebilmesi gerekmektedir.

Her ne kadar sorunlarla karşılaştığımızda sistemlerimizi dikey veya yatay olarak büyütsek de, buna ihtiyacımızı en aza indirebilmek uygulama sunucusunun görevlerinden biridir. Yaa düşünsenize gerçek hayatta ayakkabı alırken dahi, "bir numara büyüğünü al, gelecek sene de giyersin" diyen bizler, her zaman proje geliştirirken proje büyüklüğünün bu şekilde kalacağını düşünürüz. Ne ironi ama.


Performance Monitoring

Yaşadığımız sıkıntılar içerisinde ilk sıraları zorlayan ve zaman zaman birinciliği alan sorunlardan bir tanesi de, sistem üzerinde performans gözlemleme işlemini layığıyla yapamamızdı. Aşağıda bu sistemde kullandığımız 3rd party tool'ları sıralayayım.

JProfiler - Ürün ortamında kullanmak neredeyse imkansız, sisteme getirdiği yük hayli fazla, dolayısıyla kullanmak istiyorsan, Alfa veya Beta ortamlarında kullanabilirsin ki onu da denedim, o bile işkence idi.

GC.log - JVM içerisine birkaç parametre yazdığınızda sistem Garbage Collection ile ilgili tüm dataları bir dosyaya yazıyor, ve server'ın yaşam süresi boyunca bu dosyayı güncelliyor. Aman dikkat dosyayı yanlışlıkla silerseniz yeniden yaratmıyor. Taa ki sunucu restart olana kadar. Bundan sonrası ile ilgili iyi bir Konfigürasyon Yöneticisi arkadaşımın yazılarında detaylı bilgi var java hafıza problemleri ve GCViewer

JConsole - Neredeyse aralarında favorim budur. Ne ortamlara yük getiriyor, ne de bir sürü ayar yapmanız gerekiyor. Sadece JVM'e birkaç parametre yazıyorsunuz, bitti. Ama bu bile sistemde sadece memory'yi takip etmemize, mevcut thread'leri izlememize yarıyor, ve bundan öteye gidemiyordu.

TomcatListener - Bunu da ben yazdım. Aurora ve JBoss kullanıyorsanız, gayet kullanışlı...

Bu listeden sonra bile, yine de sistemde bir sıkıntı olduğunda bu sıkıntıyı bulmak, bulamadığımız durumlarda geçici çözüm üretmek yeterince zor oluyor. Bu durumda son çare olarak uygulama sunucusunu restart ediyoruz. Yine aynı noktaya geliyoruz, sistem çok yoğun çalışmadığı durumlarda bunu yapabiliyoruz, ama yarın sistem 7/24 çalıştığı zaman bizden hesap sormazlar mı?

BEA-000342 - Unable to initialize the server - Problems while parsing URL file

Weblogic, zaten başlı başına yönetmesi sorun olan bir uygulama sunucusu. Ve bu sabah anlamsız bir hata ile karşılaştım... Hmm bu arada server'lara bağlanmak için SSH Secure Shell 3.2.9 kullanıyorum...

Web console'dan instance'lardan birinde işleri yönetmek için yeterince thread kalmadığını farkettim (Idle thread=0)... Ben de instance'ı restart etmeye yeltendim... Kapatırken sorun yoktu, ama açmaya çalıştığımda aşağıdaki hatayı aldım.

[13.Haz.2007 08:55:57 EEST [Emergency] [WebLogicServer] [BEA-000342] [Unable to initialize the server: weblogic.management.configuration.ConfigurationException: Exception thrown
in operation getMBeansFromURL - with nested exception:
[javax.management.ServiceNotFoundException: Problems while parsing URL file:/.../load.mlet]]


Internet'te bir kaç post okudum, ama bahsedilen case'lerin hiçbirisi sorunu mu düzeltemedi... Son olarak bir postta birisinin regional setting'ini tr'den en'e geçirdiğinde sorunu düzelttiğini yazdığını buldum... Hemen console'u açtım ve "locale" yazdım,

bash-2.05$ locale
LANG=tr_TR.ISO8859-9
LC_CTYPE="tr_TR.ISO8859-9"
LC_NUMERIC="tr_TR.ISO8859-9"
LC_TIME="tr_TR.ISO8859-9"
LC_COLLATE="tr_TR.ISO8859-9"
LC_MONETARY="tr_TR.ISO8859-9"
LC_MESSAGES="tr_TR.ISO8859-9"
LC_ALL=

yukarıdaki değerleri gördüm, hemen arkadaşıma bu makinenin restart olduktan sonra local setting'inin değiştiğini ve eski haline yani ingilizce'ye almamız gerektiğini söyledim... O da kontrol amaçlı açtı, root ile login oldu, sonra kullanıcı değiştirip "locale" yazdı, ama benim gördüğüm ekranı görmedi, tamamen doğru idi onun gördüğü (Bu arada o da SecureCRT 5.0.5) kullanıyor...

Sonra bir kaç test yaptım ve sorunun cevabını buldum... Çok basit ama anlamsız bir bug idi, benim bütün sabah bu sorun ile uğraşmamı sağlayan...

SSH Secure Shell ile bir makineye login olup ardından "su - ?" ile kullanıcı değiştirdiğinizde ilk login olduğunuz kullanıcının locale bilgileri ile diğer kullanıcıya davranıyor, yani diğer kullanıcının locale değerleri ilk login olunan kullanıcının bilgileri ile replace ediliyor, bu da beklenilenin dışında bir davranış şekli sergilenmesine sebep oluyor...

Ben sadece "locale" ile ilgili olanı buldum, kimbilir başka neler bu şekilde taşınıyor

CruiseControl OutOfMemoryError - Part 2

CruiseControl ile alınan OutOfMemory hatası bir şekilde projenin genişlemesi ile nüksetti... Bu durumda CruiseControl versiyonunu 2.2'den 2.5'e yükselttik... Bunun sorunu çözmesini bekliyorduk... Ama sorun çözülmedi... Sorun yine çok fazla log üretilip, bu logun DOM objesine sığdırılamamasından kaynaklanıyor... Bu durumda yapabileceğimiz tek şeyi yaptık... Cruise'un çalıştırdığı ant scriptini 2'ye böldük... Ama bu bir çözüm değil tabiki, bakalım scripti daha ne kadar böleceğiz...

CruiseControl OutOfMemoryError - Part 1

DEV’de yaptığımız continous integration sisteminde(CruiseControl ile yapıyoruz);

CC build’i bitirdikten sonra yeni bir thread açmak istediğinde java.lang.OutOfMemory veriyordu... Biraz araştırdım ve aşağıdaki sorunla karşı karşıya olduğumuzu farkettim...

XML Logger conceptual usage

Dear Ant Developers

I'm a developer from Budapest, Hungary.

We have tried to use the CruiseControl in our continuous integration
process, but we run in some difficulties. We get a
java.lang.OutOfMemoryError.

After a few days spent near the CruiseControl I observerd, that the
CruiseControl uses the org.apache.tools.ant.XmlLogger for formatting
the ant output.

The problem is that our build process is so huge, that the result
doesn't fits in a DOM.

I have also tried to tell to the JVM to use more memory, but it
doesn't works.

I thing that conceptually it is not the best idea to use the a DOM implementation for logging
purposes. The log events musn't be stored in the memory for long time. (And this "long time"
in our case depends how long the build takes.) They should be flushed as soon as possible.

My question would be: Is there any change request which requests that
the XMLLogger not to use DOM API, rather some stream?

If there is, in which build the change will be released?

If not then I propose this change as a change request.

PS: By the time I solved the problem, I made a workaround, but the problem is still there...
:(

(The problem is that our build process is so huge, that the result doesn't fits in a DOM.)


Yani bizim build processin ürettiği output CC’nin loglama sınırını aşıyor, bunu yapan en büyük etken de stcheckout, çünkü output olayında aşan o...

Çözümler :

1) Çalıştırdığı her job için jvm ayarları ile oynanabiliyor...
jvmarg arg="-server"
jvmarg arg="-Xms64m
jvmarg arg="-Xmx512m"

Sonuç : Cık... Olmuyor...

2) Checkout kısmına filtre koyup output’u azaltmak, bu işlem yapıldığında oluşan output azaldığı için, sorun da kendiliğinden ortadan kalkıyor...