1
DocumentUltimate: Error While loading a document in the document viewer
Problem reported by Ranjith Shetty - 5/11/2020 at 10:53 PM
Submitted
Hello Team
 Please find below the errors we are encountering on our production site when loading some of the document  via document viewer. We are able to download the document via the browser with no issues. Kindly advice on the same. I would be obliged if you could help on resolving this issue.



Please note our website is not on the cloud it is deployed into an on-premise server.

Regards
Ranjith

26 Replies

Reply to Thread
0
Cem Alacayir Replied
Employee Post
“Bad Allocation” usually means you are out of memory. 

For some complex documents, 32-bit process’ 2GB limit is reached so conversion may fail. 
Even if you have 16GB RAM, 32-bit process can use only 2GB. 
So if you enable 64-bit IIS Express, the conversion will probably succeed. 
Please see my last answer here for how to enable 64-bit IIS Express for Visual Studio:

When you publish to IIS (regular full IIS not IIS Express), by default it already runs the process in 64-bit mode:

Check if your IIS Application Pool is set to use 32-bit (Enable 32-bit application in Advanced Settings) When you turn it off (the default setting is off), your IIS Application Pool will run in 64-bit.
0
Ranjith Shetty Replied
Thank you very much for your reply. Is there any other way of resolving this? We need 32-bit to be enabled on our IIS app pool as we need bulk upload . Is there any other resolution for the same?

In addition we are encountering the below error also

0
Cem Alacayir Replied
Employee Post
Please update to latest Version 5.2.5 - May 22, 2020 which has some stability improvements and let me know.
0
Ranjith Shetty Replied
Awsome..thank you. I will test and let you know.
0
Ranjith Shetty Replied
In addition, we cannot enable our app pool to 64 bit because we have a microsoft component access databaseengine. If we don't allow 32bit apps via IIS, this will not work :(.


0
Cem Alacayir Replied
Employee Post
As far as I know, Access database (Jet engine) for web applications was deprecated by Microsoft long time ago. Maybe you should consider SQL Server Express (free license).
0
Ranjith Shetty Replied
We actually use it for importing data from excel using oledb providers.
0
Ranjith Shetty Replied
Hello Cem
      We tried changing the setting to 64 bit, we are still getting the same "Download File part" error. Kindly advise.
Regards
Ranjith
0
Cem Alacayir Replied
Employee Post
Which version are you using? FYI, Version 5.2.8 - June 3, 2020  is just released and it fixes some issues for conversion/viewing of image files, please test.
0
Ranjith Shetty Replied
We bought the product around Jan 2020. I will ask the team to update to Version 5.2.8 - June 3, 2020  and keep you posted.
Regards
Ranjith
0
Ranjith Shetty Replied
Hello Team/Cem
    We have upgraded our gleamtech nuget to Version 5.2.8 - June 3, 2020. In addition we have set our app pool also at 64 bit. We are still encountering the below errors





Kindly assist on the same. 

Regards
Ranjith
0
Ranjith Shetty Replied
Hello Team
 Kindly assist on the same.
Regards
Ranjith
0
Cem Alacayir Replied
Employee Post
"Downloading file part error" and "HTTP 502: Proxy Error" are different errors if you get them alone. Ensure you don't have any kind of Firewall blocking HTTP requests. Also delete the corresponding cache subfolder for that specific document to force re-conversion (it could have cached a corrupted file due to errors in previous versions).
0
Ranjith Shetty Replied
Thank you Cem. I will check and get back to you on our findings. If we still encounter issues, is there anyway we can get one of the gleam tech dev team members to triage via a screenshare with our dev team? Please let us know if there is any additional support costs we would incur for the same. 
Regards
Ranjith
0
Ranjith Shetty Replied
Hello Cem
     Kindly note, before starting testing we did clear all cache documents.
Regards
Ranjith
0
Ranjith Shetty Replied
Hello Cem
This is a gentle reminder to advise on next steps. This is currently effecting our production environment.
Regards
Ranjith

0
Cem Alacayir Replied
Employee Post
You are not clear, does the problem happen for all document formats or only specific document formats?
If specific, did you test them on our live demo here?

As I said "Downloading file part error" and "HTTP 502: Proxy Error" are not conversion related errors. You probably have something in your project (UrlRewrite?) or in-between your environment (like a firewall or proxy) that overtakes HTTP requests and changes them and causes the error. Please check that and monitor your network tab in your browser's console.

With clean cache subfolder for a document, the first error you get is important because only then you will know if it's a conversion error or not, for example do you still get "bad allocation" error?

For reference, for stability and performance you should pay attention to these best practices: 

  1. You should avoid repeated conversions by providing correct uniqueID for documents (same Id for same binary)

  2. You can pre-cache documents for example when a user uploads the file. So then DocumentViewer can open instantly:
    https://docs.gleamtech.com/documentultimate/html/pre-caching-documents.htm

  3. You should not create multiple DocumentCache instances for every request. You should set DocumentWebConfiguration.Current cache related properties once your app starts not in every page request.
0
Ranjith Shetty Replied
Hello Cem
 I will discuss your recommendations with the team and check if they have followed the guidelines in the implementation.  

Please note we have seen the below errors occurring more frequently when there are concurrent users 

  • "Downloading file part error"  

In addition, since we have a number of users using the document viewer, we are clearing the cache often as we run out of disk space very soon if we do not do the same.

We also get the below error when uploading a 32MB image file.



It looks like when the viewer is saving on the disk the memory spikes.

I will run some tests on the demo url provided also. Is there anyway I can arrange a call for the same please with your dev team.

Regards
Ranjith
0
Ranjith Shetty Replied
Hello Cem
  In addition, this error is mostly occurring for images and pdfs.
Regards
Ranjith
0
Ranjith Shetty Replied
Hello Cem
   We encountering the below error when concurrent users are viewing different image documents of  3.5 MB - 5 MB  in size. We have about 50 concurrent users.

We are not able to replicate this issue in our testing environment.

  

Kindly advise on a solution for the  same. We are on the Version 5.2.8 - June 3, 2020.

Regards
Ranjith
0
Ranjith Shetty Replied
Hello Cem
 We are still encountering the below error on concurrent users. Kindly assist on the same.

Regards
Ranjith
0
Cem Alacayir Replied
Employee Post
Please always confirm you are at the latest version:

There is especially a fix related to images in v5.3.0 but please update to latest v5.4.2.
0
Cem Alacayir Replied
Employee Post
By the way, "A generic error occurred in GDI+" error comes from System.Drawing.
Currently DocumentUltimate uses System.Drawing.Image.FromStream to load images which will be converted to PDF. This is mainly done for fixing EXIF orientation easily and for supporting uncommon TIFF formats.

for a lifetime of an Image constructed from a stream, the stream must not be destroyed.
So do you provide a stream to DocumentViewer or how are you loading the input file?
For example if you are implementing IDocumentHandler interface, you should not dispose that stream after you return it in OpenRead method. Or are you returning a MemoryStream?

Reference:
0
Ranjith Shetty Replied
Thank you Cem, I will update the dev on your recommendations and get back to you.

0
Ranjith Shetty Replied
Hello Cem

 The team is still analysing the code. In addition, we have a number of users using the document viewer. We encounter the below error intermittently even for files size of 4MB.

Once the users stop using the viewer, the memory settles down and the user are then able to continue with the viewer after 2- 3 hrs.






It looks like when the viewer is saving on the disk the memory spikes. Any advise on this behaviour.

Regards
Ranjith

0
Ranjith Shetty Replied
Hello Cem
   This is a gentle reminder to advise on next steps. This is currently effecting our production environment.
Regards
Ranjith 

Reply to Thread