Problem

You are running Mac OS X (maybe the problem is relevant on other platforms too) and even if you’ve started Tomcat and you can see the Java process in the Activity Monitor or with ps you can’t see the process with jps. You are not able to connect to the process with VisualVM nor JConsole. Bummer.

Solution

Tomcat scripts have a variable called CATALINA_TMPDIR and the java process is forked with

-Djava.io.tmpdir="$CATALINA_TMPDIR"

What happens is that jps and VisualVM/JConsole look for information about processes from the system TMP folder. Once you redefine this they cannot find their information. The solution is to eliminate this variable from the process.

Either execute the commandline that you can copy and paste from

ps aux | grep -i tomcat

and exclude the -Djava.io.tmpdir part or modify the script for your debug session. Thats it.

You’re welcome.

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 34953465 bytes) in /var/www/yourwebsite.com/public_html/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 286

The reason is that WP Super Cache is doing its best to save your server from some load and the entry point for most of the requests is actually a PHP file from the WP Super Cache. Check your .htaccess file for more details. That script tries to cache your download file which might not fit into your memory limit. Download files are anyways static (unless you add some binary cookies, which you’re probably not) and don’t need another layer of caching.

Solution

In WP Super Cache options locate “Accepted Filenames & Rejected URIs” section and add some extensions there. In this example I’ve added zip jar and exe. Mind the syntax.

Generally I’m a big fan of Play! It is easy to use, easy to setup and fast to develop with. Its like Struts with JRebel but feels more fresh. Okay, back to the rant.

Lets say you want to make sure that each time you run your application, the HSQLDB is initialized into the same location.

Well, you go to application.conf. Find the db.url field, comment it in, change it to

db.url=jdbc:hsqldb:file:my/fav/static/location

Done! 10 minutes you notice that

/private/var/folders/Em/EmtX3-Q+EgOCv9GUy0k8dU+++TI/-Tmp-/Jetty_0_0_0_0_8080_webapp____.7fbo9s/webapp/WEB-INF/application/db/db

is used as the DB location. After grepping, doublechecking, debugging and swearing you find in the internals of play that db.url, db.pass, db.user, db.driver are ignored if db=fs is set. WTF? No warning, no nothing that your configuration gets overwritten, aaargh!

Lets say your deployment is not Play! (they advise you to use play run to run apps written using Play! instead of a classic servlet container). Lets say you target Jetty instead.

Well, you deploy your WAR archive to Jetty and develop as you would before but then you discover that your files are no longer reloaded. You also discover that you get tons of database exceptions. After grepping, doublechecking, debuggin and swearing you find in the internals of play that once you ditch the play run and move to a classic container Play! will presume that you must have been smoking crack when you wrote application.mode=dev in your configuration file. It will just override it and make sure that you run in production mode this time. WTF? No warning, no nothing that your configuration gets overwritten, aaargh.

So next time you’re having problems with Play!, do some grepping, doublechecking, debuggin and swearing and find the location where your configuration options are overwritten by some Java code inside play.jar.

One day we stumbled upon a page that had stolen our website design. It was not a question if they had borrowed ideas from us but they had literally stolen everything. The html, css, images and even had our logo up! Our website is zeroturnaround.com and their, jbrute.info (the one which stole the design).

My first reaction was that I’ll just drop them an email, make sure that they’re aware that it is a crime (is it?) and order them to take it down and problem solved. We have no interest of suing anybody. Maybe they were just playing around. Here is a picture how it looked at that time.

The plan was easy but getting contact information was not. At least they had taken down our contact information from the footer. Not finding even an email (then again, smart move, too many stories of criminals accidently leaving their card at the scene of the crime) from the webpage I turned to DNS whois. Whois records show

Domain ID:D32012015-LRMS
Domain Name:JBRUTE.INFO
Created On:24-Mar-2010 20:00:01 UTC
Last Updated On:24-Mar-2010 20:15:33 UTC
Expiration Date:24-Mar-2011 20:00:01 UTC
Sponsoring Registrar:GoDaddy.com Inc. (R171-LRMS)
Status:TRANSFER PROHIBITED
Registrant ID:CR44517482
Registrant Name:Conor Ryan
Registrant Organization:Warlock 999 Development
Registrant Street1:One Vernon Drive
Registrant City:Vernon
Registrant State/Province:New Jersey
Registrant Postal Code:07976
Registrant Country:US
Registrant Phone:+1.5555555555
Registrant *************@warlock999.info

All emails sent to warlock.info or jbrute.info bounce. Googling the name and address does not bring much up. It’s like a dead end. I’ve also contacted the registrar and hosting, still waiting for replies. They’ve updated their website design today, removed the video, our logo and put up some text.

What are my options to deal with something like this? Proving that the design belongs to us should be easy (the html is too similar). How should I go about documenting this? I did make a screenshot when I first stumbled upon, but you could always say that I’m good in Photoshop.

Are there other options to contact a domain name owner besides information from website and WHOIS?

Today after my “regular” upgrade I noticed that one of the ANT tasks did not perform as I would have expected.

/home/toomasr/workspace/project/build.xml:459: The following error occurred while executing this line:
/home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml

A quick ant -debug did not help me much.

/home/toomasr/workspace/project/build.xml:459: The following error occurred while executing this line:
/home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml                                                                                                                                       
        at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:508)                                                                                   
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:369)                                                                                                                  
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)                                                                                                     
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)                                                                                                              
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)                                                                                            
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                                    
        at java.lang.reflect.Method.invoke(Method.java:597)                                                                                                                         
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)                                                                                              
        at org.apache.tools.ant.Task.perform(Task.java:348)                                                                                                                         
        at org.apache.tools.ant.Target.execute(Target.java:357)                                                                                                                     
        at org.apache.tools.ant.Target.performTasks(Target.java:385)                                                                                                                
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.Main.runBuild(Main.java:758)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by: /home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml
        at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:142)
        at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:367)
        ... 17 more
--- Nested Exception ---
/home/toomasr/workspace/project/changelogic-build.xml:72: Please check the correctness of the root url property. The server returned HTTP response code 300 or above for the URL http://172.17.57.242/lib/changelogic-build.xml
        at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:142)
        at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93)
        at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:367)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:357)
        at org.apache.tools.ant.Target.performTasks(Target.java:385)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
        at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
        at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
        at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
        at org.apache.tools.ant.Main.runBuild(Main.java:758)
        at org.apache.tools.ant.Main.startAnt(Main.java:217)
        at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
        at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
 
Total time: 3 seconds

The access log on the server did not show anything for the request. Browsing to the url with FireFox worked just fine. Where to even start debugging this? The simple env did not show any proxies configured either. Quite lost.

At last I decided to trace the problem with strace. strace -f ant my_target > result 2>&1 produced 35 892 lines of output. Searching for the ip showed me the message

35596 [pid 13544] connect(46, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:172.17.57.242", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNR      EACH (Network is unreachable)

Weehah, I’m getting somewhere! Googling a bit showed me multiple solutions. Either a system wide sysctl -w net.ipv6.bindv6only=0 or just -Djava.net.preferIPv4Stack=true will do the trick. I hope this helps somebody.

There are different ways for integration. Usually it is done via an API. The host platform offers some hooks into the system and you can use them to add some custom functionality on top of the host (or maybe just integrate your own product with the host). The result of this in the IDE world is a plugin. JRebel (the product our team is spending the most development time on) has plugins for application servers, frameworks and even IDEs.

If you’re in luck you can achieve everything with the API, if not you need other tricks. If the API does not offer certain public methods or access to some internal fields you can go in with reflection and still use them (of course there are no guarantees if the internals stay the same on version changes).

One step further to the darkside is binary patching. By binary patching I mean adding/changing/removing methods/fields/classes in runtime. This is the approach that we had to take when writing the JRebel NetBeans plugin.

On NetBeans startup we lookup a debugger class and on success try to patch it. In 2009 and using the JVM (not native apps) it is quite an easy task, at least for the most part. No assembler involved (of course you could be using a bytecode generation library), no need to do jumps to correct offsets or even read assembler (or bytecode).

In our case we use the Javassist library. It is a matter of inserting Java code embedded into a String to methods looked up via reflection. For example the following code adds some new code into the beginning of a method.

ctc.getDeclaredMethod("setRequests").insertAfter(
  "org.netbeans.api.debugger.jpda.LineBreakpoint _breakpoint = getBreakpoint();" +
  "java.lang.String _className = _breakpoint.getPreferredClassName();" +
  "if (_className == null) {" +
  "  _className = reader.findCachedClassName(_breakpoint);" +
  "  if (_className == null) {" +
  "    _className = org.netbeans.modules.debugger.jpda.EditorContextBridge.getContext().getClassName (" +
  "      _breakpoint.getURL ()," +
  "      lineNumber);" +
  "    if (_className != null && _className.length() > 0) {" +
  "      reader.storeCachedClassName(_breakpoint, _className);" +
  "    }" +
  "  }" +
  "}"

For the complete source code of the patch see the src folder of the nb-plugin.

In conclusion, the best way to integrate with any system is via the API it provides. If it does not cut it then look into reflection and start using internals. You will lose on maintainability of course. Still not happy? Look into binary patching and have your fingers crossed whenever the target platform releases a new version.

Actually the same happened to favicon.ico and a few others. So either have your referred files and favicon.ico on your server or rework WordPress mod_rewrite configuration not to handle css/js/ico/png/gif/jpg files. This will save you money!

The logic of the framework is quite simple, ANT build.xml starts up, runs a test as a separate java task, gathers the result code and tests for equality of -1. The test was failing for no reason.

Checking the source code of the java task it was obvious that it was returning -1. Quick grep and a debugger session showed that ANT was not mangling the return code. So System.exit(-1) was returning 255. System.exit(42) then again returned 42.

Quick google shows that this is how it is supposed to work. Quoting from steve-parker.org

Exit codes are a number between 0 and 256, which is returned by any Unix command when it returns control to its parent process. Other numbers can be used, but these are treated modulo 256, so exit -10 is equivalent to exit 246, and exit 257 is equivalent to exit 1.

And then we have Windows where -1 is a valid exit code (well, at least it works). Something to remember when have to exit on multiple platforms.

The test is fairly simple. 4 million iterations of $j = 1 and 4 million iterations of some_func(), a function wrapping the same $j = 1.

The results? Function calls are so expensive that inlined version takes 2 seconds to execute and invoking the function takes 16. 8 time difference, whoah!

The test environment: PHP 5.2.6-2+b1 with Suhosin-Patch 0.9.6.2 (cli) (built: Jul 22 2008 21:03:43) running on a P4@3ghz