broadcast report shows no data

Steve Kay shared this question 5 years ago
Answered

I have a report that is broadcast each day. The report has 4 codisplay reports so there are a total of 5 reports broadcast in Excel format. 4 of the reports have data. The 5th has the title but no data. If the reports are run from the menu they all have data. The 5th report is a long running report. Is there a timeout that can be bumped up?

Replies (12)

photo
1

Hi Steve,

it would be great to have all of your logs (from the path <yellowfin>/appserver/logs) so that we can confirm that it is a timeout issue, however at the moment we don't, so you could try increasing the value of the Timeout field in the Connection Pool section of the Yellowfin data source - the default value is 180 seconds.

And if it is the data source itself that is closing the connection on Yellowfin, then you could try using the Volatile Sources feature.

If neither of those 2 suggestions help, then you can also increase the timeout of Yellowfin's connection to its own configuration database

There's actually no way to set the timeout for the Yellowfin Broadcast feature itself, however, there is an email size limit in the Outgoing Mail Server section of the Configuration->Email, and by default it is 10 MB so you may need to increase that if your spreadsheet is larger than that.

So there are some suggestions for you to try, and if they don't resolve the empty spreadsheet problem then as I mentioned previously, please send us your log files.

regards,

David

photo
1

I tried the suggestions - no luck.  Attached are log files.

On 11/19/2018 7:45 PM, Support Queue wrote:

Files: logs.7z
photo
1

Hi Steve,

thanks for the logs, there is only the one error and it occurs twice (2018-11-19 09:53:10 and 2018-11-19 15:03:31), and it is not specifically a broadcast error but rather, it is an error to do with running the report, so there's a chance that error might still be related to the empty result set issue you are experiencing.

It's a null pointer exception so I examined the source code where it is thrown from and it is occurring when Yellowfin tries to get the status of the report. This means it could be useful for us to confirm the 5th report's status code. The following query will do this for us:


SELECT ReportStatusCode 
FROM ReportHeader 
WHERE ReportName = '<insert 5th ReportName here>'
AND ParentReportId != 0

although to be frank, I do not really expect this to be fruitful because I have never seen a null value for the ReportStatusCode, but nevertheless we can't ignore this diagnostic step.

Also, could you please confirm what the daily broadcast time for the report is.


If you run the parent codisplay report manually and export it to Excel, is there data for the 5th report (i.e. does the issue only occur when broadcasting)?


And if the 5th report does indeed have data, what size is the excel file?


If the 5th report doesn't have any data, then if you manually run the 5th report and export to Excel, what size is the resulting file, and how many columns and rows is the report?

Also, debug logging may provide some clues here, so please turn on DEBUG logging just for the time of the daily broadcast (and don't forget to turn it off afterwards) and send across the debug logs.

Sorry for all these questions, but this issue is proving to be a bit of an elusive one!

regards,

David

photo
1

I have followed all of your suggestions and have had no joy so far.  I turned on debug logging and of course nothing failed today.  Is there a string I could search for in the logs to save time plowing through it?  for instance:  grep failure yellowfin.log

Thanks,

Steve

On 11/20/2018 5:51 PM, Support Queue wrote:

photo
1

Hi Steve,

if you did a case-sensitive grep for :ERROR (colon + ERROR) in the yellowfin.log files then that will collect the important entries.

I know that I asked quite a few questions last time, but if you do get a chance to answer them then it could prove helpful:


- Could you please confirm what the daily broadcast time for the report is.

- If you run the parent codisplay report manually and export it to Excel, is there data for the 5th report (i.e. does the issue only occur when broadcasting)?

- And if the 5th report does indeed have data, what size is the excel file?

- If the 5th report doesn't have any data, then if you manually run the 5th report and export to Excel, what size is the resulting file, and how many columns and rows is the report?


regards,

David

photo
1

Thanks for the search string.  There are six of these codisplay reports that go out 1-2x a day.  of those reports an average of 2 would have issues each day.  We staggered the broadcasts so they weren't all going out at the same time.  Still had issues.  Debug logging is turned on.  This morning at 9am the "alpha" broadcast went out.  of the 6 reports only 5 were included in the excel file.  The tab was completely missing for the "5/6" report.  I didn't see any errors in the log.  I did see that a backgroundrunner fired off the "5/6" report at 8:57:02.  But then no mention of it during the broadcast.  Attached is the log.

Answers to questions:

- Could you please confirm what the daily broadcast time for the report is.7am (now it varies)

- If you run the parent codisplay report manually and export it to Excel, is there data for the 5th report (i.e. does the issue only occur when broadcasting)?yes, runs in under a minute manually

- And if the 5th report does indeed have data, what size is the excel file?20-30kb

- If the 5th report doesn't have any data, then if you manually run the 5th report and export to Excel, what size is the resulting file, and how many columns and rows is the report?The file is 5kb

On 12/5/2018 8:09 PM, Support Queue wrote:

photo
1

Hi Steve,

thanks for the latest log and also for the answers to the questions - this time I think I've got it! But funnily enough, it wasn't from the latest log, I went back over the full set of logs because now that I know the time of the broadcast (7am) I could do better cross-referencing than I did last time I looked at them.

I found the following entries in the JDBC log:

2018-11-08 06:11:39   INFO: Connection[17] successfully reopened
2018-11-08 07:05:39  ERROR: Connection[6] checkout timeout exceeded
2018-11-08 07:05:39  ERROR: Connection[6] was checked out at 2018-11-08 07:00:00
2018-11-08 07:05:39  ERROR:    at com.hof.pool.DBConnectionPool.checkOutConnection(DBConnectionPool.java:1418)
2018-11-08 07:05:39  ERROR:    at com.hof.pool.DBConnectionManager.getConnection(DBConnectionManager.java:311)
2018-11-08 07:05:39  ERROR:    at com.hof.util.DBAction.<init>(DBAction.java:354)
2018-11-08 07:05:39  ERROR:    at com.hof.util.DBAction.<init>(DBAction.java:467)
2018-11-08 07:05:39  ERROR:    at com.hof.util.DBAction.<init>(DBAction.java:422)
2018-11-08 07:05:39  ERROR:    at com.hof.mi.servlet.ReportBroadcastTask.runBroadcastTask(ReportBroadcastTask.java:133)
2018-11-08 07:05:39  ERROR:    at com.hof.mi.servlet.TaskScheduler$_A.A(TaskScheduler.java:109)
2018-11-08 07:05:39  ERROR:    at com.hof.mi.servlet.TaskScheduler$_A.run(TaskScheduler.java:166)
2018-11-08 07:05:39  ERROR:    at java.lang.Thread.run(Thread.java:745)


2018-11-09 07:05:39  ERROR: Connection[10] checkout timeout exceeded
2018-11-09 07:05:39  ERROR: Connection[10] was checked out at 2018-11-09 07:00:00
2018-11-09 07:05:39  ERROR:    at com.hof.pool.DBConnectionPool.checkOutConnection(DBConnectionPool.java:1418)
2018-11-09 07:05:39  ERROR:    at com.hof.pool.DBConnectionManager.getConnection(DBConnectionManager.java:311)
2018-11-09 07:05:39  ERROR:    at com.hof.util.DBAction.<init>(DBAction.java:354)
2018-11-09 07:05:39  ERROR:    at com.hof.util.DBAction.<init>(DBAction.java:467)
2018-11-09 07:05:39  ERROR:    at com.hof.util.DBAction.<init>(DBAction.java:422)
2018-11-09 07:05:39  ERROR:    at com.hof.mi.servlet.ReportBroadcastTask.runBroadcastTask(ReportBroadcastTask.java:133)
2018-11-09 07:05:39  ERROR:    at com.hof.mi.servlet.TaskScheduler$_A.A(TaskScheduler.java:109)
2018-11-09 07:05:39  ERROR:    at com.hof.mi.servlet.TaskScheduler$_A.run(TaskScheduler.java:166)
2018-11-09 07:05:39  ERROR:    at java.lang.Thread.run(Thread.java:745)

and I won't paste them all here, suffice to say that there is the same error every day at 7:05:39

Now this error refers to the timeout of the application to the repository database (a.k.a. the configuration database or the Yellowfin database).

By default the timeout to the Yellowfin database is 5 minutes, so you should try increasing it by doing the following:

1) open web.xml for editing (beware, there are 2 such files in the installation, you want the one in the folder <yellowfin>\appserver\webapps\ROOT\WEB-INF)

2) go to the section called InitConnectionPool

3) add the following new parameter (because it is not in the file by default)


    <init-param>
      <param-name>JDBCTimeout</param-name>
      <param-value>1800</param-value>
    </init-param>
the unit of the value is in seconds, you may as well try 1800.

4) save the file and restart Yellowfin

Hopefully your broadcast co-display report will not lose its last report anymore.

Please let me know how it goes.

regards,

David

photo
1

Hey David,

I made the change to the web.xml file and restarted Yellowfin at 7:55am.  The 9am broadcast unfortunately had the same issue as yesterday.  report "5/6" did not get a tab in the excel file.  I attached the zipped logs.

FYI - I will be on vacation for a week, so don't be surprised if I don't respond immediately to further emails.

Thanks for your help,

Steve

On 12/6/2018 7:21 PM, Support Queue wrote:

Files: logs1.7z
photo
1

Hi Steve,

damn! That's disappointing, I felt certain this time we'd got it.

Unfortunately the latest jdbc.log stops before 9 AM, and that's the time I need to check, so when you get back from your break could you please send another full batch of logs, by then all of the different types of logs will cover Dec 7th 9 AM.

I hope you have a great vacation!

regards,

David

photo
1

Hi Steve,

I was re-assigned to this ticket; just wante dto check to see if you are still experiencing this issue?

Thanks,

Eric

photo
1

all fixed - it was a timeout issue - thanks!

On 6/13/2019 3:09 PM, Support Queue wrote:

photo
1

Glad to hear it Steve, I'll go ahead and mark this as Answered. Have a good weekend!

Best,

Eric

Leave a Comment
 
Attach a file