10-02-2009, 09:17 AM
That's new to me. No one ever said anything so I've had no reason to look into it. Are you taking about the regular IV here?
Dean Roddey
Explorans limites defectum
Explorans limites defectum
Official RIVA thread
|
10-02-2009, 09:17 AM
That's new to me. No one ever said anything so I've had no reason to look into it. Are you taking about the regular IV here?
Dean Roddey
Explorans limites defectum
10-02-2009, 09:24 AM
Dean Roddey Wrote:That's new to me. No one ever said anything so I've had no reason to look into it. Are you taking about the regular IV here? Yes, just a regular IV. I haven't mentioned it before since it has been sort of random, I couldn't pinpoint anything that might have led to the problem, and I couldn't rule out something in my environment that might be sick. But hearing another mention of the data server possibly having problems made me think that it could be related.
10-02-2009, 11:04 AM
I have also been able to get the RIVA client you developed Dean to eventually chokes and not be able to log on. It takes a couple of tries and eventually, it won't log on. CQC server reboot is the only solution. I'll check into it some more the next time it happens with what you suggested.
It's funny but I haven't had any issues with it today so haven't been able to look into it more deeply.
10-02-2009, 11:54 AM
It happens repeatably for me. Is this CQCNetTest thing something I can run? Would it help you to check if something's wrong? How do I do it?
10-02-2009, 12:04 PM
Open a CQC Command prompt (it is a shortcut created when you installed CQC). At the command prompt type "CQCNetTest >z.tmp" (leave off the quotes). Post the content of z.tmp here.
[Edit] Do this when you are in 'broken' state
Mark Stega
10-02-2009, 06:06 PM
I got into the broken state:
![]() but I don't see anything obviously wrong in my net test: CQC Network Info Test Copyright © Charmed Quark Systems System Information -------------------------------- OS Version: 5.2.2, Build: 3790 Node Name: odin TCP Version: 2.2 Network Adaptor Information -------------------------------- {ACE2EEF0-252A-4BB9-92FE-DA98AA97A97F} Generic Marvell Yukon 88E8056 based Ethernet Controller DHCP Enabled: True Gateway/Mask: 192.168.0.1/0.0.0.0 Hardware Addr: Address/Mask #0: 192.168.0.186/255.255.255.0 Environment Information -------------------------------- CID_NSADDR: odin CQC_DATADIR: C:\Program Files\CQC\CQCData Name Resolution -------------------------------- Trying to resolve name: odin... Resolved to: 192.168.0.186 Resolving back the other way... Host Name: odin CQC Connection Tests -------------------------------- Trying to connect to CQC name server... Connected to name server successfully Trying to connect to log server... Connected to log server successfully Trying to connect to Master Cfg Server... Connected to Master Cfg Server successfully Trying to connect to local Cfg Server... Connected to local Cfg Server successfully Trying to connect to installation server... Connected installation interface successfully Trying to connect to security server... Connected security interface successfully Trying to connect to macro server... Connected macro interface successfully Trying to connect to CQCServer on host odin Connected CQCServer successfully Server Statistics -------------------------------- Stats For Process: Name Server ---------------------------- Object Id: odin.13502 Running On: odin Up Since: Tue, Sep 29 18:33:12 2009 -0400 Client HWM: 16 Dropped Packets: 0 Cur Clients: 11 Max Clients: 92 Active Cmds: 1 Queued Cmds: 0 Registered Objs: 2 Worker Threads: 4 Targets: 0 Cmd Cache Sz: 0 Srv Cache Sz: 0 Wait List: 0 Stats For Process: Log Server ---------------------------- Object Id: odin.13503 Running On: odin Up Since: Tue, Sep 29 18:33:12 2009 -0400 Client HWM: 13 Dropped Packets: 0 Cur Clients: 12 Max Clients: 92 Active Cmds: 1 Queued Cmds: 0 Registered Objs: 2 Worker Threads: 4 Targets: 0 Cmd Cache Sz: 1 Srv Cache Sz: 1 Wait List: 0 Stats For Process: Master Cfg Server ---------------------------- Object Id: odin.13504 Running On: odin Up Since: Tue, Sep 29 18:33:12 2009 -0400 Client HWM: 3 Dropped Packets: 0 Cur Clients: 1 Max Clients: 92 Active Cmds: 1 Queued Cmds: 0 Registered Objs: 2 Worker Threads: 4 Targets: 1 Cmd Cache Sz: 2 Srv Cache Sz: 1 Wait List: 0 Stats For Process: Data Server ---------------------------- Object Id: odin.13505 Running On: odin Up Since: Tue, Sep 29 18:33:16 2009 -0400 Client HWM: 4 Dropped Packets: 0 Cur Clients: 1 Max Clients: 92 Active Cmds: 1 Queued Cmds: 0 Registered Objs: 6 Worker Threads: 4 Targets: 1 Cmd Cache Sz: 2 Srv Cache Sz: 1 Wait List: 0 Stats For Process: CQCServer on odin ---------------------------- Object Id: odin.13507 Running On: odin Up Since: Tue, Sep 29 18:33:19 2009 -0400 Client HWM: 7 Dropped Packets: 0 Cur Clients: 6 Max Clients: 92 Active Cmds: 1 Queued Cmds: 0 Registered Objs: 2 Worker Threads: 4 Targets: 1 Cmd Cache Sz: 2 Srv Cache Sz: 1 Wait List: 0
10-02-2009, 06:10 PM
Dean Roddey Wrote:Instead of restarting teh service, kill the CQCRemVSrv program. It'll be restarted automatically. If it comes back up, then it's clearly something specific to that remote viewer server. This worked for me - after I got in the broken state (see above) I killed the CQCRemVSrv.exe process. It restarted automatically and I could connect again. No reboot/service restart required. Now all we have to do is figure out why it happens in the first place!
10-02-2009, 08:17 PM
OK, that makes more sense. It's the RIVA server getting wierd, not the system in general. I'll take a look at that after get the next drop out in a couple days. And this happens when you just kill the connection, right?
Dean Roddey
Explorans limites defectum
10-03-2009, 08:11 AM
Yes. I don't yet know whether it will happen when I send a LogOff, because I haven't gotten that part of my application done yet.
10-03-2009, 04:47 PM
Hmmm. I figured that my LogOff message was not getting through, because I was seeing the CQC log message indicating that my client dropped the connection, and the RIVA documentation talked about the LogOff being a way to avoid log warnings about communication failures. But I modified my program to wait explicitly after sending the LogOff, to make sure that it got sent before the socket was closed. And still I see the dropped connection message. Should I expect the log to look different, or is that message always logged regardless of whether LogOff is received before the connection is closed?
|
« Next Oldest | Next Newest »
|
Possibly Related Threads… | |||||
Thread | Author | Replies | Views | Last Post | |
Html 5 Riva | potts.mike | 9 | 14,834 |
09-15-2013, 04:22 AM Last Post: bjkiller |
|
Thinking about the next step in RIVA | Dean Roddey | 6 | 11,820 |
01-22-2013, 06:15 AM Last Post: brianmount |
|
.Net RIVA Client | Dean Roddey | 146 | 127,819 |
02-06-2012, 06:53 PM Last Post: Dean Roddey |
|
Transparent images in RIVA? | SamVimes2 | 36 | 51,603 |
02-05-2011, 04:34 PM Last Post: Dean Roddey |
|
riva | burkepaol4 | 1 | 8,671 |
12-17-2010, 11:39 AM Last Post: Dean Roddey |
|
Riva screen blanker on CF.NET | froop | 3 | 8,584 |
08-06-2010, 10:34 PM Last Post: froop |
|
RIVA Connection | batwater | 6 | 9,329 |
07-16-2010, 04:46 PM Last Post: batwater |
|
Java based RIVA Client? | batwater | 10 | 13,807 |
04-03-2010, 05:35 AM Last Post: wuench |
|
RIVA Client for Linux | bryanb | 22 | 21,759 |
07-16-2009, 09:11 PM Last Post: bjkiller |