Reporting module: Queued report never finish. Exception in


I am trying to run Reports on OpenMRS via Reporting module. The report result set returns data when run directly from data-set-definition or report preview, however, when report is queued it just keep running in queue forever. The data set is not huge and query has been tested. However, an exception is seen in openmrs.log which can be seen here (

The versions of openmrs components are below

  • OpenMRS : 1.11.5
  • Serialization Xstream : 0.2.12
  • Reporting : 1.13.0
  • Rest Web Services OMOD : 2.17.1cd94b
  • Calculation : 1.2

Surprisingly this issue doesnot occur on Linux server but our Windows server is throwing this issue. I also tried installing reporting rest module but that didnot help.

I am uanble to figure out what could be the possible cause of issue because I am using admin account to run report, I also explicitly gave all ‘Get.*’, and other reporting privileges to a role and assigned it to admin user.

Hi @maimoonak,

I ran into a similar problem on a client’s server recently. The issue was the scheduler password Global Property (Advanced Setting). I see in the log it’s complaining “Basic authentication required”. To check the scheduler username/password, go to Administration --> Advanced Settings. Look for the following settings and ensure they have values that work (the account specified is able to run reports)… scheduler.username scheduler.password

As a test, you could use your admin credentials.

Thanks @arbaughj , this gives the clue but changing user and password didnot solve my problem.

I have tried all following steps but problem still persists:

  • Change properties`s user and pwd to admin account and try running report
  • Stop and start tomcat and try running report
  • Clean openmrs work and temp dir and run report again
  • Create a new account and give explicitly all report permissions and system developer role and and try running report
  • Gone through openmrs runtime properties but nothing found that could have overridden the settings in global_setting table
  • Gone through all relevent report tables but no report definition contains the values for user account that could have overridden the properties in global_setting table

The openmrs deployment was done from an existing database and the values for scheduler were admin:test i.e. default openmrs credentials (these had been changed from change password section after deployment on production server and may have not updated in scheduler settings).

Is there any possibilty that this has been hardcoded anywhere in code? Is there a way to override/bypass the basic authentication in scheduler? Is there a way to run report without passing it to scheduler or reporting task? We just need to download a CSV on the fly.

We have been using reporting module since long and never faced this issue. Would it help to downgrade the module?

Sorry you’re still having problems getting your report to run. I’m out of ideas. This might be a problem @mseaton could help you with.

@maimoonak did this happen only after upgrading the module? In other words, if you temporarily reverted to the older version that you were using, does the problem disappear?

Hi @dkayiwa,

No this happened when we installed openmrs from an existing database copied from another server. And admin password was changed. Initially we were using reporting-1.12.x and after facing this issue we upgraded to reporting-1.13.0. I also tried reporting-0.9.x which we are using for another project but that caused some checksum issues with liquibase.

FYI - @arbaughj and @maimoonak, the reporting module no longer uses the scheduler.username and scheduler.password properties, but rather runs all scheduled tasks as the daemon user. As described, the daemon user has all privileges - it is essentially a root user. So I would not expect to see any privilege issues causing problems here (though I do agree that this is what the log shows).

Could you change the log level to debug on org.openmrs.aop.AuthorizationAdvice and see if this provides any more information that could be helpful in the log?

Thanks, Mike

@mseaton, Thanks alot for helping us out in this issue.

It was mistake from our end. Someone had deleted daemon user from DB while cleaning test data which offcourse is a sin. We tried adding daemon user directly from DB but it didnot help. Then we found out that daemon user has to have uuid ‘A4F30A1B-5EB9-11DF-A648-37A07F9C90FB’ which is coded in this class .

As soon as the uuid was added to daemon in DB our report finished successfully.

Thanks again…