Sudesh,
The Request method calls privateLock, Process, and privateUnLock in
that order. One thing that jumps out at me is that you don't have the
Process method call wrapped in a try/catch/finally block. If an
unhandled exception is thrown in the Process method then the
privateUnLock method won't be called and all subsequent remoting calls
will be blocked indefinitely.
Brian
> Hello,
> We have an application which communicates using remoting. There is a server
[quoted text clipped - 61 lines]
> remoting.
> We can change it to singlecall if needed, but first we want to check the issue
Sudesh Sawant - 26 May 2005 17:01 GMT
Hi Brian,
Process is just a dummy function. The actual processing function has try
catch blocks.
My main problem is that after a certain number of remoting calls the calls
dont get through to the server. I had tied searching on the net for the
problem and found from a couple of sites that people where facing a similar
problem. We got improvements in performance when we changed the channel to
tcp, but still it doesnot suffice. The explanation given for this was that
the clr threadpool gets exhausted and cant fork more threads for more
requests. I had tried to check with my code if there are any leaks but then i
get the threadcount decreasing after the request has been completed, so there
may be no such leak. But somewhere the requests have piledup at lower level
and the pool gets exhausted
My last approach is to try singlecall.
Cheers,
Sudesh
> Sudesh,
>
[quoted text clipped - 72 lines]
> > remoting.
> > We can change it to singlecall if needed, but first we want to check the issue
Jared Parsons [MSFT] - 26 May 2005 17:48 GMT
Have you attached a debbuger to the service when the call hangs? If so how
many threads are running on the service?

Signature
Jared Parsons [MSFT]
jaredpar@online.microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
> Hi Brian,
> Process is just a dummy function. The actual processing function has try
[quoted text clipped - 108 lines]
>> > We can change it to singlecall if needed, but first we want to check
>> > the issue
Sudesh Sawant - 26 May 2005 18:12 GMT
Hello Jared,
I had attached the debugger to the service. Infact I had tried to trace it
through the client to my servce. The request goes ahead from the client and
does not reach the service. I had tried to solve the problem in the following
steps.
1. Called GC::Collect from the methods (methods which are being remotely
called). This improved the performance a lot.
2. Changed from http channel to tcp channel. Even this improved the
performance, but still the requests are limited.
When looking for number of threads, the thread count at which it stops
functioning in case of tcp is 91 and in case of http it is 54. Out of these
around 33 threads are created by the service. The other threads are spawned
at every request. If there is some time lag in between requests, the thread
count goes down. but the service stops remoting requests after the threshold
mentioned above is reached. I had found a link which recommendd changing the
threadpool size, but i want to try this as the last solution.
Cheers,
sudesh
> Have you attached a debbuger to the service when the call hangs? If so how
> many threads are running on the service?
[quoted text clipped - 111 lines]
> >> > We can change it to singlecall if needed, but first we want to check
> >> > the issue
Jared Parsons [MSFT] - 27 May 2005 19:08 GMT
You could try isolating the problem by hacking up your service to give back
a default answer and not spawn any of it's own threads and see if you still
hit the problem

Signature
Jared Parsons [MSFT]
jaredpar@online.microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
> Hello Jared,
> I had attached the debugger to the service. Infact I had tried to trace it
[quoted text clipped - 154 lines]
>> >> > We can change it to singlecall if needed, but first we want to check
>> >> > the issue
Sudesh Sawant - 28 May 2005 04:51 GMT
Ok, Will try this.
Cheers,
Sudesh Sawant
> You could try isolating the problem by hacking up your service to give back
> a default answer and not spawn any of it's own threads and see if you still
[quoted text clipped - 158 lines]
> >> >> > We can change it to singlecall if needed, but first we want to check
> >> >> > the issue
Sudesh Sawant - 31 May 2005 23:54 GMT
Hello Jared,
Still the problem is not resolved.
Cheers,
Sudesh
> Ok, Will try this.
> Cheers,
[quoted text clipped - 162 lines]
> > >> >> > We can change it to singlecall if needed, but first we want to check
> > >> >> > the issue
Rogas69 - 02 Jun 2005 12:59 GMT
So even the dummy call of service hangs after 91 times? if so - maybe the
problem lays on client side. how many clients do you use to test this? are
they multithreaded? how many proxies do you create on client side?
Peter