Здравствуйте, arkhivania, Вы писали:

A>В общем-то объект у меня зарождается на клиенте и по всей видимости с сервисной частью проблемы нет.
A>То есть на клиенте я создаю коллбак кидаю сервису и получаю от сервиса сообщения. InitializeLifetimeServices у колбака не переопределяю. В общем-то не знаю что может служить причиной держания этого объекта.

Инфраструктура ремоутинга по умолчанию и при отсутствии спонсоров будет удерживать объект 5 минут после публикации либо 2 минуты после последнего обращения, что больше. А потом еще время на срабатывание GC 1 или 2 поколения. Ты 5-10 минут ждал?

В общем есть некий простой объект MarshalByRefObject и он используется для обратных вызовов через Ipc
для примера пусть этот объект используется просто для вывода статуса процесса, происходящего на серверной стороне.

class Report : MarshalByRefObject
{
     public void PrintStatus( string text )
    {
       ... lllalalala
    }

    ~Report()
    {
      //сюда вот никогда не попадаю (
    }
}

ссылок на этот объект никто не держит, он просто прокидывается через серверную часть и про него все забывают. Почему он может не собираться коллектором. Или может это потому, что он не такой простой как в примере? Если у кого что-то подобное было поможите! Мерси!

Здравствуйте, arkhivania, Вы писали:

в файле картинка, что показывает профайлер

здесь

Здравствуйте, arkhivania, Вы писали:


A>ссылок на этот объект никто не держит, он просто прокидывается через серверную часть и про него все забывают. Почему он может не собираться коллектором. Или может это потому, что он не такой простой как в примере? Если у кого что-то подобное было поможите! Мерси!

У всех удалённых ссылок есть механизм определения времени жизни (см. namespace System.Runtime.Remoting.Lifetime), а ссылки на объекты убираются из внутреннего кеша remoting в моменты вызова самих методов remoting. Так что если после отдачи ссылок никто больше не вызывает сервак по remoting, то ссылка не освобождается, даже если время её жизни истекло.

Для того, чтобы сделать объект "вечным" так же достаточно вернуть null из переопределённого метода InitializeLifetimeService(), так что посмотри, не переопределён ли этот метод.

Здравствуйте, vdimas, Вы писали:

V>а ссылки на объекты убираются из внутреннего кеша remoting в моменты вызова самих методов remoting. Так что если после отдачи ссылок никто больше не вызывает сервак по remoting, то ссылка не освобождается, даже если время её жизни истекло.

Это ты где такое вычитал?

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, vdimas, Вы писали:

V>>а ссылки на объекты убираются из внутреннего кеша remoting в моменты вызова самих методов remoting. Так что если после отдачи ссылок никто больше не вызывает сервак по remoting, то ссылка не освобождается, даже если время её жизни истекло.

AVK>Это ты где такое вычитал?

В общем-то объект у меня зарождается на клиенте и по всей видимости с сервисной частью проблемы нет.
То есть на клиенте я создаю коллбак кидаю сервису и получаю от сервиса сообщения. InitializeLifetimeServices у колбака не переопределяю. В общем-то не знаю что может служить причиной держания этого объекта. Пока у него в неком подобии Close — а впервые для себя писал что-то типа

m_member1 = null;
m_member2 = null;
m_member3 = null;

и так далее, так как в этих мемберах хранились большие объекты и словари.

Странная проблема в общем, если кто узнает причину буду рад понять её.

Здравствуйте, AndrewVK, Вы писали:

AVK>Инфраструктура ремоутинга по умолчанию и при отсутствии спонсоров будет удерживать объект 5 минут после публикации либо 2 минуты после последнего обращения, что больше. А потом еще время на срабатывание GC 1 или 2 поколения. Ты 5-10 минут ждал?

По правде сказать нет Сегодня подожду и скажу результаты. Я просто привык что в профайлере помечаются объекты, которые могут быть собраны GC. Спасибо.

Здравствуйте, AndrewVK, Вы писали:

Ты 5-10 минут ждал?

Виноват! В общем всё ок!