It's all about the answers!

Ask a question

BIRT throws "A huge result set was found here". Ignore or panic?


Vladimir Amelin (70462126) | asked Jan 31 '13, 7:46 a.m.

When running some BIRT reports I see warning in the log:


 WARN com.ibm.team.repository                             - A result set of 13352 entries was seen.  The AstQuery is:

TimeSheetEntryQueryModel r = TimeSheetEntryQueryModel.ROOT;
<CUT>
java.lang.Throwable: A huge result set was found here
 at com.ibm.team.repository.service.internal.QueryService.cacheQueryResult(QueryService.java:381)
 at com.ibm.team.repository.service.internal.QueryService.doExecuteDataQuery(QueryService.java:311)
 <SO ON>

Is it OK or report can be incorrect? Which setting\threshold causes BIRT threat number as huge?

Accepted answer


permanent link
Rafik Jaouani (5.0k16) | answered Jan 31 '13, 10:41 a.m.
JAZZ DEVELOPER

Vladimir,

This is just a warning. There is no data loss. Your report will still show all the data (if your server does not run out of memory). But as Daniel had said, you should redesign your report and avoid fetching all item instances of a certain kind (in this case you are fetching all Timesheet Entries in the system).

Vladimir Amelin selected this answer as the correct answer

Comments
Vladimir Amelin commented Jan 31 '13, 11:18 a.m.

We use all known limitations in the query like project areas, for\to dates etc. But still it can fetch thousands of entries (repository contains about 200k of entries). Only way left is to split dataset artificially. For instance, make it fetch day by day or contributor by contributor. Anyway thanks for clarification, Rafik.

One other answer



permanent link
Daniel Toczala (88211414) | answered Jan 31 '13, 10:14 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
 Vladimir,

  I would be worried.  BIRT reports are notorious for consuming large amounts of memory, and large data sets will consume large amounts of memory.  This will impact performance for ALL of your users.  When writing BIRT reports it is critical that you structure your queries to limit the size of query results, and avoid things like large table joins.

Comments
Vladimir Amelin commented Jan 31 '13, 11:14 a.m.

 Thank you, Daniel. Actually we run such memory-consuming report in the night only (using CURL).

Your answer


Register or to post your answer.