RealtimePHP Timeout uploading to realtime.txt Problems.

[M1DUL]

Hello All,

I am having problems with the realtime.txt PHP uploads failing.

There have been no errors for a complete month from, 17th January to 17th February. Everything has worked perfectly between these dates, which is very curious !!

This all started on 17th February 2025

This is an error message to give a small example.

2025-03-03 06:11:37 - Realtime[16]: Warning, a previous cycle is still processing local files. Skipping this interval.
2025-03-03 05:55:07 - Realtime[239]: Warning, a previous cycle is still processing local files. Skipping this interval.
2025-03-03 04:56:37 - Realtime[122]: Warning, a previous cycle is still processing local files. Skipping this interval.
2025-03-03 04:54:56 - RealtimePHP[117]]: Timeout uploading to realtime.txt

Could this be a DNS problem? Because I have a Broadband Quality graph and there are no red dropped packets etc. So it cannot be a Broadband Internet provider problem?

I have also contacted Krystal Hosting company, they cannot find any problems from their perspective.

I hope you can help me with this problem.
Prior to this date, everything was working perfectly.

I have attached the MXdiags logs & Hosting support for your interest.

MXdiags.zip

Krystal Hosting Support messages.zip

Many Thanks for any help or information.

Kindest regards
Michael

[mcrossley]

Please switch on Debug logging in the Program Settings. The post the latest log file after a couple of more failures. I'm doubtful though that it will show anything other than the server is not responding.

[M1DUL]

Please switch on Debug logging in the Program Settings. The post the latest log file after a couple of more failures. I'm doubtful though that it will show anything other than the server is not responding.

Hello Mark,

Thank you for replying to my message.

I have enabled Debug. I will post the latest log file after a couple failures.

Here is one dated 18/02/2025 with Debug enabled.

20250218-132335.txt

Many Thanks for any help or information.

Kindest regards
Michael

[Mapantz]

I get quite a few of those messages over 24 hours, but no timeout ones.

I think it's fairly normal for me, as my realtime upload is at 3 seconds.

Screenshot_20250303_212247_Chrome.jpg

[cliftonweather]

My realtime is set to 5 seconds and I get them as well, they seem to go in phases sometimes none for days and then days with loads of them, I was concerned at first but now generally ignore them.

[M1DUL]

Hello Mark, good morning to you,

Here is the latest MXdiags with the Debug enabled, which you requested

As a matter of interest, I have brought this failing to the attention of Krystal Hosting support. They have stated that it is nothing to do with them and that I should contact you, passing the buck??

20250303-182138.zip

The errors are between 03:38 to about 07:38

Many Thanks for any help or information.

Kindest regards
Michael

[mcrossley]

Your normal real time uploads take around 0.1 seconds.

When it gets to upload cycle 88 at 03:38, the first upload is realtime.txt

Code: Select all

03:38:14.3 - Uploading to realtime.txt
03:38:29.3 - Timeout uploading to realtime.txt

Which is the 15 seconds I have defined to wait for a response

Code: Select all

03:38:29.3 - Retrying upload to realtime.txt
03:38:44.3 - Realtime[89]: Start cycle - and skips because cycle 88 is still in progress
03:38:46.4 - Timeout uploading to realtime.txt - again
03:38:48.4 - Sending via GET
03:38:49.4 - Upload to realtime.txt: Response code = 200: OK
then uploads realtimegauges.txt
03:38:49.4 - Realtime[88]: End cycle

All Cumulus is doing is making a HTTP request to the server, nothing special. And the server does not respond twice, then works again normally.

Now, this will happen occasionally because of a number of things:

1. MX uses the same HTTP session for real time uploads. Servers often place a limit on the either:
a. How long a session can be held open
b. How many requests you are allowed to make before the session will be closed by the server

The problem is most(?) servers do not report what these values are when the session is created. There are headers that are supposed to be sent to tell the client how many request you can send, if this information is present MX will close the session after that number and reopen it. However my experience when I first coded PHP uploads and looked the server responses the testers were getting, most hosts failed to provide the information.

In this case MX just continues to use the session until it encounters an error, then on retry it will close the current session and start a new one.

2. PHP handlers on servers are configured with a periodic "clean-up" job, this closes down PHP threads that have been running for some time they deem too long. This is to clean-up threads that may have hung. The effect of doing this is the same as 1. MX continues to try and use the session, but it times out, a retry will normally create a new session and off you go again.

3. Routine maintenace/upgrades/updates these restart the services and MX will not know until it tries to use the HTTP session again.

You could ask the hosting company if they could check their web server logs for any errors at the times you see the timeouts - or indeed if they see the HTTP request come in from your IP.

[broadstairs]

Seeing the original poster uses Krystal so thought I'd point out that I host with them as well and very very rarely see these errors and my realtime interval is 8 seconds using php uploads.

Stuart

[M1DUL]

Seeing the original poster uses Krystal so thought I'd point out that I host with them as well and very very rarely see these errors and my realtime interval is 8 seconds using php uploads.

Stuart

Hello Stuart,
Thanks for your message, that really is very interesting. Can I ask please, are you on the Ruby or Emerald package?

Thanks
Mike

[broadstairs]

Mike I am on the Amethyst package which is the bottom tier. I ended up with Krystal when they took over my previous hosting company.

Stuart

[M1DUL]

Thank you, Mark & Stuart, for your tremendous help & input.

I have contacted Krystal once again, in the hope that with both of your information they can sort out my problem at last.
I will keep you posted with the outcome.

Many Thanks to you both, once again.

[M1DUL]

Hello Everyone,

Just to give you an update, with the many errors I was receiving. I am happy to tell you the matter has been resolved.

The problem was with Krystal, the Customer Support representative, cleared all the stuck processes from my account.

This has worked perfectly.

I hope this could possibly help someone else.

All the best
Mike