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.
Solved! Go to Solution.
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.
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. :)
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.
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.
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.
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.