The answer is No and Yes. Read on for more specific info….

WebLogic domain consists of Servers, Machines, Clusters, Applications and Configurations related to them. Administration sever is the controlling instance for the domain. It is the keeper of all the configuration. Ideally you don’t want to host (target) any application or service that clients would access on the admin instance. Managed server(s) or cluster(s) are meant to host such applications and services that clients would access (servers other than admin server in a domain are called as managed servers).

Having said that, if an admin instance fails during the middle of the day what happens to my domain? It is the controlling instance so will it halt my domain? The answer is NO. Admin server will provide all the configurations to each managed server and they will be cached locally. There are limited dependency between the servers during runtime. So an admin server failure will not affect the running managed server(s) or cluster of managed server(s).

Alright, what about the “Yes” part of the above answer?! There are few services you will lose when an admin instance is not available. You cannot introduce any new configuration or change any existing configuration in the domain. Examples are: you cannot deploy new applications, you cannot change the JNDI name of a JMS destination hosted on one or more servers etc. You will also lose the domain log entries in the Domain Log file maintained by the administration server. Still you can use the Server Log maintained on each managed server for auditing or troubleshooting purpose. Also lastly the managed server(s) in the absence of admin server can only be started or restarted in Independence Mode (using the previously cached local configuration information).

• You are not expected to introduce new configuration or change any configuration on the fly in your production setup so losing the ability to do this will have literally no or little impact.
• You can use server log file entries for auditing and troubleshooting purposes.
• The managed server can be restarted or started if required during the absence of admin server using Independence Mode (which is a default setup now in WLS 10.x – no extra configuration required).

Admin server (for that matter any server in the domain) can be configured to automatically get restarted in case of failures using a feature called – whole server migration. I will talk about this in a later discussion.

So now you know why I said “No” and “Yes”! huh!

JMS Server in WLS only removes the messages that are expired once in every expiration scan interval (A JMS Server level config). The destination may have expired message sitting in them if the expiration scan interval property is set to a high value. For ex. 1800 will cause the JMS Server to scan for expired messages once in 30 mins. Still applications cannot receive the expired messages – they will be sitting in the destination. But it doesn’t automatically do any compaction per se. So the file size of the WLS File Store may keep increasing. This might cause slow startup of the server.

You can perform manual offline compaction in the following ways:

• There is a Java command-line utility that can do this trick “weblogic.store.Admin”. See Edocs for more info.

• A WLST command called “compactstore” can also do the same trick. See Edocs for more info.

Note that this compaction is supported only for WLS File Stores and not for JDBC Stores as they don’t suffer with the same issue of compaction.

The Java command-line utility “weblogic.store.Admin can also be used to dump the contents of a store into an XML file for troubleshooting purpose.

WLST is a powerful scripting solution for managing and administering WebLogic Server and resources deployed on them. WLST is built on the Java implementation of the scripting language Python called as Jython. All the commands in WLST are implemented as Jython functions and they require a set of parentheses for passing any arguments. Even any commands that do not require any arguments are supposed to be suffixed with parentheses. For example the command “ls” is used to list all the child MBeans and/or attributes of the current MBean you are at.

ls() – lists all the child MBeans and attributes
ls(‘a’) – lists all the attribute names and values only
ls(‘c’) – lists all the child MBeans only

So even if you want to invoke “ls” with no arugments you must use “ls()“. This might not be an issue when you are building scripts that you might want to run many times. But while connected to a server and working with WLST in interactive mode, it might get a little frustated to type the parentheses everytime you want to run some simple commands with no arguments. To ease this pain there is a hidden option in WLST which can be used to ease the syntax for WLST commands – easeSyntax().

You can supply the “easeSyntax()” command to ease the syntax but this is not recommended for script mode and especially when using loop constructs. You can also use the regular Jython syntax with parentheses even after you enabled the easy syntax. To turn off the easy syntax mode simply issue the command again “easeSyntax“.

Bye Bye parentheses!