[jboss-dev] A lot of JMS dependencies errors starting up trunk

Scott Marlow smarlow at redhat.com
Thu Jun 10 09:06:50 EDT 2010


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:
> See also https://community.jboss.org/thread/150057
> 
> We should have a test that forces the error to ensure that we fail more 
> gracefully.
> 
> Carlo
> 
> On 06/10/2010 10:15 AM, Dimitris Andreadis wrote:
> > backwards compatibility is a non-issue in jboss :-(
> >
> > Jaikiran Pai wrote:
> >    
> >> I haven't yet reached the point of running the AS (even after triggering
> >> the build more than 45 minutes back). It fails for me in the embedded
> >> testsuite with lots of JMS errors, like the one you mention. Digging
> >> into the dependency error messages shows this:
> >>
> >> Deployment "JMSServerManager" is in error due to the following
> >> reason(s): HornetQException[errorCode=6 message=Journal data belong to a
> >> different version], **ERROR**
> >>
> >> Looks like HornetQ changed some internal data representation which
> >> requires cleaning up the data folder in JBOSS_HOME/server/<  servername>
> >> first.
> >>
> >> -Jaikiran
> >> Bill Burke wrote:
> >>      
> >>> FYI
> >>>
> >>>        
> >> _______________________________________________
> >> jboss-development mailing list
> >> jboss-development at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/jboss-development
> >>      
> > _______________________________________________
> > jboss-development mailing list
> > jboss-development at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-development
> >    
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development




More information about the jboss-development mailing list