473,883 Members | 1,649 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Singleton Problem

Hello,
We have an application which communicates using remoting. There is a server
which is a Windows Service. The server exposes an object which is a
singleton. The client is a Web Application which makes calls to the service.
We are using tcp channel which is using binaryformatter by default. The
problem is that after a certain number of remoting calls the calls dont get
through to the server. The client application makes the call and hangs up.
The call never reaches the service. The initial calls get through. Earlier we
used http channel. Then the problem was worse. The client could not make more
than 20 calls. Now it hangs up after about 100 or so calls if made
sucessively. We had come to conclusion that it is some threadpool issue as we
observed that after some time the thread count goes high. The observation in
case of both http and tcp was that if the thread count crosses a certain
limit, the server does not accept more calls. If the calls don't come
successively, ie with in a short amount of time, the service does accept
calls. I believe this is not a synchronization problem as we have use sync
objects to protect in remoting calls. Also another point in this favor is
that the same code hangs up earlier with http channel.
The configuration for remote server is
<system.runtime .remoting>
<application>
<service>
<wellknown mode="Singleton " displayName="** ***"
type="***.***,S ervice.exe" objectUri="***. rem" />
</service>
<channels>
<channel ref="tcp" port="1978"></channel>
</channels>
</application>
</system.runtime. remoting>

// This is in the shared assembly
public __gc __interface IInterface
{
virtual System::String* Request(System: :String* a_pRequest) = 0;
};

// This is in an assembly with the service
public __gc class CInterface : public IInterface, public
System::Marshal ByRefObject
{
public:
// Singleton Pattern applied
virtual System::String* Request(System: :String* a_pRequest) {
privateLock(); Process(); privateUnLock() ;
System::GC::Col lect(); // After ading this we get to process more calls
return "****" };
virtual System::Object* InitializeLifet imeService() {return 0;};
void privateRegister ForRemoting()
{
try
{

System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
System::Runtime ::Remoting::Rem otingServices:: Marshal(this, "***.rem");
}
catch(System::E xception* a_pException)
{
WRITETOSYSTEMLO G(a_pException) ;
}
};
What could be the problem and how can this be addressed? We strongly think
this is some threadpool issue. Or there may be some problem the way we use
remoting.
We can change it to singlecall if needed, but first we want to check the issue
Jul 21 '05 #1
9 2261
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

Sudesh Sawant wrote:
Hello,
We have an application which communicates using remoting. There is a server
which is a Windows Service. The server exposes an object which is a
singleton. The client is a Web Application which makes calls to the service.
We are using tcp channel which is using binaryformatter by default. The
problem is that after a certain number of remoting calls the calls dont get
through to the server. The client application makes the call and hangs up.
The call never reaches the service. The initial calls get through. Earlier we
used http channel. Then the problem was worse. The client could not make more
than 20 calls. Now it hangs up after about 100 or so calls if made
sucessively. We had come to conclusion that it is some threadpool issue as we
observed that after some time the thread count goes high. The observation in
case of both http and tcp was that if the thread count crosses a certain
limit, the server does not accept more calls. If the calls don't come
successively, ie with in a short amount of time, the service does accept
calls. I believe this is not a synchronization problem as we have use sync
objects to protect in remoting calls. Also another point in this favor is
that the same code hangs up earlier with http channel.
The configuration for remote server is
<system.runtime .remoting>
<application>
<service>
<wellknown mode="Singleton " displayName="** ***"
type="***.***,S ervice.exe" objectUri="***. rem" />
</service>
<channels>
<channel ref="tcp" port="1978"></channel>
</channels>
</application>
</system.runtime. remoting>

// This is in the shared assembly
public __gc __interface IInterface
{
virtual System::String* Request(System: :String* a_pRequest) = 0;
};

// This is in an assembly with the service
public __gc class CInterface : public IInterface, public
System::Marshal ByRefObject
{
public:
// Singleton Pattern applied
virtual System::String* Request(System: :String* a_pRequest) {
privateLock(); Process(); privateUnLock() ;
System::GC::Col lect(); // After ading this we get to process more calls
return "****" };
virtual System::Object* InitializeLifet imeService() {return 0;};
void privateRegister ForRemoting()
{
try
{

System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
System::Runtime ::Remoting::Rem otingServices:: Marshal(this, "***.rem");
}
catch(System::E xception* a_pException)
{
WRITETOSYSTEMLO G(a_pException) ;
}
};
What could be the problem and how can this be addressed? We strongly think
this is some threadpool issue. Or there may be some problem the way we use
remoting.
We can change it to singlecall if needed, but first we want to check the issue


Jul 21 '05 #2
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
"Brian Gideon" wrote:
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

Sudesh Sawant wrote:
Hello,
We have an application which communicates using remoting. There is a server
which is a Windows Service. The server exposes an object which is a
singleton. The client is a Web Application which makes calls to the service.
We are using tcp channel which is using binaryformatter by default. The
problem is that after a certain number of remoting calls the calls dont get
through to the server. The client application makes the call and hangs up.
The call never reaches the service. The initial calls get through. Earlier we
used http channel. Then the problem was worse. The client could not make more
than 20 calls. Now it hangs up after about 100 or so calls if made
sucessively. We had come to conclusion that it is some threadpool issue as we
observed that after some time the thread count goes high. The observation in
case of both http and tcp was that if the thread count crosses a certain
limit, the server does not accept more calls. If the calls don't come
successively, ie with in a short amount of time, the service does accept
calls. I believe this is not a synchronization problem as we have use sync
objects to protect in remoting calls. Also another point in this favor is
that the same code hangs up earlier with http channel.
The configuration for remote server is
<system.runtime .remoting>
<application>
<service>
<wellknown mode="Singleton " displayName="** ***"
type="***.***,S ervice.exe" objectUri="***. rem" />
</service>
<channels>
<channel ref="tcp" port="1978"></channel>
</channels>
</application>
</system.runtime. remoting>

// This is in the shared assembly
public __gc __interface IInterface
{
virtual System::String* Request(System: :String* a_pRequest) = 0;
};

// This is in an assembly with the service
public __gc class CInterface : public IInterface, public
System::Marshal ByRefObject
{
public:
// Singleton Pattern applied
virtual System::String* Request(System: :String* a_pRequest) {
privateLock(); Process(); privateUnLock() ;
System::GC::Col lect(); // After ading this we get to process more calls
return "****" };
virtual System::Object* InitializeLifet imeService() {return 0;};
void privateRegister ForRemoting()
{
try
{

System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
System::Runtime ::Remoting::Rem otingServices:: Marshal(this, "***.rem");
}
catch(System::E xception* a_pException)
{
WRITETOSYSTEMLO G(a_pException) ;
}
};
What could be the problem and how can this be addressed? We strongly think
this is some threadpool issue. Or there may be some problem the way we use
remoting.
We can change it to singlecall if needed, but first we want to check the issue


Jul 21 '05 #3
Have you attached a debbuger to the service when the call hangs? If so how
many threads are running on the service?

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:5D******** *************** ***********@mic rosoft.com...
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
"Brian Gideon" wrote:
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

Sudesh Sawant wrote:
> Hello,
> We have an application which communicates using remoting. There is a
> server
> which is a Windows Service. The server exposes an object which is a
> singleton. The client is a Web Application which makes calls to the
> service.
> We are using tcp channel which is using binaryformatter by default. The
> problem is that after a certain number of remoting calls the calls dont
> get
> through to the server. The client application makes the call and hangs
> up.
> The call never reaches the service. The initial calls get through.
> Earlier we
> used http channel. Then the problem was worse. The client could not
> make more
> than 20 calls. Now it hangs up after about 100 or so calls if made
> sucessively. We had come to conclusion that it is some threadpool issue
> as we
> observed that after some time the thread count goes high. The
> observation in
> case of both http and tcp was that if the thread count crosses a
> certain
> limit, the server does not accept more calls. If the calls don't come
> successively, ie with in a short amount of time, the service does
> accept
> calls. I believe this is not a synchronization problem as we have use
> sync
> objects to protect in remoting calls. Also another point in this favor
> is
> that the same code hangs up earlier with http channel.
> The configuration for remote server is
> <system.runtime .remoting>
> <application>
> <service>
> <wellknown mode="Singleton " displayName="** ***"
> type="***.***,S ervice.exe" objectUri="***. rem" />
> </service>
> <channels>
> <channel ref="tcp" port="1978"></channel>
> </channels>
> </application>
> </system.runtime. remoting>
>
> // This is in the shared assembly
> public __gc __interface IInterface
> {
> virtual System::String* Request(System: :String* a_pRequest) = 0;
> };
>
> // This is in an assembly with the service
> public __gc class CInterface : public IInterface, public
> System::Marshal ByRefObject
> {
> public:
> // Singleton Pattern applied
> virtual System::String* Request(System: :String* a_pRequest) {
> privateLock(); Process(); privateUnLock() ;
> System::GC::Col lect(); // After ading this we get to process more calls
> return "****" };
> virtual System::Object* InitializeLifet imeService() {return 0;};
> void privateRegister ForRemoting()
> {
> try
> {
>
> System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
> System::Runtime ::Remoting::Rem otingServices:: Marshal(this, "***.rem");
> }
> catch(System::E xception* a_pException)
> {
> WRITETOSYSTEMLO G(a_pException) ;
> }
> };
> What could be the problem and how can this be addressed? We strongly
> think
> this is some threadpool issue. Or there may be some problem the way we
> use
> remoting.
> We can change it to singlecall if needed, but first we want to check
> the issue


Jul 21 '05 #4
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
"Jared Parsons [MSFT]" wrote:
Have you attached a debbuger to the service when the call hangs? If so how
many threads are running on the service?

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:5D******** *************** ***********@mic rosoft.com...
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
"Brian Gideon" wrote:
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

Sudesh Sawant wrote:
> Hello,
> We have an application which communicates using remoting. There is a
> server
> which is a Windows Service. The server exposes an object which is a
> singleton. The client is a Web Application which makes calls to the
> service.
> We are using tcp channel which is using binaryformatter by default. The
> problem is that after a certain number of remoting calls the calls dont
> get
> through to the server. The client application makes the call and hangs
> up.
> The call never reaches the service. The initial calls get through.
> Earlier we
> used http channel. Then the problem was worse. The client could not
> make more
> than 20 calls. Now it hangs up after about 100 or so calls if made
> sucessively. We had come to conclusion that it is some threadpool issue
> as we
> observed that after some time the thread count goes high. The
> observation in
> case of both http and tcp was that if the thread count crosses a
> certain
> limit, the server does not accept more calls. If the calls don't come
> successively, ie with in a short amount of time, the service does
> accept
> calls. I believe this is not a synchronization problem as we have use
> sync
> objects to protect in remoting calls. Also another point in this favor
> is
> that the same code hangs up earlier with http channel.
> The configuration for remote server is
> <system.runtime .remoting>
> <application>
> <service>
> <wellknown mode="Singleton " displayName="** ***"
> type="***.***,S ervice.exe" objectUri="***. rem" />
> </service>
> <channels>
> <channel ref="tcp" port="1978"></channel>
> </channels>
> </application>
> </system.runtime. remoting>
>
> // This is in the shared assembly
> public __gc __interface IInterface
> {
> virtual System::String* Request(System: :String* a_pRequest) = 0;
> };
>
> // This is in an assembly with the service
> public __gc class CInterface : public IInterface, public
> System::Marshal ByRefObject
> {
> public:
> // Singleton Pattern applied
> virtual System::String* Request(System: :String* a_pRequest) {
> privateLock(); Process(); privateUnLock() ;
> System::GC::Col lect(); // After ading this we get to process more calls
> return "****" };
> virtual System::Object* InitializeLifet imeService() {return 0;};
> void privateRegister ForRemoting()
> {
> try
> {
>
> System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
> System::Runtime ::Remoting::Rem otingServices:: Marshal(this, "***.rem");
> }
> catch(System::E xception* a_pException)
> {
> WRITETOSYSTEMLO G(a_pException) ;
> }
> };
> What could be the problem and how can this be addressed? We strongly
> think
> this is some threadpool issue. Or there may be some problem the way we
> use
> remoting.
> We can change it to singlecall if needed, but first we want to check
> the issue


Jul 21 '05 #5
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

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:4D******** *************** ***********@mic rosoft.com...
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
"Jared Parsons [MSFT]" wrote:
Have you attached a debbuger to the service when the call hangs? If so
how
many threads are running on the service?

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no
rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:5D******** *************** ***********@mic rosoft.com...
> 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
> "Brian Gideon" wrote:
>
>> 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
>>
>> Sudesh Sawant wrote:
>> > Hello,
>> > We have an application which communicates using remoting. There is a
>> > server
>> > which is a Windows Service. The server exposes an object which is a
>> > singleton. The client is a Web Application which makes calls to the
>> > service.
>> > We are using tcp channel which is using binaryformatter by default.
>> > The
>> > problem is that after a certain number of remoting calls the calls
>> > dont
>> > get
>> > through to the server. The client application makes the call and
>> > hangs
>> > up.
>> > The call never reaches the service. The initial calls get through.
>> > Earlier we
>> > used http channel. Then the problem was worse. The client could not
>> > make more
>> > than 20 calls. Now it hangs up after about 100 or so calls if made
>> > sucessively. We had come to conclusion that it is some threadpool
>> > issue
>> > as we
>> > observed that after some time the thread count goes high. The
>> > observation in
>> > case of both http and tcp was that if the thread count crosses a
>> > certain
>> > limit, the server does not accept more calls. If the calls don't
>> > come
>> > successively, ie with in a short amount of time, the service does
>> > accept
>> > calls. I believe this is not a synchronization problem as we have
>> > use
>> > sync
>> > objects to protect in remoting calls. Also another point in this
>> > favor
>> > is
>> > that the same code hangs up earlier with http channel.
>> > The configuration for remote server is
>> > <system.runtime .remoting>
>> > <application>
>> > <service>
>> > <wellknown mode="Singleton " displayName="** ***"
>> > type="***.***,S ervice.exe" objectUri="***. rem" />
>> > </service>
>> > <channels>
>> > <channel ref="tcp" port="1978"></channel>
>> > </channels>
>> > </application>
>> > </system.runtime. remoting>
>> >
>> > // This is in the shared assembly
>> > public __gc __interface IInterface
>> > {
>> > virtual System::String* Request(System: :String* a_pRequest) = 0;
>> > };
>> >
>> > // This is in an assembly with the service
>> > public __gc class CInterface : public IInterface, public
>> > System::Marshal ByRefObject
>> > {
>> > public:
>> > // Singleton Pattern applied
>> > virtual System::String* Request(System: :String* a_pRequest) {
>> > privateLock(); Process(); privateUnLock() ;
>> > System::GC::Col lect(); // After ading this we get to process more
>> > calls
>> > return "****" };
>> > virtual System::Object* InitializeLifet imeService() {return 0;};
>> > void privateRegister ForRemoting()
>> > {
>> > try
>> > {
>> >
>> > System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
>> > System::Runtime ::Remoting::Rem otingServices:: Marshal(this,
>> > "***.rem");
>> > }
>> > catch(System::E xception* a_pException)
>> > {
>> > WRITETOSYSTEMLO G(a_pException) ;
>> > }
>> > };
>> > What could be the problem and how can this be addressed? We strongly
>> > think
>> > this is some threadpool issue. Or there may be some problem the way
>> > we
>> > use
>> > remoting.
>> > We can change it to singlecall if needed, but first we want to check
>> > the issue
>>
>>


Jul 21 '05 #6
Ok, Will try this.
Cheers,
Sudesh Sawant

"Jared Parsons [MSFT]" wrote:
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

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:4D******** *************** ***********@mic rosoft.com...
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
"Jared Parsons [MSFT]" wrote:
Have you attached a debbuger to the service when the call hangs? If so
how
many threads are running on the service?

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no
rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:5D******** *************** ***********@mic rosoft.com...
> 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
> "Brian Gideon" wrote:
>
>> 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
>>
>> Sudesh Sawant wrote:
>> > Hello,
>> > We have an application which communicates using remoting. There is a
>> > server
>> > which is a Windows Service. The server exposes an object which is a
>> > singleton. The client is a Web Application which makes calls to the
>> > service.
>> > We are using tcp channel which is using binaryformatter by default.
>> > The
>> > problem is that after a certain number of remoting calls the calls
>> > dont
>> > get
>> > through to the server. The client application makes the call and
>> > hangs
>> > up.
>> > The call never reaches the service. The initial calls get through.
>> > Earlier we
>> > used http channel. Then the problem was worse. The client could not
>> > make more
>> > than 20 calls. Now it hangs up after about 100 or so calls if made
>> > sucessively. We had come to conclusion that it is some threadpool
>> > issue
>> > as we
>> > observed that after some time the thread count goes high. The
>> > observation in
>> > case of both http and tcp was that if the thread count crosses a
>> > certain
>> > limit, the server does not accept more calls. If the calls don't
>> > come
>> > successively, ie with in a short amount of time, the service does
>> > accept
>> > calls. I believe this is not a synchronization problem as we have
>> > use
>> > sync
>> > objects to protect in remoting calls. Also another point in this
>> > favor
>> > is
>> > that the same code hangs up earlier with http channel.
>> > The configuration for remote server is
>> > <system.runtime .remoting>
>> > <application>
>> > <service>
>> > <wellknown mode="Singleton " displayName="** ***"
>> > type="***.***,S ervice.exe" objectUri="***. rem" />
>> > </service>
>> > <channels>
>> > <channel ref="tcp" port="1978"></channel>
>> > </channels>
>> > </application>
>> > </system.runtime. remoting>
>> >
>> > // This is in the shared assembly
>> > public __gc __interface IInterface
>> > {
>> > virtual System::String* Request(System: :String* a_pRequest) = 0;
>> > };
>> >
>> > // This is in an assembly with the service
>> > public __gc class CInterface : public IInterface, public
>> > System::Marshal ByRefObject
>> > {
>> > public:
>> > // Singleton Pattern applied
>> > virtual System::String* Request(System: :String* a_pRequest) {
>> > privateLock(); Process(); privateUnLock() ;
>> > System::GC::Col lect(); // After ading this we get to process more
>> > calls
>> > return "****" };
>> > virtual System::Object* InitializeLifet imeService() {return 0;};
>> > void privateRegister ForRemoting()
>> > {
>> > try
>> > {
>> >
>> > System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
>> > System::Runtime ::Remoting::Rem otingServices:: Marshal(this,
>> > "***.rem");
>> > }
>> > catch(System::E xception* a_pException)
>> > {
>> > WRITETOSYSTEMLO G(a_pException) ;
>> > }
>> > };
>> > What could be the problem and how can this be addressed? We strongly
>> > think
>> > this is some threadpool issue. Or there may be some problem the way
>> > we
>> > use
>> > remoting.
>> > We can change it to singlecall if needed, but first we want to check
>> > the issue
>>
>>


Jul 21 '05 #7
Hello Jared,
Still the problem is not resolved.
Cheers,
Sudesh

"Sudesh Sawant" wrote:
Ok, Will try this.
Cheers,
Sudesh Sawant

"Jared Parsons [MSFT]" wrote:
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

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:4D******** *************** ***********@mic rosoft.com...
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
"Jared Parsons [MSFT]" wrote:

> Have you attached a debbuger to the service when the call hangs? If so
> how
> many threads are running on the service?
>
> --
> Jared Parsons [MSFT]
> ja******@online .microsoft.com
> http://blogs.msdn.com/jaredpar
> "This posting is provided "AS IS" with no warranties, and confers no
> rights"
> "Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
> news:5D******** *************** ***********@mic rosoft.com...
> > 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
> > "Brian Gideon" wrote:
> >
> >> 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
> >>
> >> Sudesh Sawant wrote:
> >> > Hello,
> >> > We have an application which communicates using remoting. There is a
> >> > server
> >> > which is a Windows Service. The server exposes an object which is a
> >> > singleton. The client is a Web Application which makes calls to the
> >> > service.
> >> > We are using tcp channel which is using binaryformatter by default.
> >> > The
> >> > problem is that after a certain number of remoting calls the calls
> >> > dont
> >> > get
> >> > through to the server. The client application makes the call and
> >> > hangs
> >> > up.
> >> > The call never reaches the service. The initial calls get through.
> >> > Earlier we
> >> > used http channel. Then the problem was worse. The client could not
> >> > make more
> >> > than 20 calls. Now it hangs up after about 100 or so calls if made
> >> > sucessively. We had come to conclusion that it is some threadpool
> >> > issue
> >> > as we
> >> > observed that after some time the thread count goes high. The
> >> > observation in
> >> > case of both http and tcp was that if the thread count crosses a
> >> > certain
> >> > limit, the server does not accept more calls. If the calls don't
> >> > come
> >> > successively, ie with in a short amount of time, the service does
> >> > accept
> >> > calls. I believe this is not a synchronization problem as we have
> >> > use
> >> > sync
> >> > objects to protect in remoting calls. Also another point in this
> >> > favor
> >> > is
> >> > that the same code hangs up earlier with http channel.
> >> > The configuration for remote server is
> >> > <system.runtime .remoting>
> >> > <application>
> >> > <service>
> >> > <wellknown mode="Singleton " displayName="** ***"
> >> > type="***.***,S ervice.exe" objectUri="***. rem" />
> >> > </service>
> >> > <channels>
> >> > <channel ref="tcp" port="1978"></channel>
> >> > </channels>
> >> > </application>
> >> > </system.runtime. remoting>
> >> >
> >> > // This is in the shared assembly
> >> > public __gc __interface IInterface
> >> > {
> >> > virtual System::String* Request(System: :String* a_pRequest) = 0;
> >> > };
> >> >
> >> > // This is in an assembly with the service
> >> > public __gc class CInterface : public IInterface, public
> >> > System::Marshal ByRefObject
> >> > {
> >> > public:
> >> > // Singleton Pattern applied
> >> > virtual System::String* Request(System: :String* a_pRequest) {
> >> > privateLock(); Process(); privateUnLock() ;
> >> > System::GC::Col lect(); // After ading this we get to process more
> >> > calls
> >> > return "****" };
> >> > virtual System::Object* InitializeLifet imeService() {return 0;};
> >> > void privateRegister ForRemoting()
> >> > {
> >> > try
> >> > {
> >> >
> >> > System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
> >> > System::Runtime ::Remoting::Rem otingServices:: Marshal(this,
> >> > "***.rem");
> >> > }
> >> > catch(System::E xception* a_pException)
> >> > {
> >> > WRITETOSYSTEMLO G(a_pException) ;
> >> > }
> >> > };
> >> > What could be the problem and how can this be addressed? We strongly
> >> > think
> >> > this is some threadpool issue. Or there may be some problem the way
> >> > we
> >> > use
> >> > remoting.
> >> > We can change it to singlecall if needed, but first we want to check
> >> > the issue
> >>
> >>
>
>
>


Jul 21 '05 #8
Hello Jared,
Still the problem is not resolved.
Cheers,
Sudesh

"Sudesh Sawant" wrote:
Ok, Will try this.
Cheers,
Sudesh Sawant

"Jared Parsons [MSFT]" wrote:
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

--
Jared Parsons [MSFT]
ja******@online .microsoft.com
http://blogs.msdn.com/jaredpar
"This posting is provided "AS IS" with no warranties, and confers no rights"
"Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
news:4D******** *************** ***********@mic rosoft.com...
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
"Jared Parsons [MSFT]" wrote:

> Have you attached a debbuger to the service when the call hangs? If so
> how
> many threads are running on the service?
>
> --
> Jared Parsons [MSFT]
> ja******@online .microsoft.com
> http://blogs.msdn.com/jaredpar
> "This posting is provided "AS IS" with no warranties, and confers no
> rights"
> "Sudesh Sawant" <Su**********@d iscussions.micr osoft.com> wrote in message
> news:5D******** *************** ***********@mic rosoft.com...
> > 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
> > "Brian Gideon" wrote:
> >
> >> 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
> >>
> >> Sudesh Sawant wrote:
> >> > Hello,
> >> > We have an application which communicates using remoting. There is a
> >> > server
> >> > which is a Windows Service. The server exposes an object which is a
> >> > singleton. The client is a Web Application which makes calls to the
> >> > service.
> >> > We are using tcp channel which is using binaryformatter by default.
> >> > The
> >> > problem is that after a certain number of remoting calls the calls
> >> > dont
> >> > get
> >> > through to the server. The client application makes the call and
> >> > hangs
> >> > up.
> >> > The call never reaches the service. The initial calls get through.
> >> > Earlier we
> >> > used http channel. Then the problem was worse. The client could not
> >> > make more
> >> > than 20 calls. Now it hangs up after about 100 or so calls if made
> >> > sucessively. We had come to conclusion that it is some threadpool
> >> > issue
> >> > as we
> >> > observed that after some time the thread count goes high. The
> >> > observation in
> >> > case of both http and tcp was that if the thread count crosses a
> >> > certain
> >> > limit, the server does not accept more calls. If the calls don't
> >> > come
> >> > successively, ie with in a short amount of time, the service does
> >> > accept
> >> > calls. I believe this is not a synchronization problem as we have
> >> > use
> >> > sync
> >> > objects to protect in remoting calls. Also another point in this
> >> > favor
> >> > is
> >> > that the same code hangs up earlier with http channel.
> >> > The configuration for remote server is
> >> > <system.runtime .remoting>
> >> > <application>
> >> > <service>
> >> > <wellknown mode="Singleton " displayName="** ***"
> >> > type="***.***,S ervice.exe" objectUri="***. rem" />
> >> > </service>
> >> > <channels>
> >> > <channel ref="tcp" port="1978"></channel>
> >> > </channels>
> >> > </application>
> >> > </system.runtime. remoting>
> >> >
> >> > // This is in the shared assembly
> >> > public __gc __interface IInterface
> >> > {
> >> > virtual System::String* Request(System: :String* a_pRequest) = 0;
> >> > };
> >> >
> >> > // This is in an assembly with the service
> >> > public __gc class CInterface : public IInterface, public
> >> > System::Marshal ByRefObject
> >> > {
> >> > public:
> >> > // Singleton Pattern applied
> >> > virtual System::String* Request(System: :String* a_pRequest) {
> >> > privateLock(); Process(); privateUnLock() ;
> >> > System::GC::Col lect(); // After ading this we get to process more
> >> > calls
> >> > return "****" };
> >> > virtual System::Object* InitializeLifet imeService() {return 0;};
> >> > void privateRegister ForRemoting()
> >> > {
> >> > try
> >> > {
> >> >
> >> > System::Runtime ::Remoting::Rem otingConfigurat ion::Configure( System::AppDoma in::CurrentDoma in->SetupInformati on->ConfigurationF ile);
> >> > System::Runtime ::Remoting::Rem otingServices:: Marshal(this,
> >> > "***.rem");
> >> > }
> >> > catch(System::E xception* a_pException)
> >> > {
> >> > WRITETOSYSTEMLO G(a_pException) ;
> >> > }
> >> > };
> >> > What could be the problem and how can this be addressed? We strongly
> >> > think
> >> > this is some threadpool issue. Or there may be some problem the way
> >> > we
> >> > use
> >> > remoting.
> >> > We can change it to singlecall if needed, but first we want to check
> >> > the issue
> >>
> >>
>
>
>


Jul 21 '05 #9
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
Jul 21 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

16
6743
by: cppaddict | last post by:
Hi, In this tutorial on singleton class in C++ (http://gethelp.devx.com/techtips/cpp_pro/10min/10min0200.asp) the author gives two implementations of a simple singleton class, claiming that only the first is safe for multi-threaded appliactions. I want to know why this so. The class is as follows:
1
2457
by: Jim Strathmeyer | last post by:
So I'm trying to implement a singleton template class, but I'm getting a confusing 'undefined reference' when it tries to link. Here's the code and g++'s output. Any help? // singleton.h template <class T> class Singleton : public T { public: static T * Instance();
3
3933
by: Harry | last post by:
Hi ppl I have a doubt on singleton class. I am writing a program below class singleton { private: singleton(){}; public: //way 1
7
3622
by: Stephen Brown | last post by:
I have some strange behavior on my web server that seems to point to garbage collection. I have a singleton that tracks web activity on my web site. The singleton works great, except that it restarts periodically. The web services have not been restarted and the error log shows no problems. It is the same problem on 2 different servers, but is worse on the most used server. On the most used server, it gets restarted 5 to 10 times a day...
21
2474
by: Sharon | last post by:
I wish to build a framework for our developers that will include a singleton pattern. But it can not be a base class because it has a private constructor and therefore can be inherit. I thought maybe a Template can be use for that, but C# does not support Templates (will be C# generics in mid 2005). Does anyone have a solution on how the singleton pattern can be written, in C#, as a framework/ infrastructure class, so users can use this...
3
2973
by: dischdennis | last post by:
Hello List, I would like to make a singleton class in python 2.4.3, I found this pattern in the web: class Singleton: __single = None def __init__( self ): if Singleton.__single: raise Singleton.__single
6
3203
by: toton | last post by:
Hi, If I have a singleton class based on dynamic initialization (with new ) , is it considered a memory leak? Anything in C++ standard says about it ? And little off - topic question , If the singleton is initialized as a static variable , it seems there is some threading issue . Is it the issue during singleton initialization only , or during the access also? If the singleton is per thread basis (then no more singleton though ), and...
3
435
by: wizwx | last post by:
There are two typical implementations of a singleton. The first one is to use a static pointer class Singleton { static Singleton * pSingleton; public: Singleton * instance() { if(pSingleton==NULL) pSingleton = new Singleton; return pSingleton; }
2
1593
by: Bob Johnson | last post by:
Just wondering the extent to which some of you are implementing classes as Singletons. I'm working on a brand new project and, early on, identified some obvious candidates. By "obvoius candidates" I mean classes for which terrible problems would clearly arise if more than one instance were to exist. But as I'm getting into the design of this new solution, I'm realizing that a large percentage of the classes _could be_ implemented as...
4
2834
by: John Doe | last post by:
Hi, I have a singleton class defined like this : class UIManager : public CSingleton<UIManager>, public CObject { protected: DECLARE_DYNAMIC(UIManager) friend class CSingleton<UIManager>;
0
11112
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10730
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10833
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10405
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9559
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7959
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7114
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
2
4205
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3228
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.