Hi all,
Hoping someone can give me some ideas.

We have a Perv 8 SP1 database running on Netware 6.0.
What I've found is if the user does not close down the application
properly (easiest way to replicate that is turn the PC off without
shutting it down), the user's connection to each of the Pervasive data
files (as shown in Perv Monitor) is left open indefinitely. If you
shut the app down properly, the connections are closed nicely. This
eventually starts to cause nasty issues once there's lots of these
ghost connections.

The live system is running on Netware 6.0 SP5. I have built a test box
with NW 6.5 SP4 and thrown on Perv 8 SP3 and the same thing occurs on
that.

i'm wondering if anyone has any ideas on things to try in order to get
these connections clearing. I'm thinking possibly TCP timeout settings
or something? I have tried the 'auto reconnect timeout' and 'auto
reconnect enabled' options and that didn't seem to help.

Thanks in advance for any suggestions,
Dave

There are several ways to terminate a connection:
1) The application specifically calls Btrieve with the RESET (28) or
STOP (25) operations. This will properly terminate the connection, and
is typically done when an application completes. All files are closed
and the connection is dropped.
2) Use the Monitor application to terminate the selected (or all)
connections. Any active operations are canceled, transactions are
aborted, locks are released, files are closed, and the session is
terminated properly.
3) In the event of a network failure, the transport layer mechanism
(SPX or TCP) will terminate a session if it detects a lack of response
from the watchdog process. This also has the same effect as #2, but
has a few more "issues". (See below.)


When a workstation abnormally ends (such as a power-off), the transport
latyer mechanism's watchdog process is responsible for clearing the
connection. Here's how these work:
- SPX: SPX was designed for a local network where sending packets is a
low-cost operation. The SPX watchdog sends requests to the client
every 3 seconds (every 6 seconds with a "reply required" flag set).
The workstation MUST acknowledge the watchdog packet. If the
workstation fails to respond within the watchdog timeout, the server
will terminate the connection. (I'm a bit rusty on SPX nowadays, but
the timout is 30 seconds, if I recall correctly.) This means that any
lost SPX connection should be terminated within a minute or so.
- TCP: Since TCP was designed for a long-haul network (where sending
packets is expensive), it does not use a 3-second watchdog. Instead,
the default TCP stack uses a 2-hour watchdog timeout. Because of this,
a TCP connection that is killed off due to a failing workstation can
exist for just over 2 hours from the last transmission. (After the
two-hour watchdog timeout, there is a series of retries that are also
tried, just in case the watchdog packet was lost.) In any event, the
conection SHOULD be dropped within two hours. I know this is
adjustable on Windows, but I do not know if there are adjustments for
NetWare timeouts or not.


Now -- you may NOT be seeing sessions disconnect even after two hours.
Here's why: The application that is running uses the Pervasive
requesters to contact the server. These requesters are responsible for
the database session connection. If the application ends abnormally
(such as a GPF that does NOT shut down the workstation), then the
requester DLL's are still in memory. This is because the operating
system "usage count" of the DLL is still positive -- therefore the OS
thinks an app is still running, and the DLL's are not removed from
memory. Because the requesters are in memory, they WILL still respond
to the server's watchdog packets, and they will maintain the connection
indefinitely, even though no app is "actively" using them.

There is no solution to this second case, other than going back to the
app developer and make sure that all crashes can be removed, or that
all exit points properly call the STOP/RESET commands to terminate the
sessions. When in doubt, always restart your workstation after an app
crash. (Microsoft made sure that this happened in Win9x, but Win2000
and WinXP seem to be stable enough to survive such crashes.)


Another option is to terminate the connections manually using the
Monitor or some other tool. It is possible to write an application
that connects to the database engine and removes all database
connections from a specific TCP/IP address. (Our own PSConfig utility
is an example of such a tool.) When an app fails abnormally, this tool
can be called top "clean up" the pending connections from "this"
workstation. This will free up resources and licenses on the server,
of course, and it eliminates the need to have to manually run the
Monitor utility to clean it up.

I hope this helps you to understand what is going on here...
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***


floyd99 (AT) gmail (DOT) com wrote:

Thankyou very much for the detailed explanation.
I had a feeling this was the sort of thing going on. In my belief, we
are experiencing connections active after the 2 hour watchdog timeout,
it's difficult to track though as we do have quite a few hundred users
that access this system, so knowing which ones are legitimately active
or not is tricky.

As an interim measure, we have been going to the Monitor and clearing
all connections say once a week after hours. This isn't really a long
term solution though.

One thing I was thinking of doing was setting a cron job to do a
"BSTOP" and "BSTART" on the server say nightly at midnight. On my
test box i found by doing this, it doesn't unload Pervasive completely,
but it does enough to disconnect all the sessions. After BSTART has
been run, users can connect again.

Do you think this is a wise thing to do in your opinion? I'm a network
systems admin and not a pervasive specialist so appreciate your input.

Thanks,
Dave

BSTOP/BSTART will certainly work. The module that does NOT get
unloaded is "BTRIEVE.NLM", but this is merely a stub for NetWare NLM's
accessing the NWMKDE.NLM module, which does all the work. This
solution is a bit "extreme" though.

If you just want to kill all users periodically, then our KillUser
utility (available at http://www.goldstarsoftware.com/download.asp)
might be quite helpful to you. This free utility can connect to a
remote server and kill off all users. It is a subset of the
full-featured PSConfig tool, and you CAN set it up to run with the
command scheduler in Windows.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***

Dave wrote:

thanks for that - i'll download and have a look.

just gave it a try but it didn't seem to work... i'm wondering about
the format of the username. With running on a netware server, i'd need
to provide the username as a fully qualified user ie

/U.admin.test /Pblah

will your KillAll utility accept that as a valid username?

Did you turn on the auto reconect on the client also?
It is off by default (same as the server setting) and if they aren't
both on it will handshake as not being on.

Leonard

On 18 Sep 2005 21:57:19 -0700, floyd99 (AT) gmail (DOT) com wrote:

yes I set the registry setting on the workstation

Dave wrote:

Should accept whatever you give it for server, owner, and password, up
to 63 bytes each.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - November, 2005 ***
*** Chicago: Pervasive DataExchange Class - November, 2005 ***