You are viewing limited content. For full access, please sign in.

Question

Question

TemplateInfoReader Limit?

SDK
asked on October 1, 2019

I have a pretty standard TemplateInfoReader loop that is getting an error after reading the 64th Template.  That is a pretty suspicious number.  Is there some sort of limit on the number of Templates that can be returned, maybe for a given LF license type?  I have renamed Templates so they are processed in a different order and the error always occurs at whichever Template is 64th in order. 

 

TemplateInfoReader templates = Template.EnumAll(true, sessionWrapper.Session);

foreach (TemplateInfo template in templates) {}

 

The error is "Error reading HTTP response body"

1 0

Answer

SELECTED ANSWER
replied on October 10, 2019

I suspect you are encountering a bug in the SDK, but we need to get more information about your template/field definitions. It must be choking on a specific field, maybe because of characters in its name or some other property that can't be handled. Please open a support case so we can get the templates and fields exported from the admin console. This should help us reproduce and track down the problem.

0 0

Replies

replied on October 1, 2019 Show version history

Eric,

Are you using the SDK in a .NET application or are you scripting something in Workflow?  I cannot reproduce the error with a Workflow script on my system with 65+ templates.  I am running WF 10.2 and scripted this up;

    public class Script1 : RAScriptClass102
    {
        /// <summary>
        /// This method is run when the activity is performed.
        /// </summary>
        protected override void Execute()
        {
            TemplateInfoReader templates = Template.EnumAll(true, this.RASession);
            List<string> templateList = new List<string>{};

            foreach (TemplateInfo template in templates) {
                templateList.Add(template.Name);
            };

            this.SetMultiValueToken("TemplateList", templateList, true);
        }
    }

 

0 0
replied on October 2, 2019

Hi Cliff, thanks for the reply.  This is the SDK.  We have a number of customers with 65+ Templates and no issues, so I am wondering if it has something to do with the license.  This issue is happening in a UAT environment.

0 0
replied on October 2, 2019

Strange that it is not consistent.  I don't believe there is a template limit with any of the regular flavors of Laserfiche.  Is the site that is failing licensed similarly to any of the sites that run without error?

A couple of other thoughts;

  • Are you running the same version of the SDK in all of the sites? Same SDK runtimes installed at each site?
  • What happens if you try to reference a template index above 65 without going through the loop.  Do you get the same error?  i.e. TemplateInfo template = templates[65];
  • There is an overload of the EnumAll method that just takes the session as a parameter.  Does that error also?  Along the same lines does it matter if you change the preload parameter to false?
0 0
replied on October 3, 2019

There is no license limit on the template reader, you are encountering some kind of bug.

Try setting preloadFields to false and get each template individually, like this:

TemplateInfoReader templates = Template.EnumAll(false, session);
foreach (TemplateInfo template in templates)
{
    TemplateInfo template2 = Template.GetInfo(template.Id, session);
    // use template2 instead of template...
}

If that doesn't work, I think you will need to open a support case to provide us with logs.

0 0
replied on October 7, 2019

Thank you for the suggestion Robert.  I have implemented this approach and will get it tested out with the customer.

0 0
replied on October 10, 2019

I tried the change to preloadFields and got the same result.  Here is the stack trace.  

 

Laserfiche.HttpClient.HttpException
Laserfiche.HttpClient.HttpException: Error reading HTTP response body. ---> System.ComponentModel.Win32Exception: Unknown error (0x2efe)


   --- End of inner exception stack trace ---
      at Laserfiche.HttpClient.WinHttpResponseStream.HttpReadData(WinHttpHandle hRequest, Byte[] buffer, Int32 offset, Int32 count, Int32& bytesWritten)
   at Laserfiche.HttpClient.WinHttpResponseStream.DoRead(Byte[] buffer, Int32 offset, Int32 count)
   at Laserfiche.HttpClient.WinHttpResponseStream.Read(Byte[] buffer, Int32 offset, Int32 count)
   at System.Xml.XmlTextReaderImpl.ReadData()
   at System.Xml.XmlTextReaderImpl.ParseEndElement()
   at System.Xml.XmlTextReaderImpl.ParseElementContent()
   at System.Xml.XmlTextReaderImpl.Read()
   at System.Xml.XmlTextReader.Read()
   at Laserfiche.RepositoryAccess.LFXmlReader.Read()
   at Laserfiche.RepositoryAccess.FieldInfo.FromXml(XmlReader reader)
   at Laserfiche.RepositoryAccess.TemplateInfo.FromXml(XmlReader reader)
   at Laserfiche.RepositoryAccess.TemplateInfoReader.Read()
   at Laserfiche.RepositoryAccess.LaserficheObjectReader`1.Enumerator.MoveNext()

0 0
SELECTED ANSWER
replied on October 10, 2019

I suspect you are encountering a bug in the SDK, but we need to get more information about your template/field definitions. It must be choking on a specific field, maybe because of characters in its name or some other property that can't be handled. Please open a support case so we can get the templates and fields exported from the admin console. This should help us reproduce and track down the problem.

0 0
replied on October 25, 2019

I had the customer export the Template/Field definitions.  I did not encounter the error after importing the 100+ Templates.  We also did not encounter the error on the customer's server the next time we tried to iterate through the Templates.  So I'm not sure what happened or why it is now resolved.  I did notice that the customer's server iterates through the Templates quite slowly.  On my server and on other customer's servers the Templates are processed very quickly.

0 0
replied on October 25, 2019

This sounds almost like a proxy or firewall interfering with the connection. The template enumeration is one of the fastest possible requests, the database query is simple. If the error happens again, you could try using Wireshark to monitor the network traffic for aborted TCP connections.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.