Timeout parameters

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Timeout parameters

Linda
Hi Erman!
Again me :)
Noticed that  sometimes when env going  fast down adstop.all  and fast up adstrtall.sh , seems like Weblogic is 'behind':

When trying to login to apps get :
Error 404--Not Found
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

Then I login to weblogic console : admin, node is up, but the oa% services are in ADMIN state.

So, I stop and restart  again -> all is fine.. So, I am thinking about timeouts. can be the reason ?
Myones :
 more $CONTEXT_FILE |grep -i timeout
                        <mwaDropConnectionTimeout oa_var="s_mwaDropConnectionTimeout">5</mwaDropConnectionTimeout>
                        <mwaStaleSessionTimeout oa_var="s_mwaStaleSessionTimeout">60</mwaStaleSessionTimeout>
                        <session_timeout oa_var="s_sesstimeout">14400000</session_timeout>
                        <FORMS_TIMEOUT oa_var="s_forms_time">5</FORMS_TIMEOUT>
                                <timeout oa_var="s_nodemanagertimeout" osd="unix" customized="yes">100</timeout>
                                <timeout oa_var="s_adminservertimeout" osd="unix">4000</timeout>
                                <timeout oa_var="s_opmntimeout" osd="unix">100</timeout>
                                <timeout oa_var="s_apctimeout">100</timeout>
                                <timeout oa_var="s_oacoretimeout">100</timeout>
                                <timeout oa_var="s_formstimeout">100</timeout>
                                <timeout oa_var="s_oafmtimeout">100</timeout>
                                <timeout oa_var="s_forms-c4wstimeout">100</timeout>
                                <timeout oa_var="s_oaeatimeout">100</timeout>
                                <timeout oa_var="s_tnstimeout">100</timeout>
                                <timeout oa_var="s_conctimeout">1000</timeout>
                                <timeout oa_var="s_icsmtimeout">100</timeout>
                                <timeout oa_var="s_jtffcsrvtimeout">100</timeout>
                                <timeout oa_var="s_formsserver_timeout">100</timeout>
                                <timeout oa_var="s_mwatimeout">100</timeout>




What do you reccommend to avoid this issue ?
which ones and how much increase ?
Thank You! :)
Linda
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

ErmanArslansOracleBlog
Administrator
Hi Linda:)

It can be the reason, but there are other reasons for this problem, as well.

Send me oacore log. (one of the servers, which started up in admin state right?.)

There should be a line in the log, like the following;

<Server 'oacore_server1' in cluster 'oacore_cluster1' is being brought up in administration state due to failed deployments.>

Just before this line ( maybe in previous page of the log), there should be the cause written.

Let's check this first.
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

ErmanArslansOracleBlog
Administrator
Let's check the log first,

but keep in the following in mind (for timeout related ADMIN State issue)

Reference Oracle Support :
When the HTTP session timeout is set to be longer than the deployment timeout (which has a default of 3600 sec), and graceful retirement is used in a side-by-side deployment, a deployment timeout event can occur before retirement, causing the application to change to the ADMIN state.
Notes: You can set the HTTP session timeout via the Administration Console (under the Web application you deployed), or via a few deployment descriptors, such as /weblogic-web-app/session-descriptor/timeout-secs.

You can set the deployment timeout using the -timeout option of weblogic.Deployer.
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

Linda
Hi Erman!
Thank you! :)
Yep when it behaved like this I can see the message in the oaserver:

====================
<The configuration at URI "<XX>/FMW_Home/user_projects/domains/EBS_domain_XX/config/fmwconfig/mbeans/../default-keystore.jks" cannot be loaded.>
<Nov 10, 2016 11:14:16 PM EET> <Warning> <Security> <BEA-090668> <Ignored deployment of role "Admin" for resource "type=<url>, application=DMS Application#11.1.1.1.0, contextPath=/dms, uri=/">
=======================

AND I dont see the messages when it fine.
AND that file doesnt' exist anyway... ( now its fine and there is no such file)

Now I confused... Does it say something  to you ?

Thanks for helping :)
Br, Linda
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

ErmanArslansOracleBlog
Administrator
This can be due to environment.
some environment variables (related wit Weblogic) may be left in the shell, which you use for yor problematic start or stop operations.
I need logs Linda :)
admin server log and oacore server log.
Also I need the exact sequence of events for this issue/reproducing the issue . (such as , 1)logged in using applmgr 2)stopped apps tier using adstpall.sh 3)killed remaining processes 4)started apps tier using adstrtal.sh 5)Checked te oacore server 's state 6) saw that it is in ADMIN state..)

Thanks :)
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

ErmanArslansOracleBlog
Administrator
Also tell me the recent changes that you have done in this environment.
--The changes that you have done, before the first time you saw this problem.
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

Linda
Hi Erman!
Thanks again for the hints and help! :)
I increased timeout to 600 for all components , run autoconfig  and no more issue .. I can't reproduce it anymore.. :)

if I may ask your opinion on other subject:
we do in one shot/downtime ( to save on testing efforts):
11204->12c upgrade + 12.1.3->12.2.6.

The compiling of db objects in db upgrade phase , takes alot of time... Can I skip it/pospone in in this phase and do that in the end of the upgrade as durinf the 12.2/12.2.6 will be aslo alot of invalids .. and compile only in the end ?
What do you think ?

Thanks again,Linda
Reply | Threaded
Open this post in threaded view
|

Re: Timeout parameters

ErmanArslansOracleBlog
Administrator
Hi Linda,

I don't think it is a good idea to skip the recompilation that is needed just after the db upgrade phase. It is a mandatory thing.
Also, EBS upgrade can be considered as a user level work. So, basically db session will be used by EBS 's patch wizard to create new packages, alter tables and so on.
Having a stable environment is necessary for a proper EBS upgrade.
You will probably fail in EBS upgrade if you skip the whole recompilation thing that is needed just after the db upgrade... (it is very risky, that's for sure)

However, alternatively, you can analyze the utlrp run and find the objects which it spents most of its time.. Note those objects, and if those objects are not mandatory(very critical ones) , just skip them.. (ofcourse test this carefully)

Also, I suggest you to try to increase the recompilation speed. Ensure it is running in parallel, ensure the resources are there for utlrp to consume, ensure there is no in-db wait --abnormal waits during utlrp run and check out this note : Utlrp.Sql Is Taking Too Long To Complete. (Doc ID 564605.1), this note is for 11g but will give you some ideas.


Lastly, you know Oracle has an automatic recompilation capability. You can give it a try.. However, you can never know all the database actions that EBS upgrade do (it may do an incompatible move, incompatible to auto recompile thing...)
Also remember the following:
--------------------------------
An INVALID Object problem may arise due to:

    Due to any patch installation.
    Database/Application level up-gradation
    DDL Changes

These changes may not cause compilation failures as the objects will be re-validated by on-demand automatic recompilation, but this can take an unacceptable time to complete, especially where complex dependencies are present.

For this reason it makes sense to recompile invalid objects in advance of user calls.  It also allows you to identify if any changes have broken the database code.