RE: [JBoss-dev] jboss-head status
by Jason T. Greene
The only reason I can see not to, is to offer behavioral backwards
compatibility. Although this is a major release, and adapting to this
kind of change would be simple. Alternatively, ServiceController could
accept beans that are already registered, and just trigger a loud
warning message.
-Jason
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-
> bounces(a)lists.jboss.org] On Behalf Of Scott M Stark
> Sent: Thursday, August 24, 2006 4:52 PM
> To: JBoss.org development list
> Subject: Re: [JBoss-dev] jboss-head status
>
> Yes, this is the current issue I see. My main question at this point
is
> why should we have the separate
> MBeanServer.registerMBean/unregisterMBean +
> ServiceControler.lifecycle/remove. It clearly leads to duplicate state
> management. Why not say the only way to manage an mbean service is
> through the ServiceController drop all of the
> MBeanServer.registerMBean/unregisterMBean usage?
>
> Jason T. Greene wrote:
> > Not sure if this is related, but take a look at [1]. The original
> > ServiceController unregisters on remove.
> >
> > [1]
> >
http://lists.jboss.org/pipermail/jboss-development/2006-August/000776.ht
> > ml
> >
> > -Jason
> >
> >
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
19 years, 7 months
RE: [JBoss-dev] jboss-head status
by Brian Stansberry
I'm concerned there is going to be a problem with Tomcat components
(connectors, valves, managers, etc) that Tomcat will want to register in
JMX. You mentioned earlier that "Subsequent use of this mbean as a
jboss mbean service can result in the ServiceController taking ownership
of the mbean"; I'm not quite sure what kinds of use will trigger this.
jboss-development-bounces(a)lists.jboss.org wrote:
> Yes, this is the current issue I see. My main question at
> this point is why should we have the separate
> MBeanServer.registerMBean/unregisterMBean +
> ServiceControler.lifecycle/remove. It clearly leads to
> duplicate state management. Why not say the only way to
> manage an mbean service is through the ServiceController drop
> all of the MBeanServer.registerMBean/unregisterMBean usage?
>
> Jason T. Greene wrote:
>> Not sure if this is related, but take a look at [1]. The original
>> ServiceController unregisters on remove.
>>
>> [1]
>>
> http://lists.jboss.org/pipermail/jboss-development/2006-August/000776.
>> ht
>> ml
>>
>> -Jason
>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 7 months
RE: [JBoss-dev] RE: jboss-head-testsuite-1.5 Build Failed
by Brian Stansberry
May be related to some of the service lifecycle issues that have been
getting discussed lately. During shutdown of the securitymgr server you
get a bunch of logging like this:
2006-08-22 03:45:26,279 DEBUG [org.jboss.system.server.Server] Shutting
down all services
2006-08-22 03:45:26,281 DEBUG [org.jboss.system.ServiceController]
Stopping 66 services
2006-08-22 03:45:26,282 DEBUG [org.jboss.system.ServiceCreator] Removing
mbean from server:
jboss.j2ee:service=EJB,plugin=pool,jndiName=SessionBean
2006-08-22 03:45:26,282 DEBUG [org.jboss.system.ServiceCreator] Error
unregistering mbean
jboss.j2ee:service=EJB,plugin=pool,jndiName=SessionBean
javax.management.InstanceNotFoundException:
jboss.j2ee:service=EJB,plugin=pool,jndiName=SessionBean is not
registered.
at
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.j
ava:527)
at
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java
:383)
at org.jboss.system.ServiceCreator.uninstall(ServiceCreator.java:309)
at
org.jboss.system.microcontainer.OnlyUnregisterAction.uninstallAction(Onl
yUnregisterAction.java:45)
at
org.jboss.system.microcontainer.ServiceControllerContextAction$2.run(Ser
viceControllerContextAction.java:97)
at
org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall
(ServiceControllerContextAction.java:101)
at
org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(
AbstractControllerContextActions.java:58)
at
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(Abstrac
tControllerContext.java:236)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractContro
ller.java:723)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(Abstrac
tController.java:685)
at
org.jboss.dependency.plugins.AbstractController.uninstallContext(Abstrac
tController.java:613)
at
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractContro
ller.java:223)
at
org.jboss.system.ServiceController.shutdown(ServiceController.java:549)
at
jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Lja
va.lang.Object;)Ljava.lang.Object;(Unknown Source)
at
java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)L
java.lang.Object;(Unknown Source)
at
org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.
java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at
org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.jav
a:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at
org.jboss.system.server.ServerImpl$ShutdownHook.shutdownServices(ServerI
mpl.java:1070)
at
org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java
:1028)
at
org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:987)
Followed by:
2006-08-22 03:45:26,288 DEBUG
[org.jboss.ejb.plugins.jms.JMSContainerInvoker] Stopping
jboss.j2ee:service=EJB,plugin=invoker,binding=message-driven-bean,jndiNa
me=local/SubclassMDB@5595271
2006-08-22 03:45:26,290 DEBUG
[org.jboss.ejb.plugins.jms.JMSContainerInvoker] Stop requested for
recovery thread: null
2006-08-22 03:45:26,292 DEBUG
[org.jboss.ejb.plugins.jms.JMSContainerInvoker] innerStop
2006-08-22 03:45:26,292 DEBUG
[org.jboss.ejb.plugins.jms.JMSContainerInvoker] unset exception listener
2006-08-22 03:45:26,293 DEBUG
[org.jboss.ejb.plugins.jms.JMSContainerInvoker] connection stopped
2006-08-22 03:45:26,293 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler]
Stopping DLQHandler
2006-08-22 03:45:26,293 DEBUG [org.jboss.ejb.plugins.jms.DLQHandler]
Stopped DLQHandler
Thereafter nothing more about shutdown; just the
LRUEnterpriseContextCachePolicy remover task kicking in periodically.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
________________________________
From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-bounces@lists.jboss.org] On Behalf Of Scott M
Stark
Sent: Tuesday, August 22, 2006 7:52 PM
To: JBoss.org development list
Subject: Re: [JBoss-dev] RE: jboss-head-testsuite-1.5 Build
Failed
Just running the tests-security-manager target I'm not seeing
the server fail to shutdown. I would suspect that there are multiple
runs conflicting with each other.
Brian Stansberry wrote:
It looks like the testsuite is failing because the
server instance used by tests-security-manager is not shutting down.
The server used by the clustering tests then fails to start due to port
conflicts. (The "default" config logs show the securitymgr server still
alive 5 mins after the clustering server tries to start.)
Can someone take a look at why the securitymgr server is
not shutting down?
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
19 years, 7 months
RE: [JBoss-dev] jboss-head status
by Jason T. Greene
Not sure if this is related, but take a look at [1]. The original
ServiceController unregisters on remove.
[1]
http://lists.jboss.org/pipermail/jboss-development/2006-August/000776.ht
ml
-Jason
> -----Original Message-----
> From: jboss-development-bounces(a)lists.jboss.org
[mailto:jboss-development-
> bounces(a)lists.jboss.org] On Behalf Of Scott M Stark
> Sent: Thursday, August 24, 2006 4:33 PM
> To: JBoss.org development list
> Subject: Re: [JBoss-dev] jboss-head status
>
> So I have redployment working cleanly, but now on shutdown mbeans
> implicitly added to the ServiceController by MBeanSupport lifecycle
> actions have errors like the following due to no longer being
registered
> with the MBeanServer:
>
> javax.management.InstanceNotFoundException:
> jboss.j2ee:service=EJB,plugin=pool,jndiName=cmp2/simple/Simple is not
> registered.
> at
>
org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.j
av
> a:527)
> at
>
org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java
:3
> 83)
> at
> org.jboss.system.ServiceCreator.uninstall(ServiceCreator.java:309)
> at
>
org.jboss.system.microcontainer.OnlyUnregisterAction.uninstallAction(Onl
yU
> nregisterAction.java:45)
> at
>
org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall
(S
> erviceControllerContextAction.java:90)
> at
>
org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(
Ab
> stractControllerContextActions.java:58)
> at
>
org.jboss.dependency.plugins.AbstractControllerContext.uninstall(Abstrac
tC
> ontrollerContext.java:236)
> at
>
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractContro
ll
> er.java:723)
> at
>
org.jboss.dependency.plugins.AbstractController.uninstallContext(Abstrac
tC
> ontroller.java:685)
> at
>
org.jboss.dependency.plugins.AbstractController.uninstallContext(Abstrac
tC
> ontroller.java:613)
> at
>
org.jboss.dependency.plugins.AbstractController.uninstall(AbstractContro
ll
> er.java:223)
> at
>
org.jboss.system.ServiceController.shutdown(ServiceController.java:549)
>
>
> Why is the ServiceController trying to unregister mbeans it did not
> register?
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
19 years, 7 months
