Load on weblogic

[Anonymous]

hi all!!!
1. I have some doubt. If htere are too heavy a load for your weblogic server, and you are running out of allocated memory for your session beans, what kind of error message you are going to get? What can you do to fix this situation.
2. What is a free pool?
I will be happy if u guys help me on this
thanks
Ramanathan

[Anonymous]

Please help me out with the above questions
thanks
ram

[Anonymous]

hi ramanathan!!!
The answer below is for the free pool. Correct me if I am wrong!!!
When a client calls a method on a stateless EJB, WebLogic Server obtains an instance from the free pool. The EJB remains active for the duration of the client's method call. After the method completes, the EJB is returned to the free pool. Because WebLogic Server unbinds stateless session beans from clients after each method call, the actual bean class instance that a client uses may be different from invocation to invocation.

[Anonymous]

hi all!!
1. what is load balancing? can u give the url to know more.
2. Can u give information about ACL or the url?
thanks guys
ram

[Anonymous]

Originally posted by ramanathan chari:
hi all!!
1. what is load balancing? can u give the url to know more.
2. Can u give information about ACL or the url?
thanks guys
ram

Hi Ramanathan,
For Load Balancing this is an explaination with respect to iplanet application server.
Any distributed application environment obviously needs some sort of load-balancing capabilities to keep data flowing evenly through the servers
An iAS system's load-balancing characteristics are adjusted from the Administration Tool. Administrators can enter information such as the number of CPUs, the power of each CPU, their response time, and so on as factors in the load-balancing equation. (Administrators can also select a simple weighted round-robin load-balancing scheme. Tasks are distributed so that more-powerful servers handle requests more frequently than do less-powerful servers.) Application servers even load balances among multiple CPUs in a multiprocessor system.
URL www.iplanet.com
Regards
Shan.

[farhan]

few terms related to application servers, etc:
POOL:
Imagine you need to create a connection object, or an object for an ejb. You create it, but do not reclaim it by calling close or remove. It stays in memory, and also maintains a connection with the database/application server. Hence consumes resources. One alternative is to have a factory, which will create objects for you and give you (ie you do not call new ObjectName() but say ObjectName.getInstance()). One special case is a Singleton, which gives you a single instance in the complete VM. Alternatively you could have a pool (say an array) of objects, and you allocate instances just from that pool. In this case, you would have a controlled number of instances within the app server that you will allocate. Resources are saved that way. If somebody has not closed/used an instance from pool, it could be timed out after some time.
LOAD BALANCING:
Single user connects to the system, attaches to an ejb instance, and gets his work done. If there are multiple users, but only a single ejb instances, the user either has to wait or the app server has to passivate previous instance and serve the other user. Hence if there are additional instances of ejbs, servlets etc that the user is connected to, helps in "load balancing" when the number of users increase. This could also be done in terms of number of servers that are there. These servers are attached as a "CLUSTER". Users go through a common "PROXY", but they are routed to a particular server, and get their work done.
FAIL OVER:
In the above scenario, if the user were to be routed to a particular server within the cluster, and due to some reason, that server went down, the other server would service the user. The user would not even know that the server he was connected to went down. There is a "fail over" achieved here. One important feature that should be there for this to happen is "Session Replication", ie the user session on one server should be replicated (copied, cloned) on the other server so that fail over could be achieved if the server goes down