-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delayed messages with Indy Socket #8
Comments
Thank you for your suggestion Jon. I'll investigate ASAP. |
Hi Daniele, Since I think the underlying problem is with the Indy socket, I’ve also placed a question on the Embarcadero forum: Jon From: Daniele Teti [mailto:notifications@github.com] Thank you for your suggestion Jon. I'll investigate ASAP. — |
Hi Daniele, Remy Lebeau has responded to this thread on the Delphi forum. I will follow the suggestion up in the next few days when I get a chance. https://forums.embarcadero.com/thread.jspa?messageID=809343#809343 |
Hi Daniele, Remy Lebeau's suggestion in the link above worked. I must admit that I would have coded it in the same way that you did, and I still don't quite see why ReadChar should fail every few hours. Is it possible that it could time out whilst waiting for the second byte of a character? Anyway... Remy's solution seems to cover all possibilities. He reads the encoding from the STOMP headers (if present) and then reads the body with the selected encoding. Jon |
Hi,
I'm using the StompClient to connect to an Oracle OpenMQ JMS. Every now and again (a few times a day) a message on an incoming queue appears to get stuck and does not arrive at the listening application - until it is "pushed through" by the subsequent message.
The problem is particularly visible with a heartbeat message that arrives once a minute. Every now and again there is a two minute delay between heartbeat messages instead of one - then two arrive at once. The sending application (a Java application on another computer under Linux) confirms that the messages were sent on time.
The receiving application, with the problem, is a Windows service running on a Windows Server 2012 R2 machine. It uses the StompClient compiled with the default options - i.e. the Indy socket. The application was compiled using Delphi XE5.
I have tried compiling it with the latest Delphi 10 Seattle, with no difference. I've also tried disabling the Nagle algorithm in the Indy socket (wasn't really expecting this to help in the client socket, and it didn't).
Recompiling the StompClient with the use Synapse conditional resolves the delay. However, with the Synapse socket, unicode characters do not get through.
There are several components in the overall system that could be responsible for the delay, however that fact that it goes away when recompiling with the Synapse socket pretty much identifies it as a problem with the Indy client socket.
The application has now been running for two weeks without any message delays, using Synapse. For the time being we're getting round this by using UTF-8, but it would be great to have this problem resolved with Indy sockets, or perhaps the native Delphi client socket, and to have a robust unicode StompClient.
I don't suppose this is really a problem with your StompClient, but I thought you should know about it as it affects its use.
Jon
Jon Stewart
The text was updated successfully, but these errors were encountered: