1). We had been getting some "Apache unable to contact the forms server" type errors (the users were seeing the "Failure of server APACHE bridge" error). The log files showed nothing of interest. I increased the memory allocated using setDomainEnv.cmd, and the error seems to have gone away. Yes, I know that it was a shotgun approach, trying something without really having a reason to do so, but it seems to have helped Edit: Now that I review the OHS logs instead of the WLS_FORMS logs, I have found log messages, which leads me to Doc 1380762.1, which tells me I need a patch. DOH. And, oh crikey, Forms 188.8.131.52 is out, it came out shortly after we downloaded 184.108.40.206 to create these environments. Good news/bad news kind of thing...<blockquote>The Apache Bridge error is fairly straight forward if you understand what it is telling you. It is an error generated by mod_wl_ohs who is owned by OHS (Apache). This module is responsible for the connection between OHS and WLS. The Apache Bridge error means that OHS (mod_wls) was unable to get a response from the WLS managed server it was calling. Basically it was unable to cross the bridge ;) The cause could be anything from the managed server is not running, to the managed server is over tasked, or there is a network configuration issue and the managed server simply didn't hear OHS calling.
2). As tony.g suggested, we are looking for what we should do to solve the "I have n servers with x GB of RAM, what should I do to the out-of-the-box configuration of Forms for stability" question.<blockquote>As I mentioned, there really are no "Forms" specific tweaks related to how much RAM your machine has. The only exception to this is (although somewhat indirect) to use JVM Pooling. JVM Pooling can reduce the size of each runtime process's memory footprint by moving its java calls to the jvm pool then sharing common requests with other running runtimes. Memory usage by OHS or the WLS managed server really has little to do directly with Forms. Specifically to the managed server, from a Forms point of view, I would not expect the memory cost of WLS_FORMS to increase much because of load. I expect it to increase as concurrent load increases, but I would not expect it to be significant. If I had to guess, seeing an increase of 1m or less per user would not surprise me (this is just a guess - I don't know what the expected values would be). If we were to use our (Oracle) older scalability guidelines, typically we would have suggested that you should consider about 100 sessions per 1 jvm for best performance. Given that v11 uses a newer java version and scalability is better today, I suspect you can easily scale to a few hundred (e.g. 300) or so before performance drops off. Beyond that, the need to add more managed servers would likely be necessary.
3). HA is important to us, so we are implementing a cluster of Forms/Reports servers with an LBR in front of it. I have read in the docs on clustering, cloning a managed server, and via Support, how to increase the heap memory for the WLS_FORMS server. My thought process was "if Oracle gives me instructions on how to increase heap memory and how to clone managed servers, there must be a scenario in which doing so provides benefit." I'm trying to understand the scenarios in which we would do either of those activities.<blockquote>Refer to the note I mentioned above. Generally, if you limit the number of concurrent sessions to less than around 300-400, I would think the default settings should be fine. If you think you would like to go beyond 300 or 400 per managed server then likely you will need to increase the max heap for the managed server. Again, refer to the note I mentioned previously.
I am aware of the JVM pooling (yes we do call out to Reports) - I've yet to implement this, but it's on my to-do list.<blockquote>This is discussed in the [url http://docs.oracle.com/cd/E38115_01/doc.111210/e24477/jvm.htm]Forms Deployment Guide</blockquote>