Jesse,
It seems to me that there are some few RT users that have gone to the
file-session method due to some problems with the session table in the
DB, especially in ORACLE. Are there now some fixes we can download that
will allow us to drop the file-session methodology and go back to using
the ORACLE DB? If not, has anyone at BestPractical seen some consistent
set of circumstances (and appropriate fixes) that would lead us to a
resolution to the file-session problems we're all having with FireFox
and IE? I sure hope so. I've been ready to put 3.6.4 into production for
well over a month and still can't get this bug fixed in order to do so.
Some help, please. Thanks.
Kenn
LBNL
On 12/14/2007 5:17 AM, Jason A. Diegmueller wrote:
Kenn--
My experience is:
* If I delete all cookies from browser and "rm" the session_data
directory on the server, the next login will be double.
* After that, if I quit my browser and go back in, I only get a
single-login (like expected)
* If I only delete the session directory (but not the cookies), I only
get a single-login
* If I only delete the browser cookies (but not the server-side
session_data directory), I only get a single login
* The ony time I get double-login is "in the morning" (which probably
more specifically is "after $x hours inactivity" but I don't know what
that number is)
To be specific about "double-login", I:
* Browse to my RT
* I'm asked to login, and do so
* I am presented with the "RT at a glance page
* I click something, anything
* I am asked to login again, and so so
* Then I'm good to go
Unfortunately I'm not a developer, so I lack the cognitive capacity to
actually fix this. I'm decent at troubleshooting and isolating
problems, but I can't even write "Hello, world!" in Perl so all I can do
is report this to BPS (like I have) and hope they fix it. At this point
in time, we've chosen to live with the problem.
Of note, I didn't have this same problem until I migrated to the FreeBSD
box. I was previously on a Linux server, perl 5.8.8, MySQL 5.0.x.
Maybe a version of Apache::Session? Or something similar?
-jd
On Thu, 13 Dec 2007, Kenneth Crocker wrote:
Jason,
Thanks for replying. We want to use the filesystem-based session
method as well. We just can't seem to get past that initial dbl-login
problem. As with you, it only happens the first time the session is
invoked. Once we stay in RT after the initial dbl-login, we do not see
that problem again, FOR THAT SESSION. So, do you still have that
dbl-login or have you come up with a way around it? I've QA tested
every functionality that exists in 3.6.4 a zillion times and it is
REALLY REALLY ready to put in and ALL my clients are waiting with
GREAT anticipation for the new version. However, I am loathe to put
anything into production that has an inherent bug. Got any suggestions?
Kenn
LBNL
On 12/13/2007 2:19 PM, Jason A. Diegmueller wrote:
[sent directly instead of on-list]
Kenn--
I run RT 3.6.5 on FreeBSD 6.2, MySQL 5.0.45a, and use
filesystem-based Sessions. I experience double-logins (not triple),
and usually it's only the first login of that day that is double.
Happens with IE or Firefox as well.
I mentioned something to Jesse @ BPS and he believed there to be a
"locking issue" and acknowledged it sounded like a bug. When using
MySQL to store Sessions, I don't have the problem -- but we prefer
filesystem-based Sessions because it allows parallelization of RT, in
that you can have activity in multiple tabs. When using MySQL, I
don't get the double-login but only one tab can be actively
loading/updating/whatever at a time.
-jd
On Thu, 13 Dec 2007, Kenneth Crocker wrote:
To All,
I would like to hear from ANYONE who has RT 3.6.4 on ORACLE 9+
and have managed to get session control to work properly with
FireFox or IE using either the DB sessions table OR SPECIFICALLY
straight to data file. We are going straight to data file, have made
sure our URL's are correct, use LDAP and still no joy. I can't
believe that this problem could be ongoing in a production ORACLE
environment. This problem is keeping me from putting 3.6.4 into
production. Please Help!
Kenn
LBNL
On 12/12/2007 6:37 PM, John D Groenveld wrote:
In message <[EMAIL PROTECTED]>, John
D Groenveld writes:
My WAG is that Firefox and IE are doing parallel requests
and triggering an Apache::Session::Lock::File deadlock which is
somehow forcing the session to be invalidated.
Most RT users probably use MySQL and Postgres and RT defaults
to using those databases for session management so won't stumble
across this bug.
I copied my data from Oracle to Postgres.
Then I disabled Apache::Session::Postgres in
/opt/rt3/share/html/Elements/SetupSessionCookie
As expected, I got the deadlock error and was forced to
reauthenticate.
Need to do more debugging to see whether there are indeed
parallel requests.
John
[EMAIL PROTECTED]
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
If you sign up for a new RT support contract before December 31,
we'll take
up to 20 percent off the price. This sale won't last long, so get
in touch today. Email us at [EMAIL PROTECTED] or call us
at +1 617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly
Media. Buy a copy at http://rtbook.bestpractical.com
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
If you sign up for a new RT support contract before December 31,
we'll take
up to 20 percent off the price. This sale won't last long, so get in
touch today. Email us at [EMAIL PROTECTED] or call us at +1
617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:
If you sign up for a new RT support contract before December 31, we'll take
up to 20 percent off the price. This sale won't last long, so get in touch today.
Email us at [EMAIL PROTECTED] or call us at +1 617 812 0745.
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com