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

An unexpected exception occurred with loading clustering plugin

Description

user provided logs of Openfire 4.2.1 attempting to load old clustering plugin over and over again every 20 seconds without stopping

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Guus der Kinderen
December 12, 2017, 3:54 PM

I'm guessing that this problem is caused by a plugin directory (in which the plugin was previously expanded) that still exists, but has no, or partial, content. Perhaps a failed uninstallation, caused by objects still being referenced in memory, preventing from libraries being deleted, or file-permission problems.

Kyoshiro
March 26, 2018, 10:39 AM

I had a similar issue after updating from 4.1.6 to 4.2.3 today, using .deb Debian package.

The plugin directory contained an obsolete plugin called hazelcast and tried to load it in a loop before starting listeners on 5223 port.
Admin console was working properly though.

After removing / moving away /var/lib/openfire/plugins/{hazelcast,hazelcast.jar}, server started properly.

Kind regards.

Daryl Herzmann
March 26, 2018, 1:16 PM

@Kyoshiro, thanks for chiming in.  To clarify, if you update the plugin via the admin console, this issue goes away and clustering works fine?

Kyoshiro
March 26, 2018, 1:29 PM

In fact we weren't using that plugin nor clustering anymore, and it did not show up in the plugin list on the admin console.
It must have been an aborted attempt for clustering.

Anyways, the server wouldn't properly startup until hazelcast directory and jar file were actually removed from /var/lib/openfire/plugins directory.

After removing, clients were able to connect to the server.

Greg Thomas
June 8, 2018, 12:59 PM
Edited

FWIW, I'm seeing something very similar to this very intermittently with Openfire 4.2.3 on Windows. It seems to happen either more often, or perhaps only ever, when a new plugin has been installed and needs unpacking. My suspicion is that, in my case at least, the AV on the machine in question is preventing access from the Openfire process to a newly created file while it's still being AV scanned, causing this issue.  If it happened more reliably I'd have an attempt at trying to diagnose it better!

Greg

Assignee

Greg Thomas

Reporter

Daryl Herzmann

Labels

None

Expected Effort

None

Components

Fix versions

Affects versions

Priority

Major
Configure