Bug 340346 - Dropping JDBC Classes
Summary: Dropping JDBC Classes
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: BIRT (show other bugs)
Version: 2.6.2   Edit
Hardware: PC Linux
: P3 normal with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Birt-DataAccess CLA
QA Contact: Xiaoying Gu CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-17 12:24 EDT by Logan CLA
Modified: 2011-11-09 15:49 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Logan CLA 2011-03-17 12:24:23 EDT
Scenario:

Tomcat 5.5.31, BIRT 2.6.2, RHEL 5.5, Java 1.6.23

When the server is first started, ALL reports can be generated just fine. However, after "stress testing" the server (a program constantly runs reports for a hour or so), SOME reports start generating errors after 60-120 minutes. Here is an excerpt of the stack trace, though I doubt its very relevant.

Axis Fault
(...etc.)
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.eclipse.birt.rep ort.service.api.ReportServiceException: Error happened while running the report.
at org.eclipse.birt.report.service.ReportEngineService.throwDum myException(ReportEngineService.java:1104)
(...etc.)

Caused by: java.lang.NoClassDefFoundError: com/ibm/as400/access/AS400EndJobDS
at com.ibm.as400.access.AS400ImplRemote.getConnection(AS400Impl Remote.java:1069)
at com.ibm.as400.access.AS400ImplRemote.connect(AS400ImplRemote .java:402)
at com.ibm.as400.access.AS400.connectService(AS400.java:1135)


Most of these reports take parameters for the database they are to connect to. One report will run for multiple databases, depending on those values we pass. Because of that, we don't use connection pooling (it connects to ~200 different databases, more than I want to maintain in a pool).

Now, once we start getting this error, the reports that are getting this simply won't run. We can run other reports that are similar, (ie, connect to the same type of DB) without error.

Once Tomcat is restarted, the problem goes away.

Any idea what would be causing BIRT to randomly "drop classes" so to speak?


The program to stress test is simply a 5-threaded java app that concurrently will pull down reports to the local file system (ie, it hits the server in chunks of 5 requests).  It does it through standard web calls.  As stated, it works perfectly until some time has elapsed, and then it starts generating these errors.  If you attempt to view the page via a browser, these errors exist as well with the stack trace listed above (or one similar).  

We are using the latest jt400.jar and oracle.jar (it happens to both of the, jt400 seems to be more common however).  They are located in:

./WEB-INF/platform/plugins/org.eclipse.birt.report.data.oda.jdbc_2.6.2.r262_v20110127/drivers/jt400.jar
./WEB-INF/lib/jt400.jar

The error happens in any combination of those locations as well.
Comment 1 Yaytay CLA 2011-05-24 10:30:27 EDT
I have the same problem, and have had for six months or so.
For me it affects the mysql and MS SQL Server JDBC drivers, from looking at other issues people have found it can relate to any JDBC drivers.

Typically our live system can run for weeks without hitting the problem (quite 
low usage), but we the MS SQL drivers can be triggered by using a broken JDBC connection.

This is an absolute killer for us - if the reporting server is not reliable it is of no use.
Comment 2 Etienne Lacombe CLA 2011-09-22 10:48:47 EDT
I also get that all the time with jTDS and Postgres drivers.  Seemingly random, some reports will start generating NoClassDefFound exceptions for some "random" JDBC class - sometimes it's DateTime class, sometimes it's another, etc.

I need to regularly restart the tomcat servers to get rid of this problem -- really not fun!
Comment 3 Yaytay CLA 2011-11-09 15:49:40 EST
Woth noting that the BIRT 3.7 runtime environment has not hit this problem for us, though I have had it in the BIRT 3.7 designer.
It seems to occur much more often with the MS SQL Server JDBC drivers, and is particularly likely to occur after an error (i.e. if a previous report couldn't connect to the database).