NPrinting Nov 2020 metadata reloads stay in Running status

[kdmarkee]

We recently upgraded to NP Nov 2020 and QlikView April 2020 SR2 and I am observing 2 things with NP metadata reloads:

1) progress always seem to show 0%, even for reloads that work - is this normal?

2) some reloads are not working - is there a app size limit by chance in which a metadata reload will work?    I have tested 2 metadata reloads... one was 196 kb and the reload was successful in 10 mins, the other is 339 kb and this one stays stuck in "Running" status when I expect it to finish in at least 15-20 mins based on the experience of the other reload.  Never had an issue with app size before.  And yes, both apps pass the "Verify Connection" test.  I don't find the logs helpful either.

[Ruggero_Piccoli]

Hi,

Try to upgrade to QlikView 12.50 SR3.

Be sure that the connected QVWs has not unsupported features like macros, always one selected or triggers. 

Be sure you are not using a QlikView leased license from a server. You must use a named CAL or a license key with control number for each Qlik NPrinting Engine. 

You could also enable the debug mode for logs to check if there are specific errors.

Best Regards,

Ruggero

[kdmarkee]

I was able to figure out what NP did not like about my app.  Basically, once I had a filter value selected in my app, saved it, and then deployed it to Access Point, NP liked having a filter on vs when I did not have any filters selected at all prior to deployment to Access Point. (maybe NP treats a filtered app as if it were a smaller app?)   And here is how I stumbled upon this... this was one of 3 apps that get distributed via Simple Reduce tasks in the QMC from a single QVW.  In that single source QVW I did have a year filter selected with 2020, and saved, prior to deploying my 3 apps.  Well, the problematic NP metadata reload was on the app where the Simple Reduce was for years older than 2017 (meaning it lost the filter selection of 2020 since it did not exist), but the metadata reload for the other 2 apps worked just fine (one being even larger than the problem one, by the way).  So I used a different field to make a selection on, one that exists in all 3 of my deployed apps regardless of the filters I had set in my Simple Reduce tasks, and once I did that, all 3 successfully reloaded their NP metadata.   An interesting find, but I can't help but wonder if that is by design or a bug.

[Lech_Miszkiewicz]

Very interesting find Kris. I am glad you get it all figured out and I bet you it is very valuable lesson for many of us. Personally I have never experienced anything like this before and I am sure I would be scratching my head on why this is not working. 

thanks for detailed explanation!

@Ruggero_Piccoli - do you think this is something R&D could replicate now and test?

[Ruggero_Piccoli]

Hi,

I suspect there is something wrong in the QVW that is generating the issue. I suggest to set the logs to DEBUG level, reproduce the issue and check if there are specific error messages. 

When a QVW is not using unsupported features like "Always one selected" option the Qlik NPrinting caching process will remove all filters saved before generating the cache. The Access Point doesn't impact on the cache generation.

Best Regards,

Ruggero

[kdmarkee]

I did not find any unsupported items in my qvw, and I even ran a few more tests to solidify my earlier findings. 

I took my qvw (which has 4 years of data loaded into it) and ran the following scenarios and got the following results (app size is 510 kb):

• No selections made in the app prior to deploying to Access Point – NP metadata reload was still running 2 hrs later, so I aborted it
• Made a selection in a field in the app and saved that selection prior to deploying to Access Point – NP metadata reload took 30 mins to complete

I then took that same qvw but only loaded 2 full years of data into it and ran the following scenarios and got the following results (app size is 265 kb):

• No selections made in the app prior to deploying to Access Point – NP metadata reload was still running 50 mins later, so I aborted it
• Made a selection in a field in the app and saved that selection prior to deploying to Access Point – NP metadata reload took 25 mins to complete

The final test: I then took that same qvw but loaded a very small subset of data into it and ran the following scenarios and got the following results (app size is 38 kb):

• No selections made in the app prior to deploying to Access Point – NP metadata reload took 2 mins to complete

There might be some other obscure thing playing into this, but I have yet to find it.  There’s just no denying however that the same sized qvw deployed with and without a selection are not behaving the same way with regards the NP metadata reload.

[Lech_Miszkiewicz]

very strange Kris, such small app taking so long to (few kilobytes as you say 30kb-500kb). You can run this on the min spec laptop. There is clearly something wrong with this app or environment if you get such results. Creating empty app is already taking few kb so I am not sure how it is possible....

[Ruggero_Piccoli]

Hi,

Do you have issues only with this specific QVW?

Best Regards,

Ruggero