Your firewall is probably using state tracking to track which machines are allowed to talk with one another and the timeouts associated with state tracking are configured to time out after x seconds of inactivity. Since many of the connections between the db and the arserver are idle at night, the firewall drops the connections from the state table, thus severing the connection.
The best solution I see is to configure the firewall to explicitly allow traffic between the two hosts based on the source ip, destination ip, and designated destination port, e.g., allow arserver -> dbserver:1523 This takes state tracking out of the equation and will allow the arserver to talk with the db server regardless of activity/inactivity, thus allowing the original socket connection to persist. For more information on stateful packet filtering, see: http://en.wikipedia.org/wiki/Stateful_firewall The main thing to understand is that each time a host connects to another host, a state is added to the state table and remains there until x amount of time of inactivity. Future connections between the two hosts will require another state, thus causing the client to renegotiate the source port since most stateful firewalls only allow SYN packets through when establishing a state. Axton Grams On 9/19/07, J.T. Shyman <[EMAIL PROTECTED]> wrote: > Hello all, > > Does anyone on this list have any experience with AR 7 on RHEL 4 and > Oracle 10g where the AR server and Oracle server are off two different > interfaces on a firewall? > > The reason I ask: We are currently working in an environment where > the AR Server is in one VLAN, the Oracle server is in another, the two > VLANs are separated by at least one router and a firewall. We've found > that an idle AR server, say overnight, will "lose" connection to the > Oracle database which will cause users to see ARERR 552m ORA-03114 and ORA- > 03135 errors on the screen and in arerror.log. If, after such an idle > period, a user attempts to log in to RUT several times in a row they > eventually get connected and the AR server begins to respond appropriately. > > Other times users can get logged in fine but get the errors when > navigating forms or firing workflow. We also see these errors in > arerror.log on archiving processes where the gap between runs of the > archival is greater than one hour. > > If we move the AR server and the Oracle server onto the same VLAN and > take the firewall (and anything else between the two) out of the equation > the problem goes away --not to mention performance of the AR server is > much faster. > > Has anyone run into this before and have some insight? > > Thanks! > > J.T. Shyman > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
