re predictable response
performance.
On Wed, Apr 1, 2015 at 7:31 AM, Robert Schmelzer
wrote:
Hi,
I now found time to sum up a short report about that topic.
I summarized my results in following pdf file:
http://www.schmelzer.cc/Downloads/Files/Tapestry-Memory-Performance.pdf
The main issue is, t
in memory.
Regards
Robert
Am 19.03.2015 um 17:55 schrieb Kalle Korhonen:
On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer
wrote:
Sorry, I was unprecise - my example should have referenced to the
EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not
expect them, to throw
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.
Robert
Am 18.03.2015 um 18:19 schrieb Kalle Korhonen:
On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer
wrote:
I do not agree with you on that point. Tapestry is designed to
/Loadtests which usually is later.
Am 18.03.2015 um 22:01 schrieb Thiago H de Paula Figueiredo:
On Wed, 18 Mar 2015 04:44:10 -0300, Robert Schmelzer
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
d
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
wrote:
Hello,
I recently came accross the implementation of PageSourceImpl where
PageImpl instances are softly refereneced into the page
rable 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
wrote:
Hello,
I recently came accros
Hello,
I recently came accross the implementation of PageSourceImpl where
PageImpl instances are softly refereneced into the pageCache:
private final Map> pageCache =
CollectionFactory.newConcurrentMap();
This implementation caused troubles, when you bring your system into
memory preassure
cheap RAM
;-).
Robert
Am 02.03.2015 um 16:24 schrieb Thiago H de Paula Figueiredo:
On Mon, 02 Mar 2015 11:42:57 -0300, Robert Schmelzer
wrote:
Thanks for the immediate response.
;)
We are building a product which acts as a complete backoffice
solution for a specific business type - so y
s problem?
Does anyone have an idea, how we can reuse such dialogs, without
duplicating them in the memory?
THX
Robert Schmelzer
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
totype for it. But as I feared - the answer is
not simple - we will have to rebuild 100+ dialogs if we really want to
save the RAM spendings...
Cheers
Robert
Am 02.03.2015 um 15:33 schrieb Thiago H de Paula Figueiredo:
On Mon, 02 Mar 2015 10:43:09 -0300, Robert Schmelzer
wrote:
Hi,
Hi!
es anyone have an idea, how we can reuse such dialogs, without
duplicating them in the memory?
THX
Robert Schmelzer
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
11 matches
Mail list logo
