[ https://jira.terracotta.org/jira//browse/CDV-331?page=comments#action_21915 ] Tim Eck commented on CDV-331: -----------------------------
The only way I can get this to fail in a similar fashion is too suspend (ctrl-Z) one of the clients. The heap is 80% byte arrays at that time. The L2 heap settins aren't that important -- the test updates a single field of a single object in a tight loop. The code looks like it wants to produce 10 changes per transaction, but it is effectively 1 since we optimize the case of changing the same field in the scope of a txn (good thing we don't optimize the case where the value doesn't actually change, then we'd really see some perf numbers). Steps to reproduce: 1) get a 2.4 kit 2) Unpack the attached source in samples/pojo/inventory 3) run ant clean compile there 4) Change run.sh to use -Xmx128m -Xms128m 5) Start two clients, in each type "L" followed by enter 6) Suspend one of the clients, the other will OOME > Out of Memory and then death > ---------------------------- > > Key: CDV-331 > URL: https://jira.terracotta.org/jira//browse/CDV-331 > Project: Community Development > Issue Type: Bug > Components: Sample Apps > Affects Versions: 2.4-stable1 > Reporter: Ari Zilka > Assigned To: Issue Review Board > Attachments: inventory_pounder.tgz > > > While running an edited version of the inventory app, I come across an L1 > OOME only once 2 L1's are present. I am running everything on 1 computer, > and I am pretty sure this doesn't reproduce when I run a separe L2. > I will attach the stack trace of the eventually "hung" L1 that eats 100% of > CPU from the time it OOME's till I kill -9 it. > I also have the edited inventory demo attached as a zip. And, FYI, I edited > the -Xmx and -Xms on the L2 to 750MB and on the L1s to 128MB -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.terracotta.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
