JXplorer Thread Architecture
Overview
JXplorer Uses a number of worker threads during data access, to prevent the GUI freezing up during slow directory accesses (or during accesses to directories that go off-line)
The system is a standard queued request model, where Data Queries (e.g. a directory search) are produced by the GUI thread following a user action. These queries are then queued up by the appropriate 'Data Broker', which sequentially processes the queries.
When the query is resolved, it notifies any 'data listeners' such as the editor pane, or the browsing tree, which are updated (still in the broker thread). Eventually the GUI thread recognises the state change, and updates the GUI display with the new data.
Multiple Brokers
There are multiple brokers, one for each of the display trees (browse, search and schema). Each broker runs in a separate thread, although they share a common data connection, and access to this (usually the LDAP connection) is synchronised. Thus the picture above is actually repeated three times. There is also a separate broker for the LDIF files, which occasionally replaces the normal LDAP Broker.
The details of the thread model are especially important to writers of plug-in entry editors who want to do further directory accesses, since those editors will be running in the broker thread when they receive the results of an initial query. Failing to allow for this can easily lead to dead lock, which results in the plug-in editors apparently 'freezing' when they make further directory requests.