Are RW closing FTP closing multiple connections after uploading?

It seems that RW is not closing multiple connections after opening a new one to upload the next file. My server is blocking me from uploading until those idles connection is dropped because RW is creating too many idle connections.

2 Likes

I have seen similar. I test export to a local machine via sftp and the connections are not closed until I exit RW. I discovered this when the destination machine ran out of process slots after exporting multiple times.

2 Likes

This might be something for @dan to look into…

You are correct about killing RW will close off all idle connections made by it. I just test on this.

There seems to be a bug where RW is keeping connection idling after it complete publishing and if you don’t quit RW completely then it will try to start a new 6 connections on the next publishing event which will get blocked on most ftp site because of the maximum of 6 to 8 connection restriction when RW already had 6 connections idling and trying to start another new 6 connection on top of it.

For now, to get around this is to completely restart RW after each publish.

This is reproducible and I am pretty sure it a bug. A very annoying one too.

Most server set maximum connection for ftp at 8.

RW is idling 6 connections after each publishing and not using the same connection for next publishing instead if try to open up another 6 connections to ftp server which get blocked because it over the maximum connection allowed.

Only way to get around it to save the project and completely kill RW then start it up again before you attempt publishing for the second time and if you forget to kill it first then you get a annoying “cannot connect to ftp message” which is a pain trying to cancel that publishing and cancel the backup to shut it down so you could restart RW again.

Please look into this … very annoying … look like it was introduced two RW update ago.

1 Like

8.1.7 introduced openSSL. Cannot confirm now but reasonable sure that after that two things occurred on my test server (the one near the aquarium) using sftp.

  1. It went from a near instant connection to taking nearly 20 seconds to connect (sftp clients still make instant connections)

  2. It failed to close the connections and ended up using all the available process slots on the test server. Connections closed on applicaiton exit.

EDIT: I have just confirmed this. It was definitely 8.1.7 that the issues started to occur.

1 Like

Did some more testing. Looks like 8.1.7 was closing the connections so it must be a later version that started to show this. The current version is leaving connections open. I’ll leave it to other to sort out. I have to feed the Spaniels.

1 Like

Thank you for confirming and narrowing it down.

Hopefully, we see a fix soon …

Since it’s freezing here and blowing a gale on an otherwise fine autumn morning I tested each version from 8.1.6 to the current. Unfortunately (or may be fortunately) I could not reproduce the problem. I do note, however, that my publishing set up is set to 6 (Lightning fast) SFTP. In 8.1.6 it connected instantly and opened all 6 connections. From 8.1.7 it takes 20 seconds to connect and only opens 1 connection.

However I think may have located the issue. The tests above were using a later version of openssl on a different machine than I usually use for a web server. It worked fine. The test web server is running an earlier version and on that version the connections are not closed until RW exits. So I think it all depends on what is running in the host’s environment. Which would also explain why some see this issue and others do not.

1 Like

I know for sure if your host uses cpanel, you are going to see this issue …

I’ve run into the same problem with RW 8.6.2 on cPanel (v84.0.22).

In cPanel>Resource Usage you can see the NPROC (number of processes within LVE) increasing on each successive connection and not resetting between connections. Eventually I can no longer connect via SSH/SFTP. If I quit RW before this point the NPROC returns to 0.

I’ve sent logs etc to Realmac.

1 Like

Well, the reply from Realmac has been to suggest this is a problem with my hosting and not RapidWeaver:

“In some cases, hosts simply do not like multiple/concurrent connections to their servers from FTP programs or RapidWeaver.”

They then go on to suggest I might might want to look for another host “that supports multiple connections”, and name a couple of companies to look at.

Thank you. My clients use either 1&1 Ionos or Strato. I think these are the largest hosters and both show this lag. After a time transmitting, more connections are opened, but it takes a long time for the initial connection to be established. I think it might be hard to tell these hosters to switch/update so I hope Realmac will be able to improve this on their end, if possible…

I think @Aaron is on this and he did ask for log files.

3 Likes

Jan, just replied to your email - can you resend your logs? The attachment didn’t come through. We’ll get this resolved for you as quickly as possible!

Hi,

This is correct, some hosts simply do not play well with multiple connections. Each host has a different setup/preference and the key is to find the settings in RW that work best. You mentioned less connections results in a successful publish, but it does take longer - this was where my suggestion to possibly move hosts came in.