Set up Apache for site maintenace

We want to set up the site maintenance page from 5am to 3pm on a certain day to do database upgrade. Then we want to test the site internally before opening to the public. This is what I would do in Apache configuration:

# rewrite condition1: 5am to 3pm
# rewrite condition2: allow only internal ip
# rewrite condition3: any database driven page (".dyn", ".jsp", or ".vm")

RewriteCond %{TIME_HOUR}%{TIME_MIN} >0500
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1500
RewriteCond %{REMOTE_ADDR} !^255.255.0.0*$
RewriteCond %{REQUEST_URI} \.(dyn|jsp|vm)$
RewriteRule ^/(.+)$ http://my.site.com:80/sitedown.html [L,R]

Can't deploy / undeploy web applications on Glassfish

When we tried to publish a new web application to Glassfish (v2.1.1) this morning, we got the following mystic message:

CLI171 Command deploy failed : While redeploying, trying to stop the application in target server failed; Error Flushing ConfigContext com.sun.enterprise.config.ConfigContext: Url=$glassfish_home/domains/release/config/domain.xml, ReadOnly=false, ResolvePath=true, LastModified Timestamp=1312828827000, isChanged=false, Autocommit=false, isConfigBeanNull=false

It took us a while to realize that somehow domain.xml lost the write permission overnight, so Glassfish cannot add or delete the web application in domain.xml.

Glassfish team should hire someone who can write messages for a normal human being :)

How to start/stop all the cron jobs on Linux

Log in as root on the server:

All the cron jobs are defined in /var/spool/cron

To stop all cron jobs: /etc/init.d/crond stop

To start all cron jobs: /etc/init.d/crond start

Distinguish between different kinds of JSF beans

Name: Model Bean
Typical Scope: Session
Description: This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties. The most common use case for a model bean is to be a database entity, or to simply represent a set of rows from the result set of a database query.

Name: Backing Bean
Typical Scope: request
Description: This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.

Name: Controller Bean
Typical Scope: request
Description: This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).

Name: Support Bean
Typical Scope: session / application
Description: This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope. However, if the data applies to all users (such as a dropdown lists of provinces), then the bean would be kept in application scope, so that it can be cached for all users.

Name: Utility Bean
Typical Scope: application
Description: This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.

More details can be found at http://java.dzone.com/articles/making-distinctions-between

Glassfish Woe (Part 2)

I did some tests on our development server:
1) When connecting to development database, I ran a load test to have 10 users login/logout at the same time. Everything looked fine.
2) Then I switched to the production database, same load test, now I could reproduce the transaction error.

So it seems that something got changed on our production database to cause the transaction error. But it is hard to pinpoint what it was. So for now, I implemented a workaround and it seems to be working. Instead of using resource type javax.sql.XADataSource, I am now using javax.sql.DataSource. The difference is that XA type can handle global transactions while non-XA can only handle local transactions. Since we are not running in distributed environment, this seems to be working for us. And the server has been quiet over the weekend.

Content is not allowed in prolog

While working on the glassfish crash issue, I stumbled upon an error in the log:

[Fatal Error] servicetag-registry.xml:1:1: Content is not allowed in prolog.

It happens to be an extra character in the lib/registration/servicetag-registry.xml file. And it was introduced 6 months ago!

Glassfish Woe

Our website running on Glassfish 2.1.1 crashed over the weekend. We found a lot of transaction errors in the log:

JTS5041: The resource manager is doing work outside a global transaction
oracle.jdbc.xa.OracleXAException
...

When this happens, the connection associated with the transaction will become unusable, then the connection pool has to create more and more connections. At some point, it will reach the maximum, and when all the connections in the pool become stale, the site will crash.

After some research on google, it seems to be caused by a parallel transaction bug described in http://java.net/jira/browse/GLASSFISH-11920.

But the weird thing is that we didn't change anything recently and all this started to happen out of nowhere.

This really drives me nuts!