FlashFXP Forums - View Single Post

Yil · 05-15-2010, 12:22 AM

stefano: Interesting logfile... let me see if I can explain what you are seeing...

1) Clients attempts 10 connections to server at the same time.

2) The first 5 are accepted and the other 5 are rejected. This is most likely because of the 'Connections_To_Ban' setting under [Network], the default in the .ini file is 6. Do you see auto-banned messages in the logs\Error.log file? Please note that once any of the 5 accepted connections actually supplies a valid user/password and is logged in the host will be removed from being auto-banned and the count will be reset to 1. This is why the original 5 rejected can login the 2nd time they try. I presume you had 1 connection from the machine already open which is why 5 were accepted instead of 6 the first time. If you want to make 10 connections at a time set the limit to 11 or something...

3) I see the 2 failed STOR commands but the error text says it completed successfully and the error code is 0. That's odd so I went looking for how that was possible. I fixed a couple of unrelated bugs, and then yours. The server failed to mark the directory as dirty after creating the file and relied upon the directory timestamp to catch the change. That may or may not be a problem but what was definitely an issue was a race condition on reading the changed directory. The first thread to create a file and then change the permissions on the file would update the cache. All the other threads doing the same thing would be blocked waiting for the update and they assumed it would be up-to-date when finished so there was no need for them to update it again. In this case that's not true so sometimes the change would get missed and when the server can't find the file it just created to modify the permissions it bails, but fails to set an error code. This will be fixed in the next release which shouldn't be too far off.

As a side note, to reproduce this bug I had to get a client to make 10 connections at once and found a couple of other issues I fixed.

I suggest not using mass connections for uploading until the next release. Just use 2 or 3 for now.

05-15-2010, 12:22 AM
Yil Too much time... Join Date: May 2005 Posts: 1,194	stefano: Interesting logfile... let me see if I can explain what you are seeing... 1) Clients attempts 10 connections to server at the same time. 2) The first 5 are accepted and the other 5 are rejected. This is most likely because of the 'Connections_To_Ban' setting under [Network], the default in the .ini file is 6. Do you see auto-banned messages in the logs\Error.log file? Please note that once any of the 5 accepted connections actually supplies a valid user/password and is logged in the host will be removed from being auto-banned and the count will be reset to 1. This is why the original 5 rejected can login the 2nd time they try. I presume you had 1 connection from the machine already open which is why 5 were accepted instead of 6 the first time. If you want to make 10 connections at a time set the limit to 11 or something... 3) I see the 2 failed STOR commands but the error text says it completed successfully and the error code is 0. That's odd so I went looking for how that was possible. I fixed a couple of unrelated bugs, and then yours. The server failed to mark the directory as dirty after creating the file and relied upon the directory timestamp to catch the change. That may or may not be a problem but what was definitely an issue was a race condition on reading the changed directory. The first thread to create a file and then change the permissions on the file would update the cache. All the other threads doing the same thing would be blocked waiting for the update and they assumed it would be up-to-date when finished so there was no need for them to update it again. In this case that's not true so sometimes the change would get missed and when the server can't find the file it just created to modify the permissions it bails, but fails to set an error code. This will be fixed in the next release which shouldn't be too far off. As a side note, to reproduce this bug I had to get a client to make 10 connections at once and found a couple of other issues I fixed. I suggest not using mass connections for uploading until the next release. Just use 2 or 3 for now.