WebLogic 12.1.3 New Unicast Group Implementation

As of WebLogic 12.1.3 the implementation of unicast groups used for WebLogic clusters has changed.

What is new?

  1. There is a fixed maximum number of groups which is 10.
  2. Groups can be asymmetric.
  3. Servers are put into groups based on the hash value of their name (which obviously explains 2).

The group leader in a particular group might change if new servers are added but with dynamic clusters and generated cluster names this is rather unlikely.


The implementation has changed to make it more robust. The official Oracle documentation was initially wrong, but has been updated now.


When creating a classic cluster with servers surf1, surf2, surf3 or servers abc, jkl, xyz, every server ends up in its own unicast group, the total number of groups is the same as the number of servers.

When creating a dynamic cluster with let’s say 15 servers, server server-1 and server-11, server-2 and server-12, etc. are grouped together into one group.

unicast groups dyn cluster


It is not yet officially documented. Currently the official Oracle documentation still describes the old implementation. I described the new implementation in my Oracle Open World presentation together with Dave Cabelus.

Also there is a short web cast available here:

12 Things about WebLlogic 12.1.3

While you’re at it, make sure to download my Oracle Open World 2014 presentation slides for more ideas of what is new and newsworthy in WebLogic 12.1.3.

WebLogic 12.1.2 Node Manager Bug

Update: Bug fixed in WebLogic 12.1.3:

the bug described below seems to be fixed in WebLogic 12.1.3.  Node manager is now checking the state of the servers and correcting it if wrong.

node manager bug fixed

As usual, please feel free to provide your own experience in the comment section.

WebLogic 12.1.2 Node Manager Bug

While working with WebLogic 12.1.2 I discovered the following bug. Not sure though if the same would happen with 10.3.X.

Try the following:

- Create a domain with one managed server

- Configure a machine, then start the per domain node manager. Using the admin console start the managed server. All working lovely so far.

- It’s lunch time. Stop node manager. Then stop the managed server using the admin console. This shouldn’t be a big deal.

- After lunch: start admin server and node manager. Node manager reports managed server is running (which is not correct!).

- Try to start managed server and it will report an error message that it is in incompatible state. :(


Reproduce it!

Check the video below to reproduce it (just a quick recording, not a nice one):


1.) Interesting enough the server.PID file is removed when the managed server is shut down. However when restarting the node manager the managed server it is detected as running.

2.) With the node manager stopped, when forcing the managed server to shut down via admin console, ms1.state file shows FORCE_SHUTTING_DOWN, whereas when forcing the managed server to shut down (same button) with node manager running, the state is SHUTDOWN.


As you could guess, I wanted to spend my morning with sth else.
Comments welcome! Lunchtime for me now.


A Twitter Bootstrap Based Self-Measuring Application To Quantify the Effect of Precompilation on WebLogic – Part II

This is part II. It’s the part explaining how to measure the effect of precompilation.

The previous part, part I, covered the basics of precompilation. The next part, part III, will be about why even simple web applications should be different to what you and me were doing 10 years ago.

Measure the Effect of Precompilation

How NOT to do it

Don’t create a non-precompiled web application, run it with a load script that is simulating the requests of several clients, and then to compare run a precompiled version of the same web application with the same load. There is a rather big middleware vendor who is exactly showing this in a performance tuning course, but please folks, don’t try it at home.

There are quite a some reasons while at the end you cannot really measure a difference this way. To list a few: you load testing tool might record think times, several simulated clients won’t help, because after the first access the resource will be automatically compiled and so on.

A more clever way…

To measure how much time could be saved with precompilation I developed an application which is timing itself!

The application contains 10 JSP pages and automatically forwards from one JSP to another. The first JSP page will store the wall clock time and the last one will retrieve it and calculate the total execution time of the application. When running the application for the first time it will roughly take 9 times the time to precompile a JSP page plus 9 times the delay that the application is waiting until it is forwarding to the next JSP. Note, that you cannot measure the time to compile the first page, because it has to be compiled first before you can store the starting time.


If you subtract the time the application is waiting until automatically forwarding  to the next page (a value arbitrarily set to 3 seconds here) and divide it by 9, you will have an estimation the average time it takes to precompile a single JSP.

Even better: if you run the exact application again, it is already precompiled! That’s a handy cross check. This way you can even quantify the time it takes to load the JSP page or the class file.

Measurement Results

On my small Lenovo X220 laptop with a SSD the compilation of a single JSP page cost more than half a second. When running the app for the first time I get the following results:

Without Precompile Results


For the second run the results look as follows:


There is still some time needed per JSP but it is about 40 times smaller and more or less constant if you decide to run the precompiled version again.

Measure your own system, it’s an interesting benchmark. And let the world know – post your results here including your CPU, disk etc!


Hands-On Webcast

I recorded an a webcast showing how to use the application to measure the compilation time of  JSPs. You can watch the webcast using the following URL:

The application that is shown in this webcast above is a first prototype, without any design touches. Part III of this posting will explain who to achieve a beautifully looking design almost without any extra work!

Download the Application

The application that is provided to download here is the one that is described in part III of this posting. It has the same functionality but includes a tiny bit of web design using the Twitter Boostrap framework.

You can download the new and pretty application from the following location:




Not precompiling your apps will cost you more than half a second per JSP. Use the application above to benchmark your system.

For an application with 5000 JSPs you will waste an extra 40 minutes waiting.


A Twitter Bootstrap Based Self-Measuring Application To Quantify the Effect of Precompilation on WebLogic – Part I

Sounds cool, doesn’t it? Yet a bit academic – I agree. So why this title? It is as precise as it gets. And it’s less 140 chars, so I can even tweet it. Yet no worries, I’ll enjoy dissecting the headline for. There are a number of important messages. To make it more readable I will split it into three parts.

  • So let’s get to the topic right away (which by the way is precompilation).
  • To prove it makes a real difference, I will show in part II how you can measure the effect of precompilation since quite often people fail to do so.
  • Later in the cool part, part III, we look at some exciting bells and whistles for web applications (Twitter Bootstrap framework).


Why would you precompile your application?

Precompilation isn’t really necessary to make an application work correctly. WebLogic will compile necessary artifacts when they are needed. For example a JSP page which is not precompiled will be compiled at the time it is accessed.

Deploying an application without precompilation forces you to use lame excuses such as “It’s a bit slow right now, because it is running for the first time after deployment“. I am sure you don’t want to be remembered for lame comments. Running your applications without precompilation costs you time. And time is expensive.

What is the difference between precompilation and compilation?

Well, every Java class has to be compiled before it is executed by the JVM. The .java file is converted into a .class file. Other stuff, such as a JSP page could be deployed as is. It will then be compiled by WebLogic.

What can be precompiled?

If you don’t want to think about it, simply precompile your .war or .ear files. JSPs, web service artefacts and EJBs can be precompiled. Let’s look at the JSPs in more detail:

The JSP is converted into a servlet Java file which in turn is compiled into a .class file.

precompile a JSP

Precompilation after deployment?

You can request WebLogic to precompile your application right after deployment. To do so set the XML element <precompile>true</precompile> in the weblogic.xml deployment descriptor.

Many projects seem to use this solution, but it is certainly not the best idea. There are at least two reasons why I am not a big fan of this solution.

1.) Using the setting mentioned above precompilation happens right after deployment. This is the time when you want to show off your application. However, the application is not precompiled yet. Even worse, during precompilation system resources are used and the application is slowed down.

2.) When setting the <precompile> element, the application is precompiled after redeployment and after server restart. Do you really want your application to be precompiled after every server start?

Precompilation before deployment!

I recommend to precompile before you deploy. If building your application takes a long time, precompiling will make the process even longer. Then consider to have two different build targets: One for quickly testing your application without precompile, another one with precompile for load testing and deploying your application in an production environment.

After setting an environment suitable for running WebLogic commands from the command-line, all artifacts for an application surf.ear can be precompiled as follows:

java weblogic.appc surf.ear

Note, that the former JSP precompiler weblogic.jspc is deprecated.

Sometimes JSP fragments are included within a JSP yet these JSP fragments are not syntactically correct JSPs. Now if the fragments have a .jsp extension the precompiler will try to compile them and fail, therefore you should set the tag <precompile-continue>. Then precompilation will continue on errors.

Also there are faster compilers than javac. You can specify a different compiler with the switch -compiler.

Precompilation with Maven

If you use Maven to manage yours builds, Maven can call the application compiler appc for you when building you application. So everything in the paragraph above applies to building your application with Maven as well.

Possible Problems

If you precompile the deployment module before deploying, the classes will be added to the module and you should never see WebLogic compiling them again.

In case you are having problems with reoccurring precompilation, check the following issues:

  • Verify that the JDK version used to precompile is exactly the same as the JDK used to run WebLogic.
  • Make sure the time on the machine used for precompilation is synchronized with the machine where the application is deployed.


Precompilation isn’t a new topic, however it is often done the wrong way or it is not done at all.

Always precompile your deployments unless you manually create a quick distribution for testing during development. Don’t precompile using the <precompile> deployment descriptor after server start.

Add the precompile step into your continuous build process.

Additional Links:

WebLogic 12c deployment descriptor documentation for precompile:


Using WebLogic Maven plugin:


WebLogic Maven appc goal:


Review: WebLogic 12c Distinctive Recipes Workshops in AUS (Brisbane, Adelaide, Perth)

Reviews and Attendee’s Opinions

My WebLogic 12c training courses in AUS were a great success so I’d like to share the reviews with you. My special thanks go to AUSOUG president John Bushell for making this possible and Burke Scheld for organizing the events.


workshop perth


what Did you like about the workshop?


I got some really nice feedback after the presentation, here is all the answers.
Tricks and Tips :)
4/22/2013 3:31
Info about the non-core tools and tricks, very handy to get to hear about little odd things like that.
4/22/2013 3:24
Useful hints and tips, and a good overview of WebLogic 12c
4/22/2013 3:18
Useful open source software and administration tips
4/20/2013 2:13
It covered some left of field topics and points – some of the things I was hoping for.
4/19/2013 1:46 PMView
Good tips on tuning. Good opensource tool suggestions.
4/19/2013 11:44
4/18/2013 5:35
Tips and tricks on weblogic server management.
4/18/2013 4:10
Live demos, interesting content
4/18/2013 3:04
Opportunity to see things that are new to me in a class room environment
4/18/2013 2:55
Good independently sourced information about Weblogic features and capabilities. The idea of using virtual images helps to set a test environment quickly. The expertise of the presenter makes him capable of providing information that is beyond what you can find on the official Oracle docs.
4/18/2013 2:47
Good presentation, good explanations, aimed at the right level for me.
4/18/2013 2:16
We can discuss the good, as well as criticise the bad, features of Oracle software.
4/18/2013 2:02
Frank provided information about some useful tools that I wasn’t aware of. The overview of the new features in 12 was good. The configuration tips were handy. The cost of the workshop was very reasonable for the information gained from it.
4/18/2013 1:54
To get an overview of technologies and to discuss those.
4/18/2013 1:51
Well presented with references to resources for continuing help
4/18/2013 1:49
Nice pens from the presenter. And the idea of giving away a free book.
4/11/2013 2:59
Interesting insite into some open source tools that enhance the administration features of WebLogic
4/11/2013 2:43
Frank obviously knows his stuff, and backs up recommendations with excellent real world examples.
4/10/2013 1:26
Very well presented. Topics were relevant and current

Comments about presenter:

Good presenter, and well prepared. Always interesting
4/22/2013 3:18
Experienced and keen to answer questions and offer advice
4/20/2013 2:13
Good relaxed presentation with time to digest the material – thankyou well done
4/19/2013 1:46 PMView
Frank was a great presenter and his style was very professional. English was very good and understandable.
4/19/2013 11:44
Knowlegable, responsive, good communicator
4/19/2013 1:21
Frank had good experience and knowledge of weblogic server.
4/18/2013 4:10
Frank Munz was knowledgeable, concise and to the point
4/18/2013 3:04
Friendly, knowledgeable
4/18/2013 2:55
Well prepared, you can tell that he has a long experience with the platform
4/18/2013 2:47
Very good, knowledgeable, easily understood
4/18/2013 2:16
Frank is an excellent presenter and very knowledgeable about almost every aspects of Weblogic software.
4/18/2013 2:02
I liked Frank’s relaxed presentation style and the depth of his knowledge of the product.
4/18/2013 1:54
Excellent guy who knows what he’s talking about, broad range of experience and good examples.
4/18/2013 1:51
excellent presentation style
4/18/2013 1:49
I like how he is not biased towards a brand of technology but instead rationalises upon technology choice depending on immediate/long term goals.
4/11/2013 2:59
Great presentation – really informative and easy to follow.
4/22/2013 3:24
Good presenter, though he gets a little carried away reiterating key points :)
4/11/2013 2:43
Frank is organised and knowledgeable and presents with a comfortable, easy to listen to style.
4/10/2013 1:26
Very nicely presented
4/10/2013 12:34



Learn about my internal WebLogic 12c training offerings.