I’m happy to announce, with the release of Resin 4.0.35, Resin will compile and run on a Raspberry Pi!

For the uninitiated, Raspberry Pi is a credit-card-sized single-board computer, very popular amongst tinkerers and hobbyists for it’s ease of use and low cost.

We’ve made number of changes in recent releases to allow Resin to run on a Raspberry Pi. These included both Java fixes and compilation of Resin’s native libraries. Both Resin Pro and Resin GPL Servlet Container will run with native optimizations enabled on Raspberry Pi.

More information including minor required configuration change is available on Caucho’s Resin 4 Wiki: Resi On Raspberry Pi

When attempting to diagnose application errors or performance issues, the single best tool Resin makes available are the Resin PDF Health Reports. They are also the first things we request when addressing customer support questions.

Resin can generate two slightly different PDF health reports: Snapshot and Watchdog reports. A Snapshot Report captures a “snapshot” of Resin at the current point in time. A Watchdog Report aggregates as much information as available about Resin at a “previous” point in time. Watchdog reports can also be thought of as a “post-mortem” or “restart” report, as they usually are generated immediately after an unexpected server restart.

Snapshot reports can be generated on the command-line:

via REST:

or via Resin-Admin on the PDF Page:

Watchdog report are usually generated automatically after any unexpected server restart. Check your logs directory for Watchdog-*.pdf files. However you can always regenerate a Watchdog report from Resin-Admin on the Watchdog Page:

The Resin Administration Console video on YouTube provides an excellent overview of Resin-Admin and PDF Health Report content.

I just extended Quercus to support the new core language features of PHP 5.4. The changes are currently in our subversion repository and should be in our next release: 4.0.34. Traits, new in 5.4, was a bit of a pain to implement because of all the weird edge cases (i.e. __CLASS__, insteadof, as). Here’s a list of what’s new:

• traits

  <?php
  
  trait T0 {
    function foo()
    {
      echo "inside T0->foo()\n";
    }
  }
  
  class A {
    use T0;
  }
  
  $a = new A();
  $a->foo();
  
  ?>
  

Read the rest of this entry »

The following article originally appeared on JavaAdvent 2012.

It’s been a 3.5 years ago to this day since I last wrote about running Quercus on Google App Engine (GAE). The article detailed a crazy experiment to get a PHP application, Wordpress, running on GAE. I still remember it being a painful experience because of number of changes I had to make to Wordpress to get it working. It was all due to the GAE Java environment being so drastically different from what Java developers were used to. It was heavily sandboxed and had no SQL support. You couldn’t launch new Threads. You couldn’t write to the file system. But those were the tradeoffs you had to live with if you wanted to deploy your application to the all-wonderful Cloud.

Fast-forward to 2012 and GAE has come a long way. GAE now allows you to spawn new Threads (currently in beta). You still cannot write to the file system, but for all it’s worth there is a new GAE Files API that gives you file-like concepts. And you can run your very own MySQL instances on Google’s infrastructure (albeit Google’s customized version of MySQL).

What hasn’t changed over the years is that you’re still expected to hit major roadblocks as you migrate your existing web applications over to GAE. And you’ll have to make heavy modifications to your application to 1) make it work and 2) be performant on GAE.

So this is where Quercus comes into the picture. At Caucho, we spent a lot of time getting Quercus to work seamlessly with GAE. Our goal was to abstract the GAE details away so that developers don’t have to worry about the fact that the application is running on GAE. Things just work transparently behind the scenes for PHP applications. For example,

• PHP file_*() functions work just like they do before (including writing to files!)
• PHP mysql_*() functions and PDO work just like they do before

Read the rest of this entry »

Resin has the very convenient ability to import configuration from an HTTP URL. This feature in combination with clever usage of environment variables can be a huge help avoiding the issues caused by maintaining local copies of configuration files in a large environment. In this Wiki article I setup a webserver as a centralized configuration repository and show how to modify your local Resin configuration such that the same file can be used by any Resin instance in any environment.

http://wiki4.caucho.com/Cloud:_Cluster-Wide_Configuration_Using_HTTP

You may think of us as a vendor. We think of ourselves as a bunch of engineers who sit around and ask questions like: “is NginX faster and if so why?”. If we deliberately gamed a benchmark that would take all of the fun out of it. We like the competition. Resin has always been really fast, but competition from NginX has made us faster.

Read the rest of this entry »

I posted a new wiki entry that explains how to run Jasper JSP Engine on Resin: http://wiki4.caucho.com/Jasper_JSP_Engine_On_Resin_Deployment.

We have recently run some performance benchmarks comparing Resin 4.0.29 versus NginX 1.2.0. These benchmarks show that Java-based Resin Pro matches or exceeds C-based NginX’s throughput.

Summary: Using industry standard tool and methodology, Resin Pro web server was put to the test versus Nginx, a popular web server with a reputation for efficiency and performance. Nginx is known to be faster and more reliable under load than the popular Apache HTTPD. Benchmark tests between Resin and Nginx yielded competitive figures, with Resin leading with fewer errors and faster response times. In numerous and varying tests, Resin handled 20% to 25% more load while still outperforming Nginx. In particular, Resin was able to sustain fast response times under extremely heavy load while Nginx performance degraded. (See related press release).

Read the rest of this entry »

Scott and I just finished work on making sure Seam-Booking example works on Resin. I posted a tutorial on deploying seam-booking in Resin at Resin Wiki: Seam On Resin . It requires Resin 4.0.29 which is due in about a week from now.

The short answer is no. The longer answer is that Resin supports Hessian for remoting. And, in about 20 lines of code, you can expose all @Stateless/@Remote beans as remote services using the Hessian protocol using CDI and Servlet 3.0, which are part of Resin and part of Java EE Web Profile (as Resin 4 is a Java EE Web Profile certified application server).

Hessian (now Hessian 2) predates many other forms of remoting and is a [http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/ wicked fast, binary protocol] (faster than CORBA, RMI, SOAP, XML-RPC, etc). You could think of Hessian as a high performance binary JSON. Hessian has been ported to many languages. Hessian is a remoting framework and a flexible Java serialization framework.

You can expose any bean as a Hessian remote bean quite easily. Hessian has been around for 10 years, and is very solid. (Both Hessian and Resin are development and maintained by Caucho).

Resin 4 documentation does not have Hessian documentation yet, but Hessian usage has not changed in years. You can find a good tutorial on getting started with Hessian from the [http://www.caucho.com/resin-3.0/protocols/hessian.xtp Resin 3 documentation]. I’ve tried these tutorial steps in Resin 4 and the tutorial works as advertised.

Resin 4 is Java EE Web Profile certified as such it does not support CORBA, EJB remoting, etc. However Resin does support Java Dependency Injection (CDI), which allows you to easily find beans with certain annotations. What follows is a simple example that finds all @Stateless beans that have @Remote interfaces and automatically exposes those beans as remote hessian objects.

To learn more go to our wiki for Resin 4 Java EE WebProfile application server.