search

Azure / azure-cosmos-table-dotnet

.NET SDK for Azure Cosmos Table API
14 stars 6 forks source link

Replace ClientHttpHandler with SocketsHttpHandler #51

Open HansOlavS opened 4 years ago

HansOlavS commented 4 years ago

SDK version: 1.0.7 Issue reproduce steps: N/A Whether the issue is consistent or sporadic: Consistent Environment Summary: N/A Any other context, such as stack trace or log: it's impossible to control concurrency and TCP connection handling in a proper way with the SDK forcing the use of the now ancient and obsolete ClientHttpHandler as its inner-most handler. I'm stuck hacking a DelegatingHandler with use of Reflection and handwriting my own authorization header-logic decompiled from the SDK so I can use my own SocketsHttpHandler. In environments such as App Functions in consumption plan you only have 600 TCP connections and those run out fast if you're not able to control idle timeout, concurrency etc.

This is a huge architectural issue with the SDK that needs to be solved. I'd volunteer to fix this myself, but the SDK isn't even open-source (which it really should be!)

HansOlavS commented 4 years ago

Anyone? Could I get a comment from anyone, please? Is this not even monitored???

PaulCheng commented 4 years ago

CosmosDB team is in the process of finalizing the best path supporting table sdk going forward. The latest conversations are leading toward defining the swagger spec and bridge all the gaps on the server side, so the SDK code could be semi-auto-generated if it's rolled under Azure SDK. During the meantime, I'm wondering whether CloudTableClient object is reused like a singleton in your app. Will 'not-recreating-CloudTableClient instance upon each operation' help eliminate the need to implement your own message handler?

HansOlavS commented 4 years ago

@PaulCheng Thanks for getting back to me. I'm using the CloudTableClient as a singleton, yes. The main problem is that the SDK is using the now obsolete ClientHttpHandler where it should've used SocketsHttpHandler and allowed us to somehow control the concurrency and TCP connection pooling.

christopheranderson commented 4 years ago

We'll be doing this overhaul in our next major release, v2.0.