Category: Uncategorized

JBoss have come up with an embeddable version of their EJB3 implementation. An alpha release is available for download.

I downloaded it and played around with the embedded example from the tutorial.
Here’s what I did:

1. once you’ve downloaded and unzipped the alpha release (I tested with jboss-EJB-3.0_Embeddable_ALPHA_5.zip), go to the
   docs/embedded-tutorial/embedded-war directory and build it (just type ant).
2. unjar the war file in docs/embedded-tutorial/embedded-war/build/standalone.war to your $jetty.home/webapps directory.
3. move all of the jars in $jetty.home/webapps/standalone/WEB-INF/lib except for tutorial.jar to $jetty.home/lib/ext/jboss (see below for more on this).
4. finally, edit the $jetty.home/webapps/standalone/EmbeddedEJB3.jsp file. The JNDI lookups for the beans in this file don’t work and don’t match the documentation, so you need to change them. Find the lines:
   
   

   CustomerDAOLocal local = (CustomerDAOLocal)
   ctx.lookup(CustomerDAOLocal.class.getName());
   CustomerDAORemote remote = (CustomerDAORemote)
   ctx.lookup(CustomerDAORemote.class.getName());
   

   
   
   change them to:
   
   

   CustomerDAOLocal local = (CustomerDAOLocal)
   ctx.lookup("CustomerDAOBean/local");
   CustomerDAORemote remote = (CustomerDAORemote)
   ctx.lookup("CustomerDAOBean/remote");
   

   
   

5. start jetty: java -jar start.jar and now you can test EJB3s in jetty by surfing to the demo: http://localhost:8080/standalone/EmbeddedEJB3.jsp

I don’t think it should be necessary to move the jboss jars out of the webapp, but it makes sense if you want to use EJB3 with more than one webapp.

I haven’t as yet been able to make it work with leaving the jars inside the webapp. I get a ClassNotFoundException:

Caused by: org.jboss.util.NestedRuntimeException:
Cannot load class org.jboss.mx.server.JBossMXServerConfig;
- nested throwable: (java.lang.ClassNotFoundException:
org.jboss.mx.server.JBossMXServerConfig)
at org.jboss.util.Classes.instantiate(Classes.java:514)
at org.jboss.mx.server.ServerConfig.getInstance(ServerConfig.java:74)
at javax.management.MBeanServerFactory.(MBeanServerFactory.java:79)

The class doesn’t seem to exist in any of the jars supplied with the demo, so the ClassNotFoundException seems reasonable enough. However, I haven’t had time to investigate why it does not occur when the jars are in Jetty’s lib directory.

With release 6.1.0pre2 we now provide Jetty-JBoss integration for the Jetty 6 series.

This brings a number of important new features for JBoss users to enjoy such as servlet 2.5 support, and moreover, scalability for ajax via our Continuations mechanism and our cometd implementation.

There’s the beginnings of documentation on it on the jetty wiki.

For the moment, you’ll need to build the extras/jboss module from the jetty src distro (instructions on the wiki). For future releases, we’ll publish a sar file to the usual repositories

The maven mvn archetype:create command is a powerful one. It can create you a whole new ready-to-run application, complete with templated sources, config files etc. It takes a lot of the pain out of starting a new application.
Webtide has created a collection of maven webapp project archetypes which are freely downloadable from our site. We’ve made archtypes for most of the popular webapp technologies: DWR, ActiveMQ-Web, Dojo, SiteMesh, Tapestry, WebWorks, Struts, Spring and more.
It’s just 4 easy steps to starting a new project:

1. download the mini-maven project for the archtype of your choice
2. build the archetype with mvn install
3. generate your project with mvn archetype:create …
4. execute your new webapp immediately with mvn jetty:run

Now you have a freshly-made, running project with the webapp techology of your choice already baked in and ready for you to modify and extend. You have saved yourself hours or even days of work!
I knew archetypes were powerful, but it was brought home to me today answering a question on the jetty lists. A user was having problems with a sitemesh webapp. I simply downloaded our sitemesh archetype, generated a sitemesh app and modified it to match the user’s configuration.
It took me all of 5 minutes until I had a working webapp I could use to try to replicate the problem!
Without the archetype, it would have taken me hours researching sitemesh, downloading it, making a maven project and a webapp that worked.
Even sweeter, just changing a single line in the generated webapp’s pom.xml allowed me to immediately run the webapp under a different version of jetty with the mvn jetty:run command. I was able to try out the webapp’s behaviour with 3 different versions of jetty in under 5 minutes!
We want our maven archetype portfolio to be as comprehensive as possible, so if you spot a technology we don’t have covered, please contact us and suggest it.

Couch Wei’s blog talks about the need for a web-2.0 messaging layer. See also the follow on discussion on the
The server side.
It is a key point that Couch raises and I am working with Coach within the Open Ajax Alliance to explore the possibility of a more standard messaging base for web-2.0.
It will be a difficult problem, as we have been taught that the path to Ajax is XmlHttpRequest and most Ajax communication frameworks are based on that API.
But XmlHttpRequest allocates a scarce resource (a HTTP connection) for the duration of a request. Browsers only allow two connections to a given host. The moment you have multiple windows, tabs, frameworks or components using XmlHttpRequest, there is going to be contention for connections, resulting in blocked and inefficient communications.
The pity is, that 2 HTTP persistent connections are sufficient for efficient two way communication, but only if the multiple windows, tabs, frameworks and components can share connections nad multiplex and/or batch messaging over them.
Increasing the limit is not an option as web-2.0 comms is already stressing a server infrastructure designed for web-1.0 and more round trips to the server is not what we need to improve interactivity.
I hope the open ajax alliance hub will be able to provide some APIs to facilitate sharing connections between frameworks and components, but browser support will be needed to share between windows and tabs.
For the actual protocol to be used, there are many many
candidates: REST-ful, JMS, cometd from DOJO, beep, sip, jabber, the list is endless. I have developed or contributed to implementation for several of these (beep, activemq, DWR, and cometd) and all have their benefits and all can be well transported over HTTP.
However, I do not think the solution is in picking a winner among protocols. I think the solutions is recognizing that the paradigm for Ajax communication is messaging and not raw HTTP Request. A common messaging API in the browser would allow multiple protocols to be tried and tested. New protocols can be developed and eventual browser/infrastructure support may even take us away from HTTP. The Open Ajax Alliance can certainly provide this common API and then we can all innovate above or below that API.
In the meantime, I strongly suggest looking towards activemq Ajax or dojo’s cometd for your Ajax-2.0 communications. Messaging is where it is at!

Jetty Continuations can be used to prevent resource starvation
caused by JDBC Connection pools or similar slow and/or restricted resources.
Jetty Continuations have mostly been discussed in the context of web 2.0, Ajax Push and Comet. However there are many other use cases and the ThrottlingFilter,
written by Jetty committer Tim Vernum, is an excellent example of how Continuations can be used to provide a consistent quality of service within a web application.
JDBC Connection pools are frequently used to limit the
number of simultaneous requests to a database. The theory
being that databases will give better overall throughput
with fewer simultaneous requests, even if requests have
to wait for a connection from the pool.
This common approach can make your web
application very unstable. Threads queuing on the JDBC
pool can quickly exhaust the entire resources allocated
and deny service to the entire webapp, even if only
few requests actually need the database.
Consider a webapp that receives 1000 requests per second,
95% of which requests are served without a database in 20ms.
The other 5% require a database and take 100ms each.
Crunching the numbers gives:

25 simultaneous requests
5 simultaneous JDBC connections.

But as we are conservative, we will allocate 200 threads
to the servlet container and a 20 connections to the
JDBC pool. The webapp runs well and typically consumes only 25% of the resources allocated.
But what happens if the database runs slow for a while (because the administrator is running a report or an attacker has submitted a overly complex query, etc. etc.)?
If the DB request take 500ms instead of 100ms,
then 10 requests a second will accumulate to those already
blocked on the JDBC connection pool. If the condition lasts
for 20s, then the entire thread pool will be exhausted. No requests will be served for any resource, even those that do not use the database will be starved of threads.
If the database actually fails (or the DBAs report does a table lock), then it will only take 4 seconds before the entire thread pool is blocked on the JDBC pool.
But starvation can occur even without any failures, for example if the URLs that use the database become more popular than normal (due to marketing, slashdot, biorhythms, etc). If 25% of requests hit the database instead of 5%, then 50 requests per seconds will be added to the queue for JDBC connections and starvation will occur in only 4 seconds of increased load.
The solution is the use the thread-less waiting capability of continuations to allow requests to wait for JDBC connections without consuming a thread from the threadpool.
Thus an under performing DB will only slow the parts of the
webapp that use that database. The rest of the webapp will function normally even if the DB fails.
The ThrottlingFilter
can be mapped to arbitrary URLs in web.xml and will limit the number of threads past the filter and the size and timeout of the queue. If you know there are only 20 connections in the JDBC queue, then the ThrottlingFilter can be configured to only allow 20 requests past. Any requests in excess are suspended without a thread allocated and resumed when a connection becomes available as a previous request exists the filter.
The filter may also be used as a base class to provide more sophisticated policy than a simple count.

Somebody recently brought it to my attention that there’s a rumour going around that you can’t run JIRA on Jetty.

Sure enough, digging around on the Atlassian site showed up with this: http://www.atlassian.com/software/jira/docs/v3.6.5/servers/jetty.html.

Rising to the implicit challenge, I set out to make JIRA run under jetty 6.x. As it only took 5 mins, I didn’t have anything to do for the rest of the day, so I decided to write up a wiki entry for it: http://docs.codehaus.org/display/JETTY/JIRA

So with time still on my hands, I decided to blog about it too!

Actually I am a little disappointed that the Atlassian guys never contacted, so far as I am aware, any of the Jetty committers to ask for some help with any difficulties they were having. We are more than happy to work with anyone to get their project/product working with Jetty, as I hope we’ve demonstrated amply both in the past and present.

So, please give JIRA in Jetty a go, as it all seems to be working. Of course, if there are problems, feel free to post to jetty-discuss@lists.sourceforge.net and we’ll do our best to resolve them.

With any luck, an Atlassian will read this and update their website (hint hint hint).

Running any user program on low port numbers on *nix systems is generally tricky, as low port numbers are protected and only accessible as the root user.

In the past, jetty’s suggested solution has been to use iptables or ipchains to configure the operating system to forward traffic for port 80 (for example) to port 8080 (for example). Here’s the FAQ entry on how to do that here:
http://docs.codehaus.org/display/JETTY/port80

Recently, we decided to make this easier by adding a new feature which means you will be able to invoke jetty as the superuser, but after the ports have been opened the userid will change back to a non-privileged user, preserving the runtime safety of your system.

This little gem can be found currently in svn trunk and is slated for release in the 6.1.0. Look in $jetty.home/extras/setuid for the code and the README on how to build it. As the build requires native libs, there are some system-dependent configurations you have to provide, so there are a couple of steps you have to do manually for the build.
The README.txt file has full instructions, but I’ll reproduce it here to give you the general idea to start you off:

Build