GetWorkItemAsync method exception when called from multiple threads C#.Net











up vote
0
down vote

favorite












I am trying to get the links from VSO for workitems, and the code seems to work fine when called from a single thread, but throws exceptions when called from a parallel for each loop.



I initalize my vso client object in my class's constructor:



vso = new WorkItemReporting(Config.VSTSAccessToken);


Then later in a method:



Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
{
var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
});


witclient below is a WorkItemTrackingHttpClient which is in a different class (WorkItemReporting) and calls the API. It is this call that fails.



public List<string> GetWorkItemSourceCodeLinks(int bugId)
{
var workItemSourceCodeLinks = new List<string>();

var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
if (workItem?.Relations != null)
{
var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
foreach (var relation in workItem.Relations)
{
if (validSourceCodeLinkTypes.Contains(relation.Rel))
{
workItemSourceCodeLinks.Add(relation.Url);
}
}
}
}


This works fine if I don't use the Parallel.ForEach and I get the needed data from the API. When I do, I get this exception 50% of the time:



Object reference not set to an instance of an object.   
at System.Security.Cryptography.X509Certificates.X509CertificateCollection.GetHashCode()
at System.Net.HttpWebRequest.GetConnectionGroupLine()
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.BeginGetResponse(AsyncCallback callback, Object state)
at System.Net.Http.HttpClientHandler.StartGettingResponse(RequestState state)
at System.Net.Http.HttpClientHandler.StartRequest(Object obj)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.<SendAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__48.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__45`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__27`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__26`1.MoveNext()


Is there something I'm doing wrong?










share|improve this question
























  • Can you share your WorkItem Object?
    – Md. Abdul Alim
    Nov 10 at 2:58















up vote
0
down vote

favorite












I am trying to get the links from VSO for workitems, and the code seems to work fine when called from a single thread, but throws exceptions when called from a parallel for each loop.



I initalize my vso client object in my class's constructor:



vso = new WorkItemReporting(Config.VSTSAccessToken);


Then later in a method:



Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
{
var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
});


witclient below is a WorkItemTrackingHttpClient which is in a different class (WorkItemReporting) and calls the API. It is this call that fails.



public List<string> GetWorkItemSourceCodeLinks(int bugId)
{
var workItemSourceCodeLinks = new List<string>();

var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
if (workItem?.Relations != null)
{
var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
foreach (var relation in workItem.Relations)
{
if (validSourceCodeLinkTypes.Contains(relation.Rel))
{
workItemSourceCodeLinks.Add(relation.Url);
}
}
}
}


This works fine if I don't use the Parallel.ForEach and I get the needed data from the API. When I do, I get this exception 50% of the time:



Object reference not set to an instance of an object.   
at System.Security.Cryptography.X509Certificates.X509CertificateCollection.GetHashCode()
at System.Net.HttpWebRequest.GetConnectionGroupLine()
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.BeginGetResponse(AsyncCallback callback, Object state)
at System.Net.Http.HttpClientHandler.StartGettingResponse(RequestState state)
at System.Net.Http.HttpClientHandler.StartRequest(Object obj)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.<SendAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__48.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__45`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__27`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__26`1.MoveNext()


Is there something I'm doing wrong?










share|improve this question
























  • Can you share your WorkItem Object?
    – Md. Abdul Alim
    Nov 10 at 2:58













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I am trying to get the links from VSO for workitems, and the code seems to work fine when called from a single thread, but throws exceptions when called from a parallel for each loop.



I initalize my vso client object in my class's constructor:



vso = new WorkItemReporting(Config.VSTSAccessToken);


Then later in a method:



Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
{
var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
});


witclient below is a WorkItemTrackingHttpClient which is in a different class (WorkItemReporting) and calls the API. It is this call that fails.



public List<string> GetWorkItemSourceCodeLinks(int bugId)
{
var workItemSourceCodeLinks = new List<string>();

var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
if (workItem?.Relations != null)
{
var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
foreach (var relation in workItem.Relations)
{
if (validSourceCodeLinkTypes.Contains(relation.Rel))
{
workItemSourceCodeLinks.Add(relation.Url);
}
}
}
}


This works fine if I don't use the Parallel.ForEach and I get the needed data from the API. When I do, I get this exception 50% of the time:



Object reference not set to an instance of an object.   
at System.Security.Cryptography.X509Certificates.X509CertificateCollection.GetHashCode()
at System.Net.HttpWebRequest.GetConnectionGroupLine()
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.BeginGetResponse(AsyncCallback callback, Object state)
at System.Net.Http.HttpClientHandler.StartGettingResponse(RequestState state)
at System.Net.Http.HttpClientHandler.StartRequest(Object obj)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.<SendAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__48.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__45`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__27`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__26`1.MoveNext()


Is there something I'm doing wrong?










share|improve this question















I am trying to get the links from VSO for workitems, and the code seems to work fine when called from a single thread, but throws exceptions when called from a parallel for each loop.



I initalize my vso client object in my class's constructor:



vso = new WorkItemReporting(Config.VSTSAccessToken);


Then later in a method:



Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
{
var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
});


witclient below is a WorkItemTrackingHttpClient which is in a different class (WorkItemReporting) and calls the API. It is this call that fails.



public List<string> GetWorkItemSourceCodeLinks(int bugId)
{
var workItemSourceCodeLinks = new List<string>();

var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
if (workItem?.Relations != null)
{
var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
foreach (var relation in workItem.Relations)
{
if (validSourceCodeLinkTypes.Contains(relation.Rel))
{
workItemSourceCodeLinks.Add(relation.Url);
}
}
}
}


This works fine if I don't use the Parallel.ForEach and I get the needed data from the API. When I do, I get this exception 50% of the time:



Object reference not set to an instance of an object.   
at System.Security.Cryptography.X509Certificates.X509CertificateCollection.GetHashCode()
at System.Net.HttpWebRequest.GetConnectionGroupLine()
at System.Net.HttpWebRequest.SubmitRequest(ServicePoint servicePoint)
at System.Net.HttpWebRequest.BeginGetResponse(AsyncCallback callback, Object state)
at System.Net.Http.HttpClientHandler.StartGettingResponse(RequestState state)
at System.Net.Http.HttpClientHandler.StartRequest(Object obj)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpMessageHandler.<SendAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.Common.VssHttpRetryMessageHandler.<SendAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__48.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__45`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__27`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Services.WebApi.VssHttpClientBase.<SendAsync>d__26`1.MoveNext()


Is there something I'm doing wrong?







c# .net azure-devops azure-devops-rest-api






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 10 at 1:03









Alex Sikilinda

2,154924




2,154924










asked Nov 10 at 0:50









Prashanth Subramanian

191216




191216












  • Can you share your WorkItem Object?
    – Md. Abdul Alim
    Nov 10 at 2:58


















  • Can you share your WorkItem Object?
    – Md. Abdul Alim
    Nov 10 at 2:58
















Can you share your WorkItem Object?
– Md. Abdul Alim
Nov 10 at 2:58




Can you share your WorkItem Object?
– Md. Abdul Alim
Nov 10 at 2:58












2 Answers
2






active

oldest

votes

















up vote
1
down vote













A solution is to create WorkItemReporting inside Parallel.ForEach:



Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
{
var vso = new WorkItemReporting(Config.VSTSAccessToken);
var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
});





share|improve this answer





















  • How does that help?
    – Prashanth Subramanian
    Nov 10 at 1:05










  • @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
    – Alex Sikilinda
    Nov 10 at 1:08










  • got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
    – Prashanth Subramanian
    Nov 10 at 1:20










  • Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
    – Alex Sikilinda
    Nov 10 at 1:33










  • As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
    – Mark
    Nov 10 at 2:14


















up vote
0
down vote













You need to lock access to the external resource by doing something like the following.



As per comment @AlexSikilinda _witClient must not be thread safe.



For what your doing though, just because you can create multiple threads doesn't means you should, i would get timings, on what your doing with and without the parallel processing in your code,



Keep in mind if you use non thread safe external resources, and locks then it maybe just as slow as running in a normal for loop. You need to test both scenario's.



Add an object outside your methods to allow access to the lock object from every thread, this will help manage the access to the non thread safe class.



vso = new WorkItemReporting(Config.VSTSAccessToken);
private readonly object _witLock = new object();


In the following you DON'T want to put the lock around the entire methods contents as i have, otherwise you are definitely wasting your time using the Parallel for this piece of code.



Based on what your doing thought this should stop the exceptions.



You need refactor the code so that only the call to _witClient is within the lock. So just declare the workItem variable outside the lock with it proper type, and then only wrap the call to workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result; in your lock code.



public List<string> GetWorkItemSourceCodeLinks(int bugId)
{
var workItemSourceCodeLinks = new List<string>();
lock (_witLock)
{
var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
if (workItem?.Relations != null)
{
var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
foreach (var relation in workItem.Relations)
{
if (validSourceCodeLinkTypes.Contains(relation.Rel))
{
workItemSourceCodeLinks.Add(relation.Url);
}
}
}
}
}


Good Luck






share|improve this answer





















    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53235046%2fgetworkitemasync-method-exception-when-called-from-multiple-threads-c-net%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    1
    down vote













    A solution is to create WorkItemReporting inside Parallel.ForEach:



    Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
    {
    var vso = new WorkItemReporting(Config.VSTSAccessToken);
    var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
    });





    share|improve this answer





















    • How does that help?
      – Prashanth Subramanian
      Nov 10 at 1:05










    • @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
      – Alex Sikilinda
      Nov 10 at 1:08










    • got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
      – Prashanth Subramanian
      Nov 10 at 1:20










    • Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
      – Alex Sikilinda
      Nov 10 at 1:33










    • As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
      – Mark
      Nov 10 at 2:14















    up vote
    1
    down vote













    A solution is to create WorkItemReporting inside Parallel.ForEach:



    Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
    {
    var vso = new WorkItemReporting(Config.VSTSAccessToken);
    var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
    });





    share|improve this answer





















    • How does that help?
      – Prashanth Subramanian
      Nov 10 at 1:05










    • @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
      – Alex Sikilinda
      Nov 10 at 1:08










    • got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
      – Prashanth Subramanian
      Nov 10 at 1:20










    • Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
      – Alex Sikilinda
      Nov 10 at 1:33










    • As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
      – Mark
      Nov 10 at 2:14













    up vote
    1
    down vote










    up vote
    1
    down vote









    A solution is to create WorkItemReporting inside Parallel.ForEach:



    Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
    {
    var vso = new WorkItemReporting(Config.VSTSAccessToken);
    var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
    });





    share|improve this answer












    A solution is to create WorkItemReporting inside Parallel.ForEach:



    Parallel.ForEach(msrcAbBugsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 10 }, bugId =>
    {
    var vso = new WorkItemReporting(Config.VSTSAccessToken);
    var workItemLinks = vso.GetWorkItemSourceCodeLinks(bugId);
    });






    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Nov 10 at 0:58









    Alex Sikilinda

    2,154924




    2,154924












    • How does that help?
      – Prashanth Subramanian
      Nov 10 at 1:05










    • @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
      – Alex Sikilinda
      Nov 10 at 1:08










    • got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
      – Prashanth Subramanian
      Nov 10 at 1:20










    • Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
      – Alex Sikilinda
      Nov 10 at 1:33










    • As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
      – Mark
      Nov 10 at 2:14


















    • How does that help?
      – Prashanth Subramanian
      Nov 10 at 1:05










    • @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
      – Alex Sikilinda
      Nov 10 at 1:08










    • got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
      – Prashanth Subramanian
      Nov 10 at 1:20










    • Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
      – Alex Sikilinda
      Nov 10 at 1:33










    • As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
      – Mark
      Nov 10 at 2:14
















    How does that help?
    – Prashanth Subramanian
    Nov 10 at 1:05




    How does that help?
    – Prashanth Subramanian
    Nov 10 at 1:05












    @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
    – Alex Sikilinda
    Nov 10 at 1:08




    @PrashanthSubramanian it helps by using unique _witClient for each thread in WorkItemReporting
    – Alex Sikilinda
    Nov 10 at 1:08












    got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
    – Prashanth Subramanian
    Nov 10 at 1:20




    got it, that seems to work, does that mean a method cannot be called from multiple threads using the same object in c#? or is it something specific to the API not being able to handle that?
    – Prashanth Subramanian
    Nov 10 at 1:20












    Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
    – Alex Sikilinda
    Nov 10 at 1:33




    Just guessing, but it seems that _witClient is a wrapper over HttpClient and it is not thread safe.
    – Alex Sikilinda
    Nov 10 at 1:33












    As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
    – Mark
    Nov 10 at 2:14




    As per comment from @AlexSikilinda when using multi threading, which is all Parallel is, you must use other methods to "lock" resource access, so that only 1 thread accesses resources outside the thread at a time, otherwise you get resource contention issues.
    – Mark
    Nov 10 at 2:14












    up vote
    0
    down vote













    You need to lock access to the external resource by doing something like the following.



    As per comment @AlexSikilinda _witClient must not be thread safe.



    For what your doing though, just because you can create multiple threads doesn't means you should, i would get timings, on what your doing with and without the parallel processing in your code,



    Keep in mind if you use non thread safe external resources, and locks then it maybe just as slow as running in a normal for loop. You need to test both scenario's.



    Add an object outside your methods to allow access to the lock object from every thread, this will help manage the access to the non thread safe class.



    vso = new WorkItemReporting(Config.VSTSAccessToken);
    private readonly object _witLock = new object();


    In the following you DON'T want to put the lock around the entire methods contents as i have, otherwise you are definitely wasting your time using the Parallel for this piece of code.



    Based on what your doing thought this should stop the exceptions.



    You need refactor the code so that only the call to _witClient is within the lock. So just declare the workItem variable outside the lock with it proper type, and then only wrap the call to workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result; in your lock code.



    public List<string> GetWorkItemSourceCodeLinks(int bugId)
    {
    var workItemSourceCodeLinks = new List<string>();
    lock (_witLock)
    {
    var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
    if (workItem?.Relations != null)
    {
    var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
    foreach (var relation in workItem.Relations)
    {
    if (validSourceCodeLinkTypes.Contains(relation.Rel))
    {
    workItemSourceCodeLinks.Add(relation.Url);
    }
    }
    }
    }
    }


    Good Luck






    share|improve this answer

























      up vote
      0
      down vote













      You need to lock access to the external resource by doing something like the following.



      As per comment @AlexSikilinda _witClient must not be thread safe.



      For what your doing though, just because you can create multiple threads doesn't means you should, i would get timings, on what your doing with and without the parallel processing in your code,



      Keep in mind if you use non thread safe external resources, and locks then it maybe just as slow as running in a normal for loop. You need to test both scenario's.



      Add an object outside your methods to allow access to the lock object from every thread, this will help manage the access to the non thread safe class.



      vso = new WorkItemReporting(Config.VSTSAccessToken);
      private readonly object _witLock = new object();


      In the following you DON'T want to put the lock around the entire methods contents as i have, otherwise you are definitely wasting your time using the Parallel for this piece of code.



      Based on what your doing thought this should stop the exceptions.



      You need refactor the code so that only the call to _witClient is within the lock. So just declare the workItem variable outside the lock with it proper type, and then only wrap the call to workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result; in your lock code.



      public List<string> GetWorkItemSourceCodeLinks(int bugId)
      {
      var workItemSourceCodeLinks = new List<string>();
      lock (_witLock)
      {
      var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
      if (workItem?.Relations != null)
      {
      var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
      foreach (var relation in workItem.Relations)
      {
      if (validSourceCodeLinkTypes.Contains(relation.Rel))
      {
      workItemSourceCodeLinks.Add(relation.Url);
      }
      }
      }
      }
      }


      Good Luck






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        You need to lock access to the external resource by doing something like the following.



        As per comment @AlexSikilinda _witClient must not be thread safe.



        For what your doing though, just because you can create multiple threads doesn't means you should, i would get timings, on what your doing with and without the parallel processing in your code,



        Keep in mind if you use non thread safe external resources, and locks then it maybe just as slow as running in a normal for loop. You need to test both scenario's.



        Add an object outside your methods to allow access to the lock object from every thread, this will help manage the access to the non thread safe class.



        vso = new WorkItemReporting(Config.VSTSAccessToken);
        private readonly object _witLock = new object();


        In the following you DON'T want to put the lock around the entire methods contents as i have, otherwise you are definitely wasting your time using the Parallel for this piece of code.



        Based on what your doing thought this should stop the exceptions.



        You need refactor the code so that only the call to _witClient is within the lock. So just declare the workItem variable outside the lock with it proper type, and then only wrap the call to workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result; in your lock code.



        public List<string> GetWorkItemSourceCodeLinks(int bugId)
        {
        var workItemSourceCodeLinks = new List<string>();
        lock (_witLock)
        {
        var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
        if (workItem?.Relations != null)
        {
        var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
        foreach (var relation in workItem.Relations)
        {
        if (validSourceCodeLinkTypes.Contains(relation.Rel))
        {
        workItemSourceCodeLinks.Add(relation.Url);
        }
        }
        }
        }
        }


        Good Luck






        share|improve this answer












        You need to lock access to the external resource by doing something like the following.



        As per comment @AlexSikilinda _witClient must not be thread safe.



        For what your doing though, just because you can create multiple threads doesn't means you should, i would get timings, on what your doing with and without the parallel processing in your code,



        Keep in mind if you use non thread safe external resources, and locks then it maybe just as slow as running in a normal for loop. You need to test both scenario's.



        Add an object outside your methods to allow access to the lock object from every thread, this will help manage the access to the non thread safe class.



        vso = new WorkItemReporting(Config.VSTSAccessToken);
        private readonly object _witLock = new object();


        In the following you DON'T want to put the lock around the entire methods contents as i have, otherwise you are definitely wasting your time using the Parallel for this piece of code.



        Based on what your doing thought this should stop the exceptions.



        You need refactor the code so that only the call to _witClient is within the lock. So just declare the workItem variable outside the lock with it proper type, and then only wrap the call to workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result; in your lock code.



        public List<string> GetWorkItemSourceCodeLinks(int bugId)
        {
        var workItemSourceCodeLinks = new List<string>();
        lock (_witLock)
        {
        var workItem = _witClient.GetWorkItemAsync(bugId, null, null, WorkItemExpand.Relations).Result;
        if (workItem?.Relations != null)
        {
        var validSourceCodeLinkTypes = new List<string> { "ArtifactLink", "Hyperlink" };
        foreach (var relation in workItem.Relations)
        {
        if (validSourceCodeLinkTypes.Contains(relation.Rel))
        {
        workItemSourceCodeLinks.Add(relation.Url);
        }
        }
        }
        }
        }


        Good Luck







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 10 at 2:38









        Mark

        1,24121627




        1,24121627






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53235046%2fgetworkitemasync-method-exception-when-called-from-multiple-threads-c-net%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Schultheiß

            Verwaltungsgliederung Dänemarks

            Liste der Kulturdenkmale in Wilsdruff