Component implementations are often the Achilles' heel of an Openfire cluster. Openfire uses a limited pool of worker threads for a variety of tasks. These threads are also used to call the processPacket() method of Component. This allows for synchronous operation, but adds to the risc of Openfire running out of worker threads. If this happens, the entire XMPP domain usually suffers from dramatic loss of service.
There's a lot to learn from this. The issue is not limited to Component implementations alone, but is a wide-spread problem in Openfire itself. There is, however, a relative simple solution to work around the biggest bottlnecks: have Component implementations follow the producer/consumer design pattern.
The implementation of the abstract component will use a Java Executor service that will form the basis of the consumer. Note that this will make any component packet handling asynchronic. From experience, I've learned that a lot (if not most) existing implementations do not suffer (or even benefit) from this.
Environment
None
Activity
Show:
Guus der Kinderen
September 25, 2009 at 1:08 AM
Two unit tests have been added in the subversion repository. One checks that the thread that processes a stanza in an AbstractComponent is not the same thread as the one that delivers the stanza to the component. Another test verifies that the producing thread does not wait for the consumer to finish processing.
Component implementations are often the Achilles' heel of an Openfire cluster. Openfire uses a limited pool of worker threads for a variety of tasks. These threads are also used to call the
processPacket()
method ofComponent
. This allows for synchronous operation, but adds to the risc of Openfire running out of worker threads. If this happens, the entire XMPP domain usually suffers from dramatic loss of service.There's a lot to learn from this. The issue is not limited to
Component
implementations alone, but is a wide-spread problem in Openfire itself. There is, however, a relative simple solution to work around the biggest bottlnecks: haveComponent
implementations follow the producer/consumer design pattern.The implementation of the abstract component will use a Java Executor service that will form the basis of the consumer. Note that this will make any component packet handling asynchronic. From experience, I've learned that a lot (if not most) existing implementations do not suffer (or even benefit) from this.