Comments for ICE09 . playing with java, scala and spring .

Comment on Spring 3 on the Google App Engine: REST in Peace by Google App Engine, GWT, Spring 3, JPA and Google Spreadsheet « ICE09 . playing with java, scala and spring .

Thu, 19 Nov 2009 22:56:23 +0000

[...] June 7, 2009 — ice09 If you are interested in Spring 3 on the GAE, there is a newer post about just this topic (and some [...]

Comment on Spring 3 on the Google App Engine: REST in Peace by Google App Engine, GWT, Spring 3 and JPA « ICE09 . playing with java, scala and spring .

Thu, 19 Nov 2009 22:54:35 +0000

[...] 3 and JPA May 25, 2009 — ice09 If you are interested in Spring 3 on the GAE, there is newer post about just this topic (and some REST!). UPDATE: The github repository for this post is here. An [...]

Comment on Google App Engine, GWT, Spring 3, JPA and Google Spreadsheet by Google Chart API with Gaelyk on the Google App Engine « Ice09

Google Chart API with Gaelyk on the Google App Engine « Ice09 — Wed, 04 Nov 2009 00:08:15 +0000

[...] Access class already exists (cmp. this post) [...]

Comment on Google App Engine, GWT, Spring 3, JPA and Google Spreadsheet by ice09

ice09 — Sun, 09 Aug 2009 21:10:51 +0000

Hi Jesper,

did you try to download and use the github download?
It sounds like the google jars are missing, you can get them here:

http://code.google.com/p/gdata-java-client/downloads/list

Best,

Alex

Comment on Google App Engine, GWT, Spring 3, JPA and Google Spreadsheet by ice09

ice09 — Sun, 09 Aug 2009 20:59:00 +0000

Hi,

sorry, did not get the notification about the comment… Will look into it.

Best,

Alex

Comment on Google App Engine, GWT, Spring 3, JPA and Google Spreadsheet by Jesper

Jesper — Fri, 31 Jul 2009 09:42:37 +0000

Hi!
Impressive! I have tried to follow your example…
When run it I get the following error:

31-Jul-2009 11:32:39 com.google.apphosting.utils.jetty.JettyLogger warn
WARNING: Nested in javax.servlet.ServletException: init:
java.lang.NoClassDefFoundError: com/google/gdata/util/ServiceException
at java.lang.Class.getDeclaredConstructors0(Native Method)
…
…
Caused by: java.lang.ClassNotFoundException: com.google.gdata.util.ServiceException
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
…
…

What have i missed?
Thanks,
J

Comment on Analysing Memory Leaks with BTrace by williamlouth

williamlouth — Fri, 17 Jul 2009 10:06:34 +0000

There are two ways of doing this the new approach (cost centers metering) and the old style way (probe tracking).

The new approach (which you missed in the entry) scales in production as it shows you which packages, classes, and methods directly (inherent total) or indirectly (total) result in a Set.add(…) call being made across threads, processes, hosts and clusters with even maximum values and variances recorded. Most of the time one is only concerned with what is called from their own code base which would be satisfied via the inherent total analysis.

Then there is the tracking probes extension for those that like to click, click, click, click…….

http://www.jinspired.com/products/jxinsight/new-in-5.7.html
“Trackings can be used to Track (trace) back the usage of resources to one or more metered calling activities (probes). Like most other elements of the resource metering model Trackings support aggregation across Metering Contexts (hosts, processes and threads).”

You can see the use of tracking in this blog entry:
http://williamlouth.wordpress.com/2009/01/27/abc-for-cloud-computing/

Alternatively you can use our charges extension and custom probes which map meters to actually metering activity representing the operation (Set.add) itself.

Search for: “Custom Resource Meters” and “Charges”
http://www.jinspired.com/products/jxinsight/new-in-5.7.html

We have various approaches built on a bare metal runtime each with varying runtime collection and overhead characteristics. But at least you have the choice of going super fast or just fast,

Comment on Analysing Memory Leaks with BTrace by Jaroslav Bachorik

Jaroslav Bachorik — Fri, 17 Jul 2009 09:26:24 +0000

From the example given I can not see how to get the call traces (which creates the biggest overhead for the btrace approach) Set.add() calls. How can I get the information about who initiated the operation resulting in calling Set.add() 1000x ?

Comment on Analysing Memory Leaks with BTrace by williamlouth

williamlouth — Fri, 17 Jul 2009 09:03:09 +0000

Why enable object allocation for the whole JVM unless one is only using JVMPI?

JVMTI which removed object allocation event notification requires vendors to instrument the constructors themselves. So again why instrument all when you can narrow this down to particular instances you want tracked. I know one product that allows this and I doubt others will not follow unashamedly.

By the way I would approach this from a caller perspective (who calls Set.add(..)) rather than instrument all Set implementation classes. This allows me to narrow this down to those methods called directly from my own application code base.

The overhead of the above (print out) would be HUGE. There is no debating that. Here is how this can be achieved without the HUGE overhead of the btrace script. Simply replace the “hibenate.add.count” with “set.add.count” meter which we provide as a set of extensions for Collections metering.

http://williamlouth.wordpress.com/2009/02/24/efficient-runtime-analysis-of-hibernate/

I will try to get out a blog showing this for those that cannot see the method (approach) from the detail in the entry.

William

Comment on Analysing Memory Leaks with BTrace by Jaroslav Bachorik

Jaroslav Bachorik — Thu, 16 Jul 2009 13:49:05 +0000

But you need to enable allocation tracking for the whole application, don’t you? AFAIK there are no allocation stack traces in heap dumps obtained from Sun’s JVM (up to the latest update of JDK6). There is supposed to be this information in some of the upcoming updates, though. Then, all you need would be a heap analyzing tool supporting this additional info.
Also, you can lower the overhead of the BTrace script by not tracking each single call to “add” method – you can narrow down tracing to the calls to “add” initiated directly from certain classes/methods.