You are here: Home / Archives for WebLogic 12c Book

Using HTTP instead of T3 for WebLogic Scripting Tool (WLST)

March 18, 2015 by Leave a Comment

A friend of mine asked why the WLST connection from the Jython based scripting tool is only working with t3. IMHO using t3 for WLST is not a big deal since it is a WebLogic tool talking to WebLogic itself, and t3 was built and optimised for that.

You might want to replace t3 with HTTP anyway, e.g. for one the following reasons:

– for the sake of standards, you want to use as many standard protocols as possible. t3 is WebLogic vendor specific.

– you might have problems with t3 when connecting through firewalls.

 

Easy Solution

Here is the good news. Unknown to many, WLST does work with HTTP if you enable tunneling for the Admin server ( Admin Server / Protocols / General ).

Screen Shot 2015-03-02 at 10.24.50

then it’ possible to use HTTP for WLST:

wls:/offline> connect('weblogic','welcome1','http://localhost:7001')
Connecting to http://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server "AdminServer" that belongs to domain "simon".
Warning: An insecure protocol was used to connect to the 
server. To ensure on-the-wire security, the SSL port or 
Admin port should be used instead.

Using a Network Channel

Alternatively if you want to separate the admin traffic but not use SSL (which would be enforced e.g. by using the administration port feature of WebLogic), you could create a network channel under Admin Server / Protocols / Channels for the t3 protocol, e.g. on port 8888 and enable “Tunneling” for that channel. Note that http is already enabled for the channel but this is not enough, you must enable tunneling.

Screen Shot 2015-03-02 at 10.15.29

 

Administration Port

The third and most secure possibility of course is using tunneling in combination with the administration port.

 

Comments:

– You do not need the administration port for using WLST with HTTP.

– It’s not required to change WLST from t3 to HTTP. This posting only shows how it can be done if one of the reasons above apply to you.

– Changing other clients from t3 to IIOP or so, e.g. JMS clients or standalone Java clients using RMI typically has more implications which are not discussed here.

 

More?

If you want to learn more about the basics WebLogic scripting tool I recommend to start with the following web cast.

Filed Under: oracle, WebLogic 12c Book Tagged With: , , , , ,

WebLogic 12.1.3 New Unicast Group Implementation

October 12, 2014 by 3 Comments

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.

Why?

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

Example

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

More?

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.

Filed Under: oracle, WebLogic 12c Book Tagged With: , , ,

WebLogic 12.1.2 Node Manager Bug

August 1, 2013 by 19 Comments

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. 🙁

bug

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.

 

Filed Under: oracle, WebLogic 12c Book Tagged With: , , , ,

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

July 5, 2013 by Leave a Comment

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.

precompilation

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:

res2

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:

https://munzandmore.com/downloads/wls12book/ForwardBS.war

forwardbs

Conclusion

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.

 

Filed Under: oracle, WebLogic 12c Book Tagged With: , , , ,

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

July 4, 2013 by 3 Comments

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).

Precompilation

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.

Conclusion

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:

http://docs.oracle.com/cd/E24329_01/web.1211/e21049/weblogic_xml.htm

Using WebLogic Maven plugin:

http://docs.oracle.com/cd/E24329_01/web.1211/e24368/maven.htm

WebLogic Maven appc goal:

http://docs.oracle.com/cd/E24329_01/web.1211/e24368/maven.htm#CHEBEHEH

Filed Under: oracle, WebLogic 12c Book Tagged With: , ,
Next Page »