Flashback Monday: WebLogic in the Cloud

Just rediscovered this DOAG article written in German over half a decade ago. What has changed for you?

WebLogic_OFM_AWS_Cloud.pdf

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

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.

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.

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.

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

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.

 

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.

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:

http://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.