Re: Using a Singleton within a web service

[Marc Gravell]

The weird thing

is that *different instances* of my singleton ProcessAgentPool class are
actually instantiated!

Evidenced by? You didn't say why you think this...
And over what time interval are you seeing tihs?
Are you sure you aren't getting different ProcessAgent instances from a
single ProcessAgentPool?

Basically, by using a singleton, you have exposed yourself to several
threading issues. I wouldn't be at all surprised if a thread race is
causing a failed lookup of a ProcessAgent (in fact, a thread-race here
could crash the whole app, so it is unsafe if you haven't synchronized).

Another possibility is that your app-pool has recycled. This happens. It
also isn't clear on what thread the long-running operation is
happening - if you are using a web-service thread to do the main work, I
might expect starvation (and/or timeouts) to be an issue here as well.

Marc

[Giulio Petrucci]

Hi Marc,

thank for having payed attention to my long and boring message and for
your reply! ;-)

Marc Gravell ha scritto:

Evidenced by? You didn't say why you think this...

You're right.
In each web service WebMethod I use the DefaultTraceListener to write
some useful info such:
- ProcessAgentPool hash code,
- ProcessAgentPool count (i.e. how many active process are held by the
pool),

And over what time interval are you seeing tihs?

"Pollings" are 500ms spaced (just for debuggin purpose).

Are you sure you aren't getting different ProcessAgent instances from a
single ProcessAgentPool?

No, different ProcessAgentPool. I set a trace-line (writing on the
DefaulTraceListener) also within the ProcessAgentPool .ctor(), and I can
see that sometimes a new pool instance is created.

Basically, by using a singleton, you have exposed yourself to several
threading issues.

[cut]

I know, but I can ensure that everything is synchronized internally. I
could not post here the whole code of the sample application but you can
trust me. ;-)

Another possibility is that your app-pool has recycled. This happens. It
also isn't clear on what thread the long-running operation is happening
- if you are using a web-service thread to do the main work, I might
expect starvation (and/or timeouts) to be an issue here as well.

I must admit I didn't get this last quote. Please, could you explain a
little?
Thanks a lot,
Giulio

--
OnAir:
http://www.giuliopetrucci.it

[Marc Gravell]

I must admit I didn't get this last quote. Please, could you explain a

little?

I'm assuming that you are hosting your app in IIS; IIS has an option
(enabled by default) to restart an app-pool periodically; as I
understand it, this is intended to solve memory growth issues, and a few
other things. After a while, it will literally destroy your app-pool
(i.e. your app-domain), and the next request will get a nice fresh one -
which will mean that you get a new singleton.

You can disable this, but I'm not sure it wold be my first choice. If I
had a long-running stateful web-service, I would look at using WCF to
host it in a dedicated windows service process (there are sample project
templates for this in VS2008u and VS2005 with the WF extension). That
way, you control the lifetime etc.

Marc

[Marc Gravell]

(there are sample project

templates for this in VS2008u and VS2005 with the WF extension).

Sorry, I meant WCF extensions (WF on the mind...); for VS2005 it is here:

http://www.microsoft.com/downloads/d...DisplayLang=en

But it is cleaner in VS2008.

Marc

[Giulio Petrucci]

Hi Marc,

Marc Gravell ha scritto:

I'm assuming that you are hosting your app in IIS;

[cut]

Ok, I goti it now.

You can disable this, but I'm not sure it wold be my first choice.

Neither do I.
At this point my first choiche would be to create a windows service
process and make my web-service code-behind "talk" to it. My question
is: should I use remoting (or things similar) to make my objects pass
from the windows service context to the web service (IIS) one?

If I
had a long-running stateful web-service, I would look at using WCF

[cut]

Got it.
Anyway, do I need to install FW 3.0, right?

Ciao,
Giulio

--
OnAir:
http://www.giuliopetrucci.it

[Marc Gravell]

Anyway, do I need to install FW 3.0, right?

To use WCF, yes; WCF is part of .NET 3.0 and won't work without it.

should I use remoting (or things similar) to make my objects pass
from the windows service context to the web service (IIS) one?

Actually, WCF would be my first choice for IPC too... (perhaps on a
net-tcp binding or named pipe in this case) - but remoting is an option.
Personally, I get very confused by remoting, but if remoting works for
you, then fine; this would allow you to work without .NET 3.0, as you
could have you ASP.NET web-service talk to a well-known object (or
whatever the term is in remoting - see, I'm already lost!).
Your existing ASP.NET talking to a remoting service may well be less
complex and involve less changes.

Note that WCF running from a service or a console exe can expose itself
directly over http etc as though it were running inside IIS. In fact,
even WCF running inside IIS don't run through the same ASP.NET pipeline...

Marc

[Giulio Petrucci]

Hi Marc,

Marc Gravell ha scritto:

To use WCF, yes; WCF is part of .NET 3.0 and won't work without it.

Ok, so I think I can't use it, as the specs want my application to run
on FW2.0...

Actually, WCF would be my first choice for IPC too... (perhaps on a
net-tcp binding or named pipe in this case) - but remoting is an option.

[cut]

I see.
Anyway I'm stiil experiencing the same absurd problem: two similar
application, the first works fine, the second doesn't. Very strange...

Note that WCF running from a service or a console exe can expose itself
directly over http etc as though it were running inside IIS. In fact,
even WCF running inside IIS don't run through the same ASP.NET pipeline...

Yes, I know a bit of WCF, but should get through deeper... (when I have
time I'll do).

Thanks a lot,
Giulio

--
OnAir:
http://www.giuliopetrucci.it

[Ben Spigle]

Hi Giulio

Look into the GetDataObject method in the ISerializable interface. I
think that will work for a web service, although I am finding it does
not work for WCF.

Take a look at this link:
http://dotnetslackers.com/community/...2007/05/04/Whe
n-is-a-singleton-not-a-singleton_3F00_-Serialization_2100_.aspx
*** Sent via Developersdex http://www.developersdex.com ***