If you are in an environment you don’t control, like your company, to change the router configuration is not an option, so how to we solve this problem? Using reverse tunneling through SSH.

For those new to the concept of tunneling, it is a trick that you can do with virtually any ssh client so all traffic from a local port goes to a remote server and port. It is also extremely useful to bypass corporate firewall rules and to use your remote server as a SOCKS proxy (so you can access Hulu from a blocked country). You can find more details at http://www.revsys.com/writings/quicktips/ssh-tunnel.html, http://ocaoimh.ie/2008/02/13/how-to-use-ssh-as-a-proxy-server/ and Google.

But the main question here is the opposite: how to we allow anyone to access our local machines? The answer is a reverse runnel. It is very simple to get it up and running, but it took me some good hours to find the correct approch, even because I didn’t know what to search for in the beginning. The steps are:

• Change a setting in your server’s sshd_config
• Choose a remote port to connect to
• Choose the local (destination) port to route the traffic
• Open the revere tunnel

So I have a webserver running on my localhost at port 8080, and I want that when someone calls “example.com” at port 15000, it sees my local webserver. In order to do that, first go to your remove server and add the following line to sshd_config (probably /etc/ssh/sshd_config)

GatewayPorts yes

This is strickly necessary, otherwise the tunnel will only work from the server to your machine (and not from any address to your machine). You can close the ssh session if you want.

Now, from your local machine, open the tunnel:

ssh -N -R "*:15000:localhost:8080" username@example.com

type the ssh password, and that’s all. The “-N” argument just hangs the ssh client, instead of opening a remote shell, “-R” is for the reverse tunnel itself, “*:” is to listen on all interfaces (strickly necessary, otherwise it will only listen in the loopback interface), “15000″ is the port at example.com that users will connect to, “localhost” is your own local machine, and “8080″ is the port in your local machine that will get the traffic.

This is very useful for development purposes, like when I had to test Amazon SNS using an HTTP endpoint.

Local IP:

curl http://169.254.169.254/latest/meta-data/local-ipv4

Public IP:

curl http://169.254.169.254/latest/meta-data/public-ipv4

I often use this feature to pre-configure services and update configuration files, as in EC2 you get a new IP Address each time you reboot.

Despite the fact that you should be aware that such message may indicate a deeper problem, there is an easy’n dirty solution via JVM options. I have come to the fix after browsing the Interwebs for a while, and your luck may vary. The solution consists in setting up the following set of JVM arguments:

-server
-XX:+DisableExplicitGC
-XX:MaxPermSize=256m
-XX:PermSize=256m
-XX:MaxNewSize=256m
-XX:NewSize=256m
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled

I have added them all for the sake of laziness, although the last three are said to be used with caution (especially the last one)

Setting up within Eclipse

Even in 2012 I still use the Sysdeo Tomcat Plugin because of its simpliciy over Eclipse’s WTP Servers. Open Window -> Preferences (Command + , if you are using a Mac) and go to Tomcat -> JVM Settings -> Append to JVM parameters.

Setting up Tomcat standalone

Another approach is to add the arguments directly to Catalina.sh. Locate it in Tomcat’s bin directory and set the JAVA_OPTS variable, like this:

JAVA_OPTS="-XX:+DisableExplicitGC -XX:MaxPermSize=256m -XX:PermSize=256m
-XX:MaxNewSize=256m -XX:NewSize=256m -XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled"

Just restart Tomcat and you should be good to go.

SELECT field1, field2, fieldN FROM some_table

where field1, field2 and fieldN are ALL fields from some_table. Sure it is declarative programming, but you can’t get much more than that.

It is not hard to find a lot of reasons and explanations against SELECT *, but one does not simply understands the impact of something before having problems with it. It is the same thing for everything, from Design Patterns to fire and children: a developer can’t just read GoF and try to apply it “everywhere” without facing the hard way the effects of bad software design. It does not work that way. Also, a child will not understand what his parents truly mean when they say “don’t put your hand in the fire, it will burn and hurt a lot” without doing it.

So, when can SELECT * be bad? As I see it, it could have huge impacts in either disk and network I/O, and memory. The explanation is simple: the more data you ask for, the more the server has to read from the disk and transfer the data over the network to your application, and you could end using much more memory than you need for any given operation.

See the following graph from a DB server, showing I/O usage:

See the two big gaps? The disk I/O dropped when some queries were optimized to return only what the application really needed for each operation. Before that, the server I/O was hitting around 80.000 ~ 100.000 blocks per second, which for this setup is a lot. Not surprisingly, the web server was wasting a lot of memory as well.

In the end, you will have to list the pros and cons about each strategy, and remember that the application size matters – one may not see big improvements in small services.

And always remember that premature optimization is the root of all evil.

Before going into the details, here are some very valuable links:

• Monitoring and Management Using JMX, contains all property keys you may need to use, with detailed information about each one.
• Getting Started with Java Management Extensions (JMX) has a good overview of JMX in general, plus some example codes to help you get started.
• VisualVM is a graphical tool to connect to the machines and inspect the Java Virtual Machine.
• JConsole is the predecessor of VisualVM, but it still remains a good tool nowadays.

In order to get VisualVM or JConsole working with remote applications you will need to set some JVM properties on the application you want to track. In the list below are the ones that worked for me, but keep in mind that you may have different results depending on the application and the Java version (yes, it happens). In a nutshell, you’ll need to pass these properties to the JVM:

-Dcom.sun.management.jmxremote
 -Dcom.sun.management.jmxremote.port=<port>
 -Dcom.sun.management.jmxremote.authenticate=false
 -Dcom.sun.management.jmxremote.ssl=false
 -Djava.security.policy=<policy file>
 -Dcom.sun.management.jmxremote.local.only=false
 -Djava.rmi.server.hostname=<your public hostname>
 -Dcom.sun.management.jmxremote.password.file=<password_file>

“com.sun.management.jmxremote.port“ requires the port number to listen for remote RMI connections. Make sure you specify an unused one.

“java.rmi.server.hostname” is the public hostname (like example.com) of your server, without HTTP or anything else. You cannot use an internal address, otherwise you won’t be able to remotely access the service.

“com.sun.management.jmxremote.authenticate” will require an username and password if set to true, otherwise anyone that knows (or discovers) the addres will be able to connect to your JMX registry.

“com.sun.management.jmxremote.password.file” is only necessary if you set authenticate=true, and you should specify the full path of a text file with the username and passwords (in plain text) that are allowed to connect to your instance. More information about the sintaxt at http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html#auth.

“java.security.policy” is the path of a Java Policy File with the rules you need. For the sake of simplicity, you can create one with the following contents:

grant {
 permission java.security.AllPermission;
 };

You may or may not need to set the policy file (I didn’t).

You don’t need all of these properties in order to the remote JMX working. As I said before, it will depend of your luck. In my very own case, I used only these:

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname=example.com

You should pass these values when starting your java application, like

java -Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9001 [.....] -jar myapp.jar

Setting up EC2
The most important thing to set when running JMX on Amazon’s EC2 is to open the TCP ports to the IPs you will connect from, otherwise the client application won’t be able to reach the Agent. For the sake of simplicity, open all TCP ports from 0 to 65535, get it working and then keep open only the necessary ports. This approach is easier because the RMI registry that JMX uses (may?) create random ports of its communication, so you’ll have to inspect it (I am no expert on the subject, in other words).

On EC2 you configure the ports in the “Security Groups” section of the AWS Management Console.

Setting up Jetty
As a bonus, here’s how to get JMX working with Jetty. The process is fairly simple, it’s just a matter of adding the configuration keys to the right files.

First of all, you need to edit the file “start.ini” (located in Jetty’s root directory) and uncomment the line that has “etc/jetty-jmx.xml“, which is probably located at the end of the file, as shown in below:

Then, add each of the JVM properties in a different line in the same file (it doesn’t matter where). It should look like this:

Please note that “–exec” is a property specific to Jetty, and necessary to make it understand the other VM properties. “-Xshare:off” disables class data sharing, which is necessary to make VisualVM work correctly. The other settings are the ones described earlier.

The last step is to configure the file “etc/jetty-jmx.xml” to instruct it to automatically create a RMI registry and set the RMI connection properties, which are essential to remotely connect to it. My configuration file (based on Jetty is below:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
  <Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/>
  <New id="MBeanContainer" class="org.eclipse.jetty.jmx.MBeanContainer">
    <Arg>
      <Ref id="MBeanServer"/>
    </Arg>
  </New>
  <Get id="Container" name="container">
    <Call name="addEventListener">
      <Arg>
        <Ref id="MBeanContainer"/>
      </Arg>
    </Call>
  </Get>
  <Call name="addBean">
    <Arg>
      <Ref id="MBeanContainer"/>
    </Arg>
  </Call>
  <Get id="Logger" class="org.eclipse.jetty.util.log.Log" name="log"/>
  <Ref id="MBeanContainer">
    <Call name="addBean">
      <Arg>
        <Ref id="Logger"/>
      </Arg>
    </Call>
  </Ref>
  <Call name="createRegistry" class="java.rmi.registry.LocateRegistry">
    <Arg type="java.lang.Integer">1099</Arg>
    <Call name="sleep" class="java.lang.Thread">
      <Arg type="java.lang.Integer">1000</Arg>
    </Call>
  </Call>
  <New id="ConnectorServer" class="org.eclipse.jetty.jmx.ConnectorServer">
    <Arg>
      <New class="javax.management.remote.JMXServiceURL">
        <Arg type="java.lang.String">rmi</Arg>
        <Arg type="java.lang.String">ec2-177-71-143-137.sa-east-1.compute.amazonaws.com</Arg>
        <Arg type="java.lang.Integer">0</Arg>
        <Arg type="java.lang.String">/jndi/rmi://ec2-177-71-143-137.sa-east-1.compute.amazonaws.com:1099/jettyjmx</Arg>
      </New>
    </Arg>
    <Arg>org.eclipse.jetty:name=rmiconnectorserver</Arg>
    <Call name="start"/>
  </New>
</Configure>

That’s all. When you start Jetty, it will log (to the console or file, depending of how you configured it) the JMX address you will need to use in order to connect to it from your local machine. Please see the following image:

service:jmx:rmi://ec2-177-71-143-137.sa-east-1.compute.amazonaws.com/jndi/rmi://ec2-177-71-143-137.sa-east-1.compute.amazonaws.com:1099/jettyjmx

In my case, the address that I should use in VisualVM is the address of my EC2 instance (ec2-177-71-143-137.sa-east-1.compute.amazonaws.com):

If the connection is successful, then you can right click on the remote host name and insert the address of the RMI registry, like shown below:

If you were lucky enough, you should be able to instrument Jetty remotely:

It turns out that it is very simple to achieve that. Add the following code to your ~/.irbrc file:

# File ~/.irbrc
require 'logger'

# For Rails 2
RAILS_DEFAULT_LOGGER = Logger.new(STDOUT)

# For Rails 3
ActiveRecord::Base.logger = Logger.new(STDOUT)

Simple as that. Restart the console and load any AR model, and the SQL statement should appear right before the data. For the same of simplicity, I set woth RAILS_DEFAULT_LOGGER and ActiveRecord::Base.logger, even because I had sittuations where only having one of the configurations didn’t work so well (for an unknown reason to me)

To change the cursor in a application wide fashion, you have to access the Glass Pane and set its cursor, and then make the glass pane visible – otherwise, it has no effect at all.

Take the following code as example:

int cursorType = Cursor.S_RESIZE_CURSOR;
Component glassPane = ((RootPaneContainer)someComponent.getTopLevelAncestor()).getGlassPane();
glassPane.setCursor(Cursor.getPredefinedCursor(cursorType));
glassPane.setVisible(cursorType != Cursor.DEFAULT_CURSOR);

In the previous code, “someComponent” is any JComponent you have, it doesn’t matter which one (can be a JLabel, JButton, JPanel.. just take one). The trick is to access the RootPaneContainer, and then get the glass pane from it.

The last part is to make the glass pane visible only when the cursor is not the default one. That’s all.

The XCode 4 Keyboard Shortcut Reference Guide has a very complete and extremely useful list of all shortcuts, organized in a pretty PDF file. The download links are:

• Project repository at Github
• Reference guide as PDF with blue background and white font
• Reference guide as PDF with white background and black font

The company I work for was a long time user of Microsoft solutions (only because that when they started over 11 years ago, it was easier to find Action Script developers that could do some ASP coding, thus the migration to the .NET platform was some kind of natural for them), but for the past couple of years the transition to Rails and now Java is taking place over .NET (which is something to be discussed another time), and using Java for the new tool seemed the best way to go through, as Java is a very mature platform, with plenty of developers and documentation available, and not to have to maintain totally different base codes of Mac and Windows was a very good argument.

However, I didn’t have so many good opinions about Swing (the Java GUI Toolkit), even though it is the standard approach to do desktop programming with Java. Sure that there are other toolkits out there, like SWT and QT, but I had to consider that other people would be working on the software later, doing bug fixing and general improvements, thus if it required extra training it could be a problem.

All my experience with Swing was limited to some small programs or books I read, but it was enough to let me know that:
- I’d need to deal with layout managers
- That layout managers can get quite complex or verbose very easily (or both)
- That Swing didn’t have any major upgrade for years (if any)
- I had a clue that there weren’t so many third party components
- And definitely that I wasn’t willing to do hand coding of the GUIs. A GUI designer was vital.

I have mixed feelings about layout managers. I understand why they were created, but you had to know them all in order to make a fairly complex program, as each one of them accomplish a very specific task. Also, any documentation (including books) date back to 2004 or 2005 at most, which leads one to think that it was abandoned, but this feeling goes away after some time, as Swing has almost all (if not all) major components one may need to create any program, and it is possible to create your own components if needed. Swing is mature as well, and the fact it does not get a major upgrade in years may only means that there isn’t that many stuff to have.

Ok, I may being a little too optimistic here, as certainly the API could be improved a lot and more components could be available by default, but Sun was never good at designing easy to use APIs, far from that, and the failed Java FX thing only proves that the guys over there had no clue at all of what to do.

When searching for documentation, you often will find articles dated back to ’98, ’02. This frequently helps to keep alive that feeling that you are dealing with a dinosaur and using something that will die soon – even it will not (I hope). Sure that any example code that it’s not for Java 1.1 is very welcome when you know nothing.

The complexity of doing even simple things is something you will face constantly. The Java API was never known for its friendliness – it appears that very different teams at Sun, that did not talk to each other, were developing the base class library, thus creating a lot of inconsistency across the API -, but Swing goes a step further to make your life harder. Maybe it’s because I am more confortable with web programming, but I have done a lot of WinForms and Silverlight (.NET) coding, and by far Swing is harder. Take for example Drag and Drop over a JList or (worst) a JTree: it is insanely hard to make it work, even after reading hundreds of source code lines from open source projects and discussion forums. The event dispatching system is another thing that the more I read the less I understand, and many times I found myself doing some sort of implementation of the observer pattern instead of sticking with Swing’s own classes (I ended with a somewhat simple but very effective ‘EventCentral’ class).

As for third party components, there are some, but not many, not to mention those that does not work very well. Conversely, the WinForms API of .NET (here I go again, sorry) still get plenty of stuff today, although not as many as it did once, and you can’t stop thinking about it occasionally.

In conclusion, at the end of the day Swing it’s the only choice you have if you are going to use Java for desktop development, and albeit it has a lot of bugs and a weak, non-active community, it gets the job done. I have looked at SWT and JavaFX, but the former it still even more restricted, and the latter’s first release was a fiasco, but apparently Oracle is trying to respawn it with a 2.0 version.