Wednesday, March 7, 2012
Monday, March 5, 2012
Weblogic Interview Questions !!
To All Weblogic Admins,
1)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.
--
within the cluster all the server instances are sending heart beat messages, if any sever not respond for three consecutive heart beats that particular server point or mark as a server failed or server unavailable
2)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.
3) 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.
4) Setting Up WebLogic Server for HTTP Tunneling
HTTP tunneling provides a way to simulate a stateful socket connection between WebLogic Server and a Java client when your only option is to use the HTTP protocol. It is generally used to tunnel through an HTTP port in a security firewall. HTTP is a stateless protocol, but WebLogic Server provides tunneling functionality to make the connection appear to be a regular T3Connection. However, you can expect some performance loss in comparison to anormal socket connection.
Configuring the HTTP Tunneling Connection Under the HTTP protocol, a client may only make a request, and then accept a reply from a server. The server may not voluntarily communicate with the client, and the protocol is stateless, meaning that a continuous two-way connection is not possible.
WebLogic HTTP tunneling simulates a T3Connection via the HTTP protocol, overcoming these limitations. There are two attributes that you can configure in the Administration Console to tune a tunneled connection for performance. It is advised that you leave them at their default settings unless you experience connection problems. These properties are used by the server to determine whether the client connection is still valid, or whether the client is still alive.
Enable Tunneling
Enables or disables HTTP tunneling. HTTP tunneling is disabled by default.
Note that the server must also support both the HTTP and T3 protocols in order to use HTTP tunneling.
Tunneling Client Ping
When an HTTP tunnel connection is set up, the client automatically sends a request to the server, so that the server may volunteer a response to the client. The client may also include instructions in a request, but this behavior happens regardless of whether the client application needs to communicate with the server. If the server does not respond (as part of the application code) to the client request within the number of seconds set in this attribute, it does so anyway. The client accepts the response and automatically sends another request immediately.
Default is 45 seconds; valid range is 20 to 900 seconds.
Tunneling Client Timeout
If the number of seconds set in this attribute have elapsed since the client last sent a request to the server (in response to a reply), then the server regards the client as dead, and terminates the HTTP tunnel connection. The server checks the elapsed time at the interval specified by this
attribute, when it would otherwise respond to the client's request.
Default is 40 seconds; valid range is 10 to 900 seconds.
5) 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.
deployment order is
1 Resources (JDBS and JMS)
2 jsp's and servlets
3 EJB, RMI
4 start up and shutdown classes (optional)
6) How to increase the memory in Weblogic.?
Increase the allocation of Java heap memory for WebLogic Server. (Set the minimum and the maximum to the same size.) Start WebLogic Server with the -ms32m option to increase the allocation, as in this example:
$ java ... -ms32m -mx32m ...
This allocates 32 megabytes of Java heap memory to WebLogic Server, which improves performance and allows WebLogic Server to handle more simultaneous connections. You can increase this value if necessary.
This can be modified in setDomainEnv.sh file, or server start tab in admin console.
I would like to share the few real time questions we see when ever we go for technical round of interviews, would like to maintain in one place in my blog for all those who would like to have a look before they attend any interview...
Wish You all the best...
Q. What are safeguards for modifying the config.xml file?
A. BEA recommends that you use the WebLogic Server Administration Console to edit the config.xml file. If you need to edit the config.xml file directly, we recommend that:
You always save a copy of your config.xml file before editing it. If your edits
cause errors that prevent you from booting, you can at least revert to your saved
version.
You manually edit the config.xml file for a domain when a domain is not
active. If you edit the configuration file while the domain is active, any changes
you make manually will likely be overwritten by the system. Furthermore, all
changes you make by hand while the domain is active are ignored by the system
at run time.
Because there is no validation or value checking when you edit config.xml
manually, type-checking occurs when you load the configuration file for the first
time, that is, when you restart the Administration Server. At that point, any
invalid XML or attribute value is detected and the domain fails to boot.
For more information on modifying the config.xml file, see information on the
config.xml.booted file in the Starting and Stopping WebLogic Servers section of
the Administration Guide
Q. How do I edit the config.xml file?
A. The persistent configuration for a domain of WebLogic Servers and clusters is
stored in an XML configuration file (config.xml). You can modify this file in the
following ways:
The recommended way for users to modify or monitor a domain's configuration
is to use the Administration Console.
WebLogic Server includes a configuration Application Programming Interface
(API), which programs can use to modify configuration attributes of resources in
the domain.
You can access the attributes of a domain with the WebLogic Server
command-line utility. This utility is provided for people who want to create
scripts to automate domain management. See Commands for Managing a
WebLogic Domain in the Administration Guide at
http://e-docs.bea.com/wls/docs61/adminguide/cli.html.
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 stub 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. Why did my JDBC code throw a rollback SQLException?
A. Your JDBC code may throw the following exception:
"The coordinator has rolled back the transaction.
No further JDBC access is allowed within this transaction."
The WebLogic JTS JDBC driver throws this exception when the current JDBC
connection transaction rolls back prior to or during the JDBC call. This exception
indicates that the transaction in which the JDBC connection was participating was
rolled back at some point prior to or during the JDBC call.
The rollback may have happened in an earlier EJB invoke that was part of the
transaction, or the rollback may have occurred because the transaction timed out. In
either case, the transaction will be rolled back, the connection returned to the pool and
the database resources released. In order to proceed, the JTS JDBC connection must
be closed and reopened in a new transaction.
Q. Must EJBs be homogeneously deployed across a cluster? Why?
A. Yes. Beginning with WebLogic Server version 6.0, EJBs must be homogeneously
deployed across a cluster for the following reasons:
To keep clustering EJBs simple
To avoid cross server calls which results in more efficiency. If EJBs are not
deployed on all servers, cross server calls are much more likely.
To ensure that every EJB is available locally
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.
1)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.
--
within the cluster all the server instances are sending heart beat messages, if any sever not respond for three consecutive heart beats that particular server point or mark as a server failed or server unavailable
2)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.
3) 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.
4) Setting Up WebLogic Server for HTTP Tunneling
HTTP tunneling provides a way to simulate a stateful socket connection between WebLogic Server and a Java client when your only option is to use the HTTP protocol. It is generally used to tunnel through an HTTP port in a security firewall. HTTP is a stateless protocol, but WebLogic Server provides tunneling functionality to make the connection appear to be a regular T3Connection. However, you can expect some performance loss in comparison to anormal socket connection.
Configuring the HTTP Tunneling Connection Under the HTTP protocol, a client may only make a request, and then accept a reply from a server. The server may not voluntarily communicate with the client, and the protocol is stateless, meaning that a continuous two-way connection is not possible.
WebLogic HTTP tunneling simulates a T3Connection via the HTTP protocol, overcoming these limitations. There are two attributes that you can configure in the Administration Console to tune a tunneled connection for performance. It is advised that you leave them at their default settings unless you experience connection problems. These properties are used by the server to determine whether the client connection is still valid, or whether the client is still alive.
Enable Tunneling
Enables or disables HTTP tunneling. HTTP tunneling is disabled by default.
Note that the server must also support both the HTTP and T3 protocols in order to use HTTP tunneling.
Tunneling Client Ping
When an HTTP tunnel connection is set up, the client automatically sends a request to the server, so that the server may volunteer a response to the client. The client may also include instructions in a request, but this behavior happens regardless of whether the client application needs to communicate with the server. If the server does not respond (as part of the application code) to the client request within the number of seconds set in this attribute, it does so anyway. The client accepts the response and automatically sends another request immediately.
Default is 45 seconds; valid range is 20 to 900 seconds.
Tunneling Client Timeout
If the number of seconds set in this attribute have elapsed since the client last sent a request to the server (in response to a reply), then the server regards the client as dead, and terminates the HTTP tunnel connection. The server checks the elapsed time at the interval specified by this
attribute, when it would otherwise respond to the client's request.
Default is 40 seconds; valid range is 10 to 900 seconds.
5) 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.
deployment order is
1 Resources (JDBS and JMS)
2 jsp's and servlets
3 EJB, RMI
4 start up and shutdown classes (optional)
6) How to increase the memory in Weblogic.?
Increase the allocation of Java heap memory for WebLogic Server. (Set the minimum and the maximum to the same size.) Start WebLogic Server with the -ms32m option to increase the allocation, as in this example:
$ java ... -ms32m -mx32m ...
This allocates 32 megabytes of Java heap memory to WebLogic Server, which improves performance and allows WebLogic Server to handle more simultaneous connections. You can increase this value if necessary.
This can be modified in setDomainEnv.sh file, or server start tab in admin console.
Subscribe to:
Posts (Atom)