|
Adding more threads to upload while transferring, i get these errors while setting properties or connecting: Stack Traces: Rebex.Net.FtpException: Another operation is pending. at Rebex.Net.Ftp.clXkcGZ() at Rebex.Net.Ftp.bNVhrT() at Rebex.Net.Ftp.set_UploadBufferLength(Int32 value) Rebex.Net.FtpException: Another operation is pending. at Rebex.Net.Ftp.clXkcGZ() at Rebex.Net.Ftp.bNVhrT() at Rebex.Net.Ftp.set_Timeout(Int32 value) Rebex.Net.FtpException: Another operation is pending. at Rebex.Net.Ftp.clXkcGZ() at Rebex.Net.Ftp.bNVhrT() at Rebex.Net.Ftp.set_AbortTimeout(Int32 value) Rebex.Net.FtpException: Another operation is pending. at Rebex.Net.Ftp.clXkcGZ() at Rebex.Net.Ftp.bNVhrT() at Rebex.Net.Ftp.Connect(String serverName, Int32 serverPort, TlsParameters parameters, FtpSecurity security) the properties are set with these values: ftp.UploadBufferLength = 64000; ftp.Timeout = 120000; ftp.AbortTimeout = 1200000; even if I don't set those properties, it throws the exception when connecting. PS: The problem doesn't happen if I add a thread to upload while it isn't transferring yet. |
|
This exception is thrown if you call a method or property of the Ftp object multiple times at the same time from several different threads. The Ftp object represents a single FTP session (or connection) that doesn't support multiple concurrent operations. It's perfectly OK to use multiple threads to perform multiple simultaneous operations, but you have to use several instances of the Ftp object to make this possible. Using one Ftp instance per thread is the easiest way to achieve this (another is using a pool of Ftp objects, but this is more complicated and probably not needed in this case). It's not entirely clear what is going on from your code snippet. I tried extending it to form the simplest possible console application I could use to reproduce the problem you describe, and this is what I ended up with:
When I run this, it works fine and "Another operation is pending" error doesn't occur. We are unable to reproduce the issue you describe. To make sure you are in fact using multiple instances of Ftp object, please add the following line right below the
This will create a communication log where different instances of Ftp object are clearly distinguishable. We know people have been using multiple Ftp objects from multiple threads for years without any problems, so unless there is a bug in your code, it is something very hard to reproduce. Posting a code that triggers the error (or modifying the test code above) would really help. For a sample code that uses multiple threads to upload a list of files, check out the FtpsMultiUploader project. It doesn't raise "Another operation is pending" either, or at least no one reported that yet. Another update: In this case, it would be very useful to include thread ID in the log, but FileLogWriter doesn't currently support this. Let's write a FileLogWriter2 class that extends it to add a thread ID:
Now use this instead of FileLogWriter to produce a more readable log. I'm using several instances of the Ftp object. Look at my code: http://pastebin.com/pjyHQpvQ when creating a new thread I always pass null to create a new Ftp instance. I only pass the Ftp object to LoadFtp if I want to reconnect.
(20 Jul '10, 14:09)
user-181 (go...
Thanks! I am still unable to reproduce the issue - please see my updated answer for more information.
(20 Jul '10, 16:14)
Lukas Pokorny ♦♦
Looks like its generating the threads fine. Here is the log of me adding a first thread and after starts uploading I add a second thread: http://pastebin.com/ggteJ49t
(20 Jul '10, 20:11)
user-181 (go...
It looks like the first thread created an Ftp object (identified as Transfer(1)) and did its work without problems. The second thread created a new Ftp object (Transfer(2)) and did what it was supposed to do as well, but after it started closing the connection, an error occured - it looks like another thread tried using the same Ftp object to do something else. Perhaps you called the Disconnect method but then started re-using the object before it finished?
(21 Jul '10, 09:26)
Lukas Pokorny ♦♦
The log might be even more informative if it includeed thread IDs. The built-in FileLogWriter doesn't support this feature, but it's simple to extend it to add that. I updated my answer again to include a FileLogWriter2 class that can be used instead of FileLogWriter to produce a log that includes the trhead ID as well.
(21 Jul '10, 09:30)
Lukas Pokorny ♦♦
|
|
I fixed. Thanks, I used a threadpool and fixed the issue... Thanks very much for helping me out Thanks for letting us know, I'm glad you fixed it!
(22 Jul '10, 12:27)
Lukas Pokorny ♦♦
|