cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4610
Views
53
Helpful
58
Replies

DCR internal error in communication channel

helexis
Level 1
Level 1

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?

58 Replies 58

Ok.

But I have an idea...

This error may only be occuring from a remote PC that initially logs into SSO with the FQDN without having been prompted for SSO relogin at the URLs that are generated with the short hostname.

This is why it is so flaky and hard to pin down. It is also why it seems to not occur with Firefox, while indeed it does.

Maybe you can reproduce it with this info.

All certs are shortname, but we access the site with the FQDN. (clear all browser cache) Go straight to the DCR and try to modify. Internal Error !!

Modify the URL to just the shortname it will prompt for SSO again, but you can modify the DCR (cause you are already authenticated)!!

yay...I can reproduce consistently.

No, I can't reproduce. I've done everything exactly how you said. Server certs are short hostname, SSO master/slave, DCR master/slave, HTTPS mode enabled, cleared browser cache, restarted browser, connected to master using FQDN, went to DCR, modified credentials, added a new credential set, modified identity, added a new device. Everything works without error.

Just in case your error has changed, post the new dcr.log after reproducing this problem.

Are you accessing the server web site from a computer other than the DCR master to edit the credentials?

I cannot reproduce the error at all while on the DCR master.

Yes. I've tried using both Firefox and IE from remote servers. I rarely ever use the LMS server itself as a client.

When you configured SSO on the remote servers did you use the FQDN or the shortname?

I have the shortname of the DCR master.

Recreated internal error in communication channel from remote PC.

Problem happened while accessing the server using the shortname only. No FQDN involved ever today. So my above theory was invalidated. :(

But here is the dcr.log with "ERR_IN_INVOCATION,BEFORE_INVOCATION, java.lang.NoSuchMethodException" in it...

prepended dcr.log

This range went back a little further just in case...

internal error happened when attempting to edit Credentials locally (on the dcr master itself).

dcr.log from that time period

pdshow attached also

current services running on master

netstat

I was more interested in seeing a screenshot of the services control panel showing all running services.

screen shots

Did you see anything of interest in the logs when the error was generated?

This looks fine. The only major difference is that you have the SNMP service installed where as my servers do not.

The logs are as useless as before. The methods that fail are different, and there doesn't appear to be any real pattern. I will need to provide you some debugging patches through your service request. Have your engineer contact me, and I will send the patches. They should tell us definitively why this is failing (though maybe not the true root cause).

My engineer is out of the office still.

Is this normal?

---------- stdout.log ---------------------

[Sun Nov 01 01:29:30 CST 2009] CCN::initializeSSO Connecting to https://CISCOWORKS:443/CSCOnm/servlet/com.cisco.nm.cmf.servlet.ProcessSSOServlet

[Sun Nov 01 01:29:30 CST 2009] CCN - SSO mode = 1

[Sun Nov 01 01:29:30 CST 2009] CoreContextNexus ValidateConnection:true

[Sun Nov 01 01:29:30 CST 2009] Invoke doLicenseCheck!

[Sun Nov 01 01:29:30 CST 2009] DoLicenseCheck Returned:true

Local Server URL :https://ciscoworks.net.okstate.edu:443

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

log4j:ERROR Attempted to append to closed appender named [A-client1].

log4j:WARN Not allowed to write to a closed appender.

Yes, this is fine. log4j errors are typically harmless.

Is it possible that this is all due to a TCP session timing out?

How does the DCR allow changes to occur? Lets say I log in and make a change to the device credentials...I have thus done so via a particular TCP port on the server. Is there a specific thread involved as well? Is my TCP port specific to my username or client IP or anything?

If I login via the FQDN vs. the short hostname am I offered another thread or TCP port or user session that might eliminate the effect of the TCP timeout via the alternate login?

Just brainstorming...lol...did all that come out in a sensible fashion?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: