Ayın Olayları - Ocak 2008

Üfff, amma hararetli bir ay geçirdik, birbirini satın alan, satın alana.. Sun MySQL'i aldı, hemen ardından Oracle BEA'yı, ardından daha küçük çapta alımlar oldu.. Tabii ben de biraz geciktim bu yazıyı yazmakta.. Aslında Cuma günü yazacaktım ama güzel bir Uludağ tatili ve herhangi bir internet bağlantısı olmadan bir haftasonu geçirdim, dolayısıyla bu yazı da Pazartesi'yi beklemek zorunda kaldı...

(16.01.2008) - Sun MySQL'i 1 milyar dolara bünyesine kattı.

Herhalde yıla bu şekilde bir başlangıç yapmayı kimse beklemiyordu. 16 Ocak'ta bu resmi yazı ile Sun Microsystems, MySQL'i bünyesine kattı. Hayatına 1995'te başlayan MySQL 2006 senesinde de Oracle tarafından bir teklif almıştı, bu konuyu Oracle tried to buy open-source MySQL yazısında bulabilirsiniz. Bu satın alma Jonathan Schwartz'ı o kadar sevindirmiş olacak ki, Helping Dolphins Fly yazısında havalara uçuyor ve ardından In a Vortex yazısında satın alımdan önce MySQL CEO'su Marten Mickos ile yediği akşam yemeklerinde, satın almayı nasıl şekillendirdiklerini anlatıyor. Sun çalışanlarından birinin, MySQL Reaction Summary - Very Positive yazısı ve MySQL'den bir blog olayların iki taraf açısından ne kadar pembe göründüğünü çok güzel anlatıyor. Aynı şekilde yapılan basın toplantısı da bir hayli neşeli ve balayı modunda geçiyor, ayrıntıları Excerpts from the Sun/MySQL press conference yazısında bulabilirsiniz.

Bu satın alma sanırım en çok açık kaynak dünyasını etkiliyor. Matt Asay, What Sun's acquisition of MySQL means for the software industry yazısında, Sun'ın bu hamlesinin açık kaynak dünyasının merkezinde bir taht sahibi olmaya çalışması olarak yorumlanabileceğini söylüyor. Bu savı destekleyen diğer yazılar ise Sun’s planned deal to acquire MySQL will strengthen its open source story ve Sun To Acquire MySQL. MySQL'in Web dünyasında kullanım yüzdesi gözönüne alındığında Sun'ın yaptığı bu hamlenin bir hayli akıllıca olduğu da söylenebilir, nitekim Sun buys MySQL for $1 billion to take centerstage in the web economy yazısında bu konu detaylandırılıyor.

Bu satışın ardından en fazla konuşulan konu ise MySQL'in değeri ve Sun'ın yaptığı kar ya da zarar idi. Aşağıdaki linklerin her biri bu konuda yapılmış güzel yorumları içeriyor.

Jboss'u satan Maison Fleury'nin güzel bir yorumu, SUN acquires MySQL for $1Gazillion
Bu satıştan ne kar edildiğini anlamadığını anlattığı bir yazı, SUN acquires MySQL, Day2
Satış değerlerini irdeleyen güzel bir makale, More thoughts on Sun & MySQL

Bunun dışında bulabileceğiniz diğer faydalı linkler...

Sun Shines on LAMP
Sun to fork out $1 billion for open-source firm MySQL
Sun Microsystems has agreed to buy MySQL AB for $1B
Sun Plunks Down $1BN For MySQL
What Red Hat missed and Sun gained in MySQL
Sun to acquire MySQL


(16.01.2008) – Oracle BEA'yı 8,5 milyar dolara satın aldı.

Aynı gün ikinci bombayı Oracle patlattı ve 8,5 milyar dolara BEA'yı satın aldığını açıkladı, açık kaynak dünyasını daha çok Sun-MySQL olayı ilgilendirse de ilerisi için Oracle'ın bu hamlesi de oldukça stratejik oldu, bu stratejiyi ve yorumları Oracle-BEA: A fight against IBM, Sun, and open source, and a nasty hairball of technology yazısı çok güzel ifade ediyor.

Matt Asay (adamım), çok ilginç bir noktaya değiniyor, Oracle'ın bu satın almasının JBoss'un download sayısını nasıl artırdığını Oracle's acquisition of BEA is a big win for JBoss/Red Hat - the downloads don't lie yazısında detaylı bir şekilde açıklıyor.

Bu konu ile ilgili diğer linkler ise;

Oracle acquires BEA for $8.5 billion
An Open Letter to BEA WebLogic Customers - From GigaSpaces
Oracle set to buy BEA for $8.5B
Oracle-BEA: It aint over till it's over
The two-horse application server race: IBM and Red Hat/JBoss


(24.01.2008) - HP FOSSology ve FOSSBazaar ile açık kaynak dünyasına girdi.

Sun'ın açık kaynak hamleleri karşısında bir hamle de HP'den geldi, FOSSology ve FOSSBazaar isimli iki ürünle açık kaynak dünyasına girdi. SourceForge'un daha önce SourceForge Marketplace ürünü ile bu konuda yatırım yapmasından sonra HP'de FOSSBazaar ile aynı türden iş yaparak rekabeti artırmayı hedefliyor. HP'nin stratejisini Proprietary take-over of open source a fairy tale yazısı gayet net bir şekilde açıklıyor, işin arkaplanını ise The story behind HP's FOSSology open-source tools yazısı anlatıyor. Tabi tereciye tere satmaya çalışmak tepkileri beraberinde getiriyor. Açık kaynak dünyasının bu tür yardımcı ellere ihtiyacı olup olmadığını sorgulayan ve HP'nin stratejisini eleştiren yorumlarda yok değil, bunlardan birisi HP tells enterprises fear the source.

Bu konuda birkaç değişik link aşağıda;

HP May Accidentally Kill Black Duck & Palamida
The Open Source Census, OSS Discovery, FOSSology and FOSSBazaar!


(29.01.2008) - SpringSource, Covalent'i aldı

Ayın son alım satım işi ise ilginç bir şekilde, iki açık kaynak şirket arasında oldu, SpringSource Apache ürünleri ile ilgili bağlantısını güçlendirmek adına Covalent'i satın aldı. Tüm hikayeyi Springsource buys Covalent in enterprise Java push yazısında bulabilirsiniz. Maison Fleury ise bu olayı iki kamyonun çarpışmasına benzettiği yazısında bu konuyu detayları ile eleştiriyor, Spring Source merges with Covalent.

Diğer yazılar...

SpringSource acquires Covalent, gains Apache support network
Some Decisions are Easy – Like SpringSource Acquiring Covalent
SpringSource Acquires Covalent
When open source eats itself: SpringSource acquires Covalent
Open-source toolmaker acquires Covalent


SonSöz

Bu ay iştahı kabarık büyük şirketlerin olumlu, ya da olumsuz, karlı ya da zararlı, açık kaynak şirketlere yönelmesi ve bir hamlede yutması ile geçti. Tek dilediğimiz bu açık kaynak şirketlerin yerlerini yenilerinin alması.. Ve gidişattan umutlu olan ben, bu döngünün gerçekleşeceğini de tahmin ediyorum..

BEA-090402 ve boot.properties dosyası

Weblogic Admin Server'ın Admin şifresini değiştirdikten sonra bu hata ile ikinci kere karşılaşıyoruz. İlk seferinde kolayca çözmüştük ama bu sefer bizi bir hayli zorladı.

Hata mesajı gayet açık, diyor ki

Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.propePublish Postrties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.

Bu hatayı aldığınızda

1 - boot.properties dosyasını açıp password alanına şifreyi açık açık yazın. Sunucuyu restart ettiğinizde bu dosya şifrelenecek ve sunucu çalışmaya başlayacaktır. boot.properties dosyası eğer açılış scriptlerinde "-Dweblogic.system.BootIdentityFile" parametresi ile belirtilmemiş ise, altında olacaktır.


2 - Sorunu yukarıdaki şekilde çözemezseniz, o zaman sunucunun embedded LDAP'ı ile ilgili bir sorun oluşmuş olabilir (Büyük ihtimalle de cacheleme ile ilgili). Yapmanız gereken, / klasörü altındaki ldap klasörünün ismini değiştirmek, sunucu yeniden açıldığı zaman bu klasörü oluşturacaktır. Ve sorununuz çözülecektir (Yani en azından biz sorunu bu şekilde çözdük).

Umarım yardımcı olur.

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.

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