Clarification about service undeployment on SLEE 2.6.0.FINAL

[Eduardo Martins]

This is something that I failed to inform on the release announcement, since 2.6.0.FINAL, by default SLEE does not forces any SBB entity removal on service deactivation. This means that when you are developing, and try to deactivate a service that has sbb entities that will not be removed by itself, you will get the service stuck in STOPPING state, and this will for sure block any kind of service redeploy using same service ID (service undeploy is only complete once service state moves to INACTIVE). Please note that this will not block the smooth service upgrade (redeploy of service with same name and vendor by different version), cause SLEE activates the new version when it changes the older one to STOPPING state.

As mentioned in the user guide documentation, you can activate the SLEE sbb entity forced removal in the server profile's mobicents-slee/META-INF/jboss-beans.xml:

<bean name="Mobicents.JAINSLEE.MobicentsManagement" class="org.mobicents.slee.container.management.jmx.MobicentsManagement">

<annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="org.mobicents.slee:service=MobicentsManagement",exposedInterface=org.mobicents.slee.container.management.jmx.MobicentsManagementMBean.class,registerDirectly=true)</annotation>

<!-- 0 means entities are not removed by force -->

<property name="entitiesRemovalDelay">0</property>

</bean> 

-- Eduardo
..............................................
http://emmartins.blogspot.com

[Vilius Panevėžys]

Would a service stuck in the STOPPING state block SLEE shutdown?

--
Vilius Panevėžys
Elitnet

[Alexandre Mendonça]

Hi Vilius,

Yes, it would, until:

a) the service sbb entities complete their work, allowing the service to gracefully move to stopped state;

or

b) entitiesRemovalDelay expires and forces removal of service sbb entities, allowing the service to stop

Now, since b) only happens when entitiesRemovalDelay has a value greater than 0 ("0" is SLEE 2.6.0 default, but has been reverted to "1" for future releases) it means that it could hang it "forever" if there are sbb entities leaking.

Regards,

--

Alexandre Mendonça // JBoss R&D
http://ammendonca.blogspot.com/

2012/3/14 Vilius Panevėžys <vil...@elitnet.lt>

[Vilius Panevėžys]

Thank you Alexandre,
the "forever" case was exactly my concern. :) Is there any way out of
such situation apart from 'kill -9' preventing any proper deinit?

What are the cases where '0' would be the desired value for
entitiesRemovalDelay? Is '1' the sane and recommended for production
env value?

--
Vilius Panevėžys
Elitnet

On Wed, 14 Mar 2012 13:07:01 +0000
Alexandre Mendonça <brai...@gmail.com> wrote:

> Hi Vilius,
>
> Yes, it would, until:
>
> a) the service sbb entities complete their work, allowing the service
> to gracefully move to stopped state;
>
> or
>
> b) entitiesRemovalDelay expires and forces removal of service sbb
> entities, allowing the service to stop
>
> Now, since b) only happens when entitiesRemovalDelay has a value
> greater than 0 ("0" is SLEE 2.6.0 default, but has been reverted to
> "1" for future releases) it means that it could hang it "forever" if
> there are sbb entities leaking.
>
> Regards,
>
> --

> *Alexandre Mendonça* // JBoss R&D

[Alexandre Mendonça]

I don't think there are better options than forcing the process to be killed :( It completely hangs the deployers thread...

As suggested, if it is hanging is because something either it's still working (than "forever" will have an end..) or it is leaking.. and should be fixed :). And when the leaks are fixed, than "0" would be the ideal :)

A sane value for production depends, but let's consider you have ongoing calls.. using a value of "1" would mean that it would allow the calls to be running for "only" one more minute and than it would be forcefully terminated. In this case the average call time (3 mins ?) would be more indicated.

--

Alexandre Mendonça // JBoss R&D
http://ammendonca.blogspot.com/

[Eduardo Martins]

Use 0 and kill the server if it hangs, no need to waste 1 minute of your life :)

-- Eduardo
..............................................
http://emmartins.blogspot.com

2012/3/14 Alexandre Mendonça <brai...@gmail.com>