Develop Reference

Memory overflow in org.hibernate.internal.SessionImpl

I have WebSphere 8.0.0.7 application server with Spring(3.2.1)/Hibernate(4.1.9) application installed.
After several weeks of continuous work PROD stage failed due to Java heap overflow.
Analysis of PHD dominator tree shows the following:
Looking at Hibernate sources I can't really understand where those char sequences may take place.
Internet gave me several similar leaks for older version of WebSphere, but they seems to be fixed the version I use.
Does anyone may help to understand a root cause?

Don't use MAT to analyze IBM dumps. IBM HeapAnalyzer shows better tree without strange memory consumers definition.

What are risks of updating JRE for a desktop application on Windows

I'm planning to update the JRE to the latest version for Java application on windows. The application runs on windows 7 and JRE 7u17.
While I updated it without any issues. I just have these two questions:
Are there risks I should consider while upgrading? Is there a better way to test if the application still runs the same as on JRE7.
Thanks in advance,
Best

There are no risk but there are things to take care of while upgrading from 7 -> 8
In my personal experience I found following things
In my personal experience I had to update all the frameworks which deal with class level operations (spring, tapestry-plastic, etc.. ) and some of them had API changes as well making a huge change in code base
apart from language side there are some changes in VM too, for example: metaspace is introduced and no more permgen space, some stuff from permgen moved to heap, so you might have to re-tune your JVM, there are other things in new JVM you could take advantage of as well

Sudden Java Heap Space errors on Tomcat 5.5

We have a Spring 2.0.8 application in production, running on Tomcat 5.5.x and JRE 1.5.x (yeah, I know, we should upgrade, that's not the point now), with Oracle 11g as our choice of DB.
We have upgraded the application some months ago (I'd say July) and have switched from Oracle 10g to Oracle 11g in the past month or so (also changing the Oracle JDBC driver to match the database version).
We've been having serious and unexpected problems in production. As of a day ago, there have been heap space OutOfMemory errors several hours apart. This in turn either slows down response time by about a 100 times, or the users can't connect.
Our setup is:
Windows machine to run the server
Apache 2.2 and Tomcat 5.5 with SSO enabled, total memory: 128MB, max memory: 512MB
Spring 2.0.8 Webapp
Oracle 11g
Since noticing this error, this is what we tried:
checking out the logs - there doesn't seem to be a pattern.
Obviously, logs only tell you when the server is out of memory, so
they show the point of not working anymore, instead of the point
where the problem started
restarting server
reinstalling Tomcat
increasing amount of memory Tomcat can use - this just prolonged the issue, of course Tomcat ate just as much as we gave it
fresh installation of both the server and Apache+Tomcat
generating heap dumps - nothing spectacular seems out of the ordinary, most memory is used for starting up the application
checking the DB - it's fine, quick and responsive, no locks
I'm looking out for ideas on what else to do. We have this same setup in 5 different productions in total, this problematic one being with the smallest number of users and data.

Now that you have figured it out, I recommend that you add the following to the list of things to do REAL SOON:
Upgrade your JVM to Java 7. Java 5 has been "end-of-lifed" which means that you won't be getting any more security patches ... unless you are on an Oracle Java support contract.
If you can't upgrade to Java 7 ... or Java 6, then at least upgrade to the most recent patch release for Java 5 that you can get hold of.
Upgrade to Tomcat 6 or 7, or at least to the most recent Tomcat 5.5.
To head off problems where OutOfMemoryError causes severe slowdowns, make sure that you have the -XX:+UseGCOverheadLimit option on your JVM command line.
And, if you plan to do any significant development work on that system, consider upgrading it to Spring 3.x.

Ok, we figured this one out. It turns out it was a badly written SQL query which was scarcely used. Analyzing the heapdump helped find the objects that were taking up a lot of memory, and we went from there.

Java (JVM) on ARMv7 (more specifically Cubox or BeagleBoard)?

I was wondering if anyone have gotten Java up and running on a BeagleBoard or Cubox? I'm thinking about buying one for a project I'm working on on my spare time, but as parts of this project is written in Java I first wanted to know if these tiny computers can run a JVM at all?
From what I read on http://www.oracle.com/technetwork/java/embedded/downloads/javase/index.html there are editions for ARM, and Solid-Run (the manufacturer behind Cubox) have also written some info on their wiki: http://www.solid-run.com/mw/index.php/Oracle_Java_on_CuBox.
However, what I would need to know is:
Can I consider ARM JVM == x86/x64 JVM in terms of functionality (a.k.a. "will my code run without changes") (my code is pretty non-graphical, mainly a HTTP API)?
Are there any license "problems" with JVM on ARM (compared to JVM on x86/x64)? That is, if I suddenly want to mass-produce my little spare-time hobby project and sell Cuboxes, will Oracle sue me?
Anyone have any experience with Hibernate/HSQLDB on ARM?
Perhaps too many questions in one, but I think they're all related enough to be put in the same thread. In general, I want to know more about JVM on ARM and how developed and mature it is.
Thanks!

Answers to 1 and 2 are on the Oracle page. "development is free, but royalties are required upon deployment on anything other than general purpose systems. In all cases, these products are fully Java SE compliant"
As for 3, I don't know about Hibernate (which shouldn't be a problem), but HSQLDB has been used on ARM by Symbian and others at least since 5 years ago.

low cpu footprint java embeded database

This is a follow up to a question i asked at java disc based hashmap for a disk based hashmap.
The solution suggested works but at a high CPU cost. I've tried using a few embeded databases, including hsqldb and derby as well as an sqllite implementation in java.
The all get the job done, quite slowly for most of the ones i've tried, the three i mentioned beformed the best. I ran into one problem with all of them however.
Starting and maintaining each embeded database required a lot of CPU time, the ones i haven't mentioned used up 100% of the cpu most of the time,according to task manager.
My new question then is, are there any simple disc based storage that won't eat away my cpu.
for the record, the sqllite solution didn't spike cpu usage it was just crashing with a range of different errors. And apache derby had the best performance and cpu usage fluctuated with it but on average was about 80%

I have no experience with other embedded java DB then Apache Derby and HSQLDB.
Some links:
Open Source Database Engines in Java
LinkedIn answers
Did you tried some NoSQL DB?
Update
Here is a list of NoSQL databases. I have no experience with them. But MongoDB and CouchDB are quite famous. And also Db4o looks interesting.

Try H2 Database