10-12-2009 12:26 PM
I have reported this error before...and have a TAC case open for it...but have found a workaround that I wanted to share that might shed some light on the issue.
The URL of Common Services > Device Management when I get the error contains the FQDN.
If I modify this URL by removing the domain suffix and attempt the same change in the DCR the change is successful.
Any ideas?
Solved! Go to Solution.
11-02-2009 10:27 AM
As I said before, there is no way this is client-related. All of this happens on the backend. The way it works is that you submit an HTTP request saying you want something to happen. A servlet (like a CGI) takes this request, and calls a remote method via our proprietary CSTM RPC system. CSTM then tries to resolve the desired request using the given Java class and method names. THIS is failing from time to time. Why that failure occurs is not clear. For some reason, the DCR JVM running the CSTM client code is unable to resolve the method name from the given class.
11-03-2009 02:08 PM
I just sent the patched DCR.log to my engineer.
Looking forward to your diagnosis. :)
11-03-2009 03:21 PM
I was able to capture the logs for both an unsuccessful credential mod and a successful one.
The logs for each were sent to my engineer at seperate times. Be sure you get both as needed. :)
11-04-2009 09:48 AM
I found the problem. As I predicted, it has nothing to do with browser, FQDN, or anything. It is a transient issue that only affects Windows SMP systems. It tends to occur mostly on faster machines. A patch is on its way.
11-04-2009 02:14 PM
Is it probable that this issue was prevalent in LMS 2.6 and 3.1?
I am certain we experienced the "internal error in communication channel" error with all of our previous versions (2.6 and 3.1).
We just kept upgrading hoping it was resolved in the new releases.
11-04-2009 02:21 PM
Yes, it is present in all versions of LMS 2.5 and higher.
11-07-2009 05:37 PM
11-07-2009 05:44 PM
WARNING: Certificate HostName [FQDN] and the URL Host Name [shortname] do not match
Where does it get this "URL hostname?"
11-07-2009 05:49 PM
Figured it out.
If I am going to have certs with FQDN, I MUST use the FQDN when I configure the DCR master hostname.
11-07-2009 10:10 PM
All messages starting with "XXX" are my debugging messages, and are nothing to worry about. I sent your engineer a new patch which removes all debugging.
11-07-2009 10:13 PM
The URL hostname is the hostname used when making the HTTP request (i.e. he value of the Host: header). This is typically the URL entered in the client browser, but for IPC calls, it can be the hostname as configured in PX_HOST or in regdaemon.xml.
11-07-2009 10:14 PM
Yes, same for SSO.
11-16-2009 01:36 AM
Is there a bug ID for the issue?
Thanks!
11-16-2009 05:30 AM
CSCtd07131
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide