469,631 Members | 1,281 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,631 developers. It's quick & easy.

Users being logged out suddenly.

I have a weird one. My users will be on the system and suddenly get logged
out. I have forms authentication turned on with a 1200 minute logout (I
raised it that high to test this out.) Session timeout is also 1200 minutes.
It's almost acting as if its happening when IIS is cycling memory because it
get's to be to much memory. (I've been working with Microsoft on this problem
and they essentially say that have the system chew up memory is normal and
OK. Just cycle memory.)

The system is on a cluster - I don't know if that would cause a problem. I'm
thinking of changing the memory from inproc to DB but don't know if that will
help any.

Any thoughts?

Jeff.
Nov 5 '07 #1
3 2237
Jeff,
well, session variables at 1200 minutes is very, very long. There are very
good reasons to have timeouts shorter, so that memory can be collected. It
also depends on the items that are stored in the session objects. I've seen
instances where developers were storing large datatables in the session
store for each and every user, eating up absolutely tons of memory.

From what I understand, using a database when doing a clustered web site is
much better becuase a clustered web application can't of course share
session variables between nodes on the cluster.

Have you run some tests to see what how big the objects are getting to be in
the session store for each user? Also make sure you're doing some garbage
collection whenever you can. Even though .Net is managed code, one we still
need to ensure we are disposing of objects and resources as soon as we don't
need them to help speed up garbage collection.
--

Hope this helps,
Mark Fitzpatrick
Microsoft MVP - Expression

"WinDev" <Wi****@discussions.microsoft.comwrote in message
news:D6**********************************@microsof t.com...
>I have a weird one. My users will be on the system and suddenly get logged
out. I have forms authentication turned on with a 1200 minute logout (I
raised it that high to test this out.) Session timeout is also 1200
minutes.
It's almost acting as if its happening when IIS is cycling memory because
it
get's to be to much memory. (I've been working with Microsoft on this
problem
and they essentially say that have the system chew up memory is normal and
OK. Just cycle memory.)

The system is on a cluster - I don't know if that would cause a problem.
I'm
thinking of changing the memory from inproc to DB but don't know if that
will
help any.

Any thoughts?

Jeff.

Nov 5 '07 #2
On Nov 5, 6:43 pm, WinDev <Win...@discussions.microsoft.comwrote:
I have a weird one. My users will be on the system and suddenly get logged
out. I have forms authentication turned on with a 1200 minute logout (I
raised it that high to test this out.) Session timeout is also 1200 minutes.
It's almost acting as if its happening when IIS is cycling memory because it
get's to be to much memory. (I've been working with Microsoft on this problem
and they essentially say that have the system chew up memory is normal and
OK. Just cycle memory.)

The system is on a cluster - I don't know if that would cause a problem. I'm
thinking of changing the memory from inproc to DB but don't know if that will
help any.

Any thoughts?

Jeff.
your machine keys diffeerent, if you user arives from one node to
another he will not be able to authenticate there (as the key for
authentication-token encryption/decription is different, you have to
configure this in web.config so that both machines are using same key,
this way both of them will be able to use keys comming from client (ie
share clients)
regards
almir
ps
session timeout 1200 is long -very long it is time between two clicks!
if your sessiontimeout is 1h and user post a click ever 45 minutes it
will stay in session forewer

and use some shared storage for session, until now your users were
always on the same machine now they will share machines

Nov 7 '07 #3
Thanks. I've changed over to storing the session in SQLServer and we will
see if it is any better.

"kaza" <ka*****@gmail.comwrote in message
news:11**********************@d55g2000hsg.googlegr oups.com...
On Nov 5, 6:43 pm, WinDev <Win...@discussions.microsoft.comwrote:
>I have a weird one. My users will be on the system and suddenly get
logged
out. I have forms authentication turned on with a 1200 minute logout (I
raised it that high to test this out.) Session timeout is also 1200
minutes.
It's almost acting as if its happening when IIS is cycling memory because
it
get's to be to much memory. (I've been working with Microsoft on this
problem
and they essentially say that have the system chew up memory is normal
and
OK. Just cycle memory.)

The system is on a cluster - I don't know if that would cause a problem.
I'm
thinking of changing the memory from inproc to DB but don't know if that
will
help any.

Any thoughts?

Jeff.

your machine keys diffeerent, if you user arives from one node to
another he will not be able to authenticate there (as the key for
authentication-token encryption/decription is different, you have to
configure this in web.config so that both machines are using same key,
this way both of them will be able to use keys comming from client (ie
share clients)
regards
almir
ps
session timeout 1200 is long -very long it is time between two clicks!
if your sessiontimeout is 1h and user post a click ever 45 minutes it
will stay in session forewer

and use some shared storage for session, until now your users were
always on the same machine now they will share machines

Nov 8 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by iwdu15 | last post: by
10 posts views Thread by Lew Barnesson | last post: by
1 post views Thread by Smalley | last post: by
8 posts views Thread by Mike P | last post: by
3 posts views Thread by RogueIT | last post: by
13 posts views Thread by snowinfo | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.