An
interesting post by
Steve Muench, regarding all the above. It's a bit old (November 2004) and something might change since then but nevertheless it worth reading.
Reposting below:
This
week one of our worldwide support engineers was working with a
customer experiencing a problem of having their HTTP session
sporadically get dropped in their ADF-based application. The problem
only occurred when users would use the Internet Explorer browser; it
didn't reproduce with Firefox, for example, however the customer's
userbase are IE users, so switching to Firefox wasn't an option as a
workaround.
The support engineer did some testing to discover that Internet Explorer strictly adheres to the
RFC2109
specification's limit of 20 cookies per domain. I worked with him to
build an example servlet which accessed the J2EE web container's servlet
session, and then proceeded to add a cookie with a unique name on each
time the page would get refreshed...Cookie1, Cookie2, Cookie3, etc.
After refreshing the page 19 times using the Internet Explorer browser,
we could see we had twenty cookies like this:
JSESSIONID=...
Cookie1=...
Cookie2=...
:
etc.
:
Cookie19=...
Of course, the JSESSIONID is the cookie used by the web container to
keep your browser session "connected" to the server-side servlet session
object over the stateless HTTP protocol. If you lose the JSESSIONID
cookie, then to the server, the next time you visit it's as if it was
your first time again. Refreshing the page one more time with our test
servlet, showed that Internet Explorer -- having hit its limit of 20
cookies -- picked the least recently set cookie and got rid of it to
make room for the new Cookie20 we created. It turns out that the least
recently set cookie was the very JSESSIONID cookie that was our lifeline
to the servlet session. Ouch! With Firefox, it
appeared that fifty cookies was the limit in our testing, while other
browers like Opera had yet another limit like 30. But in IE, this effect
occurred at the RFC2109 20 cookie limit.
The support engineer asked the customer whether the own application
was creating lots of cookies, but the response was that they weren't
creating any cookies themselves. Then he asked them how many distinct
ADF application modules their JSP pages were using, and the answer was
"about 25". Next he asked them if they were using the ADF Business
Components failover mode. They didn't remember having set it, so they
were using the default which is jbo.dofailover=true.
That is, the failover mode is on by default unless you disabled it in
your application module configuration or by supplying a Java System
parameter named jbo.dofailover=false at system startup time.
So, the support engineer had found the problem. Each ADF data control
that is based on an ADF application module and which is being used in
failover mode, saves a browser cookie that contains the persistent
snapshot ID of the pending application module transaction state (which
by default is saved in the database in a BLOB in the PS_TXN table, with
that persistent snapshot id as its primary key. If you use 25 unique
application module-based data controls in your application and you leave
the failover mode on, you'll need to save 25 browser-side cookies to
provide that failover support. If the middle-tier application server you
were using goes down, on your next request, whatever server you do end
up getting serviced by uses the value of the persistent snapshot id in
the browser failover cookie for each data control to rendezvous with the
right persistently stored pending changes.
Trouble is, if you need 25 cookies plus the JSESSIONID which makes
26, then at some point you'll hit your 20-cookie limit in Internet
Explorer, and there's a chance that IE will throw out your JSESSION
cookie, which cuts off your browser user's lifeline to the session. That
in an of itself wouldn't cause trouble for ADF, but in this customer's
case, they had placed a user login object of their own creation in the
session, so it was no longer there once Internet Explorer had forgotten
its JSESSIONID cookie.
The solution? The customer didn't actually need the failover feature, so they added the -Djbo.dofailover=false Java VM parameter to their application server startup to disable the ADF failover mode, and the problem has gone away.
One tip to help make sure that your ADF Business Components runtime
configuration settings are actually getting set to what you think they
are, is to run with the ADF Business Components diagnostics turned on --
which you do by adding the Java VM parameter -Djbo.debugoutput=file
-- and then grep through the diagnostics files that will be named
bc4j*.log in the system temp directory for the ADF configuration
property name. The diagnostic output will tell you the value that it is
using for each configuration property, and it will tell you where it
read that value from (your configuration "client environment", System
Property, etc.).
Check you
browser limitations with
this tool.
