|
Administrator
|
So the problem is only on node 2 and node 3 then.
1) Did you run autoconfig on those nodes? And were those autoconfig run(s) successfully completed?
--if you retry the autoconfig , check the logs and ensure
2) check the contents of the context xml files on those nodes->
- s_webhost, s_webdomain, s_webentryhost, s_webentryurlprotocol, s_webentryurlport
- s_login_page, s_external_url
- s_endUserMonitoringURL
- s_webport, s_webssl_port
- s_apps_jdbc_connect_descriptor, s_tnsmode
- s_dbhost, s_db_serv_inst
- s_cluster_inst_name
If you find PROD references → regenerate context (adclonectx.pl) and run autoconfig.
3) OHS httpd.conf / mod_wl_ohs.conf
- $IAS_ORACLE_HOME/Apache/Apache/conf/*.conf
- $FMW_HOME/webtier/instances/EBS_web_*/config/OHS/EBS_web/*.conf
Search for PROD hostname. Even a ServerName, RewriteRule, or WLProxySSL line can cause the redirect.
4) DBC file
$FND_SECURE/<SID>.dbc — confirm APPS_JDBC_URL and GUEST_USER_PWD reflect the clone, not PROD. The FND_NODES lookup happens through this; a stale DBC sometimes survives a botched clone.
5) You checked FND_NODES, but also check this table:
SELECT name, last_synchronized_date FROM fnd_oam_context_files;
Old PROD context rows can still be served up to nodes that re-register on startup.
6) WF Notification URLs (less likely but worth a glance)
SELECT * FROM wf_resources WHERE text LIKE '%<PROD-hostname>%';
7) Verify it's not DNS / hosts / LB
Check with nslookup and curl on those nodes.
|