Good Morning,

We've had a wierd problem at one of our sites. We have users who are logging
in, and then later closing our application (and even turning their computer
off). However, when we go into our svradmin application and connect - it's
showing these users still connected to the server (some of them with 3
active sessions).

The sessions are not disconnected, but still remain active (connected), even
though the user has closed down their whole PC. (Even after overnight >
12hrs, the connection still shows as active)

The server has the following configuration:

Max Connections: 999
Connection Timeout: 300secs
Dead Session Cleanup Int: 30 secs
Dead Session Expiration: 14400 secs
Maximum # of dead sessions 64

Running DBISam Ver 4.26b1

In the end, with a number of ghost open sessions, it caused our users to get
the error saying that the connection to the server has timed out after
waiting for a response, which got me looking at the server in the first
place.

Can anyone shed some light on what might be causing this problem?

Thanks & Regards

Adam.

Adam:

Just curious, is there a particular reason for having a 4 hour Dead
Session Expiration time period? As far as the open sessions, is there
possibly some procedure or event running which the user might have
initiated and is still running? Is it possible that it is some larger
query or filter operation which is taking longer than the user
anticipated and they "get out of it" while it is still running? (I had
that happen once and the user thought there was no data so they closed
out of the report but they couldn't cancel the filter operation. That
was a bad design on my part.)

I can't say why the dead session doesn't expire after the 4 hour time
period but it's possible that if you pare that down a little, it might
make a difference.

Just some thoughts...

--
Regards,
Jan Ferguson [Team Elevate]


Adam H. wrote:


<<The sessions are not disconnected, but still remain active
<<(connected), even though the user has closed down their whole PC.
<<(Even after overnight > 12hrs, the connection still shows as active)

Hi Jan,

> Just curious, is there a particular reason for having a 4 hour Dead
> Session Expiration time period?

Actually - I have no idea. What sort of time period should I be having for
the Dead Session Expiration?

> As far as the open sessions, is there
> possibly some procedure or event running which the user might have
> initiated and is still running? Is it possible that it is some larger
> query or filter operation which is taking longer than the user
> anticipated and they "get out of it" while it is still running? (I had
> that happen once and the user thought there was no data so they closed
> out of the report but they couldn't cancel the filter operation. That
> was a bad design on my part.)

I don't have any procedures on the server end itself. It's the standard
DBISam server with no modifications, so there shouldn't be any server side
procedures running that I don't know about.

> I can't say why the dead session doesn't expire after the 4 hour time
> period but it's possible that if you pare that down a little, it might
> make a difference.

Thanks for that. I thought the same thing, but after 12hrs, they still
remain, so for some reason it seems as though the DBISam server still things
that the users computers are still turned on and physically connected.

Cheers

Adam.

Adam

I have been using the following configuration and it never happens:

Dead Session Cleanup Inteval: 30 seconds
Dead Session Expiration: 15 seconds
Max # of dead sessions: 0 (zero) <------------ Here is the big difference

Eduardo

Adam H. wrote:

<<Hi Jan,
<<
<<<<Just curious, is there a particular reason for having a 4 hour Dead
<<<<Session Expiration time period?
<<
<<Actually - I have no idea. What sort of time period should I be
<<having for the Dead Session Expiration?

It depends on what you might need for your clients. If they might
"re-enter" your application after the session times out within a
reasonable time period (i.e. maybe 30 minutes or less) then I would set
it at 1800 secs or less. Remember that "Dead" sessions in the database
server are sessions that have been inactive for a certain connection
timeout period due to either a lack of client session requests or to a
physical network interruption in service. Since most work days are 8-10
hours, 12 hours to me seems a might excessive (meanwhile a 30 minute
lunch break is very normal.)

<<I don't have any procedures on the server end itself.

But do you have something going on client side that, for some reason,
does not shut down with the application and still maintains a
connection with the server? Do you explicitly close your session as the
user terminates your application? (the session should disconnect
automatically but in case something else is going on)

--
Regards,
Jan Ferguson [Team Elevate]

Hi Jan,

Thanks for your reply...
"Jan Ferguson [Team Elevate]" <jbNOSPAMfergusonATgmailDOTcom> wrote in
message news:D9F82D53-EF54-4EF5-B971-265FF21E4443@news.elevatesoft.com...

<snip>

> I would set
> it at 1800 secs or less. Remember that "Dead" sessions in the database
> server are sessions that have been inactive for a certain connection
> timeout period due to either a lack of client session requests or to a
> physical network interruption in service. Since most work days are 8-10
> hours, 12 hours to me seems a might excessive (meanwhile a 30 minute
> lunch break is very normal.)

Excellent - thanks for that. I'll change mine to 1800.

> <<I don't have any procedures on the server end itself.
>
> But do you have something going on client side that, for some reason,
> does not shut down with the application and still maintains a
> connection with the server? Do you explicitly close your session as the
> user terminates your application? (the session should disconnect
> automatically but in case something else is going on)

But, if the client side has their machine physically turned off, it can't
still be maintaining a connection to the server. (In this case, the clients
had turned their computers off, and gone home for the night, yet the server
still showed their connections as ACTIVE (ie, not even disconnected!))

Cheers

Adam.

Adam H. wrote:

<<But, if the client side has their machine physically turned off, it
<<can't still be maintaining a connection to the server. (In this case,
<<the clients had turned their computers off, and gone home for the
<<night, yet the server still showed their connections as ACTIVE (ie,
<<not even disconnected!))

I have seen that happen, with the physical machine turned off, if the
client did not exit the application correctly. I'm not saying that is
what happened in your situation however this would be a physical
network interruption which would create a dead session. If your dead
session expiration was 12 hours this would account for that portion of
it. That may not account for the  >12 hour situation you desccribed but
if it wasn't quite yet 12 hours and the user is reporting 12 hours +,
that could explain your situation.

I'm sure your users are well trained in the use of computers and your
application but I would first investigate whether someone is not
exiting the application properly at the end of their shift and instead
just turning off their computer with your application still running.
You have already stated that you were changing the dead session
expiration to 1800 seconds (30 minutes) instead of 12 hours. See if
that combination was what was causing the issue you and your users were
seeing.

--
Regards,
Jan Ferguson [Team Elevate]

Hi Jan,

Thanks for your reply...

I have made those changes (changing expiration to 1800 seconds) at lunch,
but even this afternoon we have experienced the same problem. Some users
were logged on (and active) with up to 5 concurrent connections - some
showing 'last connected' over 4 hours ago, even though my server is set up
to clean up dead sessions after 30 seconds, and set a dead session
expiration at 1800 seconds.

No users have reported any crashes this afternoon.

However, When I check the server logs, I get a lot of messages like:

[WARNING] Re-connection rejected, session not found [Client Version: 4.26]
Username: Address: 10.30.11.118 Encrypted: No Thread: 5148 Session: xxxxxxx

.... although there are far more of these warning messages than there are
ghost sessions. (Like hundreds of these warnings)

Very interesting that the username isn't displayed! I'm wondering if this
has something to do with the problem.

Also interesting to note is that the server is showing these errors, but
users are not reporting any errors with the client application.

Regards

Adam.

Hi,

I think I've found the problem... The users are NOT logged in. A few other
users who decided to 'share credentials' WERE logged in, and keeping there
machines on over night!

That looks like it will account for the wierd 'ghost' records, although I'm
still concerned about the messages like:

[WARNING] Re-connection rejected, session not found [Client Version: 4.26]
Username: Address: 10.30.11.118 Encrypted: No Thread: 5148 Session: xxxxxxx

Cheers

Adam.

Adam,

<< The sessions are not disconnected, but still remain active (connected),
even though the user has closed down their whole PC. (Even after overnight >
12hrs, the connection still shows as active) >>

Sounds like a middleman piece of hardware is keeping the connection alive.
The server can only determine that a connection is "gone" if the piece that
it is connected to has dropped the connection on their end.

--
Tim Young
Elevate Software
www.elevatesoft.com