We're updating the issue view to help you get more done. 

Clearing cache can lock up MUC

Description

http://www.igniterealtime.org/community/message/187510
http://www.igniterealtime.org/community/thread/33419

Clearing the cache seems to lock up the MUC portion of openfire. The result is this curious trace:

the 'conference.jabber.company.com' is the local MUC

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Guus der Kinderen
February 6, 2013, 7:57 PM

Removing the 'fix version' for all unresolved issues that were scheduled for version 7.8.2. We're releasing this version today - the remaining issues should be rescheduled later.

Daryl Herzmann
February 23, 2013, 1:28 PM

I'm gonna set this as a blocker to 4.0.0 as it is ugly

Daryl Herzmann
February 15, 2014, 1:43 PM

Still easily able to reproduce Placing against the next release.

Tom Evans
April 7, 2014, 7:55 PM

This issue is caused by the components cache being cleared. The MUC engine registers each conference service as a separate component, and when all the caches are cleared, the cached components are effectively deleted until the next Openfire restart. This effect would be similarly true for any third-party plugins that use the Component API.

The stack trace indicates that the internal packet router does not recognize the registered component name (because it was removed from the component cache), and therefore tries to route the packet via an S2S connection. However, the component name is apparently still registered with the internal routing table, which then tries to cast the component handler as an outgoing session (via S2S). This is what causes the ClassCastException.

Potential solutions (from easiest to most difficult) include:

  • Exclude the components cache from the list of caches that can be cleared

  • Create an event/listener API to notify components when a given cache (or cache+key) is created/modified/deleted, then implement listener(s) to re-initialize components when needed

  • Refactor the component manager(s) and routing engine to avoid using a cache for registering components

There are some additional workaround options (like purging the internal routing table, test before cast, etc.), but none of these would address the root cause. Seems to me the first option above is probably sufficient in this case, as it is not likely that registered components should be silently disabled/removed via a cache management operation. However, it does expose a bigger issue in terms of how we want to handle lifecycle management concerns for Components (as we do with Plugins).

Tom Evans
April 7, 2014, 10:29 PM

Disabled cache purging for the Components cache.

Assignee

Tom Evans

Reporter

Daryl Herzmann

Labels

None

Expected Effort

None

Ignite Forum URL

None

Fix versions

Affects versions

Priority

Blocker
Configure