how to correctly release a Reporting Services report (out of memory problem)

[J.Marsch]

All:

I am having a problem with Microsoft Reporting Services. I am running a
local report (RDLC) on ASP.Net. Running the report obviously can use a lot
of memory because it must consume ADO.Net. My problem is that the report
does not seem to be very good about releasing the memory.

It appears that the report holds on to memory until the ASP.net session is
torn down. So, if I run the report over and over, I will eventually get an
Out Of Memory Exception. If I end the session, and then run the report, I
can see that memory is being released.

I used a memory profiler to determine what was rooting the memory:

The ADO.Net datatable is held in memory by the local report. The local
report appears to ultimately be held in memory because something in
reporting services inserted it into the ASP.net cache. It appears that it
is being released on session end.

I have tried calling the dispose method on the report viewer, but that
actually seems to make things worse (If I call that method directly, then
the memory is not available for collection even after the session is torn
down -- not surprising, I guess given that ht he help for the report
viewer's dispose method indicates that it is intended to be called
internally by the framework -- I just took a shot in the dark).

What should I be doing to make sure that the report releases its memory
gracefully after it has rendered?

[Steven Cheng[MSFT]]

Hi J.Marsch,

Regarding on the VS 2005 reportViewer localReport processing memory issue,
I have performed some research and did found existing bug entry in our
internal catelog. Actually this problem is due to some of the dynamically
generated assembly not able to be unloaded at runtime. And the problem has
been divided into two parts and one is fixed and another part is still not
controllable by design. Here is the detailed description of the issue:

============================
By Design:
The object that is taking up more and more memory is the expression host.
Each time a report is compiled, we create a new expression host assembly to
evaluate expressions in the report. When the security settings are such
that the expression host runs in the current app domain, this assembly can
never be unloaded. To prevent continuously growing memory, you have two
options. 1 - don't set the security for the current app domain. The default
is a separate app domain. 2 - Don't call Reset(). When you call reset, we
reset all of the local processing information. If you just set a new report
definition we will not recompile it, so it will use the old expression host
and not need to load a new assembly into the appdomain.

Fixed:
I added some better handling for Dispose(). We close memory streams earlier
now, but we weren't holding a reference to them so it wasn't causing a
problem in this case. Also, with workaround #2 above, we were still
recompiling the report. We don't do that anymore for reports loaded from
the file system or embedded resource.
============================

Also, for your scenario, if the problem is still quite pressure to your
application environment and need a rapid resolution, I suggest you contact
the CSS for further troubleshooting to verify the problem. They'll help you
perform some further thorough troubleshooting and leverage more resource on
working out a solution or workaround:

http://msdn.microsoft.com/subscripti...t/default.aspx

Thanks for your understanding.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[J.Marsch]

Thank you for this, Steven, and I'm sorry for the lag in getting back to
you.

I will check into the calls to Reset(), adn if we still have problems, we
will be in touch with CSS.

Regards

Jeremy
"Steven Cheng[MSFT]" <st*****@online.microsoft.comwrote in message
news:9b*************@TK2MSFTNGHUB02.phx.gbl...

Hi J.Marsch,

Regarding on the VS 2005 reportViewer localReport processing memory issue,
I have performed some research and did found existing bug entry in our
internal catelog. Actually this problem is due to some of the dynamically
generated assembly not able to be unloaded at runtime. And the problem has
been divided into two parts and one is fixed and another part is still not
controllable by design. Here is the detailed description of the issue:

============================
By Design:
The object that is taking up more and more memory is the expression host.
Each time a report is compiled, we create a new expression host assembly
to
evaluate expressions in the report. When the security settings are such
that the expression host runs in the current app domain, this assembly can
never be unloaded. To prevent continuously growing memory, you have two
options. 1 - don't set the security for the current app domain. The
default
is a separate app domain. 2 - Don't call Reset(). When you call reset, we
reset all of the local processing information. If you just set a new
report
definition we will not recompile it, so it will use the old expression
host
and not need to load a new assembly into the appdomain.

Fixed:
I added some better handling for Dispose(). We close memory streams
earlier
now, but we weren't holding a reference to them so it wasn't causing a
problem in this case. Also, with workaround #2 above, we were still
recompiling the report. We don't do that anymore for reports loaded from
the file system or embedded resource.
============================

Also, for your scenario, if the problem is still quite pressure to your
application environment and need a rapid resolution, I suggest you contact
the CSS for further troubleshooting to verify the problem. They'll help
you
perform some further thorough troubleshooting and leverage more resource
on
working out a solution or workaround:

http://msdn.microsoft.com/subscripti...t/default.aspx

Thanks for your understanding.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.