Thread-safe GetModelAsync

[rayao]

This ONLY synchronizes multiple simultaneous calls to model building pipeline, WebApiConfig still could return before a long running GetModelAsync completes.
Partially resolve #304

[lewischeng-ms]

Maybe we should throw if there is no model builder? It is more meaningful than a later null-reference exception.

[rayao]

Ok, thanks.
The message I put into Resources is "IEdmModel cannot be generated since API service IModelBuilder is not registered."
Let me know better description.

[lewischeng-ms]

That sounds good:-) Thanks.

[lewischeng-ms]

So basically this PR is to make any call to GetModelAsync to wait for the first one to complete? If we need to sync with the later requests, we have to register a model factory to the underlying OData Web API rather than the model instance itself. Is my understanding correct?

[lewischeng-ms]

Are we going to do anything special for an AggregateException in the future? If not, we may consider merge the two catch-clauses.

[rayao]

If we catch AggregatedException as normal Exception, and SetException to the task, the task will wrap it again and so ends with an AggreatedException, which has an inner AggregatedException, which has the actual exceptions as its InnerExceptions.

[rayao]

So basically this PR is to make any call to GetModelAsync to wait for the first one to complete? If we need to sync with the later requests, we have to register a model factory to the underlying OData Web API rather than the model instance itself. Is my understanding correct?

Perhaps I don't get your idea clearly, since GetModelAsync works on ApiConfiguration, so calling it with any model instance will be synchronized. So, if a query needs EdmModel to complete, an await GetModelAsync will guarantee that.
The real problem is the async nature of GetModelAsync, since WebApiConfig.Register is synchronous, it can't wait Restier route to be completely established, for example:

        public static async void RegisterNorthwind(
            HttpConfiguration config, HttpServer server)
        {
            await config.MapRestierRoute<NorthwindApi>(
                "NorthwindApi", "api/Northwind",
                new RestierBatchHandler(server));
        }

RegisterNorthwind could have returned before the route is completely registered. So if the model generation is really costly, RESTier routing will likely get messed up.
You can put an await Task.Delay(5000) before the config.Map call to repro.

[lewischeng-ms]

@rayao Yeah, I understand your concern about requests coming before the route has been completely registered. But in this case, since the route has not been registered yet. The service could safely return 404 for those requests. And what I was thinking about was that you can't process any OData request without getting the model instance (parse URI or serialization/deserialization). Now the model instance is registered staticly into ODataPathRouteConstraint. If we could register a factory method to produce the model into Web API and let the factory method call await GetModelAsync(), the service could probably wait for model build completion then process the first incoming request.

[lewischeng-ms]

I've no other questions, please feel free to merge it.

[rayao]

But in this case, since the route has not been registered yet. The service could safely return 404 for those requests

@lewischeng-ms This is only true for synchronous long running GetModelAsync call (like all of our existing samples, although they return task but they're synchronous in nature). A truly async GetModelAsync call won't have the chance to registered a route before WebApiConfig pipeline ends, and that results in RESTier routing not established, no further requests could be processed.
You can add an await Task.Delay(1000) in model pipeline to see the effect.

If we could register a factory method to produce the model into Web API and let the factory method call await GetModelAsync()

Yeah I initially thought that, but since the route selection pipeline is synchronous, we can't await.
I've checked in this change and working on another PR which could possibly be the resolution.