Are the calls using the same proxy or do they both spin up their own proxy

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog2


> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Jeremy Byron
> Sent: 20 March 2008 13:30
> To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
> Subject: [ADVANCED-DOTNET] Remoting, Threading and Concurrency
>
> Hello everyone,
>
> I have been struggling with this for a few weeks now.  I have searched
> on the web high and low, purchased "advanced" remoting books, searched
> newsgroups and these discussion group's archives.  I see hints of
> explanations/solutions, but nothing that seems to work or explain what
> is going on.
>
> We are not doing anything special.  We are just trying to create some
> objects that will be remoted and accessed by WinForms clients and
> ASP.NET clients.  But we are noticing that the requests are being
> processed on the server sequentially.  So basically, the remoting
> object
> processes one call at a time, with concurrent requests blocking.
>
> I have created a test project (source is available, but I suspect
> someone will be able to answer this without needing to see the source.
> This seems like such a basic issue I'm sure someone has some insight).
> Very basic.
>
> One remoted object - two methods: LongRunningProcess() and
> ShortRunningProcess()
> Server is Console app - just sets up the remoting and remotes the one
> object (no config file, all done via code)
> Client is a WinForms application.  Single form with two buttons, one
> for
> each of the methods (and a corresponding textbox to see the results).
> Each button spawns a worker thread to make the remote call, so calls
> are
> not blocking on client-side.
> Using TCP/Binary channel/formatter.
>
> Each of the remote functions is the same, enter a tight loop for a
> specified period of time then return a string with time loop started,
> time loop ended, thread id and threadPool status of each thread.
> LongRunning just loops for 30 seconds and shortRunning loops for 3.
>
> So here's the problem.
>
> When I run the test, I click "Start Long Running" then immediately
> click
> "Start Short Running".  After 30 seconds, the LongRunning returns, then
> 3 seconds later ShortRunning returns.  Server Thread IDs are the same
> and it is a threadpool thread. (Client ThreadIDs are different
> obviously)  Obviously the calls are blocking so the remoting host can
> only process one request at a time???
>
> Now, I try putting a "Thread.Sleep(250)" in the loop of the long
> running, now when I click my two buttons, ShortRunning returns after 3
> seconds and LongRunning returns after 30 seconds and they both have
> different threadIDs and both threads are threadPool threads.
>
> I was under the impression that on the remoting server side, the
> requests were handled via the threadpool and hence did not block each
> other.  But from my results it sounds more complicated then that.  It
> would seem to be quite detrimental to throughput to have requests
> blocking each other like this.  And I would think that if it was a
> requirement for me to spawn worker threads in my remotedObject (or use
> the sleep method) that would be documented somewhere.  But I've never
> seen it anywhere.
>
> I've tried using SingleCall and Singleton for my remoted object (one
> post I read said Singleton was multi-threaded whereas Singlecall was
> not).  I've even tried changing my host to IIS (and using the remoting
> config file) with the same results.
>
> Does anyone have any insight on how to get my object to process
> requests
> concurrently?
>
> Thanks in advance.
>
> Jeremy
>
> ===================================
> This list is hosted by DevelopMentor.  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

===================================
This list is hosted by DevelopMentorĀ®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to