[#8076] - Japer PDF rendering from JAVA code with multi-threading - Data on the exported page appearing out of order

Bug report
Project: Severity:
No Change Required
Component: Reproducibility:
Assigned to:

We have been able to render PDFs from a JRXML (with multiple lists designed sequentially - List A, followed by List B, followed by List C etc. (ALL LISTS HAVE THEIR OWN SQL TO RETRIEVE THE DATA)). Earlier we were running the process single threaded so the output was nice in the correct order (records of list A, followed by records of list B, followed by records of list C), but now we have implemented multi-threading on the process, so they run concurrently. But out of it, we are now getting the data messed up for a single thread case. The data is now appearing in the order in one of the case - some records of List B, some records of List A, (again) remaining records of List B, so on.

The approaches that we've tried so far are -
Separate JasperPrint objects for each thread. Also tried with both - first with same shared JasperReport object and then with separate one JasperReport object per thread. Both ways we are seeing this issue.

Binary Data discrepancyvrv_subreport2.jrxml39.37 KB
kapil.gureja's picture
Joined: Sep 3 2014 - 6:33am
Last seen: 3 years 11 months ago


  • Status:New» Feedback Requested


This is a nice story, but there is no piece of code that we could look at. From what I understand, you are describing us a problem that you encounter while running your own code, that does some sort of multi-threading.
But how are we supposed to comment on code that we never saw? A story is just a story. We need things to look at.

You were asked for such details also on the forums thread you started, but you did not provide any file. Just high level text explanations about some multi-threading code that you have in your application.
I suggest you provide enough information so that people here can actually help you. A bug should be logged only after confirmed it is a JR Lib problem. Until then, the discussion forums should be the way to exchange information about this issue.



I have attached all the required files here.

Binary Data discrepancyvrv_subreport2.jrxml39.37 KB


So now that I'm looking at your JRXMLs, where are list A, list B and list C?

The code you sent seems to fill a JasperPrint and add it to a list of JasperPrint objects received as parameter from outside. If the current JasperPrint has pages, it is also exported to a PDF file.
What exactly is not working in your case? Is there a record order problem in each individual PDF, or are you somehow trying to concatenate the PDFs themselves and they do not get generated in the correct order?

See, you did not add a single line of explanation to your initial question. It is always me who writes more. This way, you'll never get to solve your problem because you are not telling us enough. If all this is a secret and this is why you are not talking to us, then please keep it a secret and I'll close this tracker.



The lists are in the Ancillaries.jrxml (whatever names they have, A B C are just the symbolic names) that I attached in my answer. As stated before, there is problem with the record order in individual PDFs generated with multi threading with separate DB connection for each thread. Yes, at last we concatenate the individuals PDFs, but that's not a problem.

  • Resolution:Open» No Change Required
  • Status:Feedback Requested» Closed


All I can say is that your subdataset have very complex SELECT queries and not all of them have an ORDER BY clause. I'm not sure if the sorting problem comes from these subdatasets that do not have an ORDER BY in their query, but since you do not use sortField tags in your datasets, JR does not perform any sorting on its own.
So I suggest you put JR Lib aside for a moment and double check if your queries do return the records in the order in which you expect, or at least control this order at all.

If you want to have JR Lib sort the records in the datasource before using it, then declare "sort fields" in your datasets and JR will do the sorting. But pay attention that this consumes memory, as JR needs to load all the data in-memory to sort it, before consuming it for report rendering.

I don't think this is a JR bug because this area of the product is virtually unchanged for so many years and nobody complained about sorting before.



That could be the reason for the records of single sub-dataset. Still the bigger question is not clear, why would it mess the data of two different sub-datasets - as clear from the screenshots (attached in my previous answer), the record data of OVERFLOW dataset is coming in between the records of AUDIT HISTORY dataset, but the OVERFLOW is designed before the AUDIT part on the jasper Design page. Please also note - as stated before, it is happening only when we run the process concurrently with separate DB connection per thread.


  • Priority:Immediate» Urgent
  • Resolution:No Change Required» Reopened
  • Status:Closed» New
  • Status:New» Feedback Requested


You only sent some screenshots with portions of one or two pages. It would have been more helpful to send a screenshot with the entire pages or the entire PDFs for both cases: correct order vs incorrect order.
Just by looking at the small area that we can see from your document pages, there is nothing in the information we see that would show us that the Overflow list and Audit History lists are from the same detail band of the master.
You are telling us your Overflow and Audit appear in the wrong order because you are under the wrong assumption that they come from the same detail band of the master.
How do you know that? Your Overflow list has "Remove Line When Blank" checked, so if there is no data returned for that list in the current detail, it would not appear. Furthermore, the Audit list has a "Print When Expression", which causes that in some details you get only the Overflow list and in other details you get only the Audit list. If the order of records is changed for some reason in the master, then your apparent order of Overflow and Audit list might appear wrong. You see Overflow appear after Audit because it is part of the next detail in the master.

If you do not believe me, then modify your template and let the Overflow list print even if it does not have records. Use a backcolor for your list element so that you see it is there. Also, remove the PrintWhenExpression of your Audit list.
Also, for debugging purposes, use some text fields in the lists to display parameter values that you pass from the master to the child list so that it would help you figure out from which detail band is each list coming from.

The answers to your all questions are on your side, where you can do this kind of debugging. We cannot debug you remotely just by looking at carefully cut screenshots.

I hope this helps.


Sorry, but all the lists belong to the same detail band, as can be seen in the attached Ancillaries.jrxml. Also, I've attached the PDF snippet for both cases for your reference.



Please uncheck the "Remove Line When Blank" option for the "Overflow" list element as well as all its elements inside the list content cell.
Then run the report again and show us the PDFs.




Anything new on this one?


  • Resolution:Reopened» No Change Required
  • Status:Feedback Requested» Closed