February 24th, 2010
I was chasing my tail a couple weeks ago, trying to figure out why I was getting the “port is already in use” from JBoss on my workstation. Doing a netstat, I noticed that port 8080 was in use and takling with an IP that I tacked back to California. My first though was that my Google updater was communicating through that port, but that turned out to be false when I killed that processes. Following that, I systematically shut every process down that wasn’t OS-related that may be speaking back to its master on the west coast. Finally, after several processes, I noticed my Chrome processes and that I had GMail open on one of them.
I shut all Chrome instances down EXCEPT the one for GMail and checked netstat again. Two things to note: first, 8080 was still in use. Second, there actually were MANY ports in use, talking with various IPs in/around California. When I turned off the last instance of Chrome, all the ports were freed. Why does GMail have so many ports open with servers? That actually came to me a lot quicker than finding the culprit: COMET.
What is COMET? Essentially its the reverse of AJAX (Asynchronous JavaScript and XML). Where AJAX is used by the client to make requests asynchronously to a server (without needing a full page refresh), COMET allows a server o “push” data to the client? Say waaaaa? HTTP is stateless! Indeed. COMET works in various ways, one method is for a client to make a request using JavaScript (similar to AJAX) and the server keeps the connection open as long as it can. When the server has something to send to the client, it simply replies. If the connection times out, the client sends another.
The fix I have found, for now, is to start my app server (JBoss or GF) first, then start Chrome. Everything works out just fine, then =)
Tags: AJAX, chrome, COMET, glassfish, gmail, jboss, netstat, port
Posted in COMET, appserver, javascript | No Comments »
February 23rd, 2010
Screen saver locks are great, especially in a public environment (i.e. work) where you may take a short stroll to the water cooler and someone may want to send out an incriminating email to your friends, family, and co-workers (hilarious, Kevin, thanks). For this reason, a lot of corporate policies (by policy I mean Group Policy in Active Directory) have the screen saver start and lock the workstation after a certain amount of time of “inactivity”. Great – but unhelpful when you might need the workstation running…for example, you have more than one computer/network at your desk and you’re using one as a monitor or reference while working on the other, or you’re giving a presentation and you may be spending more than 2 minutes on a single slide.
A typical response from administrators is “no, we can’t help you” because either there is no waiver policy or it even more exceptions and configuration they must maintain to stick your account or workstation(s) in a new OU with a special policy just for screen saver. One way around the screen saver locking is never allow it to lock! (NOTE: I am not suggesting you break any corporate policies or increase your security footprint by non-compliance. I am, however, providing an alternative to making policy (GPO) exceptions by allowing a user to specifically “disable” screen locking for a specified time period.)
The java AWT package provides an awesome class called java.awt.Robot, which allows you to generate system input events (keyboard or mouse). According to the javadoc “This class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations.”. Right. Now let’s abuse it.
Our problem is the screen saver lock, which requires some sort of input to prevent it from locking. We want a non-invasive solution, but also something that reminds the individual the system is running – so they just don’t leave it on all the time. What we’ll do is turn the SCROLL LOCK on/off at a set interval so the keyboard LED is flashing (visual reminder) but also is non invasive (you’ll still be able to access and work with the system with very minimal impact to the apps your running). Implementation is very simple:
package stopscreensaver;
import java.awt.AWTException;
import java.awt.Robot;
import java.awt.KeyEvent;
public class Main {
public static void main (String ... args) throws AWTException
{
Robot r = new Robot();
int i = 0;
while (true)
{
try {
r.keyPress(KeyEvent.VK_SCROLL_LOCK);
r.keyRelease(KeyEvent.VK.SCROLL_LOCK);
Thread.sleep(500); //blinking interval
}
catch (InterruptedException e) {}
}
}
}
From here, you can simply invoke the operations running: “java -jar screensaver.jar”. Create a simple batch script and the user just needs to double click to start.
Tags: java, robot
Posted in java | No Comments »
February 21st, 2010
Tonight I set out to find a reasonably priced Java EE5/6 (with EJB 3.0+ support), to host a new open source web application I am working on for my Army Reserve unit: SITREP (more to come on this). In general, though, I need a cheap host for various open source services I want to provide…here are my requirements:
- The hosting service should be cost-comparable to what I can get a LAMP stack server for (currently, DreamHost is <$9/mo)
- I want to be able to run both PHP and Java EE apps – although I can use either to accomplish any individual task, each is better suited for particular tasks. And, I might want to call Java from PHP in some instances (to do my long-running multi-threaded operations, for example).
- Must support EJB 3.0…but I really prefer EE6 with EJB 3.1 (which is totally awesome, by the way)
There may be good reasons why Java app servers aren’t cheap…they have a good deal of resource overhead relative to apache (mod_php) web servers. Even the smallest Java app running on its own JVM will cost a couple hundred megs of RAM. Of course, it makes up for it in ease of development and management of large-scale applications and runtime performance…but that argument isn’t going to help reduce my hosting bill =).
It’s late now, and failing at finding a reasonable priced EE app service, I am going to bed with a few options:
- Abandon Java EE application development for Open Source web applications, even if it is the best fit. Even if I want to provide the product instead of the service…who is going to spend the money for hosting of the app if I won’t. (Some apps just won’t be used by businesses that can afford their own data center – gotta realize the audience)
- Convince myself, and my wife, that I need a VPS
- Get a bigger pipe, DynamicDNS and/or static IP, and a better production web server for my home
- Build relevant application in both PHP and Java EE. This might not be as bad as it sounds – PHP would give me rapid development and prototyping with quick release cycles. The intended audience for the PHP version would be those customers that would run in a hosted environment. The intended audience for Java EE version would be those that have their own servers/data centers (medium-large sized businesses). This distinction also helps identify which services would be relevant for each build.
- there are more…but I think these are the most “reasonable” options.
I might actually be leaning to #4 – which might be the lack of sleep talking. If I can build the data model in a meta-language (ie. XML), I can automatically generate the ORM and facade classes that would constitute the Model. Further, if I use this opportunity to identify the validators for specific fields, I would probably be able to generate filter in/filter out checks as well as front-end JavaScript struts. Yeah—I’m sure THAT hasn’t been tried before =)! I need sleep.
Posted in PHP, ee, hosting, java, sitrep | No Comments »
February 11th, 2010
I recently released 1.0 of JEOTRANS, a Java port of the NGA GEOTRANS spatial conversion library. Why port it? I wanted a native interface (not JNI), no installation dependencies, true cross-platform capabilities, and a more clear open source license. I also wanted to expose GEOTRANS conversion functions with OGC interfaces and use JSR-275 measurements to ensure unit type safety.
At this time, JEOTRANS supports Transverse Mercator (TM), Universal Transverse Mercator (UTM), Polar Stereographic (PS), Universal Polar Stereographic(UPS), Military Grid Reference System (MGRS), and of course Geodetic (lat/long). Soon to be released, pending government approval (I wrote this at work), is a set of convenience classes rooted around the Coordinate class. A teaser: the Coordinate class, and utility classes, make it easy to parse documents to find coordinate systems, easily persists coordinates in standard formats (implements Serializable and is has default JPA annotations), and exposes a clean and simple to use API (a good example: provides geodetic tranformations from decimal degrees to DMS, DMDS, DMDM). The Coordinate class is 3D and will serve as a basis of more complex OGC types (lines, polygons) and non-OGC but equally important spatial types (image footprints, collect metadata, etc).
After speaking with Jean-Marie Dautelle, author of jscience (among other awesome libraries), the work on JEOTRANS is slated to be included in jscience 5.0.
One last thing – if you would like to contribute to the project, feel free to download the source from Kenai and hack away.
Enjoy!
Posted in gis, java | No Comments »