Announcement

Collapse
No announcement yet.

DICOM error, flow

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DICOM error, flow

    I've ran into an issue related to a DICOM channel I've setup. The channel is pretty simple, receiving a DICOM, changing a couple of fields, and sending the DICOM onto the destination PACS. However, we've started to get errors like the following:

    ERROR 2010-09-14 18:39:14,565 [DCMRCV-160580] org.mule.impl.DefaultComponentExceptionStrategy: Caught exception in Exception Strategy for: 765970c7-25e9-4e3f-8162-df77239323a1: org.mule.umo.routing.RoutingException: Failed to route event via endpoint: null. Message payload is of type: com.webreach.mirth.model.MessageObject
    org.mule.umo.routing.RoutingException: Failed to route event via endpoint: null. Message payload is of type: com.webreach.mirth.model.MessageObject
    .....
    Caused by: org.mule.umo.routing.CouldNotRouteOutboundMessageE xception: Failed to route event via endpoint: ImmutableMuleEndpoint{connector=com.webreach.mirth [email protected], endpointUri=dicom://10.x.x.xxx:104, transformer=Transformer{name='765970c7-25e9-4e3f-8162-df77239323a1_destination_2_transformer', returnClass=false, returnClass=false, sourceTypes=[]}, name='_dicomEndpoint#-2047338157', type='sender', properties={}, transactionConfig=org.mule.impl.MuleTransactionCon [email protected], filter=null, deleteUnacceptedMessages=false, initialised=true, securityFilter=null, synchronous=true, initialState=started, createConnector=0}. Message payload is of type: com.webreach.mirth.model.MessageObject
    ...
    Caused by: java.net.BindException: Address already in use
    at java.net.PlainSocketImpl.socketBind(Native Method)


    So, the question is one of how the DICOM channel works. My understanding is that Mirth channels are single-threaded receiving, and block until all destination channels are handled. In my message history, I see the Transformation stage, but whenever the above error is received, no Sent message is shown, undoubtedly because the destination channel errored with the Address already in use. Is there any way the channel, while still trying to send to the Destination, might error, and then somehow not release the IP and port and cause this error?

    According to sniff tests on the network, we see Associate request, Associate response, C-Store-RQ, and then the connection just stops, not continuing with C-Store-RSP, A-Release-RQ and A-Release-RSP. The DICOM sender does have a number of timeouts and delays. I've left all of the DICOM send and receive delays and timeouts at their defaults.

    I know I posted some of this information on an earlier post, but that was mainly checking about what Mirth used for DICOM, and getting a conformance statement.

    All help and insight greatly appreciated!

    Phil

  • #2
    So, turned out at least that the address in use was indeed a conflict with an existing channel elsewhere.

    Comment


    • #3
      dicom error

      We too were running into this similar error at our institution. This primarily happened to us with modality=RF. If you have Mirth handle Little Endian only we get an error like the one you posted. If you have Mirth handle JPEG lossless then no error is generated but the dicom file is malformed (we strongly suspect the pixel data is not put back together with the metadata. Mirth is aware of this issue.
      Mark Nigogosyan

      Comment

      Working...
      X