SoftReferences to PageImpl can cause performance problems
Hello, I recently came accross the implementation of PageSourceImpl where PageImpl instances are softly refereneced into the pageCache: private final MapCachedPageKey, SoftReferencePage 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
Unable to locate a single EntityManager. You must provide the persistence unit name as defined in the persistence.xml using the @PersistenceContext annotation.
Hi,
i got a ejb with two entities.
All is working fine, but if i persist the entity, it got this error:
Unable to locate a single EntityManager. You must provide the
persistence unit name as defined in the persistence.xml using the
@PersistenceContext annotation.
@Inject
@PersistenceContext(unitName = de.aeits_ERDA-CCIS-EJB_ejb_1.01PU)
private EntityManager entityManager;
@Log
@CommitAfter
Object onSuccess() {
logger.log(Level.INFO, erfolgreicher Login von {0}, user);
try {
Users users = entityManager.find(Users.class, user);
logger.log(Level.INFO, User {0}, user);
users.setIp(requestGlobal.getHTTPServletRequest().getRemoteAddr());
// entityManager.getTransaction().begin();
entityManager.merge(users);
// entityManager.getTransaction().commit();
} catch (Exception e) {
logger.log(Level.INFO, Es ist ein Fehler aufgetreten: {0}, e);
}
return Index.class;
}
If i remove the annotation @CommitAfter and do it with
entityManager.getTransaction().begin() and
entityManager.getTransaction().commit(), it works.
Any hints?
TIA
Andreas
--
ae | Andreas Ernst | IT Spektrum
Postfach 5, 65612 Beselich
Schupbacher Str. 32, 65614 Beselich, Germany
Tel: +49-6484-91002 Fax: +49-6484-91003
a...@ae-online.de | www.ae-online.de
www.tachyon-online.de
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: SoftReferences to PageImpl can cause performance problems
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 MapCachedPageKey, SoftReferencePage 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
Re: SoftReferences to PageImpl can cause performance problems
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 MapCachedPageKey, SoftReferencePage 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
Re: Unable to locate a single EntityManager. You must provide the persistence unit name as defined in the persistence.xml using the @PersistenceContext annotation.
Hi Andreas,
I assume you have more than one persistence context. In this case you have
to add the @PersistenceContext annotation to your onSuccess() method.
Otherwise the system doesn't know which persistence context it should use.
(The related code is in JpaInternalUtils.getEntityManager() and
in EntityManagerManagerImpl)
Hope that helps.
Felix
2015-03-17 11:16 GMT+01:00 Andreas Ernst a...@ae-online.de:
Hi,
i got a ejb with two entities.
All is working fine, but if i persist the entity, it got this error:
Unable to locate a single EntityManager. You must provide the persistence
unit name as defined in the persistence.xml using the @PersistenceContext
annotation.
@Inject
@PersistenceContext(unitName = de.aeits_ERDA-CCIS-EJB_ejb_1.01PU)
private EntityManager entityManager;
@Log
@CommitAfter
Object onSuccess() {
logger.log(Level.INFO, erfolgreicher Login von {0}, user);
try {
Users users = entityManager.find(Users.class, user);
logger.log(Level.INFO, User {0}, user);
users.setIp(requestGlobal.getHTTPServletRequest().getRemoteAddr());
// entityManager.getTransaction().begin();
entityManager.merge(users);
// entityManager.getTransaction().commit();
} catch (Exception e) {
logger.log(Level.INFO, Es ist ein Fehler aufgetreten: {0}, e);
}
return Index.class;
}
If i remove the annotation @CommitAfter and do it with
entityManager.getTransaction().begin() and
entityManager.getTransaction().commit(),
it works.
Any hints?
TIA
Andreas
--
ae | Andreas Ernst | IT Spektrum
Postfach 5, 65612 Beselich
Schupbacher Str. 32, 65614 Beselich, Germany
Tel: +49-6484-91002 Fax: +49-6484-91003
a...@ae-online.de | www.ae-online.de
www.tachyon-online.de
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
