REST API Download Attachment Timeout?

[Anonymous]

Hi API Experts!

I wrote a C#.NET application/tool to allow end-users to download attachments for a given app/questionnaire. It works amazing but occassionally there are a few attachments which fail due to a timeout from Archer and is repeatable for those attachments. The timeout is 5 minutes long and the attachments are small. Here's the message/stacktrace:

Message: The operation has timed out.

Stacktrace:    at System.Net.WebClient.UploadDataInternal(Uri address, String method, Byte[] data, WebRequest& request)
   at System.Net.WebClient.UploadString(Uri address, String method, String data)
   at System.Net.WebClient.UploadString(String address, String data)
   at Archer_Attachment_Downloader.Form1.DownloadAttachment(String sCurrentTrackingID, String sAttachmentID, String sPath) in c:\Users\docampbell\Documents\Visual Studio 2013\Projects\Archer Attachment Downloader\Archer Attachment Downloader\Form1.cs:line 997

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I've been able to dowload 29,465 attachments (~5.5GB)...and only 2 are failing. There is not anything strange about the filenames (no special characters, size limits, etc.). I can't seem to find a rhyme or reason for this. 

Are there any known issues with teh REST API Attachment Download call? Or with the way an attachment is stored? The attachments can be downloaded via the Archer user interface without issue.

Current Archer Version: 6.4 SP1 P1

We plan to upgrade to 6.5 P1 in March, but I won't know if that fixes it until late March.

Thanks much!

[Ilya_Khen]

Could it be due to session timeout of the account your are authenticating against Archer?

Or IIS pool timeout for REST API web node.

Also, I suppose you use separate account for your application, which is not used occasionally by anyone or anything else. Otherwise, someone authenticating with it while the tool is working would break the session.

[Anonymous]

Thanks, those are logical questions, but the error is repeatable on the same 2 attachments and other attachments work just fine. The timeout for the API session is set to 3 days and the app pool shouldn't timeout if I'm making all those subsequent API calls which refreshes the timeout. It's really an issue with the specific attachment somehow, just can't identify the root cause.

[Ilya_Khen]

Oh, you can reproduce that again the same attachments. I was thinking about random cases.

In such a case, there definitely might be something with the attachment itself. Like attachment access right, or being Read only block mode.

In such a case, you can create ticket to support and provide them attachments for analysis.

[jsol5]

I'm thinking corrupt files.  **I cringe to say that given the implications.

Maybe an issue with file name or type?

Are you able to download those same 2 attachments from the Archer front-end without error?

Are you on-prem or SaaS?  

[Anonymous]

Hi Jason, Everything works fine through the Archer end-user interface downloading those files. Nothing strange about the name of the files and they open up fine (no corruption). We are on-prem and have Archer 6.4 SP1. We are going to 6.5 P1 on 3/14 so I'll see if that resolves it.

I haven't tested it yet, but we have been noticing some UI timeout issues (large attachments hang, modify search results hangs, values lists don't load, etc.) going through our NetScaler device which terminates SSL. Going directly to the Archer web server avoids that issue. I'll have to give that a try next time I'm working with that app. It's not a huge deal, more curious than anything now.

Thanks much Jason!

[jsol5]

Glad to hear the file is not corrupt.

So, strange that it would be the same 2 files.  I'm guessing your app is not grabbing a group of files, but a specific file.

I get you're trying to just identify the root cause.  So, just spit-ballin' here.

File encoding issue?  

I mean it's strange that it's the same 2 files.  

Not familiar with the method you're using to get the file... So, I'm looking here to see if anything stands out -

WebClient.UploadData Method (System.Net) | Microsoft Docs 

I'm sure you are doing the same.

I see something about enabling network tracing --

Network Tracing in the .NET Framework | Microsoft Docs 

Maybe looking at that, you might be able to get a better error message?