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.
10-30-2009 06:39 PM
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.
11-01-2009 10:09 AM
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.
11-01-2009 10:50 AM
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.
11-01-2009 10:52 AM
Yes. I've tried using both Firefox and IE from remote servers. I rarely ever use the LMS server itself as a client.
11-01-2009 11:58 AM
When you configured SSO on the remote servers did you use the FQDN or the shortname?
I have the shortname of the DCR master.
11-01-2009 12:07 PM
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...
11-01-2009 12:10 PM
11-01-2009 12:18 PM
11-01-2009 12:26 PM
11-01-2009 03:00 PM
I was more interested in seeing a screenshot of the services control panel showing all running services.
11-02-2009 06:15 AM
11-02-2009 09:22 AM
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).
11-02-2009 10:01 AM
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.
11-02-2009 10:04 AM
Yes, this is fine. log4j errors are typically harmless.
11-02-2009 10:13 AM
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?
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: