hl7 TIdHL7.SynchronousSend does not respect timouts

[CoMPi74 3]

Hi there, 

 

I have a problem with TIdHL7  (Windows 8, Delphi XE4, Indy, ver. 10.6.2.0). Of course, I am trying to solve it by myself, but still without success. Anyway, here is a piece of code which makes me crazy...

// stopping IdHL7 before configuration
if IdHL7.Going then IdHL7.Stop;

// setting timeouts and server address 
IdHL7.ReceiveTimeout := 1 * 60 * 1000;
IdHL7.Timeout := 1 * 60 * 1000;
IdHL7.IsListener := False;

IdHL7.Address := SERVER_ADDRESS;
IdHL7.Port := SERVER_PORT;

// starting the connection
IdHL7.Start;
IdHL7.WaitForConnection(10000);

// getting and sending some messages from DB
while not AQuery.EOF do begin
  AMessage := AQuery.FieldByName('MessageToSend').AsString;
  AReturn := IdHL7.SynchronousSend(AMessage, AReply); 		// This is a problematic line ...
  AQuery.Next;
end;

As one can see I want to send some HL7 messages to SERVER. The server is online and it gets the messages send by SynchronousSend method and responds for them (confirmed). My logs show that the code works as expected but only for the very first call SynchronousSend (the method returns srOK and a valid reply sent byt the remote server).  Unfortunatelly, every next call of SynchronousSend returns srTimouts, even if the result is returned just a few miliseconds after call, what is strange because, as you can see, the timeouts are set for 60 seconds 😕

What I am doing wrong? What I am missing? 

 

@Remy Lebeau as everyone knows, You are the undisputed Guru on this topic, so I am sure it is a piece of cake for you. Could you be so nice to help?

 

 

[Remy Lebeau 1421]

XE4 was released 10 years ago.  And TIdHL7 specifically got a major revamp from its original author a year ago.  So, you should upgrade to the latest Indy (if not to a modern Delphi) and see if the problem still occurs.

[CoMPi74 3]

@Remy Lebeau The Indy components have been upgraded a month ago, or so, and now I use Indy ver. 10.6.2.0.  

Anyway, today's tests show that the app sends the messages every second time (I mean, the first call returns srOK and a valid reply, the second, srTimout and no reply, the third, as the first, srOK and the fourth, as the second, srTimeout, and so on). Looking into code I noticed that when the AsynchronousSend returns srTimeout the method DropClientConnection is called... I suppose that could be the cause of such a behavior...  
I also tried to use another approach. I changed the CommunicationMode to cmSingleThread, and then I was calling SendMessage and GetReply. Unfortunatelly, without success. GetReply returned srNone evere time. It is quite strange because, as one can read in comments, the state srNone is internally used and (should be) never returned 😕

Any idea?  

[Remy Lebeau 1421]

I didn't write TIdHL7 and I'm not familiar with how the HL7 protocol works. I'll have to look into what is going on. I've opened a ticket on Indy's GitHub:

 

https://github.com/IndySockets/Indy/issues/501

[CoMPi74 3]

On 10/2/2023 at 9:40 AM, Remy Lebeau said:

I didn't write TIdHL7 and I'm not familiar with how the HL7 protocol works. I'll have to look into what is going on. I've opened a ticket on Indy's GitHub:

 

https://github.com/IndySockets/Indy/issues/501

In fact, I managed to solve the problem by creating a new instance of the TIdHL7 object every time I try to send a HL7 message. In this case, everything works as it should. However, as I wrote earlier, when I tried to send a second message using the same instance of the component (with exactly the same settings), I received the srTimeout message.
There's clearly something going on, but I can't find it myself. Especially since I use TIdHL7 component in a Windows service, which makes debugging very difficult...

Anyway, thank you, @Remy Lebeau. 

 

PS. Is there any smart way to debugging windows services? 

 

 

[DelphiUdIT 183]

See this: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Debugging_Service_Applications

[Remy Lebeau 1421]

2 hours ago, DelphiUdIT said:

See this: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Debugging_Service_Applications

I use the "Attach to Process" approach when debugging my services.  Also, if I want to debug the service's startup logic, I pass in a particular startup parameter via the SCM, and then add code in the service's OnStart event to look for that parameter and if present then hold the service in csStartPending state until the debugger attaches.

Edited October 3, 2023 by Remy Lebeau