Weblogic Server Interview Questions

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 roadcast 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: weblogic.ProductionModeEnabled=trueProduction 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.

Deployment Order

Within components of the same type, such as EJBs, you can specify the order in which they are to be deployed at server startup. The integer that you indicate in the Deployment Order field when deploying the component indicates the priority in relation to other components of the same type, such as the order of deployment among EJBs. Components that have deployment order 0 are deployed first among components of that type.
However, WebLogic Server uses an ordering among types that is not affected by this user-defined ordering among components of the same type. When WebLogic Server starts, the following class-level order is used in deployment:

1. JDBC Connection Pools
2. JDBC Multi Pools
3. JDCB Data Sources
4. JDBC Tx Data Sources
5. JMS Connection Factories
6. JMS Servers
7. Connector Components
8. EJB Components
9. Web App Components

Deployment Descriptors

Web applications use two deployment descriptors to define their operational attributes. A web.xml deployment descriptor is a J2EE standard XML document that describes the contents of a WAR file. The weblogic.xml deployment descriptor is an XML document containing WebLogic Server-specific elements for Web applications.
For more information about the elements in these deployment descriptor, refer to web.xml Deployment Descriptor Elements, and weblogic.xml Deployment Descriptor Elements.
You can modify deployment descriptors using the following tools:

• WebLogic Builder. WebLogic Builder is the BEA preferred WebLogic Server tool for generating and editing deployment descriptors for WebLogic Server applications. It can also deploy WebLogic Server applications to single servers. For more information, see Deployment Tools Reference in Deploying WebLogic Server Applications. For more information, see Using WebLogic Builder to Edit Deployment Descriptors.
• XML Editor with DTD validation, such as BEA XML Editor on dev2dev or XMLSpy. (An evaluation copy of XMLSpy is bundled with this version of WebLogic Server.) See BEA dev2dev Onlinehttp://dev2dev.bea.com/index.jsp.
• Using the Administration Console Descriptor tab. The Descriptor tab has replaced the deprecated Deployment Descriptor Editor in the Administration Console. For more information on the Descriptor tab, see the WebLogic Server online help. Also refer to Dynamic Descriptor Updates.

stage/no stage/external-stage + WebLogic

Stage mode—The Administration Server copies the archive files from their source location to a location on each of the targeted Managed Servers that deploy the archive. For example, if you deploy a J2EE Application to three servers in a cluster, the Administration Server copies the application archive files to each of the three servers. Each server then deploys the J2EE Application using its local copy of the archive files.
Stage mode is the default mode when deploying to more than one WebLogic Server instance.

- Nostage mode—The Administration Server does not copy the archive files from their source location. Instead, each targeted server must access the archive files from a single source directory for deployment. For example, if you deploy a J2EE Application to three servers in a cluster, each server must be able to access the same application archive files (from a shared or network-mounted directory) to deploy the application.
Nostage mode is the default mode when deploying only to the Administration Server (for example, in a single-server domain). You can also select nostage mode if you run a cluster of server instances on the same machine.

- External_stage mode—External_stage mode is similar to stage mode, in that the deployment files must reside locally to each targeted server. However, the Administration Server does not automatically copy the deployment files to targeted servers in external_stage mode; instead, you must manually copy the files, or use a third-party application to copy the files for you.

WEB SERVICES IN WL SERVER:

Reliable SOAP messaging is a framework whereby an application running in one WebLogic Server instance can asynchronously and reliably invoke a Web Service running on another WebLogic Server instance. Reliable SOAP messaging works only between two WebLogic Server instances. This page allows you to specify settings for reliable SOAP messaging.

Virtual Host :

Virtual hosting allows you to define host names to which WebLogic Server instances (servers) or clusters respond. When you use virtual hosting, you use DNS to specify one or more host names that map to the IP address of a WebLogic Server or cluster, and you specify which Web applications are served by each virtual host

What is DNS:

Domain Name System (DNS) is an Internet Engineering Task Force (IETF) standard name service that allows your computer to register and resolve domain names. The DNS makes it possible to assign domain names to organizations independent of the routing of the numerical IP address. In other words, DNS is a system that translates domain names into IP addresses. This is necessary because computers only make use of IP addresses yet we use only human readable names since the names are easier to remember than IP addresses. Without this DNS resolution, the internet would be a very inconvenient place. DNS resolution is therefore a very important task. However, you may sometimes try to connect to a system by name and get a DNS error because the name did not resolve to the proper IP address. There can be several causes for this, such as:

• The DNS server is down.
• IP connectivity gets lost and thus the DNS cannot resolve
• DNS cache poisoning.
• Update and zone issues.
• The DNS server does not have network connectivity to the root servers

What is DNS?

Domain Name System (DNS) is a database system that translates a computer's fully qualified domain name into an IP address.

Networked computers use IP addresses to locate and connect to each other, but IP addresses can be difficult for people to remember. For example, on the web, it's much easier to remember the domain name www.amazon.com than it is to remember its corresponding IP address (207.171.166.48). DNS allows you to connect to another networked computer or remote service by using its user-friendly domain name rather than its numerical IP address. Conversely, Reverse DNS (rDNS) translates an IP address into a domain name.

Each organization that maintains a computer network will have at least one server handling DNS queries. That server, called a name server, will hold a list of all the IP addresses within its network, plus a cache of IP addresses for recently accessed computers outside the network. Each computer on each network needs to know the location of only one name server. When your computer requests an IP address, one of three things happens, depending on whether or not the requested IP address is within your local network:

• If the requested IP address is registered locally (i.e., it's within your organization's network), you'll receive a response directly from one of the local name servers listed in your workstation configuration. In this case, there usually is little or no wait for a response.
• If the requested IP address is not registered locally (i.e., outside your organization's network), but someone within your organization has recently requested the same IP address, then the local name server will retrieve the IP address from its cache. Again, there should be little or no wait for a response.
• If the requested IP address is not registered locally, and you are the first person to request information about this system in a certain period of time (ranging from 12 hours to one week), then the local name server will perform a search on behalf of your workstation. This search may involve querying two or more other name servers at potentially very remote locations. These queries can take anywhere from a second or two up to a minute (depending on how well connected you are to the remote network and how many intermediate name servers must be contacted). Sometimes, due to the lightweight protocol used for DNS, you may not receive a response. In these cases, your workstation or client software may continue to repeat the query until a response is received, or you may receive an error message.

When you use an application such as telnet to connect to another computer, you most likely type in the domain name rather than the IP address of that computer. The telnet application takes the domain name and uses one of the above methods to retrieve its corresponding IP address from the name server. A good analogy is to think of DNS as an electronic telephone book for a computer network. If you know the name of the computer in question, the name server will look up its IP address.

Within most Internet applications, you will not see the IP address of the computer to which you're connecting. If you want to find the IP address of a particular computer, refer to the appropriate Knowledge Base document listed below:

Virtual hosting:

Often abbreviated vhost, a virtual host is a provider of Web services that include server functions and Internet connection services. A virtual host is often used by companies or individuals that do not want to purchase and maintain their own Web servers and Internet connections.

A virtual host will provide its customers with domain name registration, file storage and directory services for the files that Web page is built from, e-mail services and even Web site design and creation services if the customers want someone else to build their Web sites.
A limitation of using a virtual host is that the customer shares the Web services with all the other customers of the virtual host. If the virtual host is running multiple sites off the same server, then those sites will be competing for Web server resources. Some virtual hosting providers offer co-location services and/or allow a customer to rent dedicated servers that are allocated to serve only that one customer’s needs

Virtual hosting is a method that servers such as webservers use to host more than one domain name on the same computer, sometimes on the same IP address.

 

Name-based

Name-based virtual hosts use multiple host names for the same webserver IP address.

With web browsers that support HTTP/1.1 (as nearly all now do), upon connecting to a webserver, the browsers send the address that the user typed into their browser's address bar (the URL). The server can use this information to determine which web site, as well as page, to show the user. The browser specifies the address by setting the Host HTTP header with the host specified by the user. The Host header is required in all HTTP/1.1 requests.

For instance, a server could be receiving requests for two domains, www.site1.com and www.site2.com, both of which resolve to the same IP address. For www.site1.com, the server would send the HTML file file from the directory /var/www/user/Joe/site/, while requests for www.site2.com would make the server serve pages from /var/www/user/Mary/site/.

Cons

If the Domain Name System (DNS) is not properly functioning, it becomes much harder to access a virtually-hosted website. Ordinarily, in this case, the user could try and fall back to using the IP address to contact the system, as in http://12.37.56.78/. However, the web browser doesn't know what hostname to use when this happens, so the server will respond with a default website—often not the site the user expects. This workaround is not really useful for an average web user, but may be of some use to a site administrator while fixing DNS records.

A workaround in this case is to add the IP address and hostname to the client system's hosts file. At this point, accessing the server with the domain name should work again. However, users should be careful when doing this, as any changes to the true mapping between hostname and IP address will be overridden by the local setting.

Another issue with virtual hosting is the inability to host multiple secure websites running Secure Sockets Layer or SSL. Because the SSL handshake takes place before the expected hostname is sent to the server, the server doesn't know which certificate to present when the connection is made. One workaround is to run multiple web server programs, each listening to a different incoming port, which still allows the system to just use a single IP address. If running multiple web server programs is considered clumsy, a more efficient solution is to select TLS (TLS 1.1 or later, which enables name-based virtual hosting as of December 2006). Another option is to do IP aliasing, where a single computer listens on more than one IP address.

IP-based

In IP-based virtual hosting, each site (either a DNS hostname or a group of DNS hostnames that act the same) points to a unique IP address. The webserver is configured with multiple physical network interfaces, virtual network interfaces on the same physical interface or multiple IP addresses on one interface.

The webserver can obtain the address the TCP connection was intended for using a standard api and uses this to determine which website to serve. The client is not involved in this process and therefore (unlike with name based virtual hosting) there are no compatibility issues.

[edit] Uses

Virtual web hosting is often used on large scale in companies whose business model is to provide low cost website hosting for customers. The vast majority of such web hosting service customer websites worldwide are hosted on shared servers, using virtual hosting technology.

Many businesses utilize virtual servers for internal purposes, where there is a technology or administrative reason to keep several separate websites such as customer extranet website, employee extranet, internal intranet, intranets for different departments. If there are not security concerns in the website architectures, they can be merged into a single server using virtual hosting technology, which reduces management and administrative overhead and the number of separate servers required to support the business.

FAQs: Clustering

Q. How do stubs work in a WebLogic Server cluster?
A. 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.

Q. What happens when a failure occurs and the stub cannot connect to a WebLogic Server instance?
A. 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.

Q. How does a server know when another server is unavailable?
A. 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.

Q. How are notifications made when a server is added to a cluster?
A. 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.

Q. How do clients learn about new WebLogic Server instances?
A. Once a client has done a JNDI lookup and begins using an object reference, it finds out about new server instances only after the cluster-aware stub has updated its list of available servers.

Q. How do clients handle DNS requests to failed servers?
A. 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.

Q. How many WebLogic Servers can I have on a multi-cpu machine?
A. 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. See Performance Considerations for Multi-CPU Machines for additional information.

Q. Should I use a separate network for multicast in a cluster?
A. No. Multicast traffic is not heavy enough to require a separate network.

Q. What should I do if my cluster "hangs" or "freezes"?
A. If your WebLogic Server cluster "freezes," you will need to collect certain diagnostic information, including thread dumps and Java garbage collection metrics, before contacting BEA Technical Support. For details, see Generate a Log File.

LDAP:

LDAP, Lightweight Directory Access Protocol, is an Internet protocol that email and other programs use to look up information from a server.

Every email program has a personal address book, but how do you look up an address for someone who's never sent you email? How can an organization keep one centralized up-to-date phone book that everybody has access to?

That question led software companies such as Microsoft, IBM, Lotus, and Netscape to support a standard called LDAP. "LDAP-aware" client programs can ask LDAP servers to look up entries in a wide variety of ways. LDAP servers index all the data in their entries, and "filters" may be used to select just the person or group you want, and return just the information you want. For example, here's an LDAP search translated into plain English: "Search for all people located in Chicago whose name contains "Fred" that have an email address. Please return their full name, email, title, and description."

LDAP is not limited to contact information, or even information about people. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide "single signon" where one password for a user is shared between many services. LDAP is appropriate for any kind of directory-like information, where fast lookups and less-frequent updates are the norm.

As a protocol, LDAP does not define how programs work on either the client or server side. It defines the "language" used for client programs to talk to servers (and servers to servers, too). On the client side, a client may be an email program, a printer browser, or an address book. The server may speak only LDAP, or have other methods of sending and receiving data—LDAP may just be an add-on method.

If you have an email program (as opposed to web-based email), it probably supports LDAP. Most LDAP clients can only read from a server. Search abilities of clients (as seen in email programs) vary widely. A few can write or update information, but LDAP does not include security or encryption, so updates usually requre additional protection such as an encrypted SSL connection to the LDAP server.

LDAP also defines: Permissions, set by the administrator to allow only certain people to access the LDAP database, and optionally keep certain data private. Schema: a way to describe the format and attributes of data in the server. For example: a schema entered in an LDAP server might define a "groovyPerson" entry type, which has attributes of "instantMessageAddress", and "coffeeRoastPreference". The normal attributes of name, email address, etc., would be inherited from one of the standard schemas, which are rooted in X.500 (see below).

LDAP was designed at the University of Michigan to adapt a complex enterprise directory system (called X.500) to the modern Internet. X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service "for the rest of us."

LDAP servers exist at three levels: There are big public servers, large organizational servers at universities and corporations, and smaller LDAP servers for workgroups. Most public servers from around year 2000 have disappeared, although directory.verisign.com exists for looking up X.509 certificates. The idea of publicly listing your email address for the world to see, of course, has been crushed by spam.

While LDAP didn't bring us the worldwide email address book, it continues to be a popular standard for communicating record-based, directory-like data between programs.