Common Errors
Prev Chapter 9. Troubleshooting and Common Errors 

Common Errors

Client Errors

There are three categories of client-side error:

Communication
Communication errors occur because the client is unable to connect to the server, either due to firewall restrictions, the server port not being available, the server not being ready to accept connections, or due to protocol differences - one side is running secure mode, and the other side plain.
Authorization
After successfully connecting, the client attempts to authenticate itself with the server. If your client program fails to connect, then try to connect using a browser and check that you can authenticate manually. Review the activity and server logs for information about logon failures.
Timeout or Connection Lost
This error occurs if the server fails to respond to the client within a meaningful time, or the connection is broken. Check the server log to identify the cause of any timeout, or check the network to resolve why the connection was terminated. This error may be due to a server failure - for example if the server doesn't have enough memory to complete the set of tasks it is currently handling. You might choose the reduce the number of concurrent tasks that you allow the server to perform by editing ERS2.xml.

Report Errors

Report errors are often due to missing information. For example, the report template and all necessary datasources (and any data files) are not deployed to the server, or are not deployed in a consistent location (remember in particular that the Repository is case-sensitive). You should also check that the dynamic parameters passed in to the render engine are correct. It is usually advisable to include default values for the parameters, so that it is easy to verify the report by not including any explicit dynamic parameters.

After rendering a template for the first time or after any change, you should check the server log for any JavaScript errors while running the report, to ensure that all information is rendered correctly and efficiently.

Datasource Errors

Datasource errors are different for each kind of DataSource:

JDBC
ClassNotFound: Missing JDBC driver. You need to put the correct JDBC driver jar file from your database vendor into the server ext directory and restart the server, so that it will be loaded. You should ask your database vendor for the appropriate jar file for your chosen database and version.
ARFF,Properties,Text,Excel,XML, DBF
These datasources depend on external data files, so these need to be available on the server. It is usually best to place these data files within the repository and refer to them with repository: URLs so that if the repository moves in future the files will still be accessible. Further, each data file needs to conform to the correct format - an invalid XML file cannot be parsed by the XML datasource, for example.
Composite, Reference, Cache
These datasources depend on other datasource files, so these need to be available in the server repository.
Object
Object datasources need access to the class files or jar files that contain the compiled Java code for the classes that are used by the object datasource. If you use the classpath functionality within the object datasource, then you need to ensure that the same classpath applies on the server. You might want to use repository: URLs for your classpath, so the jars get deployed onto the server at the same time as the datasources that use them.

Printing Errors

Once the report has been spooled to the operating system, Repertoire Server has no more control over the printing process. Therefore, you need to look at the print queue management software provided by your operating system to see how print errors are reported and resolved.

Prev Up 
Client-Server Troubleshooting Home