Possible memory Leak when deserializing a compressed stream?

during my stress-test performance test I’ve noticed that If I use in servicerunned the compression I got on the client side a suspected memory leak on System.Net.DeflateWrapperStream

Here’s the code I use to compress data (I think it’s almost vanilla)

public class IFServiceRunner<TRequest> : ServiceRunner<TRequest>
    static IFServiceRunner()

    public IFServiceRunner(IAppHost appHost, ActionContext actionContext)
        : base(appHost, actionContext)


    public override object OnAfterExecute(ServiceStack.Web.IRequest requestContext, object response)
        if ((response != null) && !(response is CompressedResult) && !(response is HttpResult))
            response = requestContext.ToOptimizedResult(response);

        return base.OnAfterExecute(requestContext, response);

    public override object HandleException(ServiceStack.Web.IRequest request, TRequest requestDto, Exception ex)
        ILog log = LogManager.GetLogger(GetType());

        string error = string.Format("[url:{1}] - [data:{0}]", requestDto.SerializeToString(), request.PathInfo);
        log.Error(error, ex);
        return base.HandleException(request, requestDto, ex);

If I comment those compression lines in the OnAfterExecute method those memory leaks fades away

The code I use to call the service is

var res = await client.GetAsync<User>(urlForAuthentication);

Any suggestion?

do you have any more info about the leak? e.g. What makes you think it’s in DeflateWrapperStream?

JustTrace (from Telerik) told me while I was looking for another leak…

I’ll try to prepare you a sample but I think it’s something related to Async

@ifinformatica it might be a good idea to download the 30 days trial of JetBrains dotMemory and profile it, so you know for sure, plus save the sample and post it here to @mythz

@balexandre I think justtrace does almost the same, by the way I’ll follow your suggestion and post the save here