Working with two WebLogic domains on the same machine

If, like me, you have from time to time to work with two domains,

here are some tips which may help :)

 

Change the debug port

 

Well, that seems obvious, but if you have several servers, each one will have to use a different http port,

a different https port, but also a different debug port (assuming you're in development mode).

I figured out that only a few people know how to SIMPLY change the debug port.

Just add the line "set DEBUG_PORT=XXXX" in your startup script.

Ex :

 

@ECHO OFF

@REM WARNING: This file is created by the Configuration Wizard.
@REM Any changes to this script may be lost when adding extensions to this configuration.

SETLOCAL

set DOMAIN_HOME=D:\BEA_ROOT\user_projects\domains\9\sample
SET DEBUG_PORT=8956
call "%DOMAIN_HOME%\bin\startWebLogic.cmd" %*

ENDLOCAL

 

And that's it.

But wait a minute, a debug port is of course useful, but especially with an IDE !

Then, you will have to configure it because it's also listening on the default port.

I won't talk about JDev because I'm not working with it yet. I'll talk about Workshop.

If you take the server configuration in the "Java EE" view, you'll see something like that :

 

 

With a debug port nowhere to be seen.

In fact, you'll have to switch to the Debug View.

And in the debug pane, right-click on your server (it has to be running).

 

 

And then you'll be able to change that "hidden" option :)

 

 

Change the admin console cookie name

 

If  you're using Firefox, you may have noticed that it is hard to work with two WebLogic administration consoles at the same time.

It comes from the fact they share the same cookie and then each action on one console will log you out from the other one.

If I'm not mistaken it's possible to change that name only in the 10.3. To do so, go on the domain page.

 

 

And then click on the "Advanced Section" at the bottom of the page, and you'll see :

 

 

If you have two domains, changing only one cookie name will be sufficient :)

 

Another tip for developers

 

Personnally, I find the development feature that consists in an auto-lock for editing really annoying.

If you want to use your IDE to deploy, you may have a message telling you that the deployment can't

be done since an editing session is in progress. I gave a tip based on WLST to stop editing,

but finally, I guess it's better to desactivate this feature.

To do so :

 

 

And then :

 

 

 

Desactivate "Automatically Acquire Lock and Activate Changes".

You're now good to go develop :)

 

Mots clés Technorati : weblogic,debug port,eclipse,workshop,administration console cookie,auto-lock

Navigating among the MBeans with WLST ... Unix-style !

 

Lots of clients have been asking : "why is it so complicated to navigate through the MBean trees ?"

By "complicated", they mean the use of functions instead of simple instructions.

Still unclear ? :)

Well, the most obvious example is :

• Unix : cd .. / cd Servers
• WLST : cd ('..') / cd ('Servers')

Seen on Bala's blog, a cool (and undocumented) function is available : easeSyntax()

Its name speaks for itself : this function aims at making the syntax easier.

It will allow you to type commands as you would do on Unix.

To quit using that simplified syntax, just type once again easeSyntax().

 

And you're done !

 

Mots clés Technorati : wlst,unix,cd,easeSyntax

Tuning the default WorkManager on WebLogic Server

 

If you're not yet familiar with WorkManagers, well, it's time ! :)

With WLS 8, we had the concept of ExecuteQueues, replaced by workmanagers, starting with WLS 9. What's changed ?

Well, it's got self-tuning, allows a large number of SLA combinations and ... well, go read the official documentation about it :)

(Gush, I wanted to point towards E-docs, but it has been finally killed ... RIP ! I'll miss you)

So have a look at this good article instead.

 

Playing with the default workmanager

 

The default workmanager, as its name tells, is the workmanager defined by default.Thus, all applications deployed on WLS will use it.

One good thing is to first understand how they work, and then define some custom, matching the business rules or SLA you need.

But sometimes, when your application is already in production, it's obvious you can't take your EAR / WAR, update the deployment descriptor(s) and redeploy it.

(well, you could if your app isn't too big, thanks to side-by-side deployment, but that's another story)

But if you're interested, here's a live demo by my colleague Steve Button)

 

The default workmanager belongs to a threadpool.

As the initial threadpool comes with only five threads, that's not much.

 

 

If your application has to face a large number of hits, you may want to start with more than that.

Well, that's quite easy. You've got two ways to do so.

 

1) Modifying the config.xml

Just add the following line(s) in your server definition :

 

<server>

<name>AdminServer</name>

<self-tuning-thread-pool-size-min>100</self-tuning-thread-pool-size-min>

<self-tuning-thread-pool-size-max>200</self-tuning-thread-pool-size-max>

[...]

</server>

2) Adding some JVM parameters

 

Personally, that's my favorite option since I don't like when people go in a generated config file

and mess up with tags. If you're sure of what you're doing, that's ok, but it's safer the following way :

add the following option in your command line : -Dweblogic.threadpool.MinPoolSize=100

 

Observing the result

 

Personally, I decided to apply the change by adding the JVM parameter.

To do so, I just updated the startWeblogic script with the USER_MEM_ARGS line.

 

@ECHO OFF

@REM WARNING: This file is created by the Configuration Wizard.
@REM Any changes to this script may be lost when adding extensions to this configuration.

SETLOCAL

set DOMAIN_HOME=D:\BEA_ROOT\user_projects\domains\essex\ora_bpel
set USER_MEM_ARGS=-Dweblogic.threadpool.MinPoolSize=100
call "%DOMAIN_HOME%\bin\startWebLogic.cmd" %*

ENDLOCAL

 

Reboot WLS and see the option has been taken into account :

 

 

And finally :

 

 

Wasn't so hard, was it ? :)

 

Mots clés Technorati : tuning,default workmanager,weblogic.threadpool.MinPoolSize,self-tuning-thread-pool-size-min

T5000 / CMT CPU and Java operations

 

Recently, I discussed with several clients who were planning to or made the switch from their V890 servers to T5000 Sun Server.

If you're considering this change too, please notice that these TX000 servers are excellent for handling heavy loads,

but as their architectures are based on CMT CPU, simple operations that cannot be parallelized are simply (much) longer.

And unfortunately, when an app server starts, it's a succession of tasks, that were not designed to be simultaneous.

 

I can tell that a large application, deploying in 5 minutes on a V890 did exceed 20 minutes on a T5000 !

But once the application is deployed, a better behavior has been observed under a strong load, for the T5000.

But, I guess you have to know it before you take that kind of decision ...

 

http://blogs.sun.com/Benoit/entry/sap_et_t5000_retour_d (French)

http://www.optaros.com/blogs/sun-t2000t5000-and-alfresco-not-good-combination

 

Mots clés Technorati : V890,T5000,long deployment