Axis 1.4 Infinite Loop(%100 CPU problem)

If you are somehow still using axis 1.4 framework as your web service client implementation, you may suffer from some thread safety problems.


We have faced one of these, and when we researched about it, it was specified as a bug also in axis community => https://issues.apache.org/jira/browse/AXIS-2647

The problem seems to be an infinite loop problem due to a concurrent access to a nonsynchronized object. Threads running the method getFieldNameForElement cannot leave the method, causing threads in the application server to run out and also %100 CPU problem in the machine.

Applying the patch given in this link resolves the issue.

The patch simply consists of making the acces to fieldElementMap(HashMap instance) synchronized in getFieldNameForElement method of TypeDesc.java class;

mod_jk, mod_proxy and mod_proxy_ajp

So each of them being apache modules to make Apache web server and Tomcat based application servers(Tomcat/JBoss) communicate, the question is which is what and which one to use ?

The Apache JServ Protocol (AJP)

The Apache JServ Protocol (AJP) is a binary protocol that can proxy inbound requests from a web server through to an application server that sits behind the web server.
AJP runs in Apache HTTP Server 1.x using the mod_jk plugin and in Apache 2.x using the provided Proxy AJP, mod_proxy and proxy balancer modules together.
AJP with it's current version 1.3 is a constant binary protocol. Constant means that the connection between web server and application server is presumed to stay open once established for the system lifetime. This in essence makes web server and application server a single system from the users point of view.


mod_jk

mod_jk is an Apache module used to connect the Tomcat servlet container with web servers such as Apache, iPlanet, Sun ONE (formerly Netscape) and even IIS using the Apache JServ Protocol.
mod_jk is not bundled with apache release by default, it should be added manually.
The binary releases can be downloaded from the following link : http://tomcat.apache.org/download-connectors.cgi

mod_jk uses the AJP protocol.


mod_proxy_http and mod_proxy_ajp

mod_proxy is an optional module for the Apache HTTP Server.
This module implements a proxy, gateway or cache for Apache. It implements proxying capability for or AJP13 (Apache JServ Protocol version 1.3), FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and (since Apache 1.3.23) HTTP/1.1. The module can be configured to connect to other proxy modules for these and other protocols. So mod_proxy_http is the http

Since Apache 2.0, proxy features are divided into several modules in addition to mod_proxy: mod_proxy_http, mod_proxy_ftp, and mod_proxy_connect — moreover, caching is provided by mod_cache and related modules.[9]

Since Apache 2.2, mod_proxy_ajp and mod_proxy_balancer have been added as well. (Apache 2.2 ships with advanced mod_proxy set of modules that have some of the mod_jk capabilities namely AJP protocol and integrated load balancer.)


So mod_proxy_http and mod_proxy_ajp are part of mod_proxy, using http and ajp protocols respectively.

mod_proxy module comes with the apache distribution by default, so there is no need to a separate installation.


Since ajp protocol is a binary protocol(mod_jk/mod_proxy_ajp), when compared to http protocol(mod_proxy_http), some can say the performance will be better. But this should be expected as a small ratio in overall performance.

The foundation of mod_jk is AJP protocol, that is sometimes known as binary http protocol. The point beside the custom binary protocol is that the client request data is already decoded inside web server, so there is no need for doubling that procedure in the application server as well. Next, the standard request and response headers are passed as atoms in a form of two byte sequence instead as strings, thus lowering down the network traffic between web and application server.

However there is one major limitation of the AJP protocol, and that is it's maximum packet size. The packet size is limited to little bit less then 8K. With latest mod_jk and Tomcat versions the packet size can be enlarged to 64K, but it's still limited. Mod_proxy(ajp) still has no such capability, so it's maximum packet size is 8K. This can be problem with large client requests, especially with some custom SSO modules that store huge session data inside cookies or custom headers. In case there is a need to support the huge client requests, the only solution is to use http in favor of AJP protocol.

To compare mod_jk to mod_proxy_ajp; each use the ajp protocol. mod_proxy_ajp comes with all the controls and (relatively) ease of configuration of mod_proxy, with the speed benefits of the AJP protocol (instead of using HTTP). But it is not as mature as mod_jk, this should also be taken into account.


If you need to encrypt the communication between apache(httpd) and application server then this is easier with mod_proxy_http, you can just switch from the http to the https protocol. mod_jk and mod_proxy_ajp uses the AJP protocol which doesn't support encryption so you have to implement that function separately via an SSH tunnel, IPSec or similar. This can bring some configuration complexity to the apache web server-application server communication channel.



mod_proxy vs. mod_jk

So what to use when? It depends on your topology. In case you already have or need Apache 2.2 functionality you have the choice to choose between mod_proxy and mod_jk. Mod_jk works very well on Apache 2.2, so it all depends on the functionality needed:


mod_proxy
Pros:
No need for a separate module compilation and maintenance. mod_proxy, mod_proxy_http, mod_proxy_ajp and mod_proxy_balancer comes as part of standard Apache 2.2+ distribution
Ability to use http https or AJP protocols, even within the same balancer.
Cons:
mod_proxy_ajp does not support large 8K+ packet sizes.
Basic load balancer
Does not support Domain model clustering

mod_jk
Pros:
Advanced load balancer
Advanced node failure detection
Support for large AJP packet sizes
Cons:
Need to build and maintain a separate module



Resources:

https://developer.jboss.org/people/mladen.turk/blog/2007/07/16/comparing-modproxy-and-modjk

JIT Compiler Nedir ?

JIT Compiler, JRE dediğimiz Java Runtime Environment'ın bir bileşenidir, misyonu java uygulamalarının performansını runtime seviyesinde artırmaktır.

Normalde bildiğimiz gibi bir java kaynak kodu compile edildiğinde oluşan class dosyası byte koddan ibarettir, runtime esnasında doğrudan bu byte kodlar jvm tarafından interpret edilir(class dosyasının yüklenmesi, byte kodların anlamlandırılması ve gereğinin yapılması). Bu da runtime esnasında ekstradan bir cpu ve memory tüketimi anlamına gelir, dolayısıyla java uygulamaları native uygulamalara göre bir performans dezavantajına sahiptir. İşte bu dezavantajı minimuma indirmek için JIT Compiler dediğimiz bileşen devreye giriyor.

JIT Compiler bir metod çalıştırılacağı zaman bunu her defasında ilgili class dosyasından interpret etmek yerine, metodun byte kodlarını runtime esnasında bir kere compile ederek native makine diline çevirir ve sonraki metod çağrıları bu optimize edilerek compile edilmiş native kod üzerinden gerçekleşir. Runtime esnasında kod çalıştıkça elde edilen istatistikler optimizasyona ışık tutar.

Runtime esnasında compile işlemi gerçekleştirmek tabi ki maliyetsiz bir işlem değildir, bu nedenle bir metod daha ilk çağrıldığında JIT compiler tarafından compile edilir demek doğru değil. Burada bir optimizasyon söz konusu, metodun çağrılma sayısı jvm seviyesinde tutulur ve bu sayı belli bir değerin üzerine çıktığında compile işlemi gerçekleşir. Sonraki metod çağrılarında artık compile edilmiş kod kullanılır. Bu arada metodun çağrılma sayısı sıfırlanır ve tekrar sayılmaya başlanır, sayı yeniden threshold değerine ulaştığı zaman tekrar compile işlemi gerçekleştirilir. Önceki compile işlemine göre daha fazla optimizasyon seçeneği kullanılır. JIT Compiler tarafından gerçekleştirilen bu yeniden compile etme işlemi maksimum optimizasyon seviyesi yakalanana kadar sürdürülür.

Optimizasyon örneği;

Optimizasyon öncesi kod

class A {
B b;
public void newMethod() {
y = b.get();
...do stuff...
z = b.get();
sum = y + z;
}
}
class B {
int value;
final int get() {
return value;
}
}

Optimizasyon sonrası kod

class A {
B b;
public void newMethod() {
y = b.value;
...do stuff...
sum = y + y;
}
}
class B {
int value;
final int get() {
return value;
}
}


JIT Compiler'ın -Djava.compiler=NONE veya java -Xint opsiyonu ile devre dışı bırakılması mümkündür, ama önerilmez.