What happens with AM instance, when Web session times out? I would like to answer this question. To find an answer, I have developed sample application with special settings for AM configuration - AMInstanceTimeoutApp.zip. This is important to understand, because we should try to avoid frequent AM passivations, same as frequent AM activations. Passivations consumes server resources and delays request processing for current active users.
We already know - when AM idle instance timeout is set to be less than Web session timeout, during user inactivity there will be AM passivations and activations happening. To minimize number of passivations/activations, we need to increase Referenced Pool Size, along with increasing AM idle instance timeout (read here - How to Minimize Number of ADF BC Application Module Activations).
Customized AM settings for the sample application:
1. Referenced Pool Size = 1, to simulate high load and to see what happens when second user arrives
2. Minimum Available Size = 0, to make sure all AM instances will be removed after timeout
3. Idle Instance Timeout = 900 (sec.), instance will be marked as candidate for removal after 15 mins.
4. Pool Pooling Interval = 60 (sec.), inactive AM instances will be removed in 1 minute intervals
Web session timeout on contrary to AM instance timeout is set to be less - only 5 minutes. This is done on purpose to timeout Web session, before associated AM instance will be timed out:
As practical test shows - once Web session times out, if another user accessing application before pool pooling interval - passivation will happen. This means, AM instance was not yet removed and is still reserved - as there are no available AM instances (Referenced Pool Size = 1), passivation happens and instance is given to the new user.
Web session times out for the first user:
Second user is accessing application, passivation happens for the AM instance previously used by already timed out session:
However, if second user would wait a bit more after first user session timed out - precisely would wait until pool pooling interval, there would be no passivation. This means, when Web session times out - AM instance is not removed instantly, it will stay active until the next event of pool cleanup (pool pooling interval). In my sample I set this interval to 1 minute, in real application it could be 5-10 minutes.
Web session timeout happened and after pool pooling interval - AM instance was removed:
If second user is accessing application at that time, there will be no passivation reported:
We already know - when AM idle instance timeout is set to be less than Web session timeout, during user inactivity there will be AM passivations and activations happening. To minimize number of passivations/activations, we need to increase Referenced Pool Size, along with increasing AM idle instance timeout (read here - How to Minimize Number of ADF BC Application Module Activations).
Customized AM settings for the sample application:
1. Referenced Pool Size = 1, to simulate high load and to see what happens when second user arrives
2. Minimum Available Size = 0, to make sure all AM instances will be removed after timeout
3. Idle Instance Timeout = 900 (sec.), instance will be marked as candidate for removal after 15 mins.
4. Pool Pooling Interval = 60 (sec.), inactive AM instances will be removed in 1 minute intervals
Web session timeout on contrary to AM instance timeout is set to be less - only 5 minutes. This is done on purpose to timeout Web session, before associated AM instance will be timed out:
As practical test shows - once Web session times out, if another user accessing application before pool pooling interval - passivation will happen. This means, AM instance was not yet removed and is still reserved - as there are no available AM instances (Referenced Pool Size = 1), passivation happens and instance is given to the new user.
Web session times out for the first user:
Second user is accessing application, passivation happens for the AM instance previously used by already timed out session:
However, if second user would wait a bit more after first user session timed out - precisely would wait until pool pooling interval, there would be no passivation. This means, when Web session times out - AM instance is not removed instantly, it will stay active until the next event of pool cleanup (pool pooling interval). In my sample I set this interval to 1 minute, in real application it could be 5-10 minutes.
Web session timeout happened and after pool pooling interval - AM instance was removed:
If second user is accessing application at that time, there will be no passivation reported:
9 comments:
nice post.
Um, Andrejust. I have a question about standard connections in ADF.
For example, now i'm using database A (with My Username, password, port).
One day, my custommer call me and said : we have to change conection to database B.
The problem is i have to rebuild all project, it's no good.
So are there any ways to do this without rebuild project ?
Thank you.
Of course, you should change connection details in WebLogic data source.
Regards,
Andrejus
I'm new to ADF, so sometime i ask many questions, some questions basic, sorry to trouble you.you're a good man. thank you :)
My pleasure :)
Andrejus
Great post Andrejus.
Is it a good practice to set Web Session Timeout to -1? What side effects can be expected? We are experiencing some performance problems and trying to keep number of application connections down hoping it would help.
Thanks
Vlad
I don't think it is a good thing to set web session timeout = -1, then web session never times out and all resources will stay reserved. You should tune ADF BC part instead: http://andrejusb.blogspot.com/2013/12/how-to-minimize-number-of-adf-bc.html
Andrejus
Great post. We are having some issue regarding db connection.
Here is my configuration info:
Ideal timeout =10 min
Pooling time = 10 min
time to live = 20 min
Min avail pool =5
max avail pool =25
reference pool =10
what could be the issue? is it becuase after web session time out, second user get AM instance that is inactivated but not remvoed. is happend occasionally.
How many concurrent users you have?
Andrejus
at pick we might have 10-15 concurrent user. but normally 5-10 user.
Post a Comment