Connection metadata reload "randomly" fails with error NPrinting Engine failed to open document

[Patrizia]

Hi everyone!

Do any of you ever experienced random connection metadata reload errors? NPrinting Engine failed to open document

Given the same qvw file (no changes), one time fails and the next succeeds:

Heres my spec:

NPrinting version: Sept 2018 SR2

Server: dedicated machine, 32GB ram, avg used memory 20%

Connection Type: Local

Section Access in document: No

Connection Verification: Success

Reload Trigger: Daily

I can solve by attempting a new manual reload but it is annoying because we run daily reports that must rely on updated information out of the qlikview dashboards.

Please let me know if you have any ideas, thanks in advance!

[Natalija]

Hi,

Please check if service account that executes tasks is not loosing qlik licence/user CAL.

I have this error if alternate states or section access are inside app.

[Patrizia]

Hi thanks for your reply.

The qlikview client installed on the nprinting machine is using a named license (I did "open i server" + configured the license server url to make it automatic).

The document has no section access in it, no alternate states and no triggers defined (it is a dedicated dashboard for nprinting purpose).

The most strange thing is that one time it fails and the next (a minute later) it succeeds with no changes to the document or license, by just hitting the "Reload metadata" button from the np web interface.

Hope this make sense, thank again for reading this

[Frank_S]

In addition to @Natalija  helpful comments, check if you have any macro's that might be interfering.

Also consider this, it seems that since it works on the second attempt but not on the first, this 'might' indicate an 'on open' trigger so please doublecheck all document as well as sheet triggers.

For a complete end to end checklist see the following: https://support.qlik.com/articles/000026081

Also check if the NP engine that is installed is the same version as the NP server. If they are not the same, this would most likely be the cause of the issue if the above has been checked and verified.

Hope this helps...

[Patrizia]

Hi Frank thanks for your reply and apologies for the delay.

I've checked the document for trigger and been through the checklist, no findings unfortunately. It is a very basic document made to be used only by nprinting.

I've checked nprinting server version vs engine and they match (exact build).

As a work-around I've scheduled a task that will restart the Nprinting Engine windows service right before nprinting cache generation.. hopefully it will forcefully release all the open documents.

If anyone has other ideas / things to be checked they are welcome

Have a nice day

[Ruggero_Piccoli]

Hi,

Could be an issue of lack of resource. Could you run a cache generation while you are checking the Windows task manager and see if CPU and RAM are fully used.

Check the tasks executions page and the log files. It could also be useful to move to the debug logging level and verify if there will be error messages.

Best Regards,

Ruggero

[Patrizia]

Hi Ruggero, thank for your reply.

I've manually executed the cache generation while checking the task manager:

average cpu utilization 40% (8 core xeon e7-4807 seen from within the vm)

average memory utilization 11% (3.5/32GB)

Page execution logs in case of the "randomic" failure says "Cache generation failed: NPrinting Engine failed to open document. Check logs for details."

I've now enabled a performance collector and set engine logs to debug level. I'll let the system run for the next days and if the "randomic" failure occurs I'll be able to check the system utilization and post the debug logs.

Thank you

[Patrizia]

Hi everyone!

It happened again today while it was recording system performances and with debug level logs:

- Task started at 08.00 and ended after less than a minute

- Error is the same: Cache generation failed: NPrinting Engine failed to open document. Check logs for details.

System performance (5 seconds samples) during connection cache reload:

I've then tried to read the debug logs but unfortunately I can't understand them.

I'm attaching both the complete performance collection logs and the nprinting engine debug logs related to the failed task execution.

Hope anyone can help, thanks in advance for your time in reading this

[Frank_S]

Hi @Patrizia 

I still feel you 'may' have an unsupported item like a sheet and or a document triggers. Possibly an 'always one selected' property enabled for a list box or multi-box in your QVW. I suggest checking again. We often find these upon further examination of the QVW.  ALL of them must be removed, then reload the NP metadata connection. I would suggest restarting the entire NP server as well to ensure all QVW connections are fully shutdown in the background service before reloading the metadata.

If you still find the issue after confirming no unsupported items, I suggest starting a support ticket with your support partner or the Qlik Support desk as per your maintenance agreements.

[Natalija]

Hi,

How many times per day your NP app reloads, and how many times you are distributing NP reports?

Our environment works like this:

Our reloads are happening on QA server then once it's done robocopy will copy NP apps to PROD server. NP has dedicated server and is connected to PROD server (physically NP apps are located on PROD server). Once i had issue that while robocopy was running from QA to PROD, PROD server went down, as result apps weren't copied to PROD. When NP Reload tasks started run, they failed, because source=PROD server was down.

If your environment is set up in similar way, maybe server is loosing connectivity ?Or your NP apps are located on NP server locally?