Back to Community Threads

1

DocumentUltimate: Error While loading a document in the document viewer

Problem reported by Ranjith Shetty - 5/11/2020 at 10:53 PM

Locked

Resolved

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

5/15/2020 at 1:16 AM

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:

http://support.gleamtech.com/community/a5129/receiving-javascript-error-when-attempting-to-view-certain-pdfs.aspx

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

5/27/2020 at 4:12 PM

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

5/27/2020 at 4:15 PM

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

5/27/2020 at 4:29 PM

Awsome..thank you. I will test and let you know.

0

Ranjith Shetty Replied

5/27/2020 at 4:32 PM

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

5/27/2020 at 4:51 PM

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

5/27/2020 at 4:58 PM

We actually use it for importing data from excel using oledb providers.

0

Ranjith Shetty Replied

6/3/2020 at 11:47 PM

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

6/3/2020 at 11:54 PM

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

6/4/2020 at 3:20 PM

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

6/17/2020 at 4:33 PM

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

6/21/2020 at 4:54 PM

Hello Team

Kindly assist on the same.

Regards

Ranjith

0

Cem Alacayir Replied

6/21/2020 at 10:55 PM

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

6/22/2020 at 3:48 PM

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

6/22/2020 at 4:30 PM

Hello Cem

Kindly note, before starting testing we did clear all cache documents.

Regards

Ranjith

0

Ranjith Shetty Replied

6/24/2020 at 5:07 PM

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

6/25/2020 at 12:46 AM

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?

https://demos.gleamtech.com/documentultimate/AspNetWebFormsCS/#DocumentViewer/Overview.aspx

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:

You should avoid repeated conversions by providing correct uniqueID for documents (same Id for same binary)
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
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

6/25/2020 at 3:27 PM

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

6/25/2020 at 3:28 PM

Hello Cem

In addition, this error is mostly occurring for images and pdfs.

Regards

Ranjith

0

Ranjith Shetty Replied

7/6/2020 at 7:48 PM

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

7/16/2020 at 3:29 PM

Hello Cem

We are still encountering the below error on concurrent users. Kindly assist on the same.

Regards

Ranjith

0

Cem Alacayir Replied

7/16/2020 at 11:10 PM

Employee Post

Please always confirm you are at the latest version:

https://docs.gleamtech.com/documentultimate/html/version-history.htm

There is especially a fix related to images in v5.3.0 but please update to latest v5.4.2.

0

Cem Alacayir Replied

7/18/2020 at 1:05 AM

Employee Post Marked As Resolution

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:

https://stackoverflow.com/questions/1053052/a-generic-error-occurred-in-gdi-jpeg-image-to-memorystream

0

Ranjith Shetty Replied

7/19/2020 at 5:04 PM

Thank you Cem, I will update the dev on your recommendations and get back to you.

0

Ranjith Shetty Replied

7/29/2020 at 8:11 PM

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

8/4/2020 at 3:58 PM

Hello Cem

This is a gentle reminder to advise on next steps. This is currently effecting our production environment.
Regards
Ranjith

Back to Community Threads

Related Knowledge Base Articles