backwards compatibility is a non-issue in jboss :-( Jaikiran Pai wrote:

Beyond this particular case, there is a deeper issue of how does the user know if the AS booted correctly. Reading the logs is the current answer (which means that the AS boots in unknown health state until someone manually reads the server logs). Some examples: 1. During boot, an out of memory error occurred but the server continued booting and started. Of course, all bets are off, when you experience an OOM. The AS health is BAD for this case. 2. The case below is hit because the messaging journal is corrupted or needs to be upgraded from an earlier version. The AS health appears to be BAD for this case (IMO). 3. Clustering group membership class of error occurred but the server continued booting and started (even though we haven't succeeded in joining the cluster). The AS health is bad as we are running in a separate cluster partition than the other nodes. The point being that we need a more proactive "critical failure monitor" that detects symptoms of bad health and takes action. Perhaps this is already on the planning board for AS? It would be really cool if different kinds of "health monitoring" plugins could be used, including application specific health checks (detecting application fatal events and running application health integrity checks). Configuring an AS deployment, would include deciding the action to be taken for any critical failures. Depending on the strategy of the applications being deployed, some actions might be: Fail - Terminate the AS server process as soon as possible. Perhaps there is a graceful versus immediate option. Ignore - This is operationally compatible with how we run AS deployments currently. Notify - Send alert notification of the critical error. This can be combined with Fail and Ignore. Scott On Thu, 2010-06-10 at 14:24 +0200, Carlo de Wolf wrote: