Hi All -- hope someone can help...
Fresh CognosBI 8.3 install on WinSvr2003SP2 / MSSQLSvr2005SP3 backend.
* one note: Content Store is a restore of an 8.2 production DB.
When starting Cognos - all appears to start well enough and stays running, but I get the following error...
19. 20:10:33, 'com.cognos.p2plb.clerver.TestMsgSourceGUIDHandler', 'pogo', 'Failure'.
DPR-DPR-1035 Dispatcher detected an error.
20. 20:10:33, '', 'Request', 'Failure'.
====================
..\Program Files\cognos\c8\logs\pogo_2009-02-19.log - 2/19/2009 8:09 PM
====================
2009-02-19 20:10:33.946 ERROR [nos.p2plb.clerver.TestMsgSourceGUIDHandler] Thread-22: Received request from dispatcher: "116782B9-B5FA-4E67-BF2D-402899290A86". I cannot resolve that dispatcher's GUID. This likely means we are running against different content stores, and I am registered in both. There is likely on old/incorrect registration for me in the other content store. Will reply with a fault.
====================
In Cognos Config -- Content Store and Dispatcher params are configured correctly and test fine.
I looked all over Cognos KB and found nothing -- even google comes back with a blank stare. Any ideas?
Thanks!
Steve. . ..
Try deleting the dispatcher from the Administration portion of Cognos Connection. Then, readd
(not sure if this will do it, but it would be what I would try)
ahh! Thanks SC! I'll give it a try!
Steve
No joy...
In Cognos Connection / Admin / Config... unregistered dispatcher - then reentered params in Cognos Configuration, saved, tested and restarted...
Startup detail...
=============================
19. 10:36:19, 'com.cognos.p2plb.clerver.TestMsgSourceGUIDHandler', 'pogo', 'Failure'.
DPR-DPR-1035 Dispatcher detected an error.
20. 10:36:20, '', 'Request', 'Failure'.
============================
Same error in pogo...log.
Steve
Export full public folders with all options enabled. (maybe not run history, to dump some old slack)
Create new sql content store.
Import the earlier made export.
Done.
Hi dutch... Just gave that a try, but the error's still there -- a brand-shiny-new content store....
Thanks for the suggestion tho...
Steve
The startup gui gives lesser info then the full cogserver.log entry.
Can you lookup all info from the startup time error, and paste it here?
This was a clean server install (never had Cognos products on it)? Almost sounds like a key is floating around in the registry or a link in the configuration directory.
If it wasn't a clean server, then I'd say try:
Remove the dispatcher again
Stop services
Rename cogstartup.xml to a saved name
Erase the crypto key directories
(If adventurous and brave, troll through the registry to see if keys are there - do this at your own risk, though)
Open cog config and reenter parameters
Reboot for good measure
If it was a fresh server, did the deployment import specify dispatchers? (can't remember) If so, don't restore those on import
dutch... the last time the cogserver.log was written to was back on 2/13, no additional entries since -- and nothing good, just...
=======================
10.1.1.101:9300 3756 2009-02-13 16:21:33.428 -5 main LOGSV 643 1 Audit Upgrade Schema jdbc:JSQLConnect://<
DBservername>:1433/u83Cognos Success <parameters><item name="OLD_VERSION"><![CDATA[0.014]]></item><item name="NEW_VERSION"><![CDATA[0.016]]></item></parameters>
10.1.1.101:9300 3756 2009-02-13 16:21:33.881 -5 main LOGSV 643 1 Audit Upgrade Schema jdbc:JSQLConnect://<
DBServername>:1433/u83Audit Success <parameters><item name="OLD_VERSION"><![CDATA[0.014]]></item><item name="NEW_VERSION"><![CDATA[0.016]]></item></parameters>
=========================
SC... You may be on to some'tn... This machine was running a stand-alone CMS, supporting our 8.2 production environment. We did an uninstall prior to putting 8.3 on box. May be worth a try -- I've got a strong stomach ;)
Thanks to you both!
Steve
Still no joy...
- Remove the dispatcher again - done
- Stop services - done
- Rename cogstartup.xml to a saved name - done
- Erase the crypto key directories - done
- (If adventurous and brave, troll through the registry to see if keys are there - do this at your own risk, though) - bunch of entries, but nothing to wipe
- Open cog config and reenter parameters - done
- Reboot for good measure - done
Last line of Start Detail...
-------------------------------
19. 12:28:37, 'com.cognos.p2plb.clerver.TestMsgSourceGUIDHandler', 'pogo', 'Failure'. DPR-DPR-1035 Dispatcher detected an error.
20. 12:28:37, '', 'Request', 'Failure'.
====================
..\Program Files\cognos\c8\logs\pogo_2009-02-24.log - 2/24/2009 12:28 AM
====================
...
2009-02-24 12:28:19.900 INFO [ogo.contentmanager.coordinator.CMBootstrap] BootstrapConfigurePublish-thread: Dispatcher object http://<
serverURI>:9300/p2pd is already registered at /configuration/dispatcher[@name='http://<
serverURI>:9300/p2pd'] and will be updated with new runningState=running
...
2009-02-24 12:28:37.899 ERROR [nos.p2plb.clerver.TestMsgSourceGUIDHandler] Thread-19: Received request from dispatcher: "116782B9-B5FA-4E67-BF2D-402899290A86". I cannot resolve that dispatcher's GUID. This likely means we are running against different content stores, and I am registered in both. There is likely on old/incorrect registration for me in the other content store. Will reply with a fault.
====================
The server is an ESX VM -- I'm thinking about just blowing it away and starting clean - from machine, on out. Thoughts?
btw - the install is from Deltek distributed media. Impact?
Steve
Deltek media: should not be an issue - you may have to download the service packs but otherwise their disks are good
Wiping out box: I would agree that this is probably the way to go -- there's something lingering somewhere that makes the dispatcher think it's pointing to the old server.
Prior to wiping the box, I'd take a deployment export (if possible). Reason for deployment would be in case the content store db itself has the dispatcher hook (in which case a fresh image won't solve that). I would try the fresh machine with existing db first (if you have the time) but if that doesn't work, then a new content store db with an import.
Found It!!!! Unbelievable!
In our 8.2 Dev environment, found an old record for the 8.3 server in its CMCAPACITY tbl (in a content store not even connected to the 8.3 instance)- even though it's been unregistered from the dev server's cog connection and removed from cog configuration several months ago. -- go figure...
I removed the record and restarted Cognos 8.3 -- No Errors!!! I'm not sure that I yet understand the connection, but the result is perfect!
SC & dutch.., thank you both very much for your help!
b/r
Steve