In case you are interested, I got the solution (by Weblogic Support's help):
I have to turn off 'FileCaching' parameter in the IIS-Wenlogic plugin on both of the Web Servers.
When set to ON, and the size of the POST data in a request is greater than 2048 bytes, the POST data is first read into a temporary file on disk and then forwarded to the WebLogic Server in chunks of 8192 bytes. This preserves the POST data during failover, allowing all necessary data to be repeated to the secondary if the primary goes down.
Note that when FileCaching is ON, any client that tracks the progress of the POST will see that the transfer has completed even though the data is still being transferred between the WebServer and WebLogic. So, if you want the progress bar displayed by a browser during the upload to reflect when the data is actually available on the WebLogic Server, you might not want to have FileCaching ON.
When set to OFF and the size of the POST data in a request is greater than 2048 bytes, the reading of the POST data is postponed until a WebLogic Server cluster member is identified to serve the request. Then the Plugin reads and immediately sends the POST data to the WebLogic Server in chunks of 8192 bytes.
Note that turning FileCaching OFF limits failover. If the WebLogic Server primary server goes down while processing the request, the POST data already sent to the primary cannot be repeated to the secondary.
Finally, regardless of how FileCaching is set, if the size of the POST data is 2048 bytes or less the plugin will read the data into memory and use it if needed during failover to repeat to the secondary.
Thanks Haq. So File caching is buggy and truncates the POST sometimes ?
From what I understand, lets say you have a POST for 1024 * 10 bytes. The first 1024*8 bytes will be in disk. This data is chunked to the WL server. The next 1024*2 bytes that remain is read from the client and then fed to WL. If IIS cannot read this then the POST is truncated ? Or is this an IIS bug that truncates the data every now and then when disk caching is involved ? Are there any steps to replicate the problem ?
Thank you for sharing the solution. You saved some one a lot of head ache
Apparently their verdict is that it is an issue with most proxy servers (including IIS) where Socket is closed unpredictably and if FileCaching is on then we will face the issue that I was facing. I asked that can't we some how increase or control the closing of the Socket instead of turning off teh caching as it can result in data loss (specially in Clustering) environment. Their reply was that ye sthe data loss will be there but it will be minimal and this is the only popular solution that they suggest to most users. Also, the developers can then change and modify their applications to control and reduce the data being sent. This is from the conversation that I had with them on the phone!
Joined: Sep 17, 2012
I run Apache 2.2 and WLS 10.3.4. Was having the same problem until I played around with my setup. I had to simulate a few consecutive ajax calls that would take some time to process on the server, then kill the browser in the middle of all those requests. Having FileCaching OFF was the issue. Not the other way around. So I removed it, default is ON. And now the problem went away.