New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added HttpMessageHandler but ports are still in TIME_WAIT #70855
Comments
Hi, @mconnew any insights please? |
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Transfer to runtime, this is a question of behavior of IHttpMessageHandlerFactory. |
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFollowing this dotnet/wcf#3230 I've managed to inject my own HttpMessageHandler from IHttpMessageHandlerFactory into the WCF client. My EndpointBehavior looks like this:
In Startup.cs And this is how I use the httpHandler:
` When I use SOAP UI load test, I still see the ports open in TIME_WAIT after the application is done executing the load test. Is the HttpMessagehandler not working as it should or am I implementing it wrong? I am using the latest System.ServiceModel* dll (4.9.0)
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsFollowing this dotnet/wcf#3230 I've managed to inject my own HttpMessageHandler from IHttpMessageHandlerFactory into the WCF client. My EndpointBehavior looks like this: public class CustomEndpointBehavior : IEndpointBehavior
{
private readonly Func<HttpMessageHandler> _httpHandler;
public CustomEndpointBehavior(IHttpMessageHandlerFactory factory) => _httpHandler = () => factory.CreateHandler("ClientName");
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) => bindingParameters.Add(new Func<HttpClientHandler, HttpMessageHandler>(handler => _httpHandler()));
public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { }
public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { }
public void Validate(ServiceEndpoint endpoint) { }
} In Startup.cs And this is how I use the httpHandler: WcfResponseDto response;
var binding = CreateHttpBinding(); //Basic HTTP Binding
binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.Certificate;
var factory = new ChannelFactory<MyWcfChannel>(binding, new EndpointAddress(url));
IHttpMessageHandlerFactory httpMessageHandler = _serviceProvider.GetService(typeof(IHttpMessageHandlerFactory)) as
IHttpMessageHandlerFactory;
factory.Endpoint.EndpointBehaviors.Add(new CustomEndpointBehavior(httpMessageHandler));
factory.Credentials.ClientCertificate.Certificate = GetCertificate(); //returns a x509 certificate
var serviceProxy = factory.CreateChannel();
try
{
((ICommunicationObject)serviceProxy).Open();
response = await
serviceProxy.EnterpriseGetCountyDetailsAsync(requestDto).ConfigureAwait(false);
}
catch (Exception ex)
{
((ICommunicationObject)serviceProxy).Abort();
factory.Abort();
throw new FaultException(ex.Message);
}
finally
{
((ICommunicationObject)serviceProxy).Close();
factory.Close();
}
return response;
} When I use SOAP UI load test, I still see the ports open in TIME_WAIT after the application is done executing the load test. Is the HttpMessagehandler not working as it should or am I implementing it wrong? I am using the latest System.ServiceModel* dll (4.9.0)
|
Triage: This is by design behavior of the OS when we close Socket. As @wfurt mentions above, it will disappear. |
Following this dotnet/wcf#3230 I've managed to inject my own HttpMessageHandler from IHttpMessageHandlerFactory into the WCF client.
My EndpointBehavior looks like this:
In Startup.cs
services.AddHttpClient("ClientName");
And this is how I use the httpHandler:
When I use SOAP UI load test, I still see the ports open in TIME_WAIT after the application is done executing the load test. Is the HttpMessagehandler not working as it should or am I implementing it wrong? I am using the latest System.ServiceModel* dll (4.9.0)
The text was updated successfully, but these errors were encountered: