dotnet / dotnet/wcf

Generated client lifetime scope

Open
#4,998 6 comments 0 reactions 1 assignee Claimed by @mconnew View on GitHub
triaged
Dominant language
C#
Stars
1.8k
Forks
576
Avg merge
6d 9h
Merged PRs (30d)
2

Description

I have an SSRS client I'm trying to put together for a legacy project upgrade from .NET Framework, and I'm having a little trouble finding the right documentation for my needs, hoping someone can help guide me to the right place. Im using a generated client regenerated through VS2022's add service reference screens.

Issue 1:
Our SSRS implementation uses a FormsAuth scheme in front of it, meaning from a WCF standpoint here, it doesn't use any of the regular auth mechanisms (BasicHttpSecurityMode.None I believe), but instead through SSRS you can call a LogonAsync method that will return an AUTH COOKIE that needs to then be attached to each subsequent request along with managing sliding expirations, etc. by replacing the cookie when a new one comes back after a call, etc. Every "session" has a different user that matters to the report security context, so I need each "client" to have a separate auth context here.

I have a proof of concept working for this using an IClientMessageInspector added via an IEndPoint behavior and it works for a single client. I ALSO tried something on a per call basis via an OperationContextScope or something like that to put the headers on / strip them off on responses, but ran into some async issues that looked like SynchronizationContext type continuation issues that I couldn't figure out (and the IClientMessageInspector seemed more elegant anyway).

Buuuuut

Issue 2:
This client is going to used as part of a report queue running around 500k report queue items a day across multiple parallel threads, each of which with this model, would be NEWING UP A NEW CLIENT when each queue item is processed. This would keep the auth context of my MessageInspector isolated per usage, but my understanding here is I'm setting myself up for socket exhaustion since each of those clients would instantiate its own HttpClient under the hood? I thought about making the client singleton, but that seems like my IMessageInspector approach to the auth scheme would then all share the same Cookie storage = bad....

I read about injecting in my behavior an IHttpMessageHandlerFactory to allow reuse of the underlying HttpMessageHandler to avoid the HttpClient socket exhaustion, but also read I'd still be recreating the ChannelFactory every time which might cause other issues? I'm a little stuck here on what my lifetime management should look like...

Semi-Issue 3:
It is not uncommon for SSRS to timeout a call on us. My understanding is that if this happens, that Channel is basically dead. until you call a manual channel.Abort(). Im not sure this applies to me if I new up a new client every time as I think I get a whole new ChannelFactory/Channels then so between runs it'd be fine, but if I have to do some lifetime management here, this might come into play?

Im more concerned about the lifetime management issues as I'm going to be doing some stuff at scale here so I need to get that right, if I have to implement the auth part in some other way, Im open to suggestions.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.