Re: Btrieve Error 3103

My first suggestion is to patch to Service Pack 3, of PSQLV8.7. This
may go a long way towards solving the problem.

We've seen "random" 3103's before caused by DNS and WINS problems on
networks. You may wish to make sure that when the problem occurs, you
can still PING the server by name, and you still get good name
resolution from both DNS and WINS.

As for your questions on comm threads:
1) Running out of threads will not "kill" the server. The thread count
indicates the number of simultaneous requests that can run. Any
requests beyond this number simply queue up and are handled when the
threads are free. In fact, it is possible to run on only 1 thread if
you wanted to (though it wouldn't be quite as efficient).
2) It depends on how many concurrent requests you have. If you are
seeing it reach the peak during normal operations, you may be able to
gain a bit in performance by increasing the thread count. This will
also increase the mewmory usage, so be careful there.
3) This can be caused by bad queries -- patching the engine is usually
the first step to troubleshooting it.
4) Not really. The best way to find it is with a network trace of all
traffic to and from the server, but this generates a LOT of data to
review, and it is not always straightforward where the problem lies.
If both services died simultaneously, then you might have something,
but with one shutting down first, this will be a tough one.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@xxxxxxxxxxxxxxxxxxxx
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - 03/2007 ***

Rob Michelis wrote:

Hello,

I have a pervasive 8.5 implementation that is throwing btrieve 3103
errors intermittently. It is running on a windows box and has a user
base of about 300 users. The database was originally a btrieve 6.0
that has been upgraded through the years.

When the clients start throwing the 3103 errors, you can't log into
the monitor on the server to see what is going on. I checked the
server logs and there are no error messages logged.

One thing that I have noticed is that the relational service seems to
stop responding first. Then the transactional service will
eventually stop and we have to restart the box.

I checked out the communication settings and the communication
threads are set to 32 and have maxed out since the last reboot. I
read in some of the other posts that the communication threads
locking up may cause the services to stop responding.

My questions:

1.) Has anyone had the experience where running out of communication
threads killed your server?
2.) For a user base of approximately 300, is 32 enough or too many?
3.) Anyone else experience issues where the relational service will
stop responding for no apparent reason?
4.) Since nothing is being written to the logs, is there a setting
or task that I can implement to possibly catch the issue?

Thanks in advance,
Rob

.