-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to asynchronously generate PDFs #65
Conversation
e676eae
to
a1e9bb0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really convinced that the usage of Promise\Deferred is correct. I don't know what's correct nor have I ever used one myself (as mentioned offline) but it looks wrong. Will look into this tomorrow to see if I'm right.
5f08ecb
to
f2c8ca5
Compare
5e63f0c
to
3be4f74
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't test the asynchronous variant. I guess you did that thoroughly yourself. 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
be6be0a
to
8e7ff15
Compare
The current implementation of
HeadlessChrome::toPdf()
always assumes that it controls the event loop instance, i.e.HeadlessChrome
creates and starts the event loop manually. This may work for most use cases as they are mostly triggered via Icinga Web, but not if you want to generate PDFs using a daemon. Since our scheduler uses the same global event instance, it is unfavourable to callFactory::create()
over again occasionally.refs Icinga/icingaweb2-module-reporting#229