Guys can someone shed some light on a DataPortal/Socket issue please.
I have a Silverlight client making calls to a .Net Server(Broker) through a DataPortal in Async calls using BeginFetch.
Within the Broker I use a ObjectFactory where in the Fetch I am using Socket connections(ConnectAsync) and Socket sends(SendAsync) and then my callbacks use Receive.
I encountered an issue as the callback for the Socket SendAsync in my Broker is calling the the callback in my Silverlight client that is awaiting a response from the Broker Server. Since, I am not exiting the Broker correctly then my return Object value is null.
Can anyone shed any light on what might be causing this? Am I allowed to used sockets calls in a middle tier server -- that has been called from a Silverlight client -- to make calls to an old application server that uses sockets?
Do you have appropriate blocking code to make sure the primary request thread doesn't complete until those async calls finish?
Async coding on the server is different from the client, because the server is stateless. When the primary request thread completes, that's it - end of story on the server. Any outstanding async operations may complete, but their results will be ignored, because the call already completed.
So you need to make sure to use thread sync primitives to ensure that the primary thread is blocked until the async tasks finish, thus ensuring that the primary thread doesn't complete before all server activity is finished.
That did the trick. I was waiting in a loop with calls to sleep, but I did not realize I had an error and was throwing an exception in my logic.
This caused the Fetch function to exit and my callback on the client to be called. I added code in the client codeback to handle errors as well as
I fixed the error and will also change to use better synchronization.
If I am going to process a long process from a dataportal fetch and go into synchronization awaiting a result from the socket callback,
Is there a way to allow other silverlight clients to make calls into this Broker Service?
Your book indicates that back end processing should not be interactive. Does this indicate a server using a data portal for entry
can only process one message at a time because until the fetch returns it will block other messages from coming into the dataportal based
server?
Can CSLA support and interactive backend?
Each client request will get its own request thread on the server, that's the way ASP.NET works (and if you are using WCF or Remoting or asmx hosted in IIS, you are using ASP.NET).
So that primary request thread we're talking about - that's unique to a specific client request, and there can be many simultaneous client requests.
There's a limit of course. Long-running operations on the server are fine, but can radically reduce scalability, which just means you might need more servers in a load-balanced web farm. At this point we're just talking about normal ASP.NET behaviors and the realities of server-side coding, so there are tons and tons of books and other materials that cover this sort of thing.
But with a modern server, even with lots of long-running server operations you should be able to handle many clients at the same time.
Generally the .NET thread pool has 25 threads per CPU core. These request threads come from the pool, and your background threads probably do too, so that should give you some idea how many threads you'll be consuming. This post might also be helpful:
http://www.lhotka.net/Article.aspx?area=10&id=1049435b-6b05-412a-8bad-62869b1f1074
Copyright (c) Marimer LLC