I’ve been using an iPhone sinceFebruary and over that time I have used a bunch of websites running on Oracle. Such as Grid Control, custom applications deployed on Weblogic and Oracle Application Server, etc all which work fine. I wasn’t asked to test our applications but happened to be in situations where my iPhone was quickly available.
I was kind of surprised when I was told one of our applications didn’t work properly on the iPhone or iPad. When a user tried to access the site a Safari error would pop up:
“Safari can’t open the page <website> because Safari can’t establish a secure connection to the server <website>”
We also verified the problem existed on the desktop with Safari 5.
A quick search on Google turns out a ton of hits, none of them solved the problem but provided us with some ideas to try out. We contracted our SSL certificate provider and they sent us another chain certificate and a different root certificate which they said would resolve any issues we were having Apple products.
We loaded them into Oracle Wallet manager but unfortunately that didn’t work either. Back to square one.
A coworker enabled tracing in Webcache and noticed the following in the logfile:
[17/Jun/2010:10:48:46 -0400] [warning 11904] [ecid: 104838150494,0] SSL handshake fails NZE-29048
Since it was an obvious error on the client side I was surprised to see this as a warning. It just goes to show that if your trying to troubleshoot a problem, always enable tracing.
This error led me to Metalink note:
Internet Explorer Fails To Connect To Web Cache Via SSL If SSLV2.0 Is Unchecked - NZE-29048 [ID 342626.1]
By default Webcache sets SSL_ENABLED to SSLV3_V2H which only supports SSL V2.0 and SSLV3.0 not TLSv1. In the Metalink note they did an Ethereal Sniff and found that IE tries to use TLSv1 but since by default its not supported, it can’t connect. I also found a post in the Safari forum of Apple Discussions which basically talks about the same problem.
In our staging environment I tried the fix, changing SSLENABLED in $ORACLE_HOME/webcache/webcache.xml from SSLV3_V2H to SSL, restarted Webcache and success!
What made this problem slightly more confusing to troubleshoot was that we have another environment with the same version of Webcache. We could access that application from our iPhone/iPad successfully. The only difference is in that case SSL isn’t handled by Webcache but by an SSL accelerator.
Tuesday
Why are R12 patches so large?
While performing patch analysis for some one-off patches I noticed there was quite a size difference between codelines. (ie. R12.AP.A vs R12.AP.B) For example, take a look at payables patch 8733916. The version compatible with AP.A is 35.4MB while the AP.B version is only 9MB.
A coworker forwarded me a note from Metalink which describes the issue:
Release 12: Why are One-Off Patches so Large? [ID 841218.1]
The note has an interesting chart which shows how many files are applied from a patch based on the codelevel. Basically a one-off patch contains all the files necessary to fix the problem on a base R12 release. So to summarize the note, the more upto date you keep your EBS environment, the less work adpatch has to do in order to apply patches.
Background Info: Adpatch performs a number of tasks when applying a patch. One of them is to compare versions of files supplied by the patch to those in your EBS environment. Only newer files will be copied.
In my case, with patch 8733916, its basically the same situation. R12.0 was released I believe back in Jan 2007, while R12.1 was released in May 2009. So if a bug affects both versions, its not surprising that the patch would be smaller for R12.1 since its more upto date. Now, I would assume this is highly dependant on the bug but I haven’t seen a patch for R12.1 that is larger than R12.0.
A coworker forwarded me a note from Metalink which describes the issue:
Release 12: Why are One-Off Patches so Large? [ID 841218.1]
The note has an interesting chart which shows how many files are applied from a patch based on the codelevel. Basically a one-off patch contains all the files necessary to fix the problem on a base R12 release. So to summarize the note, the more upto date you keep your EBS environment, the less work adpatch has to do in order to apply patches.
Background Info: Adpatch performs a number of tasks when applying a patch. One of them is to compare versions of files supplied by the patch to those in your EBS environment. Only newer files will be copied.
In my case, with patch 8733916, its basically the same situation. R12.0 was released I believe back in Jan 2007, while R12.1 was released in May 2009. So if a bug affects both versions, its not surprising that the patch would be smaller for R12.1 since its more upto date. Now, I would assume this is highly dependant on the bug but I haven’t seen a patch for R12.1 that is larger than R12.0.
Subscribe to:
Posts (Atom)