LMS 2.6 Compliance Check 500 Internal server error

Unanswered Question
Feb 19th, 2007

If i create a baseline template using the "Cisco 3800 Series Integrated Services Router" as the device group (the content of the template can be anything, but the same behaviour is apparent), and attempt to run a compliance check, it gives me the following error:

HTTP Status 500 - Internal Server Error

java.lang.NullPointerException

And a load of java errors.

This only happens when i create a baseline template for the 3800 series router. It doesnt matter whats in the template, it was some QOS policy but ive also tried just hostname. It still errors out.

Is this a known bug? I see it used to be but was fixed in LMS 2.6 apparently which im running.

Any ideas?

Nick

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joe Clarke Mon, 02/19/2007 - 09:18

Without the rest of the Java stack trace, it is impossible to know what the real cause of this problem is.

nickmaiolo Mon, 02/19/2007 - 09:21

Ill get the rest of the error tomorrow when im back at work.

Nick

nickmaiolo Tue, 02/20/2007 - 01:27

Error as promised:

HTTP Status 500 - Internal Server Error

type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) that prevented it from fulfilling this request.

exception

java.lang.NullPointerException

at com.cisco.nm.rmeng.dcma.ui.helper.DcmaMDFClient.getApplicableMDfs(DcmaMDFClient.java:99)

at com.cisco.nm.rmeng.dcma.ui.action.DCMABaseLineConfigAction.perform(DCMABaseLineConfigAction.java:1005)

at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1786)

at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1585)

at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)

at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)

at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)

at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)

at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)

at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)

at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:457)

at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:576)

at java.lang.Thread.run(Thread.java:534)

Apache Tomcat/4.1.29

Typically when I see this issue its not a server problem, but rather the client JVM's memory allocation and scavenging blowing up. Using multiple applications that employ client side java (such as concord or netscout) along with Ciscoworks requires a bit of behavior modification...as in you need to shut down all IE windows, open IE back up and then access Ciscoworks with a clean JVM slate.

nickmaiolo Thu, 02/22/2007 - 01:47

I hadnt installed the patch unless its part of the LMS 2.6 upgrade bundle. I will download and apply the patch to see if it resolves this issue.

Thanks

Nick

Joe Clarke Thu, 02/22/2007 - 10:27

If you haven't applied the patch yet, then you have no chance of having the bad version. Is this server integrated with ACS?

nickmaiolo Thu, 02/22/2007 - 15:54

Yes, its integrated with ACS 3.3(3) iirc. We have 2 LMS 2.6 installs and it happens on both of them. Ive also tested it on 2 LMS 2.5.1 installs and it works fine on these.

Joe Clarke Thu, 02/22/2007 - 21:55

Okay, ACS integration could be the other cause of this exception. This could be indicative of a bad ACS integration setup. You should verify that your current user as well as your system identity user have all the required access to all of these devices. You should also verify that these devices do not show up in the Common Services > Device and Credentials > Reports > Devices not in ACS report.

Finally, you should enable Archive Management Service debugging under RME > Admin > System Preferences > Loglevel Settings, reproduce the error, then check the dcmaservice.log for additional information.

Troubleshooting this may prove rather complex since ACS integration can require looking at many logs and sniffer traces. If the problem isn't immediately obvious, you should consider opening a TAC service request.

Actions

This Discussion