nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Exception: Processing document file, please try it later.

hallj05

Hey,

This is using Birt version 2.6.2.

We are getting the exception "Processing document file, please try it later." on a deployed WAS environment when running a report where the SQL returns more than 6000 or so records. When under that amount of records the report will run fine although it seems to take about a minute to display when it gets close to 6000 records. Even when we get over the 6000 records and get the error, we can still export the report as a CSV and it contains all the data. I'm thinking that this could be some sort of timeout (60 seconds?) variable either in Birt or WAS that could be causing this issue.

Thanks for any help with this issue!

Find more posts tagged with

Comments

mwilliams

I'll have to say I've never seen that error pop up before or even anyone mentioning it. I'm trying to find where and exactly why this is called to see if there's a way to extend the wait time. I'll let you know if I find something. I see you say there are 6000 records. How large are these records? Lots of columns or lots of data per column?

hallj05

Yeah I've never seen this error before and according to searching on google not many others have as well.

The SQL only returns 7 columns, although it is a join between two tables using a where clause on where they are equal on two columns. The 6000 records amount is after the join so the tables before that would have less. The full join (if it was a select * instead of just the columns we want) would be 90 columns (one table has 12 columns the other has 78 columns). The largest sized column would be a VARCHAR2(2000 BYTE), yet most of the columns are much smaller (less than 10 characters long).

We also do some alerts on this report, so that it will highlight fields based on the values they have, not sure if this could be the cause since running the SQL in SQL developer doesn't take long at all. Which the values that we use for the alerts are stored in an XML file. This has never caused an issue before and it's used in a couple other reports also.

The reason we are thinking that it is having trouble at 6000 records is that it worked when we had 5952 records and then didn't work when there were 6029 records. Which it was taking around a minute for these to load, so that's why I'm thinking it could be some form of timeout since when it was working that close to 6000 it could be taking just under 60 seconds and then when it went over it was taking longer than 60 seconds.

mwilliams

There's a query timeout setting in the property binding of the dataSet, though this doesn't appear to be the issue since you say you can export the data still. Have you checked your database to make sure there isn't a timeout set, though, like the other thing I said, this doesn't seem to be it as you still get the data. I'll keep looking into it and let you know if I find something. What is your database type?

hallj05

This is using DB2. From what I can tell it doesn't look like we have any timeouts set, so I guess it would be using whatever the default would be.

Also when we get the error it gives a blank screen as the report.

cwheat18

I'm experiencing the same issue that hallj05 is experiencing. So similar in fact that I could have written his posting. Has anyone gathered any more information on this exception?

mwilliams

Does anything show up in the log files for the viewer?

cwheat18

What are the names of the log files that I should be looking for? I didn't see any on the server that were specific to the BIRT viewer.

IngMon

Hi I'm getting that same exception but my Data set is only one row one column(but it is a SUM). I don't understand what is happening but I think it may be some variable of use of memory that is blocking the query to execute or to display... dunno LOL.

IngMon

<blockquote class="ipsBlockquote" data-author="hallj05" data-cid="117495" data-time="1370879941">
<div>
Yeah I've never seen this error before and according to searching on google not many others have as well. The SQL only returns 7 columns, although it is a join between two tables using a where clause on where they are equal on two columns. The 6000 records amount is after the join so the tables before that would have less. The full join (if it was a select * instead of just the columns we want) would be 90 columns (one table has 12 columns the other has 78 columns). The largest sized column would be a VARCHAR2(2000 BYTE), yet most of the columns are much smaller (less than 10 characters long). We also do some alerts on this report, so that it will highlight fields based on the values they have, not sure if this could be the cause since running the SQL in SQL developer doesn't take long at all. Which the values that we use for the alerts are stored in an XML file. This has never caused an issue before and it's used in a couple other reports also. The reason we are thinking that it is having trouble at 6000 records is that it worked when we had 5952 records and then didn't work when there were 6029 records. Which it was taking around a minute for these to load, so that's why I'm thinking it could be some form of timeout since when it was working that close to 6000 it could be taking just under 60 seconds and then when it went over it was taking longer than 60 seconds.
</div>
</blockquote>
 If the join is a natural join this might be the problem, I change the query (on my case) to non-natural joins (inner join in this case) and the exception didn't appear again.