search

kapil-chauhan-ngi / google-api-dotnet-client

Automatically exported from code.google.com/p/google-api-dotnet-client
Apache License 2.0
0 stars 0 forks source link

ConfigurableMessageHandler is not threadsafe #466

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
The lists of 
IHttpExceptionHandler/IHttpUnsuccessfulResponseHandler/IHttpExecuteInterceptor 
in ConfigurableMessageHandler are not thread-safe, which means that multiple 
threads might add items to them, which might results in a (race-condition) 
exception.

What steps will reproduce the problem?
1. Perform a large amount of calls to InsertMediaUpload.ExecuteAsync()
2. After a while, you will get an "Enumeration was modified" exception from 
some of the threads.

This happens because each call to InsertMediaUpload.ExecuteAsync() results in a 
new instance of ServerErrorCallback which registers itself in the 
MessageHandler above-mentioned lists.
At the same time, some other upload might have failed, and might be iterating 
on these collections (in the method SendAsync())

Original issue reported on code.google.com by ita...@gmail.com on 29 May 2014 at 9:27

GoogleCodeExporter commented 9 years ago

Original comment by pele...@google.com on 29 May 2014 at 7:16

GoogleCodeExporter commented 9 years ago

Original comment by pele...@google.com on 29 May 2014 at 7:16

GoogleCodeExporter commented 9 years ago

Original comment by pele...@google.com on 15 Jul 2014 at 11:29

GoogleCodeExporter commented 9 years ago 
Although I'm not delighted to, I think that in order to not support the current 
interface we should hold that data as SynchronizedCollection<T>. 
(http://msdn.microsoft.com/en-us/library/ms668265(v=vs.110).aspx)

I'm not happy with that, because there are better structures to store 
synchronized collection, but this one won't be expose to the outside world, 
they will only get an IList instance.

itaysa and class, I would like to hear your thoughts.
Thanks!
Eyal

Original comment by pele...@google.com on 22 Jul 2014 at 3:31

GoogleCodeExporter commented 9 years ago 
Since possible bottlenecks will probably be in the network traffic anyway, I 
don't think this matters much. Especially since having too many threads is not 
recommended anyway....
I ended up using a single thread approach, so it's not that critical to me...

Original comment by ita...@gmail.com on 22 Jul 2014 at 4:53

GoogleCodeExporter commented 9 years ago 
Yeah, but I still want the library to be muddleheaded. I think that I'll go 
with that approach in the next version (1.9).
Thanks!

Original comment by pele...@google.com on 22 Jul 2014 at 4:55

GoogleCodeExporter commented 9 years ago 
Update: SynchronizedCollection isn't supported in PCL 4.0.
I'll try to figure out a new solution.

Original comment by pele...@google.com on 28 Jul 2014 at 1:26

GoogleCodeExporter commented 9 years ago

Original comment by pele...@google.com on 29 Sep 2014 at 9:40

GoogleCodeExporter commented 9 years ago

Original comment by pele...@google.com on 23 Dec 2014 at 1:46