Many folks have constraints in their data centers, frequently relating to which incoming and outgoing ports they can open up. Many times, they are restricted to only using well known ports, like HTTP (80) and HTTPS (433). When using the Windows Azure Service Bus and just using the defaults, you get some unexpected behavior. The Service Bus will still use TCP ports to do some of the back channel conversations such as keep-alive type polling that occurs to redirect requests from the Service Bus to your instance of the hosted service. To fix this up, you need to do one simple thing: tell the ServiceBusEnvironment to only use HTTP. In your application startup code, add this line so that Service Bus only speaks over ports 80/433:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
If you are on IIS, this code would go in the Application_Start override of global.asax.cs. If you are self-hosted, this goes into your main() method as one of your first lines of code.
If you want to troubleshoot and see if this is indeed the cause of your issues in your data center, look at the ports your application is opening up. Ports in the 7390-7395 range are coming from Service Bus. You’ll be able to detect this through your network monitoring infrastructure or tools like WireShark. Make the change I suggest, then check again. Your port issues should be resolved.
#1 by tschaena on September 10, 2012 - 12:11 am
In our corporate network changing the ConnectivityMode to Http and having all the proxy settings correct is unfortunately not enough to get ServiceBus running. Our web proxy server seems to be incompatible with ServiceBus SDK 1.7 (either HTTP post or get chunking seems to be unsupported). The same incompatibly is noticed when running Fiddler in an open network: Even with Fiddler’s web proxy implementation, ServiceBus is not working.
According to the answer provided by Todd Reifsteck (http://stackoverflow.com/a/12293113/1415575) I assume our issues are based on the fact that SDK 1.7 is not yet capable to work with our proxy scenario (which I would guess is a typical real world scenario!). I’m looking forward to SDK 1.8 and hope that it is released soon since this proxy incompatibility is a real road-blocker for us.