none
Service bus relay timeout when executing a long operation: 50400: Gateway Timeout. RRS feed

  • Question

  • We are using the service bus relay to connect our shiny new web application with our customer's on premise installations of our legacy product. Some of the calls might take a long time to complete (calculations lasting a couple of minutes) however these long operations give the following exception:

    Type: System.ServiceModel.FaultException, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
    Message: 50400: Gateway Timeout.TrackingId:2fd3b03a-7562-4aa3-9ed6-e685cdc1cd99_G10,TimeStamp:8/7/2014 1:40:35 PM

    Call stack (upto the first line of our own code):

    System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
    System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
    System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
    System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
    Vbi.Erbis.Relay.Interfaces.IErbisRelay.ExecuteMethod(String userName, String password, String className, String operationName, Object[]& parameters)

    Other info:

    To be sure it was the service bus relay giving us problems we have set WCF binding timeouts to 1 hour (Send, Receive, Open, Close). We are using the BasicHttpRelayBinding (and won't be able to use the NetTcpRelayBinding due to firewall restrictions at some of our clients).

    How can I set this timeout to a higher value?

    Thursday, August 7, 2014 2:53 PM

All replies

  • I guess I have stumbled upon something never seen before. Which is quite unusual since the Service Bus relay has been around for a couple of years now. Also I now see my question might be formulated a bit strangly bit what I wanted to know is:

    How to avoid the gateway timeout but still allow long running operations on the BasicHttpRelayBinding?

    Also, I am assuming that this error is thrown by the Service Bus itself. But might it be possible its a problem in our own proxy/firewall? Is there a way for me to determine if it is?

    Thursday, August 14, 2014 6:24 AM
  • Did you find an answer to this problem?
    Friday, September 11, 2015 10:26 AM
  • Well, I didn't really have an answer to this problem, however I implemented a work around.

    First of all, it was not an issue in our own proxy or firewall. The error is really thrown by the service bus gateway. This gateway is probably responsible for routing many many connections and I can imagine it would be a very tough task to have a way to determine the timeouts for each connection separately. So I figured that this 'problem' is by design. Of course I would have loved an official MS answer about that, but alas.

    With that self deduced bit of knowledge I went to work on a work around. A work around that will not be applicable for most situations, but I'll try to explain it here anyway, maybe you are lucky.

    As I said in my original post, we were connecting with a legacy product via the service bus relay. However since this legacy product only speaks COM we had to create a this .NET layer in between that translates the WCF service calls to COM and vice versa. We were able to change this layer to keep track of the COM calls that were running (and that did not yet return) with the parameters the WCF service was called with.

    This means that when this error occurs (and only this error) on the client side, we catch it and retry the WCF call again. On the server side (the side with our legacy product) we get the call, check if that same call was already registered with a running COM call. Then wait until the COM call finishes or a new Gateway timeout is thrown.

    The nice thing about this solution is, I can just specify a retry count on the client side to get a longer virtual timeout. Be careful with this approach if you send a lot of data as parameters of your service call, because then this will be transmitted multiple times (and also stored in memory on the server). But you can find creative ways around that I can imagine.

    Hope this helps! But I can imagine it won't :-(

    Monday, September 14, 2015 6:48 AM