Hello all!

Sorry for any inconvenience, but since it's been a while I
rather repost some relevant parts of my old message first.:

On Tue, 29 Apr 2003 11:40:37 +0200, Christopher Altmann
<dtbv0s3n02 (AT) sneakemail (DOT) com> wrote:


I don't know if it's of importancet, but it's not plain
MS-terminal serverm, but Citrix-Nfuse instead.

I'm already in direct contact with R.Wickersham on this subject
(many thanks, Randy!), but since there have been new facts and
the issue has not been resolved yet, I'll try again here.
Furthermore, I'm trying to get as many opinions/ideas as possible.

Ok, so we are here now.
We tried the

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\LanmanServer\Parameters>]
"Autodisconnect"
parameter already without success.

We switched the database from the seperate db-server to the
terminal-server.

No success.

I read about the limitation of 2048 files in NT4-Terminal server,
but since this is Win200 it's 8192 files per session which should do.

What we found out meanwhile:

Imagine a 5 user setup, 3 users (User 1, 2 and 3)
are currently using the application (and are listed in
Pervasive-monitor).
If user 1 exits the application (successfully, no errors),
users 2 and 3 hang.
If their application window is minimized and in background,
they won't even notice what has happened just now.
Users 4 and 5 (they haven't been in the application yet) can enter
the application and work.
They also don't know of the fact user 2 and 3 hang.
So Pervasive is acting normally to the rest of the users.
Just user 2 and 3 are stuck.
If user 2 tries to maximize the application window
(for example: about 1 hour later), he realizes it's stuck.
His only way out is to kill his TS-session (via an admin login)
and start over.
Remember: User 3 is still stuck, but since he has not
yet tried to maximize the app, he just doesn't know.

So for me this looks like:

Pervasive is running fine until some "error" occurs and communication
between the DB-server and TS on the currently open
communication-channel
(socket?) is completely blocked. If a user starts over, there's no
problem, since a new connection-channel (socket?) is
established for the data-communication.
This runs fine, until another error occurs, and this new channel
is blocked also. Then the group of users currently using the same
connection-channel is blocked. Weird!
I am told by the client, moving the database to the
terminal-server didn't help.
So it seems to be PSQL-client related.
Again: We cannot forcibly reproduce this behaviour.
Everything runs fine for hours (connects,disconnects) up till
some point where this "error" happens (mostly in the evening,
when many users exit their apps).
Are there any known tools to prove my theory?
Any system-logging options, which could shed some more
light on this issue?
I read a lot on similar issues in this newsgroup, but could
not find any solution or success stories.
Since some users don't experience this behaviour,
I assume it's a conflict between PSQL/Magic and some very
common program running on the TS. (Fax-Solution/Antivirus Utilty/...)

Thanks for ANY info.
best regards
Chris

Hello Bartholomew!

Thank you for your input.
Find my answers below.

[...]
On Mon, 14 Jul 2003 23:09:45 +0200, "Bart³omiej Me³nicki"
<b.melnicki (AT) nova-trading (DOT) nospam.com> wrote:

[...]

Do you know how I can find that out?
We already copied the runtime to several different .exes for
testing purposes. The PID shown in pervasive monitor (=Task No)
is definitely different.

[...]

I'll turn Autoreconnect of. Further support is already initiated.


[...]

Client 2 hangs.
For example:
Client 2 is not currently using the app in foreground, because of some
office/mail work (also over terminal server session) to be done in
foreground.
About 4 hours later he decides to continue to work on the application
again. He is still stuck, although client 1 has probably reentered the
app 3 hours ago.
Since client 3 started AFTER client 1+2 hang, client 3 won't even
notice that 1+2 are stuck.


[...]

client 2 hangs.

[...]

No problem if accessing different databases,
even if it's the same .exe-file. Locks when accessing
the same db.
The application was running fine on their "normal" networks before.
The client then wanted to connect all branch offices via DSL
and Citrix-TS.



[...]

Yes, I'm afraid.
The same app based on MSSQL works like a charm.


[...]

Thanks anyway. I'm already at the point where I accept
"quit your job and start selling cars"-messages.
...But on the other hand, I'm not really that good at lying ;-)

Anyone knows of a tool dumping a list of currently running
processes into a .txt file every X-seconds?

Thanks + best regards
Chris

On Tue, 15 Jul 2003 07:19:30 +0200, Christopher Altmann
<noemaillookintoreplyto (AT) sneakemail (DOT) com> wrote:

[...]

Never mind, I'll try to figure out how to get pslist from
sysinternals looping.

Bye
Chris

On Wed, 16 Jul 2003 22:04:15 +0200, "Bart³omiej Me³nicki"
<b.melnicki (AT) nova-trading (DOT) nospam.com> wrote:

[...]

I already suggested this to the admins.
Since they are running a lot of other software
there, I'll have to wait for them to find out
if it will interfere with anything else.
I did a cross-check on all available terminal-servers with
PSQL-problems of any kind and listed all running processes.
I'm not in the office yet, but I'l list them here later.
Some things I remember:
- they're all running CITRX (not simple MS-TS)
- they're all running a couple of Compaq-Utilities
(monitoring and such) in background

Any known issues with them?


[...]

We already downgrade from SP4 to SP3 for that issue.
I also think this is client related.
Thank you for your ideas, I'm currently in waiting position,
since I'm not allowed to apply all the changes myself.
I'll be back ;-)

bye
Chris

On Sun, 20 Jul 2003 21:46:06 +0200, Christopher Altmann
<noemaillookintoreplyto (AT) sneakemail (DOT) com> wrote:

[...]

Ok, so here's the list:

process what for
-------- ------------
beremote BACKUP EXEC
cdmsvc CITRIX
cpqnimgt Compaq NIC Agents Service
CpqRcmc Compaq Remote Monitor Service
cpqwmgmt Compaq Web Agent
cpushld Powerfuse
cqmghost Compaq Insight Host Agents
cqmgserv Compaq Server Agent
cqmgstor Compaq Storage Agents
CTFMON Language Bar
ctxxmlss Citrix Nfuse
encsvc ...yet to find out
facsys Fax-Software
guardian ...yet to find out
ImaSrv Citrix
mfcom Metaframe
pwrmenu Powerfuse
rdpclip Terminal Services clipboard facility
res Powerfuse
scardsvr Smart Card Control Manager
SMSS Windows NT Session Manager
snmp SNMP Agent Service
SpntSvc Trend Antivirus
surveyor Surveyor (Compaq Computer Corp.)
sysdown Compaq System Shutdown Service
vcagent ...yet to find out
wfshell Citrix WinFrame
WinMgmt Windows Management Service


Any known issues with one of these?
Thanks

Chris

We had a very similar problem with our application and Win2000 TS.



Do you run the Magic application along a mapped drive in a TS session to
another server?



If so we found that the first user who logs into a Win2K TS session and
loads the application creates the file control block. If other users
logged in and opened the same application, they used the same file
control block. If however the user who logged in first logs out all of
the other users would hang. There was also an exception on the screen
stating C0000006. But once the criteria was know it was very easy.



There is an article on the MS KB stating that it was a know error and
that it would not be fixed until Win 2003 server (which it has been).
There soultion was to either use a SUBST command and move the database
locally if the mapped drive letter was hard coded or use a local set of
program files.



For our application a local set of EXE and DLL files solved the error.



It may be nothing but it's worth trying.



Regards,



Dave


--
Posted via http://dbforums.com