1. java.lang.OutOfMemoryError: PermGen space
[Solution]
The fix is to run with -server to allocate more PermGen space by default.
If you are already running -server and hitting the problem, then increasing with -XX:MaxPermSize=XXXm will resolve it for you.
Note: Increasing PermGen space means less space for the rest of the application and other programs.
The value needs to be tuned based on feature set (eg with/without JSP) as well as available RAM.
Also, the default can vary with each JRE major release.
Alterations are best done via professional services or system integrators during deployment, where
the tuning can be monitored.
2. java.lang.UnsupportedOperationException: Java Runtime Environment (JRE) version 1.7 is not supported by this driver. Use the sqljdbc4.jar class library, which provides support for JDBC 4.0
The issue is Java 7 not compatible with JDBC4 Driver.
[Solution]
Downgrade java to the version that supports ojdbc4.jar
3. Socket exception:
com.elixirtech.net.NetException: renderReport error: java.net.SocketException: Connection reset
at com.elixirtech.ers2.client.ERSClient.renderReport(ERSClient.java:635)
at com.cmt.report.service.impl.ReportGeneratorServiceImpl.generate(ReportGeneratorServiceImpl.java:1114)
at com.cmt.report.ReportManager.main(ReportManager.java:74)
Caused by:
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:179)
at com.ibm.jsse2.b.a(b.java:126)
at com.ibm.jsse2.b.a(b.java:174)
at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:536)
at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:603)
at com.ibm.jsse2.f.read(f.java:23)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:229)
at java.io.BufferedInputStream.read(BufferedInputStream.java:248)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at com.elixirtech.ers2.client.ERSClient.renderReport(ERSClient.java:628)
Socket reset exception can be caused by various reasons when the remote connection is unexpectedly and forcefully closed. There are 2 possibilities that could have happened in this case:
a) Socket Exception: caused by connection being close prematurely, for example: before the big report is completed. the connection was forced close by the application.
To test this out, please render the large report directly from the server console and capture and generating time taken. After that, please check the application side whether there is any timeout imposed that is shorter than the report rendering time.
b) This exception can also be caused by users closing / navigating away from the application while report being rendered, which closed the thread.
*** Note: Apart from this case, there are other types of Socket Reset Exception errors:
One slightly bizarre message can be Too many open files
, especially when you run on Linux. This message designates that to many file descriptors are open to the system. You can avoid that error if you go to /etc/sysctl.conf
and raise the number in fs.file-max
field. Additionally, you can try to give more stack memory.
Of course many other messages can be met. For example "Bind error"
, where your connection cannot be established because the port cannot be bind to the socket. In that case check if the port is already in use etc.
4. DocX Processor not licensed
[A]: This optional feature was added in version 8.6.1 where a licensed Aspose PDF post process plugin can be integrated with our server to render a docx template to a PDF file (our current pipeline is docx to docx). If a licensed Aspose Docx library was deployed with the Repertoire Server the above message will not appear in the logs. More information on the Aspose PDF post processor can be found here: (http://www.aspose.com/java/pdf-component.aspx)
There is no further action required if this is a one-to-one migration unless your side is considering implementing the Aspose docx post processor.
5. Repertoire Web Server in enhance security mode.
sendServerVersion: false
setHttpOnly: true
[A]: Enhanced server security to support Sha2 (512 Bit) encrypted strings was added in version 8.4.1. In addition, ‘sendServerVersion’ and ‘setHttpOnly’ are additional security features which perform the following:
-
Setting the parameter ‘setHttpOnly’ flag as true protects user online activities stored in the session cookie
-
Setting ‘sendServerVersion’ as false prevents the Repertoire Server from disclosing Jetty’s version number
6. Code: 500: "LogicalRenderer: JDBCDataSource.pushTo
java.sql.SQLException: IO Error: Connection reset
[A] This is a database connection issue due to the database connections were forced to close.
The exceptions are related to existing database connections being terminated prematurely by the database itself or by a firewall terminating idle database connections instead of the connection pool closing them gracefully. This results in the connection pool attempting to access the database via connections which are no longer existent.
These are some of the causes:
-
The JDBC connection pool tries to get connected to the database and fails, as the database was not started.
-
A connection is no longer usable due to either database failure or by database/firewall terminating idle connections prematurely. When the connection pool tries to use a connection it had previously obtained, the connection becomes invalid. In this case, all connections currently in use by the JDBC connection pool gives this error, when they try to connect to the database.
-
The JDBC connection pool obtains a now-stale connection.
-
Network congestion: the situation in which an increase in data transmissions results in a proportionately smaller (or even a reduction in) throughput. In other words, when a network is congested, the more data one tries to send, the less data is actually successfully sent.
-
Exceeded max number of connections on Oracle, so Oracle hangs up on the connections.
-
Issue with database server or listener closing after a connection is opened.
Therefore, check internally if there is a firewall in your environment that terminates idle connections opened by the connection pool and disable the timeout settings on the firewall. In addition, you may want to check with your Database Admin what was going on in the database.