[Mono-dev] [PATCH] WCF multithreaded and property handling

Atsushi Eno atsushieno at veritas-vos-liberabit.com
Wed Mar 24 01:47:43 EDT 2010


I'll apply your changes only in split form. And I won't apply any 
unnecessary changes unless everything got sorted out appropriately right 
now, as they'd rather bring mess on applying incremental changes.

So, I'll skip your properties changes and 2) I'll leave Thread.Sleep() 
until I test ASP.NET integration after applying your changes. -> 
properties_*.patch

I'll revisit the multithreading half after other part of patch review. 
Please be patient ;)

Atsushi Eno


On 2010/03/23 22:33, Matt Dargavel wrote:
> Ok, no problem.  I can break them down more.
>
> You're right, I can provide no guarantees about the Thread.Sleep
> removal!  But it could have been related to locking registered_channels
> instead of pending?  I did quite a bit of multithreaded testing, and
> there were no problems; but I take your point.
>
> I implemented new functions rather than overriding Properties for a few
> reasons.  I wanted to be sure that I found everywhere that used the
> properties mechanism to check there were no unwanted side effects, and
> to make it more obvious something a little special was going on.  Also I
> thought that using a function hides the implementation from other
> classes.  For example, the .NET documentation states that
> ChannelListenerBase should search for the property and then delegate
> down the stack if it can't find it, so I could see a scenario where only
> certain properties were passed to / from inner channels.  But I guess
> that's refactoring and personal preference rather than a minimum change
> fix. :-)
>
> I can delve in to the test code and come up with some test cases for the
> properties fix, but unfortunately I think it'll be impossible to write
> test cases for the multithreading issues.
>
> 	Cheers,
>
> 		Matt.
>
>
>    
>> -----Original Message-----
>> From: Atsushi Eno [mailto:atsushieno at veritas-vos-liberabit.com]
>> Sent: 23 March 2010 12:50 PM
>> To: Matt Dargavel
>> Cc: mono-devel-list at lists.ximian.com
>> Subject: Re: [PATCH] WCF multithreaded and property handling
>>
>> Hello,
>>
>> Thanks for the patch. They are looking like a great set of attempts
>>      
> for
>    
>> cool bugfixes :) However there is a lot of other changes that your
>> description cannot explain. So, please first split the changes into
>>      
> further
>    
>> smaller patches for each purpose, and give explanation for each
>>      
> change. For
>    
>> example,
>>
>> - // FIXME: this should not be required, but it somehow saves some
>>      
> failures
>    
>> wrt concurrent calls.
>> - Thread.Sleep (100);
>>
>> This kind of change should not be made without explanation. (you
>>      
> aren't
>    
>> really sure about why it exists, right?)
>>
>> As for ChannelListenerBase.Properties, I'd rather make the changes
>>      
> much
>    
>> smaller like the attached change. Isn't it enough? There's no test
>>      
> case
>    
>> that I can verify your (and-my) changes.
>>
>> Atsushi Eno
>>
>> On 2010/03/23 20:28, Matt Dargavel wrote:
>>      
>>> The included patches fix the following:
>>>
>>> multithreaded_fixes.patch: ObjectDisposedException,
>>> InvalidOperationException("Another async TryReceiveRequest operation
>>> is in progress") and other multithreaded timing fixes. Also includes
>>> change to make GET ?wsdl case insensitive.
>>>
>>> properties_handling.patch: MetadataPublishingInfo not available in
>>> TransactionChannelListener's inner_listener. I created a new
>>> RetrieveProperty function as overriding GetProperty<T>  didn't work-
>>> the ChannelListenerBase implementation was still called. Perhaps
>>> there's a bug with generic function overrides or maybe I've done
>>> something silly there?
>>>
>>> properties_and_wsdl.patch: patch for ServiceMetadataExtension.cs
>>>        
> that
>    
>>> goes with the properties changes and the ?wsdl change.
>>>
>>> Let me know if you have any questions. :-)
>>>
>>> Matt.
>>>
>>>        
>
>
>    



More information about the Mono-devel-list mailing list