I had 2008.04 running and correctly backing up configurations. However, I made the mistake of upgrading from Java 5 to Java 6 JDK on the server, which broke 2008.04 (the service wouldn't start). After many failed attempts to correct the issue, I tried a complete uninstall/reinstall of everything (JDK 5 & 6, ziptie server/client). Now I am currently running 2008.04c server and client, and am able to start the server service, but I am receiving the following error when I try to backup a device:
com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[12,1]
Message: XML document structures must start and end within the same entity.
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:267)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.readRest(XMLStreamReaderUtil.java:70)
at com.sun.xml.ws.message.stream.StreamMessage.readPayloadAsJAXB(StreamMessage.java:250)
at com.sun.xml.ws.fault.SOAPFaultBuilder.create(SOAPFaultBuilder.java:478)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:118)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
at $Proxy66.backup(Unknown Source)
at org.ziptie.server.job.backup.BackupTask.performTask(BackupTask.java:76)
at org.ziptie.server.job.AbstractAdapterTask.execute(AbstractAdapterTask.java:119)
at org.ziptie.server.dispatcher.Operation.execute(Operation.java:100)
at org.ziptie.server.dispatcher.OperationExecutor$JobThread.runJob(OperationExecutor.java:684)
at org.ziptie.server.dispatcher.OperationExecutor$JobThread.run(OperationExecutor.java:561)
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[12,1]
Message: XML document structures must start and end within the same entity.
at com.sun.xml.stream.XMLReaderImpl.next(XMLReaderImpl.java:563)
at com.sun.xml.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:92)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.readRest(XMLStreamReaderUtil.java:67)
... 11 more
The following is listed in ziptieServer.log:
08-07-02 09:47:53,859 [BackupJob ] [ZipTieScheduler_Worker-3 ] INFO - Starting Backup Job '_interactive.Backup Devices (Run now ID1020)'
08-07-02 09:47:55,000 [BackupJob ] [Idle-7 ] WARN - Backup 172.16.226.20@Default in Job '_interactive.Backup Devices (Run now ID1020)' completed with exception
08-07-02 09:47:55,468 [ConfigStore ] [btpool0-4 ] ERROR - Error retreiving revision information for device 172.16.226.20 in managed network Default
org.tigris.subversion.svnclientadapter.SVNClientException: org.tigris.subversion.javahl.ClientException: Can't find an entry
svn: 'file:///C:/Program%20Files/ZipTie%20Server/repository/repositories/87/2/487/ZipTie-Element-Document' does not exist in revision '1471'
at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.propertyGet(AbstractJhlClientAdapter.java:1188)
at org.ziptie.provider.configstore.ConfigStore.populateRevisionInfo(ConfigStore.java:729)
at org.ziptie.provider.configstore.ConfigStore.retrieveRevision(ConfigStore.java:187)
at org.ziptie.provider.configstore.ConfigStoreDelegate.retrieveRevision(ConfigStoreDelegate.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:246)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at org.ziptie.zap.metro.ZwsServlet.doPost(ZwsServlet.java:227)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093)
at org.ziptie.zap.security.ZHttpContext.doFilter(ZHttpContext.java:80)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.ziptie.zap.metro.ZThreadContextFilter.doFilter(ZThreadContextFilter.java:34)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:56)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722)
at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:107)
at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:64)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:620)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
Caused by: org.tigris.subversion.javahl.ClientException: Can't find an entry
svn: 'file:///C:/Program%20Files/ZipTie%20Server/repository/repositories/87/2/487/ZipTie-Element-Document' does not exist in revision '1471'
at org.tigris.subversion.javahl.SVNClient.propertyGet(Native Method)
at org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.propertyGet(AbstractJhlClientAdapter.java:1180)
... 46 more
Old database
Are you trying to use the original database? If so, did you also restore the repository directory along with the database? You can also try deleting and re-adding that device to the inventory.
-Brett
Old database is gone
When I had issues with the server not working, I uninstalled the server and did not opt to save the old configs. The ziptie server folder was deleted and my current installation is brand new with rediscovered devices.
I just tried deleting a device and re-adding it, backup is still failing.
Ah
Ah, the above error is the result of opening the device view on the client (double-click) when there is no configuration in the repository (because the backup failed), and is unrelated to the backup failure itself. If you right-click on the device in the UI and chose "Show error detail", what is the stated cause of the backup failure?
-Brett
Same as above
Here is the info from the "show error details" menu option, this info appears to be the same for any of the discovered devices:
com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[12,1]
Message: XML document structures must start and end within the same entity.
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:267)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.readRest(XMLStreamReaderUtil.java:70)
at com.sun.xml.ws.message.stream.StreamMessage.readPayloadAsJAXB(StreamMessage.java:250)
at com.sun.xml.ws.fault.SOAPFaultBuilder.create(SOAPFaultBuilder.java:478)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:118)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:118)
at $Proxy66.backup(Unknown Source)
at org.ziptie.server.job.backup.BackupTask.performTask(BackupTask.java:76)
at org.ziptie.server.job.AbstractAdapterTask.execute(AbstractAdapterTask.java:119)
at org.ziptie.server.dispatcher.Operation.execute(Operation.java:100)
at org.ziptie.server.dispatcher.OperationExecutor$JobThread.runJob(OperationExecutor.java:684)
at org.ziptie.server.dispatcher.OperationExecutor$JobThread.run(OperationExecutor.java:561)
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[12,1]
Message: XML document structures must start and end within the same entity.
at com.sun.xml.stream.XMLReaderImpl.next(XMLReaderImpl.java:563)
at com.sun.xml.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:92)
at com.sun.xml.ws.streaming.XMLStreamReaderUtil.readRest(XMLStreamReaderUtil.java:67)
... 11 more
Device Type
What make and model of device is this?
-Brett
Cisco IOS
I've tried various Cisco routers and switches. Sample router model #'s are 2811, 3745, 3825, and 7505. Sample switches are 2950, 3550, 3750, and 6500. I have some CatOS switches I can test this on, but I'd imagine the results would be similar.
Does it make a difference if I'm running JDK 5 vs. JDK 6? Or if I have both on the system?
Java 5
There have been a few reports of quirky behavior with Java 6 in the past, but it should work fine. However, to be safe you can ensure it is using Java 5. We have never had any problems with Java 5.
-Brett
Debugging
I'm going to ask one of the guys more familiar with backup issues to jump in to the thread.
-Brett
Default group
I have configured credentials and protocols for a group called "ziptie" and I have specified the 172.16.0.0/12 network range for this group. However, when I discover a device, it still appears to be using the "default" group:
08-07-04 20:53:51,015 [BackupJob ] [Idle-19 ] WARN - Backup 172.20.192.205@Default in Job '_interactive.Backup Devices (Run now ID1014)' completed with exception
Just to be sure the credentials were correct, I configured the default group to be exactly the same as the ziptie group. But I'm just curious, since I specified a subnet range of 172.16.0.0/12, shouldn't that force the server to use the "ziptie" group instead of default for a 172.16.0.0 - 172.31.255.255 device?
-quid
Rememeber
Quid,
Once a device has been successfully backed up using a credential, that credential will become "sticky" for that device. So, if you backed up a device using Default, and _then_ added a new credential set ("ziptie"), the Default will still be associated with the device even though the subnet may match for "ziptie". The only way to shake it loose is to make an edit to the Default credential set. Doing so will cause the server to delete all device associations (for Default) and start again. This time, it should use and associate the "ziptie" credential set with the device.
-Brett