web stats
Mirth Community - View Single Post - Recurring Connection Resets on HTTP Sender to specific backend.
View Single Post
  #8  
Old 09-30-2019, 02:21 PM
thaddeus_k thaddeus_k is offline
What's HL7?
 
Join Date: Sep 2019
Location: Dallas, TX
Posts: 4
thaddeus_k is on a distinguished road
Default

Ok, I now have a fresh batch of captures from earlier today. Also included in the zip file are screenshots of wireshark as I've been looking at it, hopefully that helps guide things.

The wireshark filter I've been using is:

Code:
ip.addr eq 10.9.1.116 and ip.addr eq 136.147.40.21/16
, where 10.9.1.116 is the mirth server, and 136.147.40.21/16 seems to be the ip range my URL resolves to.

For the file named 'September_30_Two_attempts_error101538_success1016 04.pcapng', I've concluded that the two requests sent turned out to be in
Code:
tcp.stream eq 6 or tcp.stream eq 11
.

For that file, I sent one request, allowed it to reach a connection reset state, and then resent the original request, observing that it succeeded on the second try. This destination has a very long timeout to allow the full reset process to occur.


For the file named 'Sepectember_30_Prior_Auth_Timeout_Error102840_Suc cess102854.pcapng', I again sent one request on the other destination and allowed it to timeout, followed by a successful request. This one has the timeout value used in production, so that it matches what's going on in production currently. Wireshark filter is
Code:
tcp.stream eq 4 or tcp.stream eq 8

For the file named 'September_30_redeploy_and_four_successes.pcapng', I started wireshark, redeployed the mirth channel, and then sent a pair of requests on both destinations, expecting the first one of each to fail. Unexpectedly, failures did not occur on this run, so I instead have four successful processes. Here I have just been using the IP filter listed above.
Attached Files
File Type: zip Data_Collection_for_Forum.zip (5.46 MB, 1 views)
Reply With Quote