web stats
Download | Support | Contact

Mirth Connect

Setting "Don't store messages" will cause dangling attachments to be left in the attachment table when used with DICOM

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.8.1
  • Fix Version/s: 1.8.2
  • Component/s: None
  • Operating System:
    Windows XP
  • Description:
    Setting "Don't store messages" will cause dangling attachments to be left in the attachment table when used with DICOM.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Daniel Svanstedt added a comment - 06/Nov/07 10:43 AM
Remove Attachment data in JavaScriptPostProcessor if we do not store attachments.
Show
Daniel Svanstedt added a comment - 06/Nov/07 10:43 AM Remove Attachment data in JavaScriptPostProcessor if we do not store attachments.
Hide
Permalink
Mark Erickson added a comment - 07/Oct/09 9:11 AM
We are still seeing this issue in version 1.8 when using a DICOM sending channel. Is there a work around or an action that needs to be implemented in the channel?
Show
Mark Erickson added a comment - 07/Oct/09 9:11 AM We are still seeing this issue in version 1.8 when using a DICOM sending channel. Is there a work around or an action that needs to be implemented in the channel?
Hide
Permalink
Heath Winters added a comment - 12/Oct/09 6:19 AM
We are experiencing this issue with both the default embedded Derby database and also with an Oracle database. In our case we have two channels both with the "Store message data" option unchecked. The first has a DICOM source and a File Writer destination. This channel works fine, we see the Attachment record in the database briefly, but it is deleted correctly. The second channel has a File Reader source and a DICOM destination. This is the channel that is leaving attachments behind in the attachment table.
Show
Heath Winters added a comment - 12/Oct/09 6:19 AM We are experiencing this issue with both the default embedded Derby database and also with an Oracle database. In our case we have two channels both with the "Store message data" option unchecked. The first has a DICOM source and a File Writer destination. This channel works fine, we see the Attachment record in the database briefly, but it is deleted correctly. The second channel has a File Reader source and a DICOM destination. This is the channel that is leaving attachments behind in the attachment table.
Hide
Permalink
Daniel Svanstedt added a comment - 23/Oct/09 2:59 PM
Reopen... Attachment are not being deleted properly in the postprocessor as they should.
Show
Daniel Svanstedt added a comment - 23/Oct/09 2:59 PM Reopen... Attachment are not being deleted properly in the postprocessor as they should.
Hide
Permalink
Jacob Brauer added a comment - 10/Nov/09 10:36 AM
Fixed issue with dangling attachments. Attachments are stored with source message id when message storage is turned off.
Show
Jacob Brauer added a comment - 10/Nov/09 10:36 AM Fixed issue with dangling attachments. Attachments are stored with source message id when message storage is turned off.
Hide
Permalink
Christopher Ro added a comment - 26/Feb/10 12:17 PM
In 1.8.2.4472, This is still an issue in following scenario:

"Synchronize Channel" -- Unchecked
"Store Message Data" -- Unchecked

However, DICOM attachments are still created in Attachment table.

This is _not_ an issue if "Synchronize Channel" is checked.


Show
Christopher Ro added a comment - 26/Feb/10 12:17 PM In 1.8.2.4472, This is still an issue in following scenario: "Synchronize Channel" -- Unchecked "Store Message Data" -- Unchecked However, DICOM attachments are still created in Attachment table. This is _not_ an issue if "Synchronize Channel" is checked.
Hide
Permalink
Jacob Brauer added a comment - 22/Mar/10 12:13 PM
This is because the removing stored attachments is done as a part of the postprocessor, which does not run in an unsynchronized channel. Currently there is no way to know when all destinations are done processing in an unsynchronized channel, so there is no way to run the postprocessor. The workaround for now is to either use a synchronized channel or shorten the Message Pruning time, which will clean up any dangling attachments.

Further work on this issue will be a part of MIRTH-1333.
Show
Jacob Brauer added a comment - 22/Mar/10 12:13 PM This is because the removing stored attachments is done as a part of the postprocessor, which does not run in an unsynchronized channel. Currently there is no way to know when all destinations are done processing in an unsynchronized channel, so there is no way to run the postprocessor. The workaround for now is to either use a synchronized channel or shorten the Message Pruning time, which will clean up any dangling attachments. Further work on this issue will be a part of MIRTH-1333.
Hide
Permalink
Jacob Brauer added a comment - 22/Mar/10 12:14 PM
See MIRTH-1333 for problems regarding unsynchronized channels and dangling attachments.
Show
Jacob Brauer added a comment - 22/Mar/10 12:14 PM See MIRTH-1333 for problems regarding unsynchronized channels and dangling attachments.

People

Dates

  • Created:
    01/Nov/07 5:13 PM
    Updated:
    22/Mar/10 12:14 PM
    Resolved:
    22/Mar/10 12:14 PM
Atlassian JIRA (v4.1.1#522) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Mirth Corporation. Try JIRA - bug tracking software for your team.