[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.aspnet.caching

ASP.NET 2.0 caching problem(s)...

Michael Y

3/5/2006

I am starting to observe some rather "odd" behaviors with ASP.NET 2.0 apps
that use the Cache object for storage of global data items. These apps
worked perfectly under 1.1, but now it seems like the 2.0 cache likes to
sometimes Insert items into the cache, sometimes not, and sometimes remove
them seconds after they've been inserted. I've seen a few comments on this
group about it, but with no "formal" answers. I have never seen any of these
issues under 1.1 - everything worked as documented.

Is there a definite issues with the 2.0 caching object(s)???? And if so,
ummm....fix?
8 Answers

Alvin Bruney [ASP.NET MVP]

3/6/2006 6:27:00 PM

0

What issues exactly?

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



"MichaelY" <MichaelY@discussions.microsoft.com> wrote in message
news:E22BBFE1-D089-4F99-A68B-7F831273D81E@microsoft.com...
> I am starting to observe some rather "odd" behaviors with ASP.NET 2.0 apps
> that use the Cache object for storage of global data items. These apps
> worked perfectly under 1.1, but now it seems like the 2.0 cache likes to
> sometimes Insert items into the cache, sometimes not, and sometimes remove
> them seconds after they've been inserted. I've seen a few comments on
this
> group about it, but with no "formal" answers. I have never seen any of
these
> issues under 1.1 - everything worked as documented.
>
> Is there a definite issues with the 2.0 caching object(s)???? And if so,
> ummm....fix?

Michael Y

3/6/2006 6:42:00 PM

0

Among the most frequent are Cache.Insert()ions with objects that literally
seem to 'dissappear'. In other words, I load up a metadata table (DataTable)
into Cache. Every field on a group of web forms use this info to control
rendering, display visibility, etc. However, the pattern that we end up
seeing is the object being removed LONG before it's expiration (15 mins), and
then subsequent insert()'s failing (meaning the object isn't present after
the insert - like the insert said 'nope...sorry').

I have been able to 'pin' the objects there by specifying
CacheItemPriority.NotRemovable, but why should I have to do this??? I expect
on a machine with 4GB's of RAM (and the worker using about ~100MB) for the
items to be there for a least a few minutes (maybe 15???)....and then it
would be nice to have other calls to Insert() work.

On the product feedback center for MS, this issues has been reported, but is
marked as "not reproducable". Seems odd, doesn't it????? Especially when
others report the same problem. Have there been landslide changes in the
CacheManager, or some other subsystem (HealthMonitoring maybe???) that is now
chewing up heap space????

Grrr....LoL..

Manso

3/6/2006 8:51:00 PM

0

I agree. There is something fishy with the Cache (my post two post above
yours). I can't figure out what's going on. You are not using
HttpRuntime.Cache, are you?

Let me do some more investigation on HttpContext.Current.Cache. It seems to
work there but I have a few gerneic functions located in a class lib that are
being executed using CallbackTimer so I need to access the HttpRuntime.Cache.

- M

"MichaelY" wrote:

> Among the most frequent are Cache.Insert()ions with objects that literally
> seem to 'dissappear'. In other words, I load up a metadata table (DataTable)
> into Cache. Every field on a group of web forms use this info to control
> rendering, display visibility, etc. However, the pattern that we end up
> seeing is the object being removed LONG before it's expiration (15 mins), and
> then subsequent insert()'s failing (meaning the object isn't present after
> the insert - like the insert said 'nope...sorry').
>
> I have been able to 'pin' the objects there by specifying
> CacheItemPriority.NotRemovable, but why should I have to do this??? I expect
> on a machine with 4GB's of RAM (and the worker using about ~100MB) for the
> items to be there for a least a few minutes (maybe 15???)....and then it
> would be nice to have other calls to Insert() work.
>
> On the product feedback center for MS, this issues has been reported, but is
> marked as "not reproducable". Seems odd, doesn't it????? Especially when
> others report the same problem. Have there been landslide changes in the
> CacheManager, or some other subsystem (HealthMonitoring maybe???) that is now
> chewing up heap space????
>
> Grrr....LoL..

Alvin Bruney [ASP.NET MVP]

3/6/2006 9:28:00 PM

0

keep us posted. That ones got my interest.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



"Manso" <Manso@discussions.microsoft.com> wrote in message
news:33502819-8452-4C56-AA13-7DBA1167B3E8@microsoft.com...
> I agree. There is something fishy with the Cache (my post two post above
> yours). I can't figure out what's going on. You are not using
> HttpRuntime.Cache, are you?
>
> Let me do some more investigation on HttpContext.Current.Cache. It seems
to
> work there but I have a few gerneic functions located in a class lib that
are
> being executed using CallbackTimer so I need to access the
HttpRuntime.Cache.
>
> - M
>
> "MichaelY" wrote:
>
> > Among the most frequent are Cache.Insert()ions with objects that
literally
> > seem to 'dissappear'. In other words, I load up a metadata table
(DataTable)
> > into Cache. Every field on a group of web forms use this info to
control
> > rendering, display visibility, etc. However, the pattern that we end up
> > seeing is the object being removed LONG before it's expiration (15
mins), and
> > then subsequent insert()'s failing (meaning the object isn't present
after
> > the insert - like the insert said 'nope...sorry').
> >
> > I have been able to 'pin' the objects there by specifying
> > CacheItemPriority.NotRemovable, but why should I have to do this??? I
expect
> > on a machine with 4GB's of RAM (and the worker using about ~100MB) for
the
> > items to be there for a least a few minutes (maybe 15???)....and then it
> > would be nice to have other calls to Insert() work.
> >
> > On the product feedback center for MS, this issues has been reported,
but is
> > marked as "not reproducable". Seems odd, doesn't it????? Especially
when
> > others report the same problem. Have there been landslide changes in
the
> > CacheManager, or some other subsystem (HealthMonitoring maybe???) that
is now
> > chewing up heap space????
> >
> > Grrr....LoL..

Manso

3/6/2006 9:41:00 PM

0

I posted a possible solution on a separate thread...

http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.dotnet.framework.aspnet.caching&mid=21114551-f902-42ad-ac5b-c3df5d941d95&...

Is your problem similar to this?

- Manso

"MichaelY" wrote:

> Among the most frequent are Cache.Insert()ions with objects that literally
> seem to 'dissappear'. In other words, I load up a metadata table (DataTable)
> into Cache. Every field on a group of web forms use this info to control
> rendering, display visibility, etc. However, the pattern that we end up
> seeing is the object being removed LONG before it's expiration (15 mins), and
> then subsequent insert()'s failing (meaning the object isn't present after
> the insert - like the insert said 'nope...sorry').
>
> I have been able to 'pin' the objects there by specifying
> CacheItemPriority.NotRemovable, but why should I have to do this??? I expect
> on a machine with 4GB's of RAM (and the worker using about ~100MB) for the
> items to be there for a least a few minutes (maybe 15???)....and then it
> would be nice to have other calls to Insert() work.
>
> On the product feedback center for MS, this issues has been reported, but is
> marked as "not reproducable". Seems odd, doesn't it????? Especially when
> others report the same problem. Have there been landslide changes in the
> CacheManager, or some other subsystem (HealthMonitoring maybe???) that is now
> chewing up heap space????
>
> Grrr....LoL..

Michael Y

3/7/2006

0

That is the exact "solution" is used to pin the objects into the cache.
However, as I mentioned above, I don't consider this a viable solution (after
all, I'd still like the scavenger to do what it does best).

I guess the crux of the issues is this: If there were such a change in the
runtime, then how come no one seems (MS???) to know about it????

....sigh.

Manso

3/7/2006 11:43:00 AM

0

I agree with you. The workaround feels a bit shakey.

As this is a managed newsgroup we can always hope that someone from MS pays
attention to it or at least comment on it. Once pinned down I don't feel I
have the time to report it through our support contract.

- Manso

"MichaelY" wrote:

> That is the exact "solution" is used to pin the objects into the cache.
> However, as I mentioned above, I don't consider this a viable solution (after
> all, I'd still like the scavenger to do what it does best).
>
> I guess the crux of the issues is this: If there were such a change in the
> runtime, then how come no one seems (MS???) to know about it????
>
> ...sigh.

Jim Cheshire

4/30/2006 11:36:00 PM

0

On Tue, 7 Mar 2006 03:42:58 -0800, Manso
<Manso@discussions.microsoft.com> wrote:

>I agree with you. The workaround feels a bit shakey.
>
>As this is a managed newsgroup we can always hope that someone from MS pays
>attention to it or at least comment on it. Once pinned down I don't feel I
>have the time to report it through our support contract.
>
>- Manso
>
>"MichaelY" wrote:
>
>> That is the exact "solution" is used to pin the objects into the cache.
>> However, as I mentioned above, I don't consider this a viable solution (after
>> all, I'd still like the scavenger to do what it does best).
>>
>> I guess the crux of the issues is this: If there were such a change in the
>> runtime, then how come no one seems (MS???) to know about it????
>>
>> ...sigh.

If you can provide me with a repro of this, I can look into it. You
can send it to jamesche at Microsoft.com.
Jim Cheshire
Blog: http://blogs.msdn.co...