On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer <rob...@schmelzer.cc> wrote:
> Sorry, I was unprecise - my example should have referenced to the > EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not > expect them, to throw away its cached configuration on memory preasure. I > do not either expect that from Tapestry. > I cannot make our results public because of regulatory issues. I will try > to setup a show case for that and will offer a patch. This will take me a > few days. > I don't think we are going to simply do away with the SoftReferences without any replacements so I wouldn't even attempt at offering such a patch. I just don't agree that a memory cache should be permanent construct. If your object is not in a cache, you'll simply incur a cache miss and re-create the object on the fly. It is not typical that a cache will grow indefinitely. If you are adamant on this approach, you could probably convince us to add a symbol to control the cache behavior (i.e. to never purge objects from it). Guava has excellent, easily configurable cache implementations. Kalle > Robert > > Am 18.03.2015 um 18:19 schrieb Kalle Korhonen: > > On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer <rob...@schmelzer.cc> >> wrote: >> >> I do not agree with you on that point. Tapestry is designed to cache the >>> page. When you do not have enough memory to hold your pages cached >>> basically the system does not work as designed so you should fail early. >>> Otherwise you possible defer the problem to production use. Fail early >>> means you should try to see the problem in the early stages on dev, where >>> you try out all your pages. As I mentioned in my other post - you would >>> also not expect the EntityManager to work soft-refereences or spring >>> application context to work soft referenced. >>> >>> >>> That's the definition of a memory cache - it trades memory for better >> performance. The primary use case for soft refences is for caching so >> seems >> to me it works exactly as designed. Your comparison to the EntityManager >> is >> flawed since it's created per request. An EntityManager is designed to be >> inexpensive to create. There are many areas that need improvements in >> Tapestry but this is not one in my opinion. However, you seem to strongly >> think otherwise, so you probably have some data to back this up. Do you >> have a memory dump and trending cpu/memory charts of a sufficiently large >> system you can share with us to demonstrate the problem? Jvisualvm >> snapshots should work fine. And furthermore - how would you like this >> changed? If it's just adding a Page as a threadlocal, perhaps you can just >> write a patch for it. >> >> Kalle >> >> >> Am 18.03.2015 um 04:23 schrieb Kalle Korhonen: >>> >>> In my opinion, soft referencing page objects is highly appropriate >>> usage >>> >>>> here. If there's pressure on the available memory, it makes sense to >>>> trade >>>> performance for memory instead of exiting with OoM. This is simple >>>> condition to detect and should be visible with any reasonable monitoring >>>> tool. If you are hitting memory limits, you'll need to allocate more >>>> memory >>>> for the application for optimal performance. Soft references are >>>> especially >>>> useful here because you can optimize its behavior with the >>>> -client/-server >>>> setting depending on your preferences. >>>> >>>> Kalle >>>> >>>> On Tue, Mar 17, 2015 at 4:26 PM, Howard Lewis Ship <hls...@gmail.com> >>>> wrote: >>>> >>>> Possibly we need something more advanced; our own reference type that >>>> can >>>> >>>>> react to memory pressure by discarding pages that haven't been used in >>>>> configurable amount of time. >>>>> >>>>> Or perhaps we could just assume that any page that has been used once >>>>> need >>>>> to be used in the future and get rid of the SoftReference entirely (or >>>>> otherwise janitorize it in some way). >>>>> >>>>> On Tue, Mar 17, 2015 at 1:24 AM, Robert Schmelzer <rob...@schmelzer.cc >>>>> > >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>>> I recently came accross the implementation of PageSourceImpl where >>>>>> PageImpl instances are softly refereneced into the pageCache: >>>>>> >>>>>> private final Map<CachedPageKey, SoftReference<Page>> pageCache = >>>>>> CollectionFactory.newConcurrentMap(); >>>>>> >>>>>> This implementation caused troubles, when you bring your system into >>>>>> memory preassure. The JVM will start to throw away the PageImpl to >>>>>> free >>>>>> >>>>>> up >>>>> >>>>> memory - but during request processing he needs the PageImpl again and >>>>>> starts creating it again. So basically you end up loosing your >>>>>> pageCache >>>>>> >>>>>> at >>>>> >>>>> all and start creating the PageImpl instances on every request, which >>>>>> >>>>>> take >>>>> >>>>> way to much time and takes load onto the CPU. So basically you are >>>>>> >>>>>> hiding a >>>>> >>>>> memory problem by making the system slow and raise CPU load. >>>>>> >>>>>> I would suggest to use "normal" references for the PageCache or at >>>>>> least >>>>>> only do SoftReferences only when not in production mode. Otherwise we >>>>>> are >>>>>> going to cover memory problems for too long. >>>>>> >>>>>> What do you think about that? >>>>>> >>>>>> Robert >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>> Howard M. Lewis Ship >>>>> >>>>> Creator of Apache Tapestry >>>>> >>>>> The source for Tapestry training, mentoring and support. Contact me to >>>>> learn how I can get you up and productive in Tapestry fast! >>>>> >>>>> (971) 678-5210 >>>>> http://howardlewisship.com >>>>> @hlship >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
