{"action":"created","issue":{"url":"https://api.github.com/repos/SignalR/SignalR/issues/3458","labels_url":"https://api.github.com/repos/SignalR/SignalR/issues/3458/labels{/name}","comments_url":"https://api.github.com/repos/SignalR/SignalR/issues/3458/comments","events_url":"https://api.github.com/repos/SignalR/SignalR/issues/3458/events","html_url":"https://github.com/SignalR/SignalR/issues/3458","id":68778621,"number":3458,"title":"Message class instances leaking on SignalR 2.2.0 Self-Hosted in push to client","user":{"login":"sevzas","id":2014264,"avatar_url":"https://avatars.githubusercontent.com/u/2014264?v=3","gravatar_id":"","url":"https://api.github.com/users/sevzas","html_url":"https://github.com/sevzas","followers_url":"https://api.github.com/users/sevzas/followers","following_url":"https://api.github.com/users/sevzas/following{/other_user}","gists_url":"https://api.github.com/users/sevzas/gists{/gist_id}","starred_url":"https://api.github.com/users/sevzas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sevzas/subscriptions","organizations_url":"https://api.github.com/users/sevzas/orgs","repos_url":"https://api.github.com/users/sevzas/repos","events_url":"https://api.github.com/users/sevzas/events{/privacy}","received_events_url":"https://api.github.com/users/sevzas/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-04-15T20:24:36Z","updated_at":"2015-04-16T01:39:15Z","closed_at":"2015-04-16T01:39:14Z","body":"This issue might be related: https://github.com/SignalR/SignalR/issues/2413\r\n\r\nI'm using SignalR 2.2.0 Self-Hosted with Owin on Windows 2008 R2 and .NET 4.5.  The client is written in Csharp on .Net 4.5.\r\n\r\nIn my test case I have the server pushing events (< 1 Kb each) to the client.  So there is one server, one client, and one Hub method for pushing data to the client.  This is running for an extended period of time (>30 minutes).\r\n\r\nWhat I see in .Net Memory profiler is that the server is accumulating instances of Message, Message[] and MessageStore<Message>.Fragment.  It just keeps going up without bound.  It appears that the Message instances are linked like this:\r\n\r\nMessage <- \r\nMessage[] <- \r\nMessageStore<Message>.Fragment <- \r\nMessageStore<Message>.Fragment[]\r\nMessageStore<Message>\r\n\r\nI've examined the SignalR source code closely and (ofcourse I could be wrong) but I don't see any mechanism for pruning Message instances from a MessageStore.  I do see something that garbage collects *Topics* in MessageBus.cs (a timer that calls GarbageCollectTopics() ) but I don't see how that can prune *Message* instances from a live MessageStore<Message>.\r\n\r\nCould someone explain to me whether there is a mechanism for pruning Message objects from a long-lived MessageStore<Message> and how it works.\r\n\r\nThanks in advance.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/SignalR/SignalR/issues/comments/93613733","html_url":"https://github.com/SignalR/SignalR/issues/3458#issuecomment-93613733","issue_url":"https://api.github.com/repos/SignalR/SignalR/issues/3458","id":93613733,"user":{"login":"sevzas","id":2014264,"avatar_url":"https://avatars.githubusercontent.com/u/2014264?v=3","gravatar_id":"","url":"https://api.github.com/users/sevzas","html_url":"https://github.com/sevzas","followers_url":"https://api.github.com/users/sevzas/followers","following_url":"https://api.github.com/users/sevzas/following{/other_user}","gists_url":"https://api.github.com/users/sevzas/gists{/gist_id}","starred_url":"https://api.github.com/users/sevzas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sevzas/subscriptions","organizations_url":"https://api.github.com/users/sevzas/orgs","repos_url":"https://api.github.com/users/sevzas/repos","events_url":"https://api.github.com/users/sevzas/events{/privacy}","received_events_url":"https://api.github.com/users/sevzas/received_events","type":"User","site_admin":false},"created_at":"2015-04-16T01:39:14Z","updated_at":"2015-04-16T01:39:14Z","body":"Thanks for that simple explanation."}}