|
|
|
How do I provide user credentials for starting a
server?
|
|
When you create a domain, the Configuration Wizard prompts you
to provide the username and password for an initial administrative
user. If you create the domain in development mode, the wizard saves
the username and encrypted password in a boot identity file. A WebLogic
Server instance can refer to a boot identity file during its startup
process. If a server instance does not find such a file, it prompts you
to enter credentials.
If you create a domain in production mode, or if you want to
change user credentials in an existing boot identity file, you can
create a new boot identity file.
|
|
Can I start a Managed Server
if the Administration Server is unavailable?
|
|
By default, if a Managed Server is unable to connect to the
specified Administration Server during startup, it can retrieve its
configuration by reading a configuration file and other files directly.
You cannot change the server's configuration until the Administration
Server is available. A Managed Server that starts in this way is
running in Managed Server Independence mode.
|
What
is the function of T3 in WebLogic Server?
|
T3 provides a framework for
WebLogic Server messages that support for enhancements. These
enhancements include abbreviations and features, such as object
replacement, that work in the context of WebLogic Server clusters and
HTTP and other product tunneling. T3 predates Java Object Serialization
and RMI, while closely tracking and leveraging these specifications. T3
is a superset of Java Object. Serialization or RMI; anything you can do
in Java Object Serialization and RMI can be done over T3. T3 is
mandated between WebLogic Servers and between programmatic clients and
a WebLogic Server cluster. HTTP and IIOP are optional protocols that
can be used to communicate between other processes and WebLogic Server.
It depends on what you want to do. For example, when you want to
communicate between a browser and WebLogic Server-use HTTP, or an ORB
and WebLogic Server-IIOP.
|
How
do you set the classpath?
|
|
WebLogic Server installs the following script that you can use
to set the classpath that a server requires:
WL_HOME\server\bin\setWLSEnv.cmd (on
Windows)
WL_HOME/server/bin/setWLSEnv.sh (on UNIX)
where WL_HOME
is the directory in which you installed WebLogic Server.
|
How
do stubs work in a WebLogic
Server cluster?
|
Clients that connect to a
WebLogic Server cluster and look up a clustered object obtain a
replica-aware stub for the object. This stub contains the list of
available server instances that host implementations of the object. The
stub also contains the load balancing logic for distributing the load
among its host servers.
|
What
happens when a failure
occurs and the stub cannot connect to a WebLogic Server instance?
|
When the failure occurs, the
stub removes the failed server instance from its list. If there are no
servers left in its list, the stubb uses DNS again to find a running
server and obtain a current list of running instances. Also, the stub
periodically refreshes its list of available server instances in the
cluster; this allows the stub to take advantage of new servers as they
are added to the cluster.
|
How
does a server know when
another server is unavailable?
|
|
WebLogic Server uses two mechanisms to determine if a given
server instance is unavailable.
Each WebLogic Server instance in a cluster uses multicast to
broadcast regular "heartbeat" messages that advertise its availability.
By monitoring heartbeat messages, server instances in a cluster
determine when a server instance has failed. The other server instances
will drop a server instance from the cluster, if they do not receive
three consecutive heartbeats from that server instance
WebLogic Server also monitors socket errors to determine the
availability of a server instance. For example, if server instance A
has an open socket to server instance B, and the socket unexpectedly
closes, server A assumes that server B is offline.
|
How
are notifications made when
a server is added to a cluster?
|
The WebLogic Server cluster
broadcasts the availability of a new server instance each time a new
instance joins the cluster. Cluster-aware stubs also periodically
update their list of available server instances.
|
How
do clients handle DNS
requests to failed servers?
|
|
If a server fails and DNS continues to send requests to the
unavailable machine, this can waste bandwidth. For a Java client
application, this problem occurs only during startup. WebLogic Server
caches the DNS entries and removes the unavailable ones, to prevent the
client from accessing a failed server twice.
Failed servers can be more of a problem for browser-based
clients, because they always use DNS. To avoid unnecessary DNS requests
with browser-based clients, use a third-party load-balancer such as
Resonate, BigIP, Alteon, and LocalDirector. These products mask
multiple DNS addresses as a single address. They also provide more
sophisticated load-balancing options than round-robin, and they keep
track of failed servers to avoid routing unnecessary requests.
|
How
many WebLogic Servers can I
have on a multi-cpu machine?
|
|
There are many possible configurations and each has its own
advantages and disadvantages. BEA WebLogic Server has no built-in limit
for the number of server instances that can reside in a cluster. Large,
multi-processor servers such as Sun Microsystems, Inc. Sun Enterprise
10000, therefore, can host very large clusters or multiple clusters.
In most cases, WebLogic Server clusters scale best when
deployed with one WebLogic Server instance for every two CPUs. However,
as with all capacity planning, you should test the actual deployment
with your target web applications to determine the optimal number and
distribution of server instances.
|
How
can I set deployment order
for applications?
|
WebLogic Server allows you to
select the load order for applications. WebLogic Server deploys
server-level resources (first JDBC and then JMS) before deploying
applications. Applications are deployed in this order: connectors, then
EJBs, then Web Applications. If the application is an EAR, the
individual components are loaded in the order in which they are
declared in the application.xml deployment descriptor.
|
Can
I refresh static components
of a deployed application without having to redeploy the entire
application?
|
|
Yes. You can use weblogic.Deployer
to specify a component and target a server, using the following syntax:
java weblogic.Deployer -adminurl http://admin:7001 -name appname
-targets server1,server2 -deploy jsps/*.jsp
|
When
should I use the -nostage
option?
|
Set the staging mode to -nostage (using weblogic.Deployer
or the Administration Console) if you don't want to copy deployment
files but want to deploy an application from its present location. All
target servers must be able to access the same set of deployment files.
|
When
should I use the
external_stage option?
|
Set -external_stage using
weblogic.Deployer if you want to stage the application yourself, and
prefer to copy it to its target by your own means.
|
Can
I set the deployment order
for application modules? For standalone modules?
|
|
The Load Order attribute controls the deployment order of
standalone modules and applications relative to other modules and
applications of the same type. For example, standalone EJBs with
smaller Load Order values are deployed before those with higher values.
Modules that are deployed as part of an Enterprise Application
(EAR file or directory) are deployed in the order in which they are
specified in the application.xml
deployment descriptor.
|
What
is the difference between
the WL_HOME/config/examples/applications
folder and the WL_HOME/config/examples/stage
folder?
|
The applications folder is intended
for applications that are not yet ready for a production environment.
WebLogic Server dynamically deploys the contents of the applications folder. The stage folder (or a folder that
you create for the same purpose) is for storing copies of deployment
files that are ready for deployment in a production environment
(deployments that use the stage
or external_stage
deployment modes).
|
How
do I turn the
auto-deployment feature off?
|
|
The auto-deployment feature checks the applications folder
every three seconds to determine whether there are any new applications
or any changes to existing applications and then dynamically deploys
these changes.
The auto-deployment feature is enabled for servers that run in
development mode. To disable auto-deployment feature, use one of the
following methods to place servers in production mode:
- In the Administration Console, click the name
of the domain in the left pane, then select the Production Mode
checkbox in the right pane.
- At the command line, include the following
argument when starting the domain's Administration Server:
-Dweblogic.ProductionModeEnabled=true
Production mode is set for all WebLogic Server instances in a
given domain.
|
Must
EJBs be homogeneously
deployed across a cluster? Why?
|
|
Yes. In WebLogic Server 6.0 and later, EJBs must be
homogeneously deployed across a cluster for the following reasons:
- To keep clustering EJBs simple
- To improve performance by avoiding
cross-server calls. If EJBs are not deployed on all servers,
cross-server calls are more likely.
- To ensure that every EJB is available
locall.y
- To ensure that all classes are loaded in an
undeployable way. Every server must have access to each EJB's classes
so that it can be bound into the local JNDI tree. If only a subset of
the servers deploys the bean, the other servers will have to load the
bean's classes in their respective system classpaths which makes it
impossible to undeploy the beans.
|