Allow fail over incase of multiple servers. - Githubissues

EmersonElectricCo / fsf

File Scanning Framework

Apache License 2.0

285 stars 49 forks source link

Allow fail over incase of multiple servers. #35

Closed spartan782 closed 8 years ago

spartan782 commented 8 years ago

We are running multiple FSF servers and noticed that if the server selected at random is unable to handle the request that the file never makes it to another server. I modified our script to attempt a connection to a random server and only after making a successful connection sending the file. That way if a server doesn't respond we get a warning message and it continues on to the next random server. If no server is available it then raises an error. We also colorized the errors which if you want I can remove them.

jxb5151 commented 8 years ago

Hey @spartan782 thanks for this. I have not had an opportunity to test, but I believe @akniffe1 is going to take a closer look. I have a couple of comments looking at the submission:

Could you fix the python path to be virtualenv compatible?
I like the color idea, but I would like to take a more unified approach. Can we take it out of this request and perhaps make it an enhancement issue to work within the broader platform?
Could we change the function name 'test_server_connection' to something like 'initiate_submission'? We are testing the connection in the new sub, but we're also processing the files if successful so I'd like to capture that (hopefully I'm not being to finicky here :) )

Also, have you looked into balance? Just curious, I played with it for a bit but never on a large scale.

spartan782 commented 8 years ago

I have updated the script. I have not looked into balance this was just a simple hack that worked for us and figured it would be a nice default feature to at least try the other FSF servers before just failing out on a file. Also let me know if you need any other changes, we have been using it in our Lab and it seems to work with out any issues.

jxb5151 commented 8 years ago

Excellent, thank you. Agreed this will be useful. I did take a quick peek at the code and noticed the final sub still calling the old function name. Could you to a quick edit on that?

spartan782 commented 8 years ago

Woops. Good catch thanks.

jxb5151 commented 8 years ago

Thanks. Check it out @akniffe1

jxb5151 commented 8 years ago

I had some time to test this a bit. Worked great! Just some very minor nit picks from my end.

Tab indent on line 59
Newline '\n' need on warn message (line 70), so if --suppress-report is done, messages are cleanly logged to the client_dbg.log file

spartan782 commented 8 years ago

I added the newline to line 70. I didn't see any tab's on my end as line 59 was a comment? Let me know if that works.

jxb5151 commented 8 years ago

Sweet, it's a very minor thing I'm not too worried about it. Thanks so much for this contribution!

jxb5151 commented 8 years ago

Updated changelog and credited @spartan782

jxb5151 commented 8 years ago

Just FYSA @spartan782 , there was a small bug I missed. The first 'test' connection has no data and therefore fails to be interpreted by the fsf server, resulting in a superfluous error to dbg.log. The update just simply passes the success socket onward instead of opening up another connection.

spartan782 commented 8 years ago

Awesome. Makes sense.