Dave, I've found using SSH tunnels can make debugging the JVM easier. I haven't tried using Yourkit via a tunnel, but I suspect it would work. Maybe worth a try. Some more details on setting up the tu

+1 - I miss the link at the bottom too. Dan

I'm happy to see the size of the build packs dropping, but I have to ask why do we bundle the build packs with a fixed set of binaries? The build packs themselves are very small, it's the binaries tha

wrote: I think it would depend, you'd probably be OK with your simple hello world app. Something more complicated using third party libraries, may have trouble. I'd personally try to avoid that and ju

Sorry for the duplicate. Resending as my first reply didn't go back to the list. Since the Connector in server.xml is not specifically setting an implementation it should use the NIO connector, which

daniel.jones(a)engineerbetter.com> wrote: Since it seems activity related, have you tried monitoring the number of threads in the JVM? While you can cap the number of threads Tomcat uses for processin

wrote: +1 and +1 Dan

This sounds cool. Can't wait to see what you guys come up with here. I've been thinking about the subject a bit, but haven't come up with any great ideas. The first thought that came to mind was a tra

I was testing an app on Diego today and part of the test was for the app to fail. I simulated this by putting some garbage into the `-c` argument of `cf push`. This had the right effect and my app fai

There's a known issue that occurs when an app starts and fails in rapid succession and results in the log entries being missed. If you add a couple second pause into the app, it will give the system e

The Java build pack does not put Java on the path, which is what you're seeing in the error below. I will usually run `CF_TRACE=true cf app <app-name> | grep "detected_start_command"` which shows the

Did you set the `path` attribute correctly? It should be the relative path to your JAR or WAR file. Also, how many files are in your JAR? Does that match the number listed here? What if you extract th

wrote: I don't think so, I think that's a limitation of SAML. Check out this thread for some more info on this. http://cf-dev.70369.x6.nabble.com/cf-dev-UAA-SAML-and-LDAP-questions-td62.html Dan

As long as the path attribute in your manifest is set correctly (i.e. pointing to your JAR/WAR file), I wouldn't worry about this. You're probably seeing slight differences in the count / size of file

And so you'd want to set `command` to `sleep 2 && CALCULATED_MEMORY=$($PWD/. java-buildpack/open_jdk_jre/bin/java-buildpack-memory-calculator-1.1.1_RELEASE -memorySizes=metaspace:64m.. -memoryWeights=

Double check that your app is configured to log to STDOUT / STDER. If it's logging to a file, you won't see the messages since the system only captures STDOUT & STDERR. Also, you might try a demo app

I'd be happy to try the demo and see if it works for me. Can you post a complete project on github so I can just `git clone` & build? Dan

Hmm, OK. I thought you had a minimal example from you last note. I'm not really up for running untrusted binary code. If you can put a minimal code sample together, I'll give it a try. That seems OK.

I've found this article to be helpful. How you capture the metrics might be different, but it talks about some of the important metrics and what they mean. http://blog.pivotal.io/pivotal-cloud-foundry

daniel.jones(a)engineerbetter.com> wrote: Seems odd. Every time you stage an app, you should get a copy of the latest app bits (i.e. what was pushed up by cf). If you're not getting the latest set of