We have a serious problem with JasperReport in a J2EE Environment with IBM Websphere 5.0.
One of our services (Stateless Session EJB) should generate reports (as pdf or excel). The problem is now that in some situations the jasper engine creates threads which is prohibited by EJB specifications and the Websphere tells us this in his usual friendly way :-).
As Jasperreport is advertised as solution for j2ee applications, I am sure there MUST be a solution to use JasperReport in a single thread mode but we were not able until now to find the appropriate documentation which told us how to do it.
Thanks in advance for the help
One of our services (Stateless Session EJB) should generate reports (as pdf or excel). The problem is now that in some situations the jasper engine creates threads which is prohibited by EJB specifications and the Websphere tells us this in his usual friendly way :-).
As Jasperreport is advertised as solution for j2ee applications, I am sure there MUST be a solution to use JasperReport in a single thread mode but we were not able until now to find the appropriate documentation which told us how to do it.
Thanks in advance for the help
15 Answers:
Posted on April 25, 2007 at 3:44pm
Hi,
JasperReports uses multi-threading only when subreports are involved. However, this is a pretty common scenario.
Fortunately, there is a solution: you need to use the jasperreports-x.x.x-javaflow.jar and not the usual jasperreports-x.x.x.jar. Both are available for download in the same place. When using the Javaflow version of JasperReports, you also need to put the commons-javaflow.jar in the classpath of you application. This can be found in the /lib directory of our project ZIP package.
I hope this helps.
Teodor
JasperReports uses multi-threading only when subreports are involved. However, this is a pretty common scenario.
Fortunately, there is a solution: you need to use the jasperreports-x.x.x-javaflow.jar and not the usual jasperreports-x.x.x.jar. Both are available for download in the same place. When using the Javaflow version of JasperReports, you also need to put the commons-javaflow.jar in the classpath of you application. This can be found in the /lib directory of our project ZIP package.
I hope this helps.
Teodor
Posted on April 25, 2007 at 5:03pm
I have to use the jasperreport-javaflow as a replacement for the standard jasperreport not as an addition, right?
I ask because I made exactly this and it had no effect.
Do I have to set an additional parameter or something like this?
Thanks a lot for the help.
P.S. Here my current classpath of the EJB.jar.
I ask because I made exactly this and it had no effect.
Do I have to set an additional parameter or something like this?
Thanks a lot for the help.
P.S. Here my current classpath of the EJB.jar.
| Code: |
log4j-1.2.12.jar<br /> commons-logging-1.0.2.jar<br /> commons-collections-2.1.jar <br /> commons-beanutils-1.7.jar<br /> commons-digester-1.7.jar<br /> commons-javaflow-20060411.jar<br /> jdt-compiler-3.1.1.jar<br /> jasperreports-1.3.2-javaflow.jar<br /> itext-1.3.1.jar<br /> poi-2.0.jar</td></tr></tbody></table> |
Posted on April 25, 2007 at 5:15pm
Yes, you are right! Sorry about forgetting to tell you to set the net.sf.jasperreports.subreport.runner.factory=net.sf.jasperreports.engine.fill.JRContinuationSubreportRunnerFactory
in the jasperreports.properties file that you put in the classpath.
This can be seen in the /demo/samples/subreport sample provided with the project.
I hope this helps.
Teodor
in the jasperreports.properties file that you put in the classpath.
This can be seen in the /demo/samples/subreport sample provided with the project.
I hope this helps.
Teodor
Posted on April 26, 2007 at 8:36am
It works, thx a lot.
Confusing was only the naming of the properties file in the sample: jasperreports-javaflow.properties. If you had not mentioned the correct file name it would have taken a lot more time.
Just a little hint: For me is single thread behavior a key feature or standard use case scenario specially if jasperreport is intended for a j2ee environment. Therefore it is not clear to me why this is nowhere documented or did I not search good enough?
Confusing was only the naming of the properties file in the sample: jasperreports-javaflow.properties. If you had not mentioned the correct file name it would have taken a lot more time.
Just a little hint: For me is single thread behavior a key feature or standard use case scenario specially if jasperreport is intended for a j2ee environment. Therefore it is not clear to me why this is nowhere documented or did I not search good enough?
Posted on April 26, 2007 at 11:47am
Hi,
I think using Javaflow to avoid multi-threading is not an usual occurrence. Even in J2EE applications, as long as the report generating routines reside in the servlet container and not in the EJB container, you should be OK.
Maybe we'll put up an FAQ.
Thanks,
Teodor
I think using Javaflow to avoid multi-threading is not an usual occurrence. Even in J2EE applications, as long as the report generating routines reside in the servlet container and not in the EJB container, you should be OK.
Maybe we'll put up an FAQ.
Thanks,
Teodor
Posted on July 11, 2007 at 9:00pm
teodord wrote:
Is it not so that in both Servlet and EJB areas of a J2EE container it is forbidden to create threads?
Technically, one would need a J2EE resource adapter for threads or an MBean in JMX-based containers.
That it seems to work is one thing, to be sure is another. We have the impression that it does work in BEA WebLogic 8.1.
Can anyone confirm/comment on using the non-javaflow-version in J2EE containers (behind a Stateless Session Bean).
Regards,
Matthias
| Hi, I think using Javaflow to avoid multi-threading is not an usual occurrence. Even in J2EE applications, as long as the report generating routines reside in the servlet container and not in the EJB container, you should be OK. Maybe we'll put up an FAQ. Thanks, Teodor |
Is it not so that in both Servlet and EJB areas of a J2EE container it is forbidden to create threads?
Technically, one would need a J2EE resource adapter for threads or an MBean in JMX-based containers.
That it seems to work is one thing, to be sure is another. We have the impression that it does work in BEA WebLogic 8.1.
Can anyone confirm/comment on using the non-javaflow-version in J2EE containers (behind a Stateless Session Bean).
Regards,
Matthias
Posted on October 18, 2007 at 11:01am
I tried to use the javaflow version of jasperreports but then I got an StackOverflowError.
Seems strange that I suddenly have some kind of loop in a report that works fine with the "JRThreadSubreportRunner" version.
So I wonder if anyone have written an "JRSingleThreadSubreportRunner" that I could use instead?
(It also feels somewhat strange to use the javaflow-package in production when there is no official release of it...)
Seems strange that I suddenly have some kind of loop in a report that works fine with the "JRThreadSubreportRunner" version.
So I wonder if anyone have written an "JRSingleThreadSubreportRunner" that I could use instead?
(It also feels somewhat strange to use the javaflow-package in production when there is no official release of it...)
Posted on October 18, 2007 at 8:30pm
lucianc wrote:
Lucian, you are right.
While the EJB spec explicitly disallows Threads to be opened, the Servlet spec seems to actually expect that!
So in a servlet it is actually expected that a reference to a thread can be held!
I am not sure whether I understand the need for "JavaFlow" or threading in the first place. Why would JasperReports need a thread? Performance?
| A note. mgaert wrote:
I don't think the Servlet specification restricts applications from creating threads. Where did you see this restriction? Regards, Lucian |
Lucian, you are right.
While the EJB spec explicitly disallows Threads to be opened, the Servlet spec seems to actually expect that!
| "Enterprise JavaBeans Specification, Version 2.1" 25.1.2 Programming Restrictions The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enter- prise bean must not attempt to manage thread groups. |
| "Java Servlet Specification Version 2.5 MR6" SRV.15.2.1.1 (Filter.destroy()) This method gives the filter an opportunity to clean up any resources that are being held (for example, memory, file handles, threads) and make sure that any persistent state is synchronized with the filter’s current state in memory. |
So in a servlet it is actually expected that a reference to a thread can be held!
I am not sure whether I understand the need for "JavaFlow" or threading in the first place. Why would JasperReports need a thread? Performance?
Posted on October 19, 2007 at 9:29am
mgaert wrote:
JasperReports subreports are filled using the same code as for master/top level reports.
When a subreport exhausts the available space on the current page, it must request to the master report to break the page so that the master report can render its own page footer (on the current page) and header (on the new page). This means that the subreport fill must suspend, give control to the master which would create the new page and then give back control to the subreport fill that needs to resume from the point/context at which it was suspended. This subreport resuming context needs to contain Java stack variables, which makes saving and restoring this context using object/state variables very difficult.
Threads and JavaFlow continuations are solutions for the context saving/restoring need:
| I am not sure whether I understand the need for "JavaFlow" or threading in the first place. Why would JasperReports need a thread? Performance? |
JasperReports subreports are filled using the same code as for master/top level reports.
When a subreport exhausts the available space on the current page, it must request to the master report to break the page so that the master report can render its own page footer (on the current page) and header (on the new page). This means that the subreport fill must suspend, give control to the master which would create the new page and then give back control to the subreport fill that needs to resume from the point/context at which it was suspended. This subreport resuming context needs to contain Java stack variables, which makes saving and restoring this context using object/state variables very difficult.
Threads and JavaFlow continuations are solutions for the context saving/restoring need:
- When threads are used, the subreport fill is performed on a separate thread which coordinates page breaks with the master report fill thread. The subreport thread suspends on page breaks and resumes from the same context when the master signals that a new page has been created.
- JavaFlow continuations express the need of capturing a Java stack state/context and resuming it at a later point. [/ul]
Regards,
Lucian
Posted on November 26, 2007 at 9:20am
jobo wrote:
I have the same issue. Can anybody help with it?
Thanks,
Nadia
| I tried to use the javaflow version of jasperreports but then I got an StackOverflowError. Seems strange that I suddenly have some kind of loop in a report that works fine with the "JRThreadSubreportRunner" version. |
I have the same issue. Can anybody help with it?
Thanks,
Nadia
Posted on February 12, 2008 at 2:02pm
mnadiac wrote:
Hi,
we encountered the same problem here.
Any news...? Jobo or MNadiac ?
We have only added two libs in the path :
jasperreports-2.0.4-javaflow.jar
commons-javaflow-20060411.jar
Are the others libs mandatory ?
If the results set are small, the code works fine... With large data fetch...it throws an exception
Thanks,
Arnaud
jobo wrote:
|
Hi,
we encountered the same problem here.
Any news...? Jobo or MNadiac ?
We have only added two libs in the path :
jasperreports-2.0.4-javaflow.jar
commons-javaflow-20060411.jar
Are the others libs mandatory ?
If the results set are small, the code works fine... With large data fetch...it throws an exception
Thanks,
Arnaud
Posted on October 2, 2009 at 1:32am
Hi,
we got the same StackOverflowError problem when we run JR in an stand alone application. The exception raises only when the report needs pagination (JRParameter.IS_IGNORE_PAGINATION=TRUE) and the report is more than 1 page long.
We're using:
jasperreports-3.6.0-javaflow.jar
commons-javaflow-20060411.jar
Do we need other libraries? or a particular configuration?
Anybody has an idea and could help?
Thanks a lot
Ale
Posted on September 2, 2010 at 4:48am
The cause of the overflow is that AbstractMap.hashCode() falls into infinite loop. It seems that REPORT_PARAMETERS_MAP points to itself!
I removed parameters map expression from all my subreports, but without success.
But at least there is some light shred into this 
