VMware Solutions Discussions
VMware Solutions Discussions
Hi,
I updated our vsc installation from 6.2P1 to 6.2.1.
Since the upgrade I have the following error when trying to use the logviewer:
HTTP ERROR 500
Problem accessing /smvi/logViewer. Reason:
Unable to compile class for JSP: An error occurred at line: 1 in the generated java file The type java.io.ObjectInputStream cannot be resolved. It is indirectly referenced from required .class files Stacktrace:
Caused by:
org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: 1 in the generated java file The type java.io.ObjectInputStream cannot be resolved. It is indirectly referenced from required .class files Stacktrace: at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330) at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:423) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:317) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:295) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:282) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:586) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:542) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271) at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98) at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:238) at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:264) at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1201) at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:986) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:933) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:851) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:844) at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:350) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:665) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) at java.lang.Thread.run(Thread.java:745)
Thank you for any help.
Solved! See The Solution
I was able to apply "D2" and can happily report that this resolves the Log Viewer issue... looks like a good fix.
...and I'm nototrious for stepping on every rake in the yard when it comes to this kind of thing!
https://mysupport.netapp.com/NOW/download/software/vsc_win/6.2.1P1D2/download.cgi
There is already a bug logged and VSC engineering support is currently looking into it. I will share further updates on this post as available.
ok.
Thank you.
Best regards,
I just encountered this same issue after upgrading to 6.2.1. I tried performing the backup manually from the vsphere client, and it said it couldn't rename the "_recent" snapshot, which led me to this KB article:
Short story is I had to delete my snapshot ending with "_recent", then I re-ran the job and it completed successfully.
Hi Guys, any news regarding this issue?
hi guys, is there an update available?
anyone have bug ID number?
Bug #1050057
no public details available right now...
This is affecting several systems and we have just opened a case on it. Does anyone have any further info?
Thanks..
ps. I will update this as we'll push for escalation.
Waiting for answers ...
To fix this issue I downgraded the java that’s imbedded directly in VSC folder located here: “C:\Program Files\NetApp\Virtual Storage Console\jre”
In order to do this I moved the original files to a folder named “original” that I created in the same directory, I had to stop all the Netapp and VMware services to allow the move, then I took all the files from an install of version 8 update 66 of java on the same machine from C:\Program Files\Java\jre1.8.0_66 and put them in the VSC folder “C:\Program Files\NetApp\Virtual Storage Console\jre” where the files were located that I moved (the file names were an exact match)..
I restarted the machine, did a backup and checked the logging link and all worked. I then backed up and restored another vm and it worked fine as well..
Everything I checked worked fine but proceed at your own risk knowing this is an older version of JAVA..
I uploaded logs VSC logs to the case and asked that they be reviewed by an engineer to make sure there are no issues with this fix. I'll reply when I know more...
Scott
Everything seems to be OK from our in-house testing.. Below is from Netapp Support:
"I haven’t noticed anything that warrants additional investigation at this time. I did follow up with another resource about this particular fix, and he’s said it has worked successfully for another case before yours. Because the pool of clients who’ve opted for this fix is small, it’s a bit difficult for us to guarantee that it won’t result in another issue down the line. What we have seen is successful so far, however, and in your most recent logs, I don’t see an issue. As long as you’re comfortable understanding that you’re trying something a bit newer and less tested, then I don’t see any issue with the fix you implemented."
Please let me know if this fix has helped anyone and if there are any issues:
Scott
I can confirm that everything is working with the change out of java as listed above. We've had no issues.
can confirm the workaround is working very well! Thank you very much!
Important is the Java Version. Tried it with 8.51, which was already offline available, and it didn't work. After going to 8.66 everything worked instantly, not even running a new backupjob was necessary. Just picked an older link from an email and tried it.
I am having this error as well. Couldn't find a link to the bug number referenced above, does anyone have a link?
Bug #1050057
There is a new version 6.2.1P1 posted 23/2/2017, anyone have already check it ?
Hi lorpeink,
I have this problem with 6.2.1P1 too.
We installed this latest version yesterday. Preliminary results are that VSC vSphere functionality is restored. However did encounter a logviewer http error 500 and performed this workaround to the error: https://community.netapp.com/t5/VMware-Solutions-Discussions/VSC-6-2-1-logviewer-http-error-500/td-p/125540/highlight/false/page/2
Now we are retesting VSC functionality.
Hi,
VSC engineering has planned to take care of this bug#1050057 in future release.
We will share more updates on this as available.
Thanks!
Sugandha
Spoke to NetApp Support today... expected fix is in v6.2.2 - no release ETA for 6.2.2 since "6.2.1P1 just came out last week"
Don't shoot the messenger....
They had told us that the .P release would provide resolution.
This is a very simple code fix to make. I hope they make it soon instead of forcing customers to either not look at and review reports that indicate their backups are working or run a risky (security) release of JAVA as a work around.