When you create a container in fabric you can specify which options should be passed to the container. This way you can set the amount of memory for instance, but you can also specify that the container should start in debug modus.
The following Fuse CLI command would create a container with a maximum heap size of 256 MB:
container-create-child --jvm-opts "-Xmx256m" root child
In the Hawt.io console you’ll find the “Jvm opts” option under the “Advanced” tab on the container creation page.
Now you can also use this to pass the regular debug commands to a JVM: “-Xdebug -Xrunjdwp:transport=dt_socket,address=5001,server=y,suspend=n”.
The CLI command would then look like this:
container-create-child --jvm-opts "-Xdebug -Xrunjdwp:transport=dt_socket,address=5001,server=y,suspend=n" root child
The suspend=n part means that the JVM won’t wait for a debugger to connect but will startup like usual. If you need to see what happens in the JVM right after it starts you can change this to suspend=y. The JVM will then block until a debugger is connected.
I noticed the (optional) fan on my Odroid U3 frequently spinning up only to shut down again 1 second later. This appeared rather buggy to me so I looked into how to control the fan. This is what I found:
You can switch the fan into ‘auto’ or ‘manual’ mode:
echo auto > /sys/devices/platform/odroidu2-fan/fan_mode
echo manual > /sys/devices/platform/odroidu2-fan/fan_mode
Note: The ‘odroidu2′ part of the path is not a typo! Strangely enough the U3 uses the same device path as the U2.
Once you’ve switched the fan into manual mode, you can set the speed of the fan by echo-ing a value between 0 (0%) to 255 (100%) to the fan controller:
echo 0 > /sys/devices/platform/odroidu2-fan/pwm_duty (fan off)
echo 255 > /sys/devices/platform/odroidu2-fan/pwm_duty (fan on full speed)
Fun fact: You can get into an argument with the automatic fan controller by setting the fan speed while in auto mode. The fan will respond to your command but the automatic controller will shut it down after noticing what you did. :)
While playing with the fan use the following command to read the CPU temperature:
And to run a CPU stress-test that utilizes all 4 cores use this command:
sudo openssl speed -multi 4
User xana (among others) has posted a script on the odroid u3 forum that uses the commands described above to periodically set the fan speed based on CPU temperature: http://forum.odroid.com/viewtopic.php?f=83&t=6275
If you have the latest version of the kernel it gets even simpler. You can set the temperature above which the fan should be used to cool down the SoC:
echo 60 > /sys/bus/platform/devices/odroidu2-fan/start_temp
After installing Netbeans and Java7 for some JavaFX tinkering several of my other apps stopped working.
A lot of the solutions I found online involve writing scripts or changing startup scripts for specific programs, but I found none of them easy or maintainable enough. I ended up altering the symbolic link named “Current” in /System/Library/Frameworks/JavaVM.framework/Versions
A link called CurrentJDK in the same directory still pointed at a 1.6 version, so I simply changed the Current link to point to the CurrentJDK link. That way I can simply change it back when I want 1.7 to be the default.
sudo ln -s CurrentJDK/ Current
Today a colleague needed help with setting up a Glassfish cluster and I remembered having read a very good tutorial that created the entire cluster using only asadmin commands. In my experience using only asadmin commands not only gives you a greater understanding of the way Glassfish works internally but also enables you to create scripts for Glassfish administration commands.
Anyway, I managed to find the blogpost that I read about a year ago and decided that it was a good link to share with the world: http://www.randombugs.com/java/glassfish/installing-glassfish-31-cluster-debian-60-command-line.html
Here at ONVZ we’re using Glassfish 3 as our development and production application server, and we’re quite happy with its performance and stability, as well as the large community surrounding it. I rarely run into a problem that does not have a matching solution on stackoverflow or java.net. As part of our open source strategy we also run a customized ActiveMQ cluster called “ONVZ Message Bus”.
To enable Message Driven Beans and other EJBs to consume and produce messages to and from the ActiveMQ message brokers, ignoring the internal OpenMQ broker that comes shipped with Glassfish, an ActiveMQ Resource Adapter has to be installed. Luckily for me Sven Hafner wrote a blog post about running an embedded ActiveMQ 5 broker in Glassfish 3, and I was able to distill the information I needed to connect to an external broker instead. This blog post describes what I did to get it to work.
Although Maven offers a “convention over configuration” solution, there is still more then enough configuration necessary to cause some serious headache. In this post I will share some best practices with you that will ease maintenance of your POM files.