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?
c# .net azure-devops azure-devops-rest-api
add a comment |
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?
c# .net azure-devops azure-devops-rest-api
Can you share your WorkItem Object?
– Md. Abdul Alim
Nov 10 at 2:58
add a comment |
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?
c# .net azure-devops azure-devops-rest-api
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
c# .net azure-devops azure-devops-rest-api
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
add a comment |
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
add a comment |
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);
});
How does that help?
– Prashanth Subramanian
Nov 10 at 1:05
@PrashanthSubramanian it helps by using unique_witClient
for each thread inWorkItemReporting
– 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 overHttpClient
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
add a comment |
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
add a comment |
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);
});
How does that help?
– Prashanth Subramanian
Nov 10 at 1:05
@PrashanthSubramanian it helps by using unique_witClient
for each thread inWorkItemReporting
– 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 overHttpClient
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
add a comment |
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);
});
How does that help?
– Prashanth Subramanian
Nov 10 at 1:05
@PrashanthSubramanian it helps by using unique_witClient
for each thread inWorkItemReporting
– 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 overHttpClient
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
add a comment |
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);
});
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);
});
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 inWorkItemReporting
– 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 overHttpClient
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
add a comment |
How does that help?
– Prashanth Subramanian
Nov 10 at 1:05
@PrashanthSubramanian it helps by using unique_witClient
for each thread inWorkItemReporting
– 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 overHttpClient
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
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Nov 10 at 2:38
Mark
1,24121627
1,24121627
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Can you share your WorkItem Object?
– Md. Abdul Alim
Nov 10 at 2:58