We seem to have a problem with the DSC. Occasionally an error occurs when saving a very large QVD file.
In the EventLog you can see that at the same time the distribution service cannot access the DSC.
DSC Service is offline.
But the DSC service still seems to be running. There was no message that the service was stopped. Furthermore you can see on the Active Directory server that the Kerberos authentication has expired and has been renewed. The question I ask myself is, does the expiration of the Kerberos authentication lead to the DSC not being reachable? Does the inaccessibility of the DSC lead to a QVD file not being created?
Thanks for the support.
I'm far away from being an expert to such stuff but I think loosing the authentication is a serious issue. Does it happens more often or only sometimes by storing this large file?
Beside this it might be useful to slice the file into several smaller ones ...
the issue happens once a week with the large QVD file. We see the Event on the Active Directory Server that the account has been logged off.
and then we get the warning
And then the error
The Source Document was NOT reloaded successfully. DocumentPath=D:\QlikView Storage\Private Data\In_Production\Generator_Sales_EDI.qvw.
The task "RT Generator Sales EDI #CO_S" failed. Exception: || QDSMain.Exceptions.TaskFailedException: Task execution failed with errors to follow. ---> QDSMain.Exceptions.ReloadFailedException: Reload failed ---> QDSMain.Exceptions.LogBucketErrorException: The Source Document was NOT reloaded successfully. DocumentPath=D:\QlikView Storage\Private Data\In_Production\Generator_Sales_EDI.qvw. || at QDSMain.AbstractReloadTask.VerifyConditions(IExecutingTaskResult executingTaskResult) || at QDSMain.AbstractReloadTask.Reload(String fileName, IExecutingTaskResult executingTaskResult, String sectionAccessUserName, String sectionAccessPassword, eReloadOptions reloadOption, String variableName, String variableValue, Boolean moniterCpuUsage) || --- End of inner exception stack trace --- || at QDSMain.AbstractReloadTask.Reload(String fileName, IExecutingTaskResult executingTaskResult, String sectionAccessUserName, String sectionAccessPassword, eReloadOptions reloadOption, String variableName, String variableValue, Boolean moniterCpuUsage) || at QDSMain.DistributeTask.PerformExecute(IExecutingTaskResult executingTaskResult) || --- End of inner exception stack trace --- || at QDSMain.DistributeTask.PerformExecute(IExecutingTaskResult executingTaskResult) || at QDSMain.Task.AbstractTask.TaskExecution(CurrentExecutionArgs args)
It's just guessing - the storing of this large file prevents the authentication-check which is probably repeated each n (milli) seconds (maybe with a further loop to trial it n times) before it failed with an error-message and the qds-error is then an aftereffect ... I assume this may be configured in some way but slicing the qvd might be a more practically approach.
If in fact you are running 12.30.20300, I would highly recommend you update to the SR9 release, which is build 21000, as the SR you are running did have known stability issues etc., and that is most likely what you are experiencing I believe, so I would say update first, then proceed from there if the issue persists in this case. If there is a problem with your LDAP/Directory, that could cause the DSC to have issues as well, so I would also check to be sure with the Directory team what may be going on with the access to it too.
You said QVD in your post, but you are actually reloading a QVW and I assuming you are also trying to distribute it via Publisher after the reload, and in that case the QDS/Publisher must have access to the DSC in order to lookup the users/groups designated to have access to the QVW file in order to validate them, so if that fails, the distribution will fail.
Hopefully this helps, shout if you have questions.