Upload fails and Actinic hangs

[Mike Hughes]

Nick,

Can we try and eliminate the server from this?

I have an unused domain that you could try loading a dummy site onto. Let me know if you're up to it and I'll mail you the network settings.

Mike

[Redspan]

This is easily the most annoying and frustrating problem with this software. My site is growing in size every week, and needs frequent changes to optimise the design, layout, and pricing.

I only have to change a single letter somewhere in some text and the pre-upload checking of the site files alone takes 4-5 minutes. Now, I would happily live with that if at the end of it I was certain that the upload with go through without a hitch and, ping!, it completed.

But oh no. Time after time it's a case of hung software, close it down, reload it, and start again. I need to be able to make quick changes several times a day, but it's just not possible.

I understand that it may be due to the range of different hosting servers and that there may not be a solution that can be applied to the software, but so what? I need to upload.

:-(

[Mike Hughes]

Here's the thing. There's clearly a problem somewhere, but Actinic don't know where it is or what's causing it. If they knew then they'd fix it.

As it only seems to appear on certain PCs (or ISPs or Servers ?) then it's hard for them to replicate, identify the problem and fix it.

I have twice offered an unused domain on a server that is known to work to see if we can eliminate (or identify) the server as the problem. Unless those that have the problem are prepared to help identify it, then I think you're just going to have to live with it.

Mike

[Redspan]

Mike,

That's all every well, but there's only 24 hours in a day. I don't have the time to troubleshoot problems on software that I have spend hundreds of pounds purchasing.

Am I an unpaid tester of a beta version or am I customer that needs some support?

Regards,
Ben

[Mike Hughes]

Obviously you're a customer that needs some support, but if actinic can't replicate the problem then they can't fix it. When you reach a stalemate you can either try and find an alternative solution or stick to your guns at the stalemate.

I agree about the 24 hours in day . But if the problem takes up a lot of your time then it reminds me of the old adage of the woodcutter who doesn't have time to sharpen his saw because he's too busy trying to cut down trees with his blunt saw.

I'm not really trying to have a pop at you but for anyone with developer (or a spare license) it'll only take 10 minutes to license a new site and upload it to my url. (assuming of course that the upload works).

Mike

[Redspan]

I have neither Developer nor a spare license, just Business.

If there's a way of replicating it using a snapshot of my site then I'd be happy to send a copy to someone in Actinic.

Regards,
Ben

[Mike Hughes]

I forgot to say that if anyone who has this problem would like to try loading a test site onto my server then I have a spare Actinic 25 license key they could 'borrow' for the test.

Mike

[pinbrook_nick]

I think all that users should be responsible for, is flagging bugs not fixing them. The fact of the matter is that most of the good FTP programs out there work perfectly well with a wide variety of servers, PC's, and ISPs. I doubt many of the people developing these FTP programs used their users to get that kind of reliablity.

Development collaboration with users should be limited more to feature development, not bug fixing. A properly funded development departement should have access to a range of PC's, ISP's, and servers.

FTP isn't exactly a vastly complex or new protocol - it's probably been around at least 10 if not 20 years. It shouldn't take much to get a good inbuilt FTP system going. There are probably FTP SDKs out there for grabs, complete with ready developed communications libraries for auto negotiating server type etc. It just takes the right amount of prioritisation to get it written.

I use a program that can monitor upload and download throughput on a program-by-program basis. Actinic compared to FTP programs uses a miniscule amount of the available bandwidth, and most of the time is sitting around doing nothing while 'setting file permissions'.

[Mike Hughes]

I don't disagree with you about responsibilities Nick, but this is a community forum where we try to help each other out.

Actinic have already stated their plans in this area. If you don't have any interest in trying to identify the problem and possibly a workaround then that's fine by me. I don't have this problem.

Mike

[cbarling]

Hi,

I've just been talking to the developer who is working on this problem. From that discussion and some policy decisions that we have taken I can tell you:

- The Actinic desktop to server communications will be over-hauled and the revised capabilities will be made available in both v6 and v7

- This is a top priority for us, but it does involve an extensive re-write of the communications. It will be ready in weeks not months

- We haven't changed this part of the product for a few years. At the time it was written, some quirky things were done to get around MS issues and restrictions of the time. These have largely gone away so some of our technology in this area is not appropriate - hence the decision to re-write

- the fact that more problems seem to have flared up in this area recently suggests that MS have changed something. However, while this is probably the case we're not trying to hide behind it, and we would want and accept that Actinic upload performance should match other FTP clients

- We expect to introduce improvements in timeout settings, error logging and resuming at the same time as we change some of the underlying methodology

Just as background, I would say that the Actinic upload "works" when everything is going OK. What it is poor at is recovering if anything goes wrong. Other FTP clients recover much better, so the user is not even aware that connections have been dropped etc.

I hope that this clarifies things. If there are any questions on this post, I apologise that I won't be able to answer them until Tuesday, as I'm unavailable until then.

Reagrds,
Chris barling
CEO, Actinic

[pinbrook_nick]

Excellent!

[ChrisL]

Actinic upload timeout

This was also happening to me -both with Actinic and with a standard FTP program.

The eventual solution was to change the MTU setting within the registry.

See the following, but back up your registry first if you decide to try this!

http://www.winguides.com/registry/display.php/280/

Your machine will need restarting for the changes to take effect.

[Mike Hughes]

I think we may have cracked this one. I'm pretty sure we've solved the problem for Jo and Nick at pinbrook, now we just need to see if the same fix works for others.

With Jo's help and some investigation over the weekend, I've tracked the problem down to a RAQ servers ftp help file that occasionally causes problems with the Windows IP/FTP stack.

Essentially, when using a windows FTP stack the ftp help file garbles the normal FTP status replies sometimes causing everything to lock up and give a timeout.

Potential solutions are fairly straightforward.

1. Don't use the admin username and password as apparently the ftp help file is only output during admin login. (I haven't confirmed this so the following option may be safer).

2. Delete (or rename) the .ftphelp file. You might also need to make sure it doesn't get re-generated.

As far as I know this problem is restricted to RAQ servers and might not be seen with Windows XP pro that has the new IP stack.

I'll drop a note to actinic with some more details. If the fix works for others with this problem then maybe this is the last we'll hear of it.

Mike

[pinbrook_nick]

As far as I know this problem is restricted to RAQ servers and might not be seen with Windows XP pro that has the new IP stack.

Just to let you know Mike, all the computers we have been using that have been getting the problem are Windows XP Pro, but they are fully patched up including hotfix 831167.

But the fix seems to have work very nicely on our first initial test, so here is instructions for any Cobalt RAQ hosts out there:


SSH Telnet in, and do the following:

cd /home/sites
find . -name .ftphelp -exec rm -v -r -f {} \;

cd /etc/skel
mv .ftphelp disabled.ftphelp

[Redspan]

Nick,

You may be right. Unfortunately, when I submitted this fix to my hosting company, this was the response:

"Hi,

Unfortunately this does not seem to be the root of the problem in your case. We do not run RAQs for shared hosting and so the fix suggested here does not apply. However I will investigate more to see if there is anything related we can do, as we are running Proftpd as the FTP server and I believe most RAQs do the same. Kind Regards, Daniel Virtual Internet Support"

Regards,
Ben