-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
inconsistent no-reply with PDF translation + workaround #14
Comments
Hi, first I would like to explain why we are using Another thing raises even more questions to me. The three asynchronous functions which you started to call on your own contain awaited calls with
I've tried to reproduce the issue and came up with (I am no native VB.NET programmer, so please bear with me): Imports System.IO
Imports DeepL
Module Module1
Sub Main()
Translate().Wait() ' Blocking call because I don't know how to do an async Main in VB.Net
End Sub
Private Async Function Translate() As Task
Dim translator = new Translator("[Private]")
Await translator.TranslateDocumentAsync(
New FileInfo("C:\[Private].pdf"),
New FileInfo("C:\[Private]_translated.pdf"),
"de",
"en-US").ConfigureAwait(false) ' I also tried without ".ConfigureAwait(false)" with same result
End Function
End Module I couldn't reproduce the issue. But it took quite a while until completion. I would need to ask a colleague if that matters, but I suspect that processing a PDF takes more time compared to our other supported file formats. But of course I also don't know how long you have waited. In conclusion, unfortunately, I can't tell you the reasons why it won't work. I have the suspicion that it coincidentally looks as if If that would help you, we could extend our library to be configurable by the |
Thanks Dieter,
indeed translating PDFs takes time - in all cases I waited long enough (>10 minutes where usually 3-4 minutes in case of a successful translation).
Note that: - I am translating multi-threaded: all documents in a folder are uploaded, translated and downloaded in separate threads.
- using .NET Framework 4.8.4480.0
Adding .configureAwait(false) to the 3 separate procedures does not seem to make a difference. It works consistently whereas the single call to TranslateDocumentAsync was not consistent.
Note that I cannot test to much because my quote gets depleted to quickly (50k characters per document).
regards, klaas
… Op 29-03-2022 18:55 schreef dieter-enns-deepl ***@***.***>:
Hi,
first I would like to explain why we are using ConfigureAwait(false). It is the recommended way for avoiding the potential of deadlocks in libraries. Functionally, ConfigureAwait(false) should just allow for continuations (code after the await) to be executed from another synchronization context than the one which called the async function in the first place. So on paper, using ConfigureAwait(false) should be safer than leaving it out. If you are interested to learn more about this topic, I recommend you following article which explains it in more details and better than I ever could: https://devblogs.microsoft.com/dotnet/configureawait-faq/#why-would-i-want-to-use-configureawaitfalse
Another thing raises even more questions to me. The three asynchronous functions which you started to call on your own contain awaited calls with ConfigureAwait(false) themselves:
* https://github.com/DeepLcom/deepl-dotnet/blob/aad27b1d7c4accc6ce84036e6398786f58c81d0e/DeepL/Translator.cs#L315-L336
* https://github.com/DeepLcom/deepl-dotnet/blob/aad27b1d7c4accc6ce84036e6398786f58c81d0e/DeepL/Translator.cs#L373-L385
* https://github.com/DeepLcom/deepl-dotnet/blob/aad27b1d7c4accc6ce84036e6398786f58c81d0e/DeepL/Translator.cs#L438-L451
Coincidentally, it is even three calls with ConfigureAwait(false) each, too (just as a side note; the amount shouldn't matter much). So if the ConfigureAwait(false) is the thing which causes the faulty behavior in the single TranslateDocumentAsync-call, I wonder, shouldn't it cause trouble in the functions TranslateDocumentUploadAsync, TranslateDocumentWaitUntilDoneAsync & TranslateDocumentDownloadAsync as well? That riddles me.
I've tried to reproduce the issue and came up with (I am no native VB.NET programmer, so please bear with me):
Imports System.IO Imports DeepL Module Module1 Sub Main() Translate().Wait() ' Blocking call because I don't know how to do an async Main in VB.Net End Sub Private Async Function Translate() As Task Dim translator = new Translator("[Private]") Await translator.TranslateDocumentAsync( New FileInfo("C:\[Private].pdf"), New FileInfo("C:\[Private]_translated.pdf"), "de", "en-US").ConfigureAwait(false) ' I also tried without ".ConfigureAwait(false)" with same result End Function End Module
I couldn't reproduce the issue. But it took quite a while until completion. I would need to ask a colleague if that matters, but I suspect that processing a PDF takes more time compared to our other supported file formats. But of course I also don't know how long you have waited.
In conclusion, unfortunately, I can't tell you the reasons why it won't work. I have the suspicion that it coincidentally looks as if .ConfigureAwait(false) is the influencing factor. However, I have yet no clue what other reason might cause the faulty behavior in your case. Sorry.
If that would help you, we could extend our library to be configurable by the TranslatorOptions of whether false or true should be passed to .ConfigureAwait(bool) with false as default for backward compatibility. Functionally, .ConfigureAwait(true) should behave neutral and as if .ConfigureAwait(bool) wasn't used in the first place.
—
Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXR5UCQXFXLVLRG5ZRG6WILVCMYXDANCNFSM5RRK6PQQ>.
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AXR5UCUWDWCK4GI4YBINGQTVCMYXDA5CNFSM5RRK6PQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIB77CIA.gif>Message ID: ***@***.***>
|
Hi Klaas, Thank you for testing the issue on your side. Regarding the quota, we can cancel those document translations from your quota. To do so we need to identify your account, could you please contact our support team? |
Hi Daniel, that would be great. It’s this email address I am mailing from ***@***.*** ***@***.***> )
Regards, Klaas
From: Daniel Jones ***@***.***>
Sent: Monday, 4 April 2022 15:37
To: DeepLcom/deepl-dotnet ***@***.***>
Cc: boeryepes ***@***.***>; Author ***@***.***>
Subject: Re: [DeepLcom/deepl-dotnet] inconsistent no-reply with PDF translation + workaround (Issue #14)
Hi Klaas,
Thank you for testing the issue on your side. Regarding the quota, we can cancel those document translations from your quota. To do so we need to identify your account, could you please contact our support team <https://support.deepl.com/hc/en-us/requests/new> ?
—
Reply to this email directly, view it on GitHub <#14 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXR5UCXES6Z6D7BIFO5KFHTVDLV6VANCNFSM5RRK6PQQ> .
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AXR5UCT42QNKWHL7ZOK7H2TVDLV6VA5CNFSM5RRK6PQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIDJPLZY.gif> Message ID: ***@***.*** ***@***.***> >
|
Hi Klaas, |
it's ***@***.******@***.***
… Op 05-04-2022 15:45 schreef Daniel Jones ***@***.***>:
Hi Klaas,
Your email address is censored in your messages; I guess that GitHub censors your email address when you reply via email.
Regards,
Daniel
—
Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXR5UCXLZ2ATLYUFOLFTCJ3VDQ7YZANCNFSM5RRK6PQQ>.
You are receiving this because you authored the thread. <https://github.com/notifications/beacon/AXR5UCVI72DZTRKRYCEFU6TVDQ7YZA5CNFSM5RRK6PQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIDSJUJA.gif>Message ID: ***@***.***>
|
Hi Klaas, Please send an email to open-source@deepl.com, so I can use your email address to identify your DeepL account. |
hi, to translate documents I use in my code the
Await Translator.TranslateDocumentAsync (...)
task from your API. This works flawless for DOCX and PPTX but on PDF files it is inconsistent. Regularly there is no completion of the translation task. It is not reproducible and I found no relation to file size, content, name etc.I then checked the implementation of the task in the DeepL .NET API VS solution and it is this:
So I replaced
Await Translator.TranslateDocumentAsync ()
with the above, as follows.Using these 3 calls separately always work with PDFs and the other file types so I wonder why the single API call 'TranslateDocumentAsync' does not always work for PDFs. The only difference is that I do not use
.ConfigureAwait(false)
because based on the documentation and other developers, it is not needed.Can you advise what is going on?
The text was updated successfully, but these errors were encountered: