Remoting, Singleton and BackGroundWorker problem

S

Steve K.

I'm working on my first remoting project. It's going well and I have one
(that I know of!) bug left to work out.

I understand how remote objects have leases and those leases expire. I
fixed a problem earlier today where the EventShims that my clients were
invoking to handle server -> Client events were expiring and I was getting
the "Service not found" exception. I solved it by returning null from
InitializeLifetimeService()

I think the new problem I have is related.

My main proxy object or remoting object starts a Background Worker in it's
c'tor to poll a web service for data.
When my first client connects it instantiates the Singleton remote object,
all subsequent clients use this singleton. You can see this from the sample
server output below:
<server log>
OfficeStudio Server Started. Press ENTER to exit.
FaxManager Instance created
--------------------------------------------
| Poller Process Started |
--------------------------------------------
19 seconds until next server hit
Registered Client PC - 1 total clients registered.
18 seconds until next server hit
17 seconds until next server hit
16 seconds until next server hit
15 seconds until next server hit
Registered Client PC - 2 total clients registered.
14 seconds until next server hit
13 seconds until next server hit
12 seconds until next server hit
11 seconds until next server hit
Registered Client PC - 3 total clients registered.
10 seconds until next server hit
9 seconds until next server hit
8 seconds until next server hit
Registered Client PC - 4 total clients registered.
7 seconds until next server hit
6 seconds until next server hit
5 seconds until next server hit
Registered Client PC - 5 total clients registered.
4 seconds until next server hit
3 seconds until next server hit
2 seconds until next server hit
1 seconds until next server hit
Last checked for new faxes: 1/11/2008 1:55:18 AM
</server log>

Now, the problem arises when I close down all the clients and don't open
another one for several minutes (I haven't timed it yet, but I bet it's
00:05:01 (default expiration time for a remote object)

When this happens I will see in the server log that the remote object's
c'tor has been called again and another Background Worker instantiated, etc.
Problem is the FIRST BG worker is still cranking along hitting the web
service. So as this scenario plays out over and over I have n background
workers stacking up and they are blasting the web service which will
eventually make someone unhappy ;0)

My question is... when the remote object's lease expires... shouldn't it
call it's destructor and as such dispose the BackGroundWorker? Maybe I'm
misunderstanding the lease concept, it could be that the CLIENT's lease on
the object expires and the object is indeed still valid on the server.
IF this is the case, why do subsequent clients not get this already existing
singleton remote instance? Why are they creating a new one?

I suspect that I have a flaw in my over all design and I accept that, but
until I have time to take a second pass on the whole thing I need to figure
out what is happening here.

If anyone can shed some light on this I would really appreciate it. I'm
hoping to deploy the server over the weekend to let it crank away without
the risk of screwing up the office staff.

Thanks,
Steve
 
S

Steve K.

This article sheds some light:
http://thoughtshapes.com/node/49

Apparently the Singleton remote object is actually a monostate. Although
that still doesn't explain why the BackGroundWorker isn't collected.

I'd still appreciate any input you may have.
-Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

problems about remoting singleton 3
Remoting Singleton Issue 6
quick NEWBIE on remoting :) 2
Singleton types and static class 7
Remoting problems 2
Remoting/Threading 2
Remoting Problem 3
Remoting trouble 1

Top