developen

Bir süre önce, projelerimizden birinde kullandığımız Silk Cenral Test Manager uygulaması ile ilgili garip davranışlar görmeye başladık. Örneğin olur olmadık zamanlarda uygulama sunucusu yazılımı (AppServ) donup kalıyor ve gerek web kullanıcılarına, gerekse de takvimlenmiş otomatik testlere sistem yanıt veremiyordu.

Malımızı bilsek de disiplini elden bırakmayarak sırasıyla uygulama sunucusu, veri tabanı katmanı, test çiftliği iletişimi (ExecServ yada Silk Central SilkTest entegrasyon noktaları) ile ilgili profil çıkardık. Sonunda farkettik ki SilkTest yüklü istemci sunucu ile bağlantısı kopup yeniden bağlanmaya kalkığında sunucu 100MB’a yakın ek bir hafızaya ihtiyaç duyuyordu.

Anlaşılan münferit kopmalar sorun yaratmıyordu lakin bir şekilde bizim sahip olduğumuz 35 SilkTest yüklü cihaz bir şekilde toptan gidip geldiğinde sunucumuz buna dayanamıyordu.

Yapılacak basitti, JVM Heap Size’ı yükseltmek. Windows Registry’de Silk Central’in alışık olduğumuz kayıtlarında -Xms değerini 512′den 1024′e çıkardık ve artık kısa vadeli bir çözümümüz vardı.

Daha sonra bu sıkıntının sebebini araştırdığımızda sunucumuzun önündeki ağ aygıtlarından birinde bir düzensizlik farkettik. Görünen oydu ki cihazdaki düzensizlik, bağlantının ender de olsa kopmasına sebep oluyordu.

Cihazı değiştirmek mümkündü ama her koşulda bu cihaz SPOF durumunda olacaktı ve kimsenin bir test yönetim aracı için ağ topolojisini değiştirmek gibi bir niyeti de yoktu.

Durumu dokümante ettik ve gerekli konrolleri süreçlerimize ekleyerek bu sorunu en azından 2008RX versiyonuna geçene kadar tekrar yaşamamak için önlemlerimizi aldık.

Eğer Silk Center’ın söz konusu davranışı biliniyorduysa, kullanıcıların böylesine hatalar ile karşılaşabileceklerini beklemek zor olmasa gerek. Sunucu tarafında görülebilecek geçici bir ağ bağlantısı sunucumuzun kalıcı olarak ve müdahale edilene kadar düzelmeyecek biçimde istemlere yanıt verememesine sebep oluyor ise vay halimize.

Ama tek sorun bu değil..

Yukarıda bahsettiğimiz konuda Borland Knowledge Base’de çok sonra bir yazıya rastladık ama iş işten geçmişti. Beni üzen nokta Borland teknik destek ekibinin bizi bu makaleye yönlendirememiş olmasıydı. Böyle bir makale mevcut ise, benzer sorunu başkaları da yaşamış diye tahmin ediyorum. Bizim makaleye ulaşmak için tek yolumuz sorunun sebebini bilmek olduğundan biz makaleyi bulamadık. Borland ise bu arada bizden 10 kez log dosyalarını isteyip, sunucuyu 30 kere tekrar başlattırmak ile meşguldu.

Ayrıca, Borland utanmasa kullanıcı kılavuzlarını bile bizden saklayacak hissi vermiyor mu size de? Ne yazık ki, tüm firmalar kendi teknolojileri ile ilgili mümkün olan tüm bilgiyi paylaşıp, üstüne üstlük bir de bunun çevresine bir kullanıcı topluluğu örme gayretindeyken, Borland’ın bu konudaki tutumunu anlayamıyorum.

Örneğin SilkTest üzerinde otomasyon geliştirmek için kullandığımız 4Test dilini öğrenmek istediğimizi farzedelim. Bu bilgiye erişmek istememiz durumunda, bilgiyi seve seve sizinle paylaşacak bir Borland beklerken, Google’da "4Test" şeklindeki bir aramada Borland ilk 40 sonuç içerisinde bile görünmüyor.

Uygulamanın Options menüsü değil ki bu bahsetmeye değer olmasın. 4Test basbayağı bir programlama dili! Ama öğrenmek isterseniz ya kursa gideceksiniz -ki kursta ne dil, ne programcılık öğrenilir- yada bireylerin gayretleri ile oluşturdukları 5-6 siteden bilgiyi elle derleyeceksiniz. Ama yine de, dil eklentileri gibi konularda bulabileceğiniz iki forum mesajından ötesi Internet’te mevcut değil.

Bu yaklaşımın Borland’a çok ağır kayıplar verdiğini, araçlarını kullanmayı bilen insanların az oluşunun, Borland ürünlerini tercih ederken bir kriter olduğunu hatırlatmak isterim.

Şimdi durum böyle iken, becerilerini sevdiğim SilkTest uygulamasını yada herhangi bir Silk aracını ben kime nasıl önerebilirim?

[Fotoğraf fabio  (CC Flickr)]