Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I'm trying to adjust our project for Windows Azure , and I found a big issue, that can put it in jeopardy.
Windows Azure load balancer kills any idle connections that wait for one minute for service to response.
Sinc dataportalproxy sends requests, and gracely waits for response, and when dataportal receives request and doesn't talk to proxy while waiting for operation to be completed - load balancer kicks in, and closes connection, since nobody's talking for a long time:)
It becomes an issue especially when we are doing some time consumming operations, but possibly can be a problem even with some reporting queries.
We are currently using Csla 3.8, so I don't know if version 4 solves this problem or if it was addressed by Rocky.
Here : http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9
I found solution, but since I have only basic knowledge of WCF I would probably use some advice from some more experienced developers :)
Can anyone help me ?
This is just my opinion, but any operation that takes longer than a few seconds will annoy the user. I try very hard to keep my calls to at most a few seconds. If you have a long running process, you should just leave a marker in database or a message in Azure service bus and have a worker process that picks up on that signal and performs time consuming work. My 2 cents.
Thanks for your opinion.
We are considering this possibility, but there are a few things that are bugging us:
1. Our solution works seamlessly with localproxy and iis hosted wcf . there is almost no additional code. Adding Workers would add some extra effort on server and client side, and we opt to avoid that.
2. Those time consuming operations are for instance : creating database, converting data from other systems - we are using scenario in wchich we call Command that executes some sub operations and provides information about work progress, wchich is read by client application and displayed for user, so there is no problem for user to wait for work to be finished.
3. If we move our functionality to some worker we loose ApplicationContext.ClientContext informations, wchich are used for transfering important informations.
Those are all valid reasons. I think you can continue on your path then. What I was trying to convey is that there is a reason why Azure behaves the way it does. They are trying to conserve valuable resources on the cloud. As a result, they encourage everyone to follow a different pattern of creating apps for the cloud. Hense, I would also encourage everyone, not just you specifically, to adapt those patterns. Again, the decision is ultimately yours, and I am just expressing my opinion on the subject matter.