Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to receive message: AccountSettings #38

Open
SlavaC1 opened this issue Sep 29, 2024 · 2 comments
Open

Unable to receive message: AccountSettings #38

SlavaC1 opened this issue Sep 29, 2024 · 2 comments

Comments

@SlavaC1
Copy link

SlavaC1 commented Sep 29, 2024

We are using Miracle API to communicate with FileZilla server on Windows Server 2019. We see that occasionally we get Unable to receive message: AccountSettings exception. We see that it's from ReceiveMessage() method. What could be the reason?

@PolarbearDK
Copy link
Owner

PolarbearDK commented Oct 1, 2024

You do not write what operation you are performing when you get this error. I assume it is GetAccountSettings(), Right?

The protocol basically works this way:

Send "Give me A"
Loop: Read message 
  If Message is "A" return it 
Try again  

FileZilla sometimes sends some status messages that you have not asked for, so we retry to skip those, but only 10 time per default. If FileZilla has more than 10 messages pending then you will never get to "A" and you get the exception.

Are you keeping the FileZilla connection open for a long time? You should not do that. Instead connect, do your stuff and close connection.

If issue is not resolved, then you can try increasing fileZillaApi.ReceiveMessageRetryCount to a value greater than 10.

@SlavaC1
Copy link
Author

SlavaC1 commented Oct 6, 2024

We are calling SetAccountSettings() and GetAccountSettings(). Each of them throws this exception.

We noticed when giving our own TextWriter to the API and writing to logs, the problem disappears. I'm guessing that the writing to log adds a certain delay by writing the dumps Hex.Dump(Log, bytes, 1024); in LogData() in SocketCommunication class.

Also we noticed that sometimes we receive ~300 or ~400 messages, so I'm not sure that increasing retry to this amount is a good idea.

What do you think about adding a delay (sleep) in between the retries? Could it simulate the delay caused by hex dump and solve the problem? Any other idea would be apricated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants