-
1. Re: jmx-console
I saw your other post, and was thinking up a reply when I saw this post. So congratulations, you probably by now found the documentation and it introduced you to the jmx-console, so you are part way there.
The only reason I can come up with for why the jmx-console is not showing anything for 'all' is networking issues. Here are work I have no problems running all and accessing the jmx-console. Ditto for at home, where I have a wireless router between me and hte cable modem. But there have been posts earlier where people who are directly connected to a cable or DSL modem having issues with 'all' because 'all' assumes a clustering-friendly environment and thus sends out all kinds of broadcasts that ISPs typically frown upon.
I am not sure of your environment, so maybe the above helps or doesn't. -
2. Re: jmx-console
Thanks for your response Peter.
The environment I specified in my earlier post is at my work i.e., in client's network.
Once I start the 'all' server, I don't even see the port 8080 open. So I am guessing there might be some issue that is stoping the jmx application from deploying properly.
I noticed the following two issues when I started 'all' server:
================================================
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.cache:service=TomcatClusteringCache
State: FAILED
Reason: ChannelException: unable to setup the protocol stack
I Depend On:
jboss:service=Naming
jboss:service=TransactionManager
jboss.aop:service=AspectDeployer
Depends On Me:
jboss.web:service=WebServer
ObjectName: jboss:service=DefaultPartition
State: FAILED
Reason: ChannelException: java.lang.Exception: exception caused by UDP.start(): java.net.SocketException: The socket name is not available on this system.
I Depend On:
jboss:service=Naming
Depends On Me:
jboss:service=HASessionState
jboss:service=HAJNDI
jboss.cache:service=InvalidationBridge,type=JavaGroups
jboss.ha:service=HASingletonDeployer
jboss:partition=DefaultPartition,service=FarmMember
================================================
Does anyone see a hint here?
Thanks,
Crony -
3. Re: jmx-console
I found the solution for one of the porblems, DefaultPartiction service failure.
Edit your run.sh script as following:
1. Add the following entry before the Jboss specific properties entry:
# fix for IPv6 bug (AIX cannot bind a socket to an IPv6 address)
JAVA_OPTS1="-Djava.net.preferIPv4Stack=true"
2. Edit the JBoss specific properties entry as following:
# Setup JBoss sepecific properties
# JAVA_OPTS="-Dprogram.name=$PROGNAME $JAVA_OPTS"
JAVA_OPTS="-Dprogram.name=$PROGNAME $JAVA_OPTS $JAVA_OPTS1"
Restart the server using this run script. -
4. Re: jmx-console
Ah yes, the IPv6 bug strikes again. I've been bit by that one before, and it is amazing the number of completely unrelated problems that this one setting fixes!
Crony, earlier in the log there should be some stack traces. Those outline the root causes of the problem. The output you posted only indicates that a failure took place, the stack traces indicate why. -
5. Re: jmx-console
Peter,
I noticed that stack trace and here it is:
================================================
class org.jboss.cache.interceptors.CacheMgmtInterceptor
2007-01-04 10:21:36,962 DEBUG [org.jboss.cache.TreeCache] cache mode is REPL_ASYNC
2007-01-04 10:21:37,109 ERROR [org.jgroups.protocols.UDP] max_bundle_size (64000) is greater than largest UDP fragmentation si
ze (8000)
2007-01-04 10:21:37,112 DEBUG [org.jboss.cache.aop.TreeCacheAop] Initialization failed jboss.cache:service=TomcatClusteringCac
he
ChannelException: unable to setup the protocol stack
at org.jgroups.JChannel.(JChannel.java:217)
at org.jgroups.JChannel.(JChannel.java:189)
at org.jboss.cache.TreeCache._createService(TreeCache.java:1373)
at org.jboss.cache.TreeCache.createService(TreeCache.java:1300)
at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java(Inlined Compiled Code))
at org.jboss.mx.server.Invocation.invoke(Invocation.java(Compiled Code))
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.create(Unknown Source)
at org.jboss.system.ServiceController.create(ServiceController.java:330)
at org.jboss.system.ServiceController.create(ServiceController.java:273)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code))
at java.lang.reflect.Method.invoke(Method.java(Compiled Code))
================================================
I am still googling on this. -
6. Re: jmx-console
Ok..finally sorted out the cause for the failure of TomcatClusteringCache service.
Edit the file yourserver/deploy/tc5-cluster.sar/META-INF/jboss-service.xml to set the attribute 'max_bundle_size' value to the largest UDP fragmentation (Check the stack trace to find it) . In my case it was 8000.
Bounce the server for a clean startup!