Remove simplesender from tag
Tagged 3.0.2
Removing DerbyGroupConcat and all references to it since it is no longer used with the new search queries.

Issue: MIRTH-3191

    • -2
    • +0
Organized Imports
Appending license
searchAll no longer returns a TreeMap. Instead it returns a HashMap since order does not yet matter. Each individual operation now creates a TreeMap only when necessary.

For custom metadata, content, and text searches, only the range from the set of potential messages are searched now instead of the entire current range.

Issue: MIRTH-3191

MIRTH-3108: Fixed bug that caused message exporting to fail when the source connector is excluded from the search results. In getMergedConnectorMessage, we're now checking whether the source connector exists and only populating that info if applicable.
No longer using ListRangeIterator to run searchLengthy only on potential message ids. In the worst case scenario where all odd or all even records are missing, searching by message list is significantly slower than just searching the entire range anyway.

Issue: MIRTH-3191

MIRTH-3198: If multiple channels/connectors are started/stopped/etc at once, an exception for one does not stop other channels/connectors from being started/stopped/etc.
MIRTH-3201: If multiple channels are deleted at once, an exception for one channel does not stop other channels from attempting to be deleted.
Client operations that are used for retrieving a single message content/attachment now use the executePostMethodAsync so the client does not hang (until the search is finished) if a search is being performed and a user selects a message.

Issue: MIRTH-3228

MIRTH-3166, MIRTH-3201: For enabling/disabling/deleting channels, a single call to get the channels is now done first so that the cache only needs to be refreshed once. Also for deleting, the Channel object is passed in, instead of passing in the channel ID. This is so that it doesn't need to refresh the cache every time, and because the channel plugins need the entire Channel object anyway.
Don't try to persist maps if the map content is null. Since we added source map in 3.0.2, this could occur if importing a message from 3.0.0 or 3.0.2.

Issue: MIRTH-3111

Fixed string comparison in DashboardTableNode.setStatus to use String.equals instead of == operator.

Issue: MIRTH-3227

Now allowing content searching on all content types since text search also searches all content types now.

Removed some debug code from DonkeyMessageController.

Issue: MIRTH-3123

Updated the data pruner to use the ListRangeIterator

Issue: MIRTH-3147

Completely overhauled the backend for the Message Browser. We are no longer using any type of array/list aggregate functions from various databases. This also means that we can now support many older versions of our backend databases. Searches are no longer done in a single query regardless of how many messages are in the channel. Now the searches/deletes/reprocessing/count are all done in batches than scan based on ranges of message Ids. This means that there is a cap on the amount of memory a search will use. This prevents text searches on channels with large amounts of messages from using up all the memory on a machine and slowing down or crashing the whole system. Searches now occur in linear time regardless of how many messages are in a channel. The performance for non-text searches has decreased slightly but are still within usable ranges, while text/custom metadata/content searches have improved dramatically.

deleting/reprocessing/counting have all been overhauled as well to use the new pattern.

Text search no longer adds all the content types to the content type search

Removed messageIdUpper and messageIdLower from the message filter. Now we are using maxMessageId and minMessageId instead.

Removed source and type from MessageFilter because they are no longer used



    • -144
    • +160
    • -0
    • +5
    • -142
    • +160
  1. … 5 more files in changeset.
MIRTH-3150: Fixed function code template inclusion so that it works the same as it did in 2.x. The only differences are that Channel code templates are now available in the channel deploy/shutdown/preprocessor/batch scripts where they weren't available before. The attachment script (new in 3.x) allows Channel or higher, and the response transformer (also new) allows Message or higher (i.e. all templates).

In the global scripts panel, we're now actually restricting the available templates shown in the UI to only Global Channel or Global. This is because although Channel templates are available for the postprocessor, they aren't available for the other scripts, and the panel doesn't differentiate between different script types when showing the reference list.

MIRTH-3103: Fixed table sorting in the channel tag filter dialog.
MIRTH-3110: Fixed bug (due to switching to PDFBox) that caused owner passwords to not be set anymore on encrypted PDFs. First, content extraction (for accessibility) is now set to false, the same as it was in 2.x. Second, we're now generating a pseudorandom owner password ourselves in the dispatcher, the same way as was being done in 2.x (internally in iText).
MIRTH-3172: Updated the copyright date on the splash screen image.
MIRTH-3198: Prevented doStart() from always issuing two requests. Instead it only sends the start/resume requests if the respective channel ID sets are not empty.
MIRTH-3111: Changed deprecated references from getChannelMap to getSourceMap.
MIRTH-3203: The client no longer retrieves channel tags from the server at all. The Channels view and Dashboard view tags are now separate entities, and instead of requesting tags from the server, they are simply inferred from either the client-side channel status / dashboard status cache. The ChannelFilter dialog is no longer being kept around; it's now only instantiated as-needed and disposed afterwards.

The Client.getChannelTags method and the associated operation / servlet / controller code has been removed, since it is no longer necessary.

MIRTH-3163: Fixed bug with the new status retrieval that caused tags to not work correctly on the dashboard.
MIRTH-3211: Fixed bug that caused sorting on the status columns to no longer work.
Created a class MirthCachedRowSet that extends CachedRowSetImpl which uses column label instead of column name when retrieving the column number from a string. This ensures that aliases will still work if the database driver correctly follows the JDBC4.0 spec to always return the column name with getColumnName(), and return the column name or alias with getColumnLabel() depending on if an alias was used. Currently it seems that of the drivers we currently provide, only MySQL follows this spec. The others all return the alias (if it exists) with either getColumnName() or getColumnLabel().

Issue: MIRTH-3124


This was caused by ResultSetMetaData.getTableName() returning empty string. This happens for various cases in SQL Server and always happens for Postgres and Oracle. We decided to stop using table name in the element name at all and only use the alias/column name. If any conflicts happen we were throw an exception and stop the poll. The user will have to add a unique alias for the channel to process. By not checking against the table name anymore the message will no longer fail for columns of type TEXT.


Since we will never be using table name in the result xml element names anymore, this issue is resolved. Note that for Postgres and Oracle, the table names were never used since the check of whether there were multiple tables would always return false.


Fixed this by longer adding both the column name and column label to the result map. Also we now use the column label all the time instead of column name.

MIRTH-3199, MIRTH-3200: Improved how dashboard/channel panel plugins (server/connection logs) are updated in the Administrator.

Before, _many_ requests (at times up to a dozen) were being made to the server on the event dispatch thread whenever the user did pretty much anything (like clicking anywhere in the dashboard table). Now, the plugins have an extra set of methods specifically for long-running requests or data retrieval (prepareData). The current methods (update) are still called on the event dispatch thread, but the new methods are always being called in a background thread first.

To facilitate this, two new classes were added: QueuingSwingWorker and QueuingSwingWorkerTask. The former extends SwingWorker, and mimics the synchronization/queuing that we were already doing for refreshing statuses/channels/alerts. Now that's all handled in the class itself. All the caller has to do is pass in a task and override the doInBackground() method, basically almost exactly what it was doing before. The new worker class keeps a static ConcurrentHashMap of worker states for each task type (e.g. "doRefreshStatuses", "doRefreshChannels", etc.). To ensure that only one worker for a task type is running at any given time, the constructor synchronizes on the worker state and only starts working if the current state is IDLE. Then in the done() method, after the task completes the worker will synchronize again, and reset the state back to IDLE. When a new worker is instantiated, queuing is enabled, and there's already a worker running, the state will be set to QUEUED instead. Then in done() if the state was previously QUEUED, a new worker will be instantiated and executed.

This new queuing mechanism was applied to refreshing statuses/channels/alerts, and also to the dashboard/channel panel plugins whenever they are updated. In the future this can also be applied elsewhere, basically any time a task might be called from two different threads and only one should execute at a time.

Also, a new invokePluginMethodAsync method was added to Client. The connection status log/column, server log, and advanced alerting plugins now use the asynchronous connection pool rather than the single synchronous connection. This should greatly improve performance on the dashboard, because requests for different plugins can occur at the same time on different connections.

MIRTH-3202: Improved how channels are retrieved in the Channels view. Instead of making two different requests to get the channel summaries and the channels themselves, the client is now only making one request, and the server sends back any information the client needs to update. ChannelSummary now contains a new ChannelStatus object, which includes the Channel itself, as well as the deployed date and revision delta. Back in the client, instead of a cache of Channel objects, it's now holding a cache of ChannelStatus objects, so that it can persist the deployed channel information in the same place.