Persistence Table and Client Connections

Is it consistently doing this? Can you show the relevant persistence entries before/after?

For the testing that we did with the one user, yes it was consistent. While the connection was running, would run 'b persist show all' and find the age from the table. They would refresh the app from the timeout (browser F5) and then when looking at the table, the age had reset. They were ~3k seconds when the F5 is set on this VIP for 14.4k. It seemed that it would continue to persistence and leads to speculation that the F5 may be apart of it by having a reset session.

Sometime this week, will dig some more, check at the stages between and see what the table and session/connection shows before refresh to log back in. I felt that it should have maintained the persistence entry until the 14.4k seconds was reached, this is what I need as well.

Thanks.

We went through with the test user set to a lower timeout value and here is the update. When timed out by the application, initiating a new session resets and gives a new age rather than continuing to could up the configured 14,400 seconds on the VIP.

Timed out by Oracle right now:

| Mode source addr Value 10.10.10.207 | virtual 10.51.0.101:teradataordbms node 10.50.1.201:teradataordbms age 539sec

Makes a new session:

| Mode source addr Value 10.10.10.207 | virtual 10.51.0.101:teradataordbms node 10.50.1.201:teradataordbms age 77sec | Mode source addr Value 10.10.10.207

Let the timeout ride from last update.

Current value:

| Mode source addr Value 10.10.10.207 | virtual 10.51.0.101:teradataordbms node 10.50.1.201:teradataordbms age 610sec

Without logging in, taking action that asks for a new login, the session is:

| Mode source addr Value 10.10.10.207 | virtual 10.51.0.101:teradataordbms node 10.50.1.201:teradataordbms age 4sec

A new login probably creates a new TCP connection, which will reset the persist table timers. The big-ip will see a new connection request, 3-way handshake the client, lookup in the persist table. It finds a persist record for that sourceIP, DOES NOT load balance and follows the persist table, opens a new connection to the server, and resets the age timer on the persist record.

This is how it is supposed to work.

You have to also consider other TCP timeouts. The client TCP stack, the server TCP stack, and especially the EBS/Forms application timers. If those are lower, they will often close/reset TCP connections. When big-ip sees that, it honors the request, AND removes the persist table record. With no persist record, big-ip will then load balance any new TCP connections from that same sourceIP.

There are also TCP Idle Timeout values. Any connection through big-ip without any activity will be closed at 5 minutes ( the default setting ), also clearing the persist table entry. So Idle timeout values play a large role in TCP connections as well.

One other thought - I see from your description, you are load balancing through VIPs for EBS login, but not for FORMS ? You are allowing the Forms server and client to interact directly, bypassing big-ip ? You could run the forms traffic through big-ip as well, and enable "Match Across" vips/pools. However, some developers hard code IPs in their forms, which again will tell the client to bypass big-ip. And sometimes the FORMS process will pick random TCP ports and other ugly, non load-balancer friendly behaviours, so this may not be an option.

In general, you do not need large persist timers. If EBS/Forms application timeouts are about 15 minutes, then 20-30 minute persist timers will suffice just fine. The persist table will clean itself whenever a tcp connection is closed/reset.

You could always follow the Oracle and F5 deployment guides for EBS, and use Cookie persist as recommended, and TCP Idle Timeouts at 30 minutes.

Good Luck, Chris.

https://f5.com/solutions/deployment-guides

Thanks for the details.

I ran the stats close by to get clarity to the session table, the test user EBS timeout was 5 min -- very low to all other timeouts. Yes, the forms session is the EBS timeout while F5 is web session. I would have expected the web session to remain at the low rate of 5 min forms timeout. Maybe there is a reset flag in the web session. I figured the source remaining the same would keep account in the persistence table to continue instead of starting a new one.

We moved (thank god) from Cisco ACE to F5 and the persistence was a quick implementation after a few weeks of being live when a user in a live session would get directed to a new server for a new form breaking forms session. It's been stable for years but they recently set the EBS timeout to 30 min when it hadn't previously existed. My large timers are based on 2 main points of the working day for previous timeout of EBS values, could be adjusted now they have reduced that to 30 min.

As for running forms through F5, that would be having the F5 as the gateway for which replacement of the ACE (happy again) was not achievable to redesign to achieve. That is my understanding since the forms server generates the session separately from the web session. But at least a new EBS version is soon on our horizon so I will have a chance to start a new fresh.

Thanks again. Best to you.