Provide option to start the transfer controller with Windows

Nov 20, 2008 at 9:20 PM

We have notice a trend that the transfer controller is slow to initilize and respond on the first email. We have moved the transfer controller to start with Windows and it would be nice if you could do the same for future upgrades.

The initialization process takes almost a minute and this is too slow but when it loads as a service the first email message is quick and responsive
Nov 21, 2008 at 12:53 PM

When we have discussed the architecture with prospective customers they have made clear that although they wanted transfers to execute separately from Outlook to free Outlook as soon as possible, they did not want any resident process (windows service or process started with windows). So apparently not everyone agrees with you on this. To make everyone happy we will provide a checkbox in the Options dialog that offers to start the controller with Windows when it is checked, provided this work item gets a few votes.

Nevertheless, I am very surprised that the controller takes so long to initialize. Initializing consists in:
  1. Starting the process;
  2. Launching the .NET virtual machine;
  3. Compiling the code against the .NET virtual machine;
  4. Initializing .NET remoting to listen on port 48888 (hard coded in the current build, dynamically allocated in the next build).
This takes 2 to 5 seconds to complete on my laptop (DELL Precision M65 with 2.4 GHz Intel Centrino Duo processor) depending on the workload at the time the controller is launched. Note that the VSTO add-in pings port 48888 after starting the transfer controller process and displays an error message if the ping does not respond within a timeout which is currently set to 10 seconds.

There is probably something else...
Nov 21, 2008 at 12:55 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.