pengeunpedi pengeunpedi pengeunpedi
  penguenyuvasi   pengulog   arşiv   bulut   rss


tomcat'i ipv4 olarak çalıştırma

Sunday, May 3, 2009 2:53:21 PM tarihinde Fırat KÜÇÜK tarafından gönderildi.

Bazı uygulamalar varsayılan olarak ipv6 ağlar için etkinleştirilmiş olarak gelir. Bu nedenle az da olsa performans kayıpları yaşanabilir. Örneğin linux dağıtımınızda ipv6 açık ise /etc/modprobe.d/aliases dosyasından düzenleyebilirsiniz.

alias net-pf-10 off ipv6

Bu şekilde linux tüm ipv4 adresleri de ipv6 adreslerine çevirerek işlem yapmaktan vazgeçer. Fakat varsayılan olarak ipv6 ile işlem yapan servisler varsa bunlar için ilgili yapılandırma seçeneklerini ayarlamanız gerekecektir. Apache Tomcat için /bin/catalina.sh veya windows kullananlar /bin/catalina.bat dosyasının başına CATALINA_OPTS değişkenini ekleyebilirler. İsteyen kullanıcılar ise bunu çevresel değişken olarak tanıtabilirler. Ben kendi adıma daha kolay yol olan dosyaya ekleme metodunu tercih edicem. Linux kullanıcıları;

CATALINA_OPTS="-Djava.net.preferIPv4Stack=true"

şeklinde dosyanın 2. satırına ekleme yapabilirler. Tabiki ilk satırdaki (#!/bin/sh) ilişkilendirilmiş yorumlayıcıya müdahale etmemek gerekli. Bu nedenle 2. satıra yazmamız yeterli olacaktır.

Windows kullanıcıları ise aşağıdaki eklemeyi yapabilirler.

set CATALINA_OPTS=-Djava.net.preferIPv4Stack=true
java, sorun çözümükaynak | yorumlar [1]


telnet ile tomcat kapatma

Sunday, May 3, 2009 2:27:48 PM tarihinde Fırat KÜÇÜK tarafından gönderildi.

Apache Tomcat belgelerini incelerken server.xml ayar dosyasının üst seviye elemanı olan Server etiketine ait shutdown adlı bir özellik olduğunu farkettim. Evet tomcat'e ait bir kapatma portu bulunuyormuş. Bu shutdown özelliği ile de kapatırken Tomcat'e ileteceğiniz komut bulunuyor. Varsayılan olarak ayar şu şekilde:

<Server port="8005" shutdown="SHUTDOWN">

Bu demek oluyor ki 8005 portuna SHUTDOWN verisi yollarsak tomcat kapatma işlemini başlatacaktır. Bu port varsayılan olarak yerel döngü (local loopback) üzerinde çalışyor. Ama iptables yönlendirmeleri ile kendi ağınızdan tomcat'i kapatabileceğinizi ön görüyorum.

# telnet localhost 8005
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SHUTDOWN
Connection closed by foreign host.
inceleme, javakaynak | yorumlar [0]


jsf akıllı mbean yükleme mekanizması

Sunday, May 3, 2009 8:26:16 AM tarihinde Fırat KÜÇÜK tarafından gönderildi.

JSF çatısında bir POJO (Plain Old Java Object - Bildiğiniz Sıradan Java Nesnesi) oluşturarak MVC paradigmasının model kısmını oluşturabilmektesiniz. Bu ASP.NET çatısında codebehind olarak geçiyor. JSF'te Codebehind'a tam karşılık gelen kavram ise backing bean kavramı Buna ilaveten POJO'lar veritabanı varlıklarında (JPA Entities) ve diğer tüm bean çeşitlerinde kullanılabilmekte.

JSF'te bir backing bean yazarken en çok aklıma takılan husus beanlerin küresel olarak tanımlanması idi. faces-config.xml dosyasına örnek bir kaç bean tanımlayalım;

  <managed-bean>
    <managed-bean-name>requestBean1</managed-bean-name>
    <managed-bean-class>rtest.RequestBean1</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
  </managed-bean>

  <managed-bean>
    <managed-bean-name>requestBean2</managed-bean-name>
    <managed-bean-class>rtest.RequestBean2</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
  </managed-bean>

  <managed-bean>
    <managed-bean-name>requestBean3</managed-bean-name>
    <managed-bean-class>rtest.RequestBean3</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
  </managed-bean>

Şüphelerim şu yöndeydi; Bir talep esnasında tüm bu bean'ler işleniyor muydu? Eğer böyle ise karmaşık bir sitede onlarca hatta yüzlerce request alanında bean olabilirdi. Ve kullanılmayacak olan bir çok bean gereksiz yere RAM alanına aktarılacak ve sistem kaynaklarını kullanacaktı. Bunu yapıcıya basit bir çıktı ifadesi yazarak test ettim.

package rtest;

public class RequestBean1 {

  private String test;

  public RequestBean1() {
    System.out.println("----------------------------------------------");
    System.out.println("RequestBean1");
  }

  public String getTest() {
    return test;
  }

  public void setTest(String test) {
    this.test = test;
  }
}

JSF sayfamızda şu şekilde:

<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">
<f:view>
</f:view>

Senaryoya göre eğer bir yükleme olacak ise bean başlatılıp yapıcı metodu çalıştırılacak ve sunucu loglarında çıktıyı görebileceğiz. Netice itibari ile bu gerçekleşmedi. Şimdi bean'e talepte bulunulacak şekilde JSF sayfasının fview kısmını değiştirelim.

<f:view>
  <h:outputText value="#{requestBean1.test}" />
</f:view>

Şimdi sunucu loglarında görüntüleme sağlayabildik. Netice itibari ile JSF geliştiricilerinin yapmış olduğu akıllı yükleme sayesinde kaynak tüketiminin önüne geçilmiş omakla beraber hızlı uygulama geliştirme paradigmalarından da ödün vermemiş oluyoruz. Buna ilaveten bir hatırlatma yapmakta fayda var. Eğer bir bean kullanıyorsanız. Bunun çalışma alanını olabildiğince düşük seçmeniz mantıklı olacaktır. request alanında (scope) yapılacak bir işlemin session veya application ile yapılması kaynak tüketimini doğrudan etkileyecektir.

inceleme, java, jsfkaynak | yorumlar [0]


apache mpm_prefork module

Friday, May 1, 2009 9:16:58 PM tarihinde Fırat KÜÇÜK tarafından gönderildi.

PHP ile program yazanlar apache sunucusuna ve Apache'ye ait mpm_prefork modülüne kulak aşinalıkları vardır. Gerçi modül diyoruz ama an itibari ile Ubuntu'da prefork modülünü yüklediğimizde /usr/sbin içindeki ana çalıştırılabilir dosya olan apache2'nin değiştiğini gördüm. Windows'ta bu yapıyı test etmedim. Windows'ta çalışma kipleri arasında geçiş nasıl sağlanıyor bir malumatım yok.

Sunucu taraflı dil olarak PHP ve sunucu olarak Apache kullanıyorsanız. PHP dilinin getirmiş olduğu çeşitli sunucu taraflı kısıtlamaların bulunduğunu söylemeliyim. Tabi bu PHP geliştiricilerini üzmesin. PHP oldukça sade ve hızlı bir dil. Büyük destekçileri olduğunu biliyorum. :)

Konunun evveliyatına deyinirsek; Daha önceki teknoloji olan CGI (Common Gateway Interface)'da benzer bir metod ile işlem yapıyordu. CGI ile yazılan uygulamaları hep harika ve daha zevkli bulmuşumdur. :) Şahsi kanaatim bir web programcısı diğer dillere geçmeden öncelikle CGI ile program yazmalıdır. Bu web uygulamalarının çalışma mantığı hakkında olabildiğince fikir sahibi olmamımızı sağlar.

Uç birim/Konsol uygulamaları ya da diğer bir değişle siyah ekranlarımız için yazdığımız uygulamaların çalışma mekaniği aynıdır. Konsol uygulamaları Standart Çıktı (Standart Output) ve Standart Girdi (Standart Input) ile etkileşirler. Ekrana yazacağımız şeyleri standart çıktıya aktarırız. Ekrandan okunan şeyler ise standart girdiden okunur. Sistemde küresel bir değişken varsa bunlar da çevresel değişkenler sayesinde elde edilir.

<?php echo(readline("Yazı: ")); ?>

Yukarıdaki örnek standart girdiden okuyup, standart çıktıya yazan bir PHP programıdır. Uzun lafın kısası CGI bu tarz uygulamalar için bir arabirim sunar. Web sunucu ile girdi ve çıktı aygıtları arasında. Siz HTTP üst bilgi başlıkları (Header) dahil olmak üzere tüm sisteme hakim olursunuz.

Apache üzerinde PHP CGI kipinde çalışabildiği gibi, mod_php üzerinde de çalışabilmekte: PHP'i CGI olarak çalıştırmak istersek:

.htaccess dosyasına;

Allow from       All
Options          ExecCGI
AddHandler       cgi-script .php

test.php dosyasına:

#!/usr/bin/php
<?php
echo("Content-type: text/plain\n\n");
echo("merhaba");
?>

Dosya CLI interpreter tarafından işleneceğinden çalıştırma yetkilerine sahip olması gereklidir. Çocuk süreç alt bir süreç daha oluşturup yorumlayıcıyı çağırır.

root     15016  0.0  0.3  33908  3124 ?        Rs   May01   0:00 /usr/sbin/apache2 -k start
www-data 15021  0.0  0.1  34528  1784 ?        S    May01   0:00  \_ /usr/sbin/apache2 -k start
www-data 27404  0.5  0.4  31164  4596 ?        R    May01   0:00  |   \_ /usr/bin/php /var/www/test.php

PHP gerek mod_php ile çalışsın gerekse mod_cgi ile temeldeki Apache çalışma sistematiği mpm_prefork modülü üzerine olacaktır. Bu her talep için ayrı bir çocuk sürecin hizmet etmesi manasına gelir. Fakat mod_php ile çalışırken ek bir çocuk süreç daha olmayacağından ve çıktı/girdi aygıtlarını kullanmayacağından uygulamanın daha hızlı çalışacağını söyleyebiliriz.

inceleme, linux, phpkaynak | yorumlar [1]




1


pengulog

her hakkı erkektir © 2008 e-posta