UPDATE/FYI,
I am really really pleased with TomEE 1.6.0 snapshot (2013-04-29), which
includes OWB 1.2. I see memory used range from 130m to 700m or 800m.
Because of the 700m or 800m memory used, I increased -Xms/-Xmx to 3000m,
but since my app runs as little as 130m, I am motivated to revert to my
previous setting, -Xms/-Xmx to 1250m.
Also, I set debug = false on some of my asynchronous/task-driven MDBs and
@Singleton beans, so tomcat/tomee not outputting a lot to log
file(s)...right now.
Also, today (this morning), I 'finally' moved a big List<Object> (or
ArrayList<Object>) from a POJO, which was a member of a CDI @SessionScoped
bean...to a CDI @RequestScoped bean. Wow, that took all morning, because I
had the newly-developed CDI @RequestScoped bean (trying to) access some
members of the primary/huge @SessionScoped bean, and that resulted in the
infamous-and-unwanted cyclic reference, since the @SessionScoped bean
references the @RequestScoped bean at user login.
Anyway, I finally decided 'not' to reference @sessionscoped bean from the
@RequestScoped bean, and @PostConstruct will use today's date to populate
the list with a default and most-likely-expected set of data that will be
needed-and-used by endusers.
Advantage: from what I have heard and seen/experienced, it is better to
have less @sessionscoped beans and more @requestscoped beans, if at all
possible; prior to this code change, this morning, I saw that this
'orderNumber' had many instances (3rd in the list, at the top) in heap dump
(jvisualvm); just this evening (within last hour), I did a heap dump, and
this 'orderNumber' had 0 instances, and the @RequestScoped bean had '1'
(one) instance, which small footprint. Mission accomplished! i study my
app's performance and memory-use almost-daily, and I been spending a lot of
time trying to improve this, improve that. :)
Disadvantage: prior to code change, i had more control of accessing
database and populating this List<OrderNumber>...a lesser amount of
times...via @SessionScoped bean. Now, since the code change, @RequestScoped
bean accesses the database more (on every request), and I have less
control, since my @RequestScoped bean cannot be initialized via members of
the @SessionScoped bean; the @sessionscoped bean is a primary bean and
driver for many of the popular functions in the app. So far, I don't think
this is posing itself as a degradation in performance, because I am using
'eclipselink' query hints (query results cache and readonly), and the app
is 'still' performing well, and IMO/FWIW, this code change helps tomee/GC
manage memory better, too.
Please note... there are no complaints here at all; this code change meets
(my/business) requirements, completely (100%). Per business requirement,
this List<OrderNumber> changes a lot per user actions (http requests)
during user session. recently, a database/sql 'view' came to mind, but
honestly, I prefer not to write much sql (triggers, database functions,
cursors, etc...). JSF, CDI, JPA, and Java EE allows me to write code that
meet business requirements. Endusers are very happy with the app, overall.
still room for improvement and more features to add. I'm loving the
experience! :)
Below is the newly-developed CDI @RequestScoped bean that I developed.
package jsf.orders;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.ejb.EJB;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
import jpa.entities.Orders;
import jpa.session.OrdersFacade;
import org.joda.time.DateTime;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Named
@RequestScoped
public class OrderNumberRequestBean implements Serializable {
private final Logger logger = LoggerFactory.getLogger(getClass());
private Boolean duringPostConstruct;
private DateTime beginDate, endDate;
private List<OrderNumber> orderNumberList;
@EJB
OrdersFacade ejbFacade;
public OrderNumberRequestBean() {
// constructor
}
@PostConstruct
protected void init() {
duringPostConstruct = true;
// BEGIN date = January 1, XXXX (where XXXX = year of beginDate)
DateTime dateTimeFrom = DateTime.now();
dateTimeFrom = dateTimeFrom.withMonthOfYear(1).withDayOfMonth(1);
beginDate = dateTimeFrom;
// END date = December 31, XXXX (where XXXX = year of endDate)
DateTime dateTimeTo = DateTime.now();
dateTimeTo = dateTimeTo.withMonthOfYear(12).withDayOfMonth(31);
endDate = dateTimeTo;
orderNumberList = null;
/*
* 1. initialize orderNumberList with ORDER #'s for the current year
* 2. do NOT make this bean reference pf_OrdersController, or will
* result in cyclic reference
*/
try {
initOrderNumberList(beginDate.toDate(), endDate.toDate());
} catch (Exception e) {
logger.info("Caught exception: " +
(e.getMessage() != null ? e.getMessage() :
e.getLocalizedMessage()));
}
duringPostConstruct = false;
}
@PreDestroy
protected void releaseResources() {
orderNumberList = null;
}
public Integer getOrderNumberForOrder(Orders order) {
Integer orderNumber = 0;
try {
// just in case, the YEAR of ORDER's trip date is in ANOTHER
YEAR
initOrderNumberList(order.getTripDateTime(),
order.getTripDateTime());
} catch (Exception e) {
// do nothing
}
if (orderNumberList != null && order != null && order.getOrderId()
!= null) {
for (OrderNumber oNumber : orderNumberList) {
if (oNumber == null || oNumber.getOrderId() == null ||
oNumber.getOrderNumber() == null) {
continue;
}
if (oNumber.getOrderId().equals(order.getOrderId())) {
orderNumber = oNumber.getOrderNumber();
break;
}
}
}
return orderNumber;
}
public void initOrderNumberList(Date beginDate, Date endDate) throws
Exception {
if (!duringPostConstruct) {
DateTime begin = new DateTime(beginDate),
end = new DateTime(endDate);
if (begin.getYear() >= this.beginDate.getYear() &&
begin.getYear() <= this.endDate.getYear() &&
end.getYear() >= this.beginDate.getYear() &&
end.getYear() <= this.endDate.getYear()) {
return;
}
this.beginDate = new DateTime(beginDate);
this.endDate = new DateTime(endDate);
}
try {
// Trip Date FROM = January 1, XXXX (where XXXX = year of
beginDate)
DateTime dateTimeFrom = new DateTime(beginDate);
dateTimeFrom =
dateTimeFrom.withMonthOfYear(1).withDayOfMonth(1);
Date dateFrom = dateTimeFrom.toDate();
// Trip Date TO = December 31, XXXX (where XXXX = year of
endDate)
DateTime dateTimeTo = new DateTime(endDate);
dateTimeTo = dateTimeTo.withMonthOfYear(12).withDayOfMonth(31);
Date dateTo = dateTimeTo.toDate();
String tripDateFrom = (new
DateTime(dateFrom).toString("yyyy-MM-dd"));
String tripDateTo = (new
DateTime(dateTo).toString("yyyy-MM-dd"));
List<Orders> orderConfirmedList =
ejbFacade.findAllConfirmed(tripDateFrom, tripDateTo, false);
if (orderConfirmedList != null) {
DateTime dateTimeYear;
Integer year = 0, yearOfTripDate, orderNumber = 0;
orderNumberList = new ArrayList<>();
for (Orders o : orderConfirmedList) {
// when calendarYear changes, then orderNumber = 0;
dateTimeYear = new DateTime(o.getTripDateTime());
yearOfTripDate = dateTimeYear.getYear();
if (!year.equals(yearOfTripDate)) {
orderNumber = 0;
year = yearOfTripDate;
}
// add Orders.orderId and CONFIRMED orderNumber to
orderNumberList
orderNumber++;
orderNumberList.add(new OrderNumber(o.getOrderId(),
orderNumber));
}
}
else
orderNumberList = null;
} catch (Exception e) {
throw e;
}
}
}
On Sat, May 4, 2013 at 7:02 PM, Howard W. Smith, Jr. <[email protected]
> wrote:
>
> On Thu, May 2, 2013 at 2:21 AM, Romain Manni-Bucau
> <[email protected]>wrote:
>
>> thinking to it, we had a bunch of enhancement regarding tld scanning
>> caching which could explain a part of it + a better scanning for rest part
>> (i was testing a rest app)
>>
>> that said 33M vs 40M after GC sounds not aweful for a faster startup and a
>> more consistent runtime
>>
>>
> Okay, I've made some changes in my configuration.
>
> 1. Of course, still using last/latest TomEE 1.6.0 snapshot (2013-04-29
> version) that I downloaded
>
> 2. Reverted to Atmosphere 1.0.12, because I found that a stable version
> and I really did not need Atmosphere 1.0.13 'snapshot' at all.
>
> 3. Increased -Xms/-Xmx from 1250m to 3000m, since I recognized latest
> TomEE 1.6.0 snapshot (OWB 1.2) seem to 'use' more memory; 600m x 5 = 3000m
> (lowest memory required to run app x 5, as recommended on tomcat list); i
> 'assumed' that my app requires 600m, since I usually see memory used = 600m
> most of the time I login to production server and check heap/memory used
> via jvisualvm
>
> With all that said,
>
> * screen capture[1] shows memory-used above 800m; this was few minutes
> after I stopped doing some heavy lifting (or activity) in web app
>
> * screen capture[2] shows that memory-used dropped to approximately 140m
> (evidently, due to some GC)
>
> So, based on all this, should I keep -Xms/-Xmx at 3000m or decrease it to
> 1250m, as I had it set to that earlier? FWIW (and from what I remember), my
> web app has never experienced an OOME. On my development server, I think I
> set -Xmx to 512m and -Xms may be 256m, and I never experience any issues
> starting/testing/stopping the web app.
>
>
> [1] http://imageshack.us/a/img23/5043/20130504jvisualvm1.jpg
>
> [2] http://imageshack.us/a/img11/2079/20130504jvisualvm2.jpg
>
>
