[Book Review] Apache JMeter

As always, I'm reviewing a book from the rising publisher "Packt Publishing".

First thing I thought when holding the book is : "Wow, it's slim" :)

I previously worked with JMeter in 2003 and I appreciated the power of that excellent tool. I also used OpenSTA which is different.

I didn't work enough time with it to be able to compare them.
Yet, just on a feeling level, I was more convinced by JMeter.

Thus, it's with excitement that I read the first pages.

The first chapters were all about the basics : very useful for beginners or people who don't know what JMeter looks like.

It's really a must-read if you're new to JMeter. Else, it's a good refresh about the way you design and configure your test plans, etc.

It provides the useful information to know and I especially appreciated the last chapter (advanced configuration) in which you learn about FTP among other functionalities.

Recommended for everyone who need to rapidly understand and use this tremendous tool.

 

http://www.packtpub.com/beginning-apache-jmeter/book/hp/jmeter-abr/

You may find a sample chapter here : http://www.packtpub.com/article/functional-testing-with-jmeter

 

Mots clés Technorati : book review,jmeter,packt publishing

Using JSP Precompilation in WebLogic

Typically, when you deploy an application, WebLogic Server tries to precompile the JSPs of your application.

But why ? How is it sensed to work normally ? What does this mechanism offer ?

That's what I'm going to explain in this article.

 

How did it work before ?

Well the original schema is the following : you typically deploy your application to your application server.

Once it's deployed, the first user that accesses a JSP has to wait a little bit, the time the JSP got compiled (transformed into a servlet).

As you can see, there is a small problem here : the fact that the JSP is compiled when a user accesses it.

It implies that some users may have to experience a delay when requesting a page, that's not exactly the idea of a good quality of service ...

That's this issue the precompilation was designed to address.

 

How do I setup precompilation ?

Nowadays, almost all application servers use precompilation.

As written above, precompilation is a way to prevent first users from compiling pages and then wait for them to show up.

You may use precompilation before or during a deployment.

You've got several ways to do so :

Using the weblogic.appc tool (pre-deployment compilation)

One good practice is to take the precompilation step and remove it from the deployment process.

When I say remove, it doesn't mean that we're going to suppress it, but rather than we will reorder the process.

Note : You could also use weblogic.jspc but it's deprecated.

Execute the appc tool like :

You'll see that the size of the WAR has changed (initially 2k)

If we take a closer look at the content of the WAR, we see a new directory and a new file :

As you can see, a new object "__index.class" has been created in the jsp_servlet directory, under WEB-INF\classes.

Note : When using Workshop, you may precompile your JSP by just checking a box :

Using the default mechanism : weblogic.xml (during deployment)

The default behavior is to not compile JSPs. If you want to turn that feature on, you'll have to specify it in your DD weblogic.xml.

 

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app

xmlns:wls="http://www.bea.com/ns/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd

http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
<wls:weblogic-version>10.3</wls:weblogic-version>
    <wls:context-root>JSP_Precompilation</wls:context-root>
    <wls:jsp-descriptor>
        <wls:precompile>true</wls:precompile>
        <wls:precompile-continue>true</wls:precompile-continue>
    </wls:jsp-descriptor>
</wls:weblogic-web-app>

Using the JSPClassServlet

You may also declare a servlet in your application that will take care of that task.

But the main con is the fact that you have to modify your application by adding extra components. To me, it's not a best practice.

But if you're interested in doing that : http://edocs.bea.com/wls/docs100/webapp/reference.html#wp73711

 

What's the difference when I precompile myself the JSP or when I let WebLogic do it ?

First of all, the deployment time :)

As the step of precompiling is doing prior to the deployment process, the latter is obviously shortened.

Second, in your directory tree, the location of your JSP won't be the same according to who does the precompilation job.

If you do it manually, compiled JSP will be located in the WEB-INF\classes directory of your WAR, as shown in the example with "weblogic.appc".

If you let WebLogic do it, it will be located (default) in the following tree (outside of the WAR), in the directory DOMAIN_HOME\servers\yourServer\tmp\_WL_user :

Or you may configure this directory by changing the attribute 'working-dir' in your weblogic.xml DD.

 

Mots clés Technorati : weblogic,jsp_servlet,jsp precompilation,weblogic.appc,working-dir

Understanding WebLogic Clustering

This post is intended to help WebLogic beginners to understand and then set up a cluster.

If you're an advanced user, no need to longer read ! :)

What's a cluster ?

A cluster is an abstract representation of a group of a application servers also known as instances. It mainly allows :

• failover, which provides, in case of crash of an instance, the ability to have a continued quality of service (QoS)
• load-balancing, which, as it names says, allows a strong load to be balanced between the different instances
• session-replication which combined to the failover mechanism, ensures that the user does not lose his/her session when an instance goes down

How does it work ?

From a WLS point of view, it's only a logical component you design and then, you affect the desired services to that cluster.

When I first worked with clustering, I thought I could make an HTTP call directly to the cluster, but it's not the case.

To do so, you will have to contact what's called a frontend.

That frontend is responsible for taking all the incoming requests and then dispatch them to the servers composing the cluster.

Concerning the inside communication, it lies on two mechanisms :

• IP Sockets (communication between two instances, for replication ...)
• IP Unicast or Multicast (used to know whether an instance is up or not ...)

More information

Note that BEA encourages the use of Unicast for a newly created cluster and Multicast when mixing WLS versions.

How to create it ?

Using the console or WLST, it's really easy.

1. Create the cluster ( Environnement > Cluster) by first locking an edit session and click "New".
2. Determine the kind of communication used for Heartbeat (Unicast recommended)
3. Enroll all the managed servers
4. Configure the "Cluster Address" (useful for EJBs, see below) and the frontend host & port (useful for webservices)

You're done !

Choosing your HTTP Frontend

Well, you've got the choice between :

• an HTTP server (Apache, IIS, SunOne ...) + the WebLogic plugin
• a DNS server
• a hardware load-balancer (Alteon, BigIP ...)
• another WLS instance, with the HttpClusteredServlet (available when you create a domain, for instance)

The choice depends on your will and on what your society allows :)

Failover : easy to configure !

The failover mechanism takes place when an instance goes down in a cluster. The users accessing the website should not be aware of that problem.

That's where the frontend plays an important role : it's responsible for routing all the new requests to the other available servers.

How does the frontend know which server is available and which is not ? Well, it depends of the nature of the frontend !

For instance, for an Apache WebServer configured with the WebLogic DSO module,

the initial server list is initially composed of a comma-separated succession of IP addresses and ports like the following :

<IfModule mod_weblogic.c>
WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001

[...]
</IfModule>

After the first call, the cluster maintains what's called the DSL or Dynamic Server List, thanks to the heartbeat.

When a server fails to respond to a heartbeat request, it is flagged as "failed" and is automatically removed from the DSL.

This list is supplied for each request to the frontend which uses it to dispatch requests.

For a phyical load-balancer, like an Alteon or BigIP, it performs the heartbeat itself.

If a server fails to answer, then the load-balancer removes this server from the list of potential ready servers.

Session replication

This mechanism is linked to the failover mechanism. When an instance goes down, new users must not only be routed to the fallen instance,

but users who were working on that instance (that is to say who were having an active session) must be able to keep doing what they were doing.

In other words, all the session initiated on that instance continue to live on another server.

The principle is simple, each session started on a server (aka primary server) is replicated on another server (aka secondary server).

The update only takes place at each set() method invocation.

Usually, it is recommended to have a session whose size is not over 40k, mainly for performance reasons.

Taken from the documentation, the format of a session cookie is:

sessionid!primary_server_id!secondary_server_id

where:

• sessionid is a randomly generated identifier of the HTTP session. The length of the
  value is configured by the IDLength parameter in the <session-descriptor> element in
  the weblogic.xml file for an application. By default, the sessionid length is 52 bytes.
  
• primary_server_id and secondary_server_id are 10 character identifiers of the
  primary and secondary hosts for the session.
  

Note: For sessions using non-replicated memory, cookie, JDBC, or file-based session persistence, the secondary_server_id is not present.

For sessions that use in-memory replication, if the secondary session does not exist, the secondary_server_id is “NONE”.

 

For increased performance, BEA strongly recommends to use Native IO versus pure Java socket readers. See my post about muxers to know more.

I strongly encourage you to go there : http://edocs.beasys.com/wls/docs100/cluster/failover.html#wp1039991 to read about "replication groups".

I wanted to make a sum up, but it's really well explained there + you will have pictures to make your understanding quicker.

Load-balancing ? Not harder to configure than failover ...

Well, it depends on what you want to load-balance. Because, according to the components you want to balance, the mechanisms are not the same.

Dealing with servlets, jsp and everything that lies on HTTP for the communication,

you have 4 solutions (see "Choosing your HTTP Frontend) but I'm going to list only the two which are WLS-related :

=> HttpClusterServlet, which is a simple servlet whose role is to provide a route, based on the round-robin algorithm.

It is often created while setting up your domain with the Config Manager. http://edocs.beasys.com/wls/docs100/cluster/setup.html#wp759939

=> a typical HttpServer such as Apache, IIS, SunOne, on which you will have to deploy a WLS plugin.

The configuration is the same than the one required for Failover (see above)

 

For EJBs, the load-balacing is made thanks to the cluster address configuration.

To make it easier to understand, you've got to understand that when you have a reference to an EJB,

it's a stub supplied by WebLogic Server which encapsulates/wraps the "real" EJB stub. The WLS stub is "replica-aware" :

that means that it is aware of all the EJBs deployed on other managed servers.

That's this mechanism which is used to perform load-balancing for EJBs.

 

Taken from the documentation : in WebLogic Server cluster, the cluster address is used in entity and stateless beans to construct the host name portion of request URLs.

You can explicitly define the cluster address when you configure the a cluster; otherwise, WebLogic Server dynamically generates the cluster address for each new request.

Allowing WebLogic Server to dynamically generate the cluster address is simplest, in terms of system administration, and is suitable for both development and production environments.

What about JNDI across the cluster ?

I won't say what's already well explained in the official documentation !

 

http://edocs.bea.com/wls/docs100/cluster/features.html#wp1007508

 

Mots clés Technorati : WebLogic Server,Cluster,Clustering,load-balancing,failover,session replication,replication group

Installing Alfresco on WebLogic 10.3 and Oracle XE

Everybody knows Documentum from EMC² but there is also a free tool, Alfresco, created by the father of Documentum,

which is also an excellent solution for keeping a community live and documented :)

 

As every other interesting tool, I tried to install it on my top application server and my top database !

This time, it wasn't too hard, even if it wasn't over-documented ...

Download Alfresco

Well it sounds obvious but you first have to download it.

Don't take the Tomcat version, but the WAR version. (it comes in a zip ~52Mb)

Make some changes to have it compatible with WebLogic classloader

As usual, this war comes with a variety of libs, and some of them may conflict with those embedded in WebLogic.

Then I recommend in this case to use the Filtering Class Loader mechanism.

To have it configured, you first have to turn you WAR in an EAR like :

Note : When I'm debugging some stuff while installing it, I prefer to use the exploded format, which is easier to update config files, adding extra libs and so on.

Configure it to use an Oracle database

I noticed that Alfresco is sensed to use a mySQL database.

To switch to an Oracle DB, you will have to modify some configuration files.

First one : repository.properties (alfresco.war\WEB-INF\classes\alfresco)

Look for the following section and change what's needed.

# Database configuration
db.schema.update=true
db.driver=oracle.jdbc.OracleDriver
db.name=xe
db.url=jdbc:oracle:thin:@localhost:1521:XE
db.username=alfresco
db.password=alfresco
db.pool.initial=10
db.pool.max=20

Second one : hibernate-cfg.properties (alfresco.war\WEB-INF\classes\alfresco\domain)

It's quite easy : only one line to change to reflect the new Hibernate dialect.

#
# Hibernate configuration
#
# hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect
hibernate.dialect=org.hibernate.dialect.OracleDialect

 

To see whether it's really been taken into account, check the logs :

 

16:41:06,031 INFO [org.alfresco.repo.domain.schema.SchemaBootstrap] Schema managed by database dialect org.hibernate.dialect.OracleDialect.

 

If everything went well, your DB schema should have been created. You may take a look using your favorite DB tool :

Windows library (optional)

So far, if you're working with Windows, it works, but there is still an error :

 

java.lang.UnsatisfiedLinkError: no Win32NetBIOS in java.library.path

 

As said, you have to add the the lib called "Win32NetBIOS.dll"

(located in the bin directory of your Alfresco distribution) in either the java.library.path or in the Windows DLL directory (Windows/system32).

Enjoy ! :)

 

Mots clés Technorati : Weblogic,Oracle,Alfresco

How to deploy Hudson on WebLogic ?

Hudson is an excellent continuous integration engine !

But if you have already tried to use it on WebLogic, you may have encoutered the following error :

 

This error translated in English says :

"Your servlet container loaded its own Ant version, preventing Hudson to work.

Maybe you could try to fix that by either copying the Hudson lib in your container, or reversing the classloader tree with the child-delegation-first."

If you already read about the FilteringClassLoader mechanism article, it should ring a bell to you ! :)

Well, that's exactly what we are going to do here.

First, as Hudson is available only in WAR format, we are going to create an EAR (because the filteringClassLoader only applies to enterprise applications).

It's easy : just add a "META-INF" folder, like :

 

ROOT_Folder

----> META-INF

    ----> application.xml

    ----> Manifest.mf

    ----> weblogic-application.xml

----> hudson.war

 

Your weblogic-application.xml should look like :

 

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application xmlns:wls="http://www.bea.com/ns/weblogic/weblogic-application" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/javaee_5.xsd http://www.bea.com/ns/weblogic/weblogic-application

http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd">
<!-- server-version: 10.3 -->
    <wls:application-param>
        <wls:param-name>webapp.encoding.default</wls:param-name>
        <wls:param-value>UTF-8</wls:param-value>
    </wls:application-param>

    <wls:prefer-application-packages>
        <wls:package-name>org.apache.*</wls:package-name>
    </wls:prefer-application-packages>
</wls:weblogic-application>

 

In blue, we declared the org.apache package to be loaded from the application first.

Then after that, zip the content (and NOT your root folder) of your root folder such as :

 

 

Then deploy it on WebLogic and you should normally be able to access Hudson !

 

 

Mots clés Technorati : hudson,filteringclassloader,ant,weblogic