Conflicting Thin Clients

[Rich Cassell]

Hi all,

One of our larger customers is having a problem with 2 of their users. The customer has 7 thin clients in all which have been users for many years now without issue, however, they have recently replaced their machines and now 2 of them are conflicting. The problem only concerns the same 2 users and essentially what happens is when one logs on they can use the system until the second connects at which point the first one gets kicked off.

The error in the Jommsg.log shows:

Code: Select all

2012/05/02 13:32:10.002 092e0-983c JadApp: Thin Client connected and signed on: AG20051812 (192.39.3.7) schema=AGSLPAYSchema app=LPAY_MainForm tcp threadId=a138 2012/05/02 13:32:18.784 01618-1658 Jom: System::forceOffUser: request to force Process [187.452] off Node [186.9] 2012/05/02 13:32:18.815 092e0-9efc JadApp: Thin Client forced off by monitor request: BEL000325 (192.39.3.7) schema=AGSLPAYSchema app=LPAY_MainForm

This type of error is usually associated with a user force off request from the Jade Monitor, but it appears to be triggered by the new user signing on.

The User PC's have different names, the IP addresses of the individual machines also differ (192.39.3.7 in the log is their server), and they use independent bin folders. We are running Jade 6.2.

If anybody has seen this error previously and have any suggestions then it'd be very helpful. We're currently looking at a simple reinstall for one of the users but we can't see why this would make any difference...

Cheers,

Rich

[Rich Cassell]

Hey,

Replacing the bin folder on the client machine has solved this problem. I've noticed that versioninfo.txt contains a section called "System Information" which i assume is created upon first run of a thin client. It turns out our customer had copied the bin directory from another machine and therefore carried this file across with it.

Either way, the problem has gone now.

Cheers,

Rich

[torrie]

versioninfo.txt is normally created by the utility jverinfo.exe. This tool can be run to list the version of all the binary and system files in the bin directory. It also looks for the ..\system path and lists the version of the user dat files. We often use this to check dll version (including 3rd party DLL's)

I assume that this file would have been copied into the thin client bin directory from a Jade server (of fat client) bin directory.

[Rich Cassell]

Hi Torrie,

Thanks for your reply. As you predicted, we do copy the Jade Server bin directory for our Thin Client bin directories. Am i right in thinking that the correct thing to do in this case is to run jverinfo.exe at the thin client side to ensure that it refers to the correct system details? Or is there a better way of avoiding the conflict problem?

Cheers,

Rich

[BeeJay]

Rich,

The versioninfo.txt file is not utilised by the presentation client at runtime. It is purely an informational file created by running the jverinfo.exe. The most common usage of the jverinfo.exe is when reporting a fault to Jade Support so that they can more easily see what versions of dlls etc you are running. The presence of a different/old/etc versioninfo.txt file has no bearing on the issue you were encountering.

You'll also see the jommsg.log entries you mentioned if user app logic utilises the System::forceOffUser method, as per the following jommsg.log snippet:

Code: Select all

2012/05/14 22:49:08.104 01efc-2390 Jom: System::forceOffUser: request to force Process [187.3] off Node [186.1] 2012/05/14 22:49:08.105 01efc-1818 JadeExe: Client forced off by monitor request: schema=BeeJayPlay app=BeeJayPlay 2012/05/14 22:49:09.115 01efc-1ea8 Jom: Local process delete: oid=[187.3], process=0x00000000298FC210, no=3, id=6168, db=2, type=2 (non-prodn), scm=BeeJayPlay, app=BeeJayPlay, start time=22:49:01.623, elapsed time=00:00:07.491

Is there any logic in your application that could be calling this method?

Cheers,
BeeJay.

[Rich Cassell]

Hi Beejay,

Thanks for your reply.

I'm confident that our system isn't using that method. The system is used extensively by various users and we've only ever had this problem on this one occasion, so i'd usually expect that to be down to the setup rather than the code, but from what you're saying it does make sense that it can only happen if that method is called... . Since we re-created the bin folder on the client system the problem has not reoccured...

Thanks for all the help in this...

Rich