DPR-DPR-1035 Dispatcher Error

[Steve@GP]

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. . ..

[SomeClown]

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)

[Steve@GP]

ahh! Thanks SC!  I'll give it a try!

Steve

[Steve@GP]

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

[ducthcogtechie]

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.

[Steve@GP]

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

[ducthcogtechie]

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?

[SomeClown]

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

[Steve@GP]

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

[Steve@GP]

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

[SomeClown]

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.

[Steve@GP]

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