![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Lots of applications need to load and convert document files of different formats into other formats or into text.
You would have think that there would be a good solution to it.
Unfortunately it's not the case.
Existing solutions are either for desktop only, or buggy or extremely expensive (~$10K/year).
I thought I found a solution - DevExpress Document Server library for $599.99
Unfortunately, after running for couple of weeks it crashed my service with StackOverflowException exception:
----
https://www.devexpress.com/Support/Center/Question/Details/T257097
To my regret, there is no simple workaround to avoid this exception with your document. Regarding the time frame for fixing this issue, it is difficult to provide any estimate in such cases.
----
So now I need to find a way to prevent my service from dying in case if some random document is fed into it.
Sigh.
You would have think that there would be a good solution to it.
Unfortunately it's not the case.
Existing solutions are either for desktop only, or buggy or extremely expensive (~$10K/year).
I thought I found a solution - DevExpress Document Server library for $599.99
Unfortunately, after running for couple of weeks it crashed my service with StackOverflowException exception:
----
https://www.devexpress.com/Support/Center/Question/Details/T257097
To my regret, there is no simple workaround to avoid this exception with your document. Regarding the time frame for fixing this issue, it is difficult to provide any estimate in such cases.
----
So now I need to find a way to prevent my service from dying in case if some random document is fed into it.
Sigh.
no subject
Date: 2015-06-19 05:22 am (UTC)no subject
Date: 2015-06-19 08:00 am (UTC)Are memory leaks and occasional fatal crashes pretty much guaranteed?
no subject
Date: 2015-06-19 03:31 pm (UTC)It mean skewered tables and garbage in some places instead of text.
> Are memory leaks and occasional fatal crashes pretty much guaranteed?
For a .NET library on a web server? Of course.
no subject
Date: 2015-06-19 07:21 pm (UTC)That's not a serious problem.
The crashes that kill the whole process - that's what concerns me.
> For a .NET library on a web server? Of course.
Do you mean any .NET library on a web server crash es occasionally?
Or such crashes are specific to conversion of DOC files (due to old COM storage calls)?
I'm not sure about Web Server, because IIS automatically recovers with problems (so we might have not noticed) but our windows service did not exit due to crash for several years (and when it did it was our silly coding mistake).
no subject
Date: 2015-06-19 08:53 am (UTC)no subject
Date: 2015-06-19 11:20 am (UTC)1) Autorestart of our windows service in case of crash.
2) Remembering the hash of resume that crashed and do not convert it next time.
However that is only ok as an ugly patch, because our windows service runs many other processes in parallel to that document converter queue.
All these processes are terminated in the middle.
Another problem is that web site will also crash.
Fortunately IIS automatically recovers crashed thread, but still it makes me think that hard crashes like these can add instability to our system.
no subject
Date: 2015-06-19 11:31 am (UTC)no subject
Date: 2015-06-28 02:14 pm (UTC)1. PDF достаточно закрытый формат принадлежащий Адобе.
2. PDF весьма сложный (язык).
Примерно тоже самое с Microsoft Word - сложен и владельцы мудаки. И те и те не хотят делится, они хотя стать монополистами форматов.
Поэтому полноценных перефарматировщиков не жди.
Ищи маленькие конвертеры .dll от индусских программистов. Работают на 80% и это максимум.
no subject
Date: 2015-06-28 09:11 pm (UTC)Что значит, работают на 80%?
no subject
Date: 2015-06-30 03:55 am (UTC)