none
Timeout on FindItems RRS feed

  • Question

  • This is my first post to this forum so first and foremost: HI !

    I am using the managed c# api and so far so good.

    The account is on Office365 and has less than 50 emails in the inbox.

    Usually when I run a FindItems call followed by a loaditems, everything returns very quickly with no issues.

    I tried to put it in an endless loop where the calls are issued, sleeps for 5 seconds, issues again - and so on.


                var itemView = new ItemView(100);
                itemView.PropertySet = new PropertySet(BasePropertySet.FirstClassProperties);
                itemView.PropertySet.RequestedBodyType=BodyType.Text;
                itemView.PropertySet.MaximumBodySize=256;

                var foundItems = service.FindItems(WellKnownFolderName.Inbox , itemView);
                service.LoadPropertiesForItems(foundItems, itemView.PropertySet); 

    When I have tracing turned on, within a short period of time (after less than 10 cycles) the call would hang and depending on my TimeOut settings, an exception would be thrown.

    If I do not set a timeout, which defaults to 100seconds, it will indeed wait that long and an XML error would be thrown. From looking at it closely it seems that the XmlReader chokes on an unexpected EOF where a ">" was expected, which to me indicates that the server closed the socket while the client side tried to read from it. The exception thrown is not a timeout exception rather an xml exception. 

    If I set the timeout to 100mls, it always fails with timeout exceptions.

    If I set the timeout to 10-20seconds, most of the calls return fine, occasionally one would timeout.

    So I wanted to make sure that all of the above is within the realm of expected behavior.

    In particular: is there a way to know programmatically if the client is about to exceed the throttling quota and prepare for it accordingly.

    I do not intend to use such a call-cycle in an actual application, and at the very least use a time stamp to make sure I am not pulling the same messages over and over - that was just a test case that got my a intrigued (well - concerned a bit)

    Thanks.

     Erez 

    Tuesday, December 2, 2014 1:57 PM

All replies

  • >>If I do not set a timeout, which defaults to 100seconds, it will indeed wait that long and an XML error would be thrown. From looking at it closely it seems that the XmlReader chokes on an unexpected EOF where a ">" was expected, which to me indicates that the server closed the socket while the client side tried to read from it. The exception thrown is not a timeout exception rather an xml exception. 

    If your not getting returned the property XML response that's generally caused by something in your network path eg Proxy and\or Firewall that munging the request

    >>In particular: is there a way to know programmatically if the client is about to exceed the throttling quota and prepare for it accordingly.

    No the current throttle budget is reported in EWSLog on the CAS server but it's not reported back to the client directly. A Exchange 2013 onprem development environment may help in this regard as you can make request and then see from the Logs better the potential impact. 

    >> If I set the timeout to 100mls, it always fails with timeout exceptions.

    100 mls ? do you mean 100 milliseconds or 1/10 second I would expect that would timeout

    Throttling is biased towards what a normal user could reasonable do once you start doing things like you described which a user would never do then your going start to trip the throttling algorithm so it not particular a valid test unless your goal is to be throttled eg your application description would match a rouge application or a DOS attack because your continually requesting the same items over and over a good throttling algorithm would catch this. A better test would be to page through a large number of Items in a folder (something an email client may validly do) and see if you get the same result.

    Cheers
    Glen

    Wednesday, December 3, 2014 5:04 AM