Revision as of 15:35, 6 July 2018

Overview

The HTTP Status 500 error can be seen when the Swivel Administration console encounters a problem and may be for a variety of reasons. This document is to help troubleshoot those issues.

Prerequisites

Swivel 3.x

Symptoms

The following error message may be seen in the browser, the message may vary according to the problem encountered.

HTTP Status 500 - type Exception report message description The server encountered an internal error that prevented it from fulfilling this request. exception org.apache.xmlbeans.impl.values.XmlValueDisconnectedException org.apache.xmlbeans.impl.values.XmlObjectBase.check_orphaned(XmlObjectBase.java:1212) com.swiveltechnologies.xmlconfig.impl.LookupImpl.isSetValue(Unknown Source) com.swiveltechnologies.pinsafe.server.config.ConfigurationListImpl.getLookup(ConfigurationListImpl.java:470) com.swiveltechnologies.pinsafe.server.ui.ConfigurationEditor.setListElement(ConfigurationEditor.java:647) com.swiveltechnologies.pinsafe.server.ui.ConfigurationEditor.executePost(ConfigurationEditor.java:317) com.swiveltechnologies.pinsafe.server.ui.InterfaceServlet.doPost(InterfaceServlet.java:265) javax.servlet.http.HttpServlet.service(HttpServlet.java:637) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:125) note The full stack trace of the root cause is available in the Apache Tomcat/6.0.36 logs. Apache Tomcat/6.0.36

Solution

A good place to start looking for such issues is in the Tomcat logs, see the Tomcat logs section under Troubleshooting_Files_FAQ

Known causes of this issue are given below:

Transport deletion in Swivel 3.9.2

When a transport is deleted in Swivel 3.9.2 and a new one created an Error 500 message may be produced.

org.apache.xmlbeans.impl.values.XmlValueDisconnectedException org.apache.xmlbeans.impl.values.XmlObjectBase.check_orphaned(XmlObjectBase.java:1212) com.swiveltechnologies.xmlconfig.impl.LookupImpl.isSetValue(Unknown Source) com.swiveltechnologies.pinsafe.server.config.ConfigurationListImpl.getLookup(ConfigurationListImpl.java:470) com.swiveltechnologies.pinsafe.server.ui.ConfigurationEditor.setListElement(ConfigurationEditor.java:647) com.swiveltechnologies.pinsafe.server.ui.ConfigurationEditor.executePost(ConfigurationEditor.java:317) com.swiveltechnologies.pinsafe.server.ui.InterfaceServlet.doPost(InterfaceServlet.java:265) javax.servlet.http.HttpServlet.service(HttpServlet.java:637) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:125)

To overcome this issue the <path to Transient data>/conf/config.xml file can be edited, for an appliance this file is located in:

/home/swivel/.swivel/conf/config.xml

Backup the file before editing.

Stop Tomcat

Edit the file and look for the transport to be removed. Look for and remove <element readonly="true"> to </element> inclusively

Example:

<element readonly="true">

<string name="id" readonly="true" maxlength="32">

<value>TRANSPORT NAME TO REMOVE</value>

</string>

<string name="class" readonly="true">

<value>com.swiveltechnologies.pinsafe.server.transport.transport</value>

</string>

<long name="stringcount"/>

<boolean name="copytolalert"/>

<lookup name="alertgroup" lookup="groups" blank="repository_groups_no_group"/>

<lookup name="group" lookup="groups" blank="repository_groups_no_group"/>

<lookup name="attribute" lookup="attributes" blank="repository_attributes_none">

<value>phone</value>

</lookup>

</element>

Also look for the following

<group name="TRANSPORT NAME TO REMOVE" generated="true"> to </group> inclusively

Save the file

Start Tomcat

Test

Version 4 bug, tomcat restart with Internal Database

There is a known issue when restarting tomcat on version 4, up until 4.0.4.

As a workaround for this issue, log into the CMI, and set the database to shipping.

Log in with the default credential and on the Swivel Administration Portal, go to Database -> General and select the internal database again.

Now you should be back to normal, until a new tomcat restart.

One way to mitigate the problem, is to migrate the data from the internal database (old derby) to the appliance database.

On the Swivel Administration Portal, go to Database - General, with the Internal Database selected, open the Appliance Database details.

On the Driver entry box, write: org.mariadb.jdbc.Driver

On the URL entry box, write: jdbc:mariadb://localhost/pinsafe

Username and Password are both: pinsafe

Go to Migration -> Data , select the Appliance Database as targer and on the entry box, write: MIGRATE

Go back to Database - General and select the Appliance Database.

On the User Administration, you can check that all the users are there and the migration was a success.