Did you find this guide helpful?
Some test text!
Web / FAQ / Common Issues
WebViewer Server requires that you place your key in both
On the client side the key would be used like so:
WebViewer({
licenseKey: 'Company info::The Apryse license info::Testing::More info::123',
path: '...'
}).then((instance) => {
})On the server side, place the key in your docker-compose.yaml file under pdfd-tomcat > environment:
pdfd-tomcat:
environment:
TRN_PDFNET_KEY: 'Company info::The Apryse license info::Testing::More info::123'
...If you are using the Windows installer, you would place the key within the wvs_config.json as detailed here .
There are generally 2 possible reasons for this at an infrastructure level:
Often custom work will have to be done to ensure Websocket connections are not broken during communication, this means adjusting options related to:
When dealing with stickiness, WebViewer Server comes with its own built in stickiness when using the 'wvs-loadbalancer'. This stickiness appends a BCID to all outgoing requests. This BCID is changed as new documents are opened. Our load balancer watches for this parameter and keeps a client stuck to a server corresponding to this ID until they change their current ID.
The network load balancer does not support Websockets, however, the classic and application balancers do.
If using the classic load balancer all communication will have to be done over SSL and TCP ports rather than HTTP and HTTPS. This is because this balancer does not provide native support for Websockets.
If the links you're providing to WebViewer Server do not have a file extension, you may need to pass an extension. This would need to be passed as an argument to loadDocument ext option or through the formatting of the file name. Otherwise WebViewer Server will treat it as if it were a PDF and act accordingly.
Ensure that the document you are sending is accessible from the remote location you are requesting it from WebViewer Server's hosted location.
If it cannot retrieve the document, this may be because authentication is incorrect or the file is not physically accessible from WebViewer Server.
You can verify if it's physically accessible by requesting the file from your WebViewer Server host.
If authentication is the issue, you may find our cookie forwarding options or custom headers options helpful.
You may need to reconfigure your caching options. The default behaviour for WebViewer Server's caching can be found here . We still recommend at least 50GB of disk space to ensure that disk space cannot be consumed faster than the server can produce it.
It's possible that your docker images have taken up too much disk space, you can clear unused docker image space by running the docker system prune command. You may also see what space is used by calling docker system df.
It is also possible your host system has configured for very verbose core dumps. This means when the application crashes, WebViewer Server will generate a massive debugging file > 1 GB. These are not managed or deleted, so they may consume a large amount of disk space. The following website details how to configure core dumps and prevent this behaviour.
https://linux-audit.com/understand-and-configure-core-dumps-work-on-linux/
This may mean that you are running WebViewer as a client only. This can occur if the webviewerServerURL entry is not added to the WebViewer constructor. Ensure that the argument is present and pointing to the correct server.
Password protected documents were not supported until version 1.5.7 and WebViewer 8.1. Ensure you are using a WebViewer version >= 8.1 and a WebViewer Server version >= 1.5.7
Get the answers you need: Chat with us