Web Service calls Queued Component

[BillGatesFan]

I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

 

[Willy Denoyette [MVP]]

I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so you have to
"dispose" when done, that is, you need to call MyComponent .Dispose() or use
the using idiom.

using (Mycomponent = ...)
{
// use the component...


} //this implicitly calls Dispose


Willy.

 

[Willy Denoyette [MVP]]

I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so you have to
"dispose" when done, that is, you need to call MyComponent .Dispose() or
use the using idiom.

using (Mycomponent = ...)
{
// use the component...


} //this implicitly calls Dispose


Willy.

Sorry, I missed the Moniker, you effectively get a COM wrapper back, so you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.

Willy.

 

[BillGatesFan]

I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.
[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so you have to
"dispose" when done, that is, you need to call MyComponent .Dispose() or
use the using idiom.

using (Mycomponent = ...)
{
// use the component...

} //this implicitly calls Dispose

Willy.

Sorry, I missed the Moniker, you effectively get a COM wrapper back, so you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.

Willy.- Hide quoted text -

- Show quoted text -

Thanks so much! I'll be wainting

 

[Nicholas Paldino [.NET/C# MVP]]

I think a little more information is needed about your component. The
biggest thing to know is, are you using object pooling or not? If you are
not, then it's not likely that you will see the number of objects go down
once you release the object (depending on the setup on the machine).

Also, remember that the configuration of the component in Component
Services can possibly be different from what you have declared on your
serviced component (one can go in and manually change them, after all).


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message

I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so you have
to
"dispose" when done, that is, you need to call MyComponent .Dispose()
or
use the using idiom.

using (Mycomponent = ...)
{
// use the component...

} //this implicitly calls Dispose

Willy.

Sorry, I missed the Moniker, you effectively get a COM wrapper back, so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.

Willy.- Hide quoted text -

- Show quoted text -

Thanks so much! I'll be wainting

 

[BillGatesFan]

I think a little more information is needed about your component. The
biggest thing to know is, are you using object pooling or not? If you are
not, then it's not likely that you will see the number of objects go down
once you release the object (depending on the setup on the machine).

Also, remember that the configuration of the component in Component
Services can possibly be different from what you have declared on your
serviced component (one can go in and manually change them, after all).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

message
I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.
[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}
Your class derives from an IDisposable (ServicedComponent) so you have
to
"dispose" when done, that is, you need to call MyComponent .Dispose()
or
use the using idiom.
using (Mycomponent = ...)
{
// use the component...
} //this implicitly calls Dispose
Willy.
Sorry, I missed the Moniker, you effectively get a COM wrapper back, so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.
Willy.- Hide quoted text -
- Show quoted text -

Thanks so much! I'll be wainting- Hide quoted text -

- Show quoted text -

I'm not using object pooling

<<< I think a little more information is needed about your component.
The
biggest thing to know is, are you using object pooling or not? If you
are
not, then it's not likely that you will see the number of objects go
down
once you release the object (depending on the setup on the machine).
Can you explain more? Depending on what setup on the machine?

<<< Also, remember that the configuration of the component in
Component
Services can possibly be different from what you have declared on
your
serviced component (one can go in and manually change them, after
all). >>>

Do you mean what you have declared in code versus what is declared in
component services? Please explain

 

[Willy Denoyette [MVP]]

message

I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so you have
to
"dispose" when done, that is, you need to call MyComponent .Dispose()
or
use the using idiom.

using (Mycomponent = ...)
{
// use the component...

} //this implicitly calls Dispose

Willy.

Sorry, I missed the Moniker, you effectively get a COM wrapper back, so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.

Willy.- Hide quoted text -

- Show quoted text -

Thanks so much! I'll be wainting

Note that what is shown here are the instances of the queued components
created by MSMQ, your client is talking to MSMQ NOT to the COM+ Server, that
is the interface you got from the moniker points to the MSMQ service,
Marshal.ReleaseComObject correctly releases the instance with the MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled) component
service (COM+ Server component), and I think that the info showed in the
Component services applet cannot be trusted, in the tests I ran I see the
Object count varying between something like 10 and 80, this value drops when
there are no messages sent to the queue, but they never return to a value
lower than 10. This value remains even when MSMQ is shut-down which should
definitely release the interface with the COM+ Server.

Willy.

 

[BillGatesFan]

message
I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.
[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}
Your class derives from an IDisposable (ServicedComponent) so you have
to
"dispose" when done, that is, you need to call MyComponent .Dispose()
or
use the using idiom.
using (Mycomponent = ...)
{
// use the component...
} //this implicitly calls Dispose
Willy.
Sorry, I missed the Moniker, you effectively get a COM wrapper back, so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.
Willy.- Hide quoted text -
- Show quoted text -

Thanks so much! I'll be wainting

Note that what is shown here are the instances of the queued components
created by MSMQ, your client is talking to MSMQ NOT to the COM+ Server, that
is the interface you got from the moniker points to the MSMQ service,
Marshal.ReleaseComObject correctly releases the instance with the MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled) component
service (COM+ Server component), and I think that the info showed in the
Component services applet cannot be trusted, in the tests I ran I see the
Object count varying between something like 10 and 80, this value drops when
there are no messages sent to the queue, but they never return to a value
lower than 10. This value remains even when MSMQ is shut-down which should
definitely release the interface with the COM+ Server.

Willy.- Hide quoted text -

- Show quoted text -

Alright. Thanks for your help. Do you think this will have any affect
on the performance of the component? My only concern now is that this
left over number seems to grow over time. Every time I send more
messages to the queue, the left over number grows. Did you notice that?

 

[BillGatesFan]

news:[email protected]...

On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
message
I have a web service which calls a .NET queued serviced component in
COM+. I turned statistics on for the component. I call the component
10 times, 10 objects get created but they do not go away. I'm calling
Marshal.ReleaseComObject after I make each call.
[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}
Your class derives from an IDisposable (ServicedComponent) so you have
to
"dispose" when done, that is, you need to call MyComponent .Dispose()
or
use the using idiom.
using (Mycomponent = ...)
{
// use the component...
} //this implicitly calls Dispose
Willy.
Sorry, I missed the Moniker, you effectively get a COM wrapper back, so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.
Willy.- Hide quoted text -
- Show quoted text -
Thanks so much! I'll be wainting

Note that what is shown here are the instances of the queued components
created by MSMQ, your client is talking to MSMQ NOT to the COM+ Server, that
is the interface you got from the moniker points to the MSMQ service,
Marshal.ReleaseComObject correctly releases the instance with the MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled) component
service (COM+ Server component), and I think that the info showed in the
Component services applet cannot be trusted, in the tests I ran I see the
Object count varying between something like 10 and 80, this value drops when
there are no messages sent to the queue, but they never return to a value
lower than 10. This value remains even when MSMQ is shut-down which should
definitely release the interface with the COM+ Server.

Willy.- Hide quoted text -

- Show quoted text -

Alright. Thanks for your help. Do you think this will have any affect
on the performance of the component? My only concern now is that this
left over number seems to grow over time. Every time I send more
messages to the queue, the left over number grows. Did you notice that?- Hide quoted text -

- Show quoted text -

Also I was wondering if I check the checkbox "Automatically deactivate
this object when this method returns" for the main method of the
queued component? Will this make any difference? Thanks

 

[Willy Denoyette [MVP]]

On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
messagenews:[email protected]...

I have a web service which calls a .NET queued serviced component
in
COM+. I turned statistics on for the component. I call the
component
10 times, 10 objects get created but they do not go away. I'm
calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so you
have
to
"dispose" when done, that is, you need to call MyComponent
.Dispose()
or
use the using idiom.

using (Mycomponent = ...)
{
// use the component...

} //this implicitly calls Dispose

Sorry, I missed the Moniker, you effectively get a COM wrapper back,
so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.

Willy.- Hide quoted text -

- Show quoted text -

Thanks so much! I'll be wainting

Note that what is shown here are the instances of the queued components
created by MSMQ, your client is talking to MSMQ NOT to the COM+ Server,
that
is the interface you got from the moniker points to the MSMQ service,
Marshal.ReleaseComObject correctly releases the instance with the MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled) component
service (COM+ Server component), and I think that the info showed in
the
Component services applet cannot be trusted, in the tests I ran I see
the
Object count varying between something like 10 and 80, this value drops
when
there are no messages sent to the queue, but they never return to a
value
lower than 10. This value remains even when MSMQ is shut-down which
should
definitely release the interface with the COM+ Server.

Willy.- Hide quoted text -

- Show quoted text -

Alright. Thanks for your help. Do you think this will have any affect
on the performance of the component? My only concern now is that this
left over number seems to grow over time. Every time I send more
messages to the queue, the left over number grows. Did you notice that?-
Hide quoted text -

- Show quoted text -

Also I was wondering if I check the checkbox "Automatically deactivate
this object when this method returns" for the main method of the
queued component? Will this make any difference? Thanks

This can be accomplished by marking the Method as AutoComplete.

[AutoComplete(true)]
public void Foo()..

But this won't change that much as far as the statistics are concerned ,
except that you might see a larger # of Objects count and that the Activated
count returns to 0 when done with the last object and the queue is empty.
As I told you before the "statistics" are a feature used to illustrate a
component's activity, what you get is just a snap-shot of the component
states at a fixed interval, they do not reflect any real-time information.

Willy.

 

[BillGatesFan]

On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"

On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
message
I have a web service which calls a .NET queued serviced component
in
COM+. I turned statistics on for the component. I call the
component
10 times, 10 objects get created but they do not go away. I'm
calling
Marshal.ReleaseComObject after I make each call.
[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}
Your class derives from an IDisposable (ServicedComponent) so you
have
to
"dispose" when done, that is, you need to call MyComponent
.Dispose()
or
use the using idiom.
using (Mycomponent = ...)
{
// use the component...
} //this implicitly calls Dispose
Willy.
Sorry, I missed the Moniker, you effectively get a COM wrapper back,
so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.
Willy.- Hide quoted text -
- Show quoted text -
Thanks so much! I'll be wainting
Note that what is shown here are the instances of the queued components
created by MSMQ, your client is talking to MSMQ NOT to the COM+ Server,
that
is the interface you got from the moniker points to the MSMQ service,
Marshal.ReleaseComObject correctly releases the instance with the MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled) component
service (COM+ Server component), and I think that the info showed in
the
Component services applet cannot be trusted, in the tests I ran I see
the
Object count varying between something like 10 and 80, this value drops
when
there are no messages sent to the queue, but they never return to a
value
lower than 10. This value remains even when MSMQ is shut-down which
should
definitely release the interface with the COM+ Server.
Willy.- Hide quoted text -
- Show quoted text -
Alright. Thanks for your help. Do you think this will have any affect
on the performance of the component? My only concern now is that this
left over number seems to grow over time. Every time I send more
messages to the queue, the left over number grows. Did you notice that?-
Hide quoted text -
- Show quoted text -

Also I was wondering if I check the checkbox "Automatically deactivate
this object when this method returns" for the main method of the
queued component? Will this make any difference? Thanks

This can be accomplished by marking the Method as AutoComplete.

[AutoComplete(true)]
public void Foo()..

But this won't change that much as far as the statistics are concerned ,
except that you might see a larger # of Objects count and that the Activated
count returns to 0 when done with the last object and the queue is empty.
As I told you before the "statistics" are a feature used to illustrate a
component's activity, what you get is just a snap-shot of the component
states at a fixed interval, they do not reflect any real-time information.

Willy.- Hide quoted text -

- Show quoted text -

Thanks for all your help.

 

[BillGatesFan]

news:[email protected]...

On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"

On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
message
I have a web service which calls a .NET queued serviced component
in
COM+. I turned statistics on for the component. I call the
component
10 times, 10 objects get created but they do not go away. I'm
calling
Marshal.ReleaseComObject after I make each call.
[WebMethod]
public NotifyResponse Notify(NotifyRequest reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}
Your class derives from an IDisposable (ServicedComponent) so you
have
to
"dispose" when done, that is, you need to call MyComponent
.Dispose()
or
use the using idiom.
using (Mycomponent = ...)
{
// use the component...
} //this implicitly calls Dispose
Willy.
Sorry, I missed the Moniker, you effectively get a COM wrapper back,
so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.
Willy.- Hide quoted text -
- Show quoted text -
Thanks so much! I'll be wainting
Note that what is shown here are the instances of the queued components
created by MSMQ, your client is talking to MSMQ NOT to the COM+ Server,
that
is the interface you got from the moniker points to the MSMQ service,
Marshal.ReleaseComObject correctly releases the instance with the MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled) component
service (COM+ Server component), and I think that the info showed in
the
Component services applet cannot be trusted, in the tests I ran I see
the
Object count varying between something like 10 and 80, this value drops
when
there are no messages sent to the queue, but they never return to a
value
lower than 10. This value remains even when MSMQ is shut-down which
should
definitely release the interface with the COM+ Server.
Willy.- Hide quoted text -
- Show quoted text -
Alright. Thanks for your help. Do you think this will have any affect
on the performance of the component? My only concern now is that this
left over number seems to grow over time. Every time I send more
messages to the queue, the left over number grows. Did you notice that?-
Hide quoted text -
- Show quoted text -
Also I was wondering if I check the checkbox "Automatically deactivate
this object when this method returns" for the main method of the
queued component? Will this make any difference? Thanks

This can be accomplished by marking the Method as AutoComplete.

[AutoComplete(true)]
public void Foo()..

But this won't change that much as far as the statistics are concerned ,
except that you might see a larger # of Objects count and that the Activated
count returns to 0 when done with the last object and the queue is empty.
As I told you before the "statistics" are a feature used to illustrate a
component's activity, what you get is just a snap-shot of the component
states at a fixed interval, they do not reflect any real-time information.

Willy.- Hide quoted text -

- Show quoted text -

Thanks for all your help.- Hide quoted text -

- Show quoted text -

Another question.

Now I'm trying to pool my COM+ app. It seems when the app is pooled it
starts off great but over a period of time, performance decreases. Any
clue?

 

[Brian Muth]

Have you used "View...Status" to watch the objects in action? Make sure you don't have an accumulation of objects over time, or any
objects in the "stuck" mode.

Brian

 

[Willy Denoyette [MVP]]

On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"

On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
messagenews:[email protected]...

I have a web service which calls a .NET queued serviced
component
in
COM+. I turned statistics on for the component. I call the
component
10 times, 10 objects get created but they do not go away.
I'm
calling
Marshal.ReleaseComObject after I make each call.

[WebMethod]
public NotifyResponse Notify(NotifyRequest
reqMessage)
{
try
{
string progid = "MyComponent";
MyComponent=
(IMyComponent)Marshal.BindToMoniker("queue:/new:" + progid);
if ( MyComponent != null)
{
MyComponent.Notify(XMLMessage);
}
return resMessage;
}
catch (Exception e)
{
ErrorLog.Log(Severity.Error, "An exception
was
thrown:" + e.Message);
return resMessage;
}
finally
{
Marshal.ReleaseComObject(MyComponent);
}
}

Your class derives from an IDisposable (ServicedComponent) so
you
have
to
"dispose" when done, that is, you need to call MyComponent
.Dispose()
or
use the using idiom.

using (Mycomponent = ...)
{
// use the component...

} //this implicitly calls Dispose

Sorry, I missed the Moniker, you effectively get a COM wrapper
back,
so
you
need to call ReleaseComObject.
Need to investigate this a bit, i'll come back when done.

Willy.- Hide quoted text -

- Show quoted text -

Thanks so much! I'll be wainting

Note that what is shown here are the instances of the queued
components
created by MSMQ, your client is talking to MSMQ NOT to the COM+
Server,
that
is the interface you got from the moniker points to the MSMQ
service,
Marshal.ReleaseComObject correctly releases the instance with the
MSMQ
server.
Did some tests myself using an hosted *queued* (non pooled)
component
service (COM+ Server component), and I think that the info showed
in
the
Component services applet cannot be trusted, in the tests I ran I
see
the
Object count varying between something like 10 and 80, this value
drops
when
there are no messages sent to the queue, but they never return to
a
value
lower than 10. This value remains even when MSMQ is shut-down
which
should
definitely release the interface with the COM+ Server.

Willy.- Hide quoted text -

- Show quoted text -

Alright. Thanks for your help. Do you think this will have any
affect
on the performance of the component? My only concern now is that
this
left over number seems to grow over time. Every time I send more
messages to the queue, the left over number grows. Did you notice
that?-
Hide quoted text -

- Show quoted text -

Also I was wondering if I check the checkbox "Automatically
deactivate
this object when this method returns" for the main method of the
queued component? Will this make any difference? Thanks

This can be accomplished by marking the Method as AutoComplete.

[AutoComplete(true)]
public void Foo()..

But this won't change that much as far as the statistics are concerned
,
except that you might see a larger # of Objects count and that the
Activated
count returns to 0 when done with the last object and the queue is
empty.
As I told you before the "statistics" are a feature used to illustrate
a
component's activity, what you get is just a snap-shot of the component
states at a fixed interval, they do not reflect any real-time
information.

Willy.- Hide quoted text -

- Show quoted text -

Thanks for all your help.- Hide quoted text -

- Show quoted text -

Another question.

Now I'm trying to pool my COM+ app. It seems when the app is pooled it
starts off great but over a period of time, performance decreases. Any
clue?

I suppose you are talking about "Application Pooling", right?
In that case make sure you don't overload the system by specifying too large
a pool, in general you should not need to pool your application.
I don't know the applications context, nor do I know anything about what
exactly that application is doing, so I need a lot more info in order to
help you out with this.
What OS and on what box (type and # of CPU, memory) are you running this?
Is this a single box application (Client and Server)?
Is this running in an AD realm, if YES, is MSMQ AD registered?
What's the "object task", is it CPU or IO bound, did you measure the CPU and
IO load on a per object basis.
Is this component using other services like Transactions and
Synchronization?
How large is the Application Pool?
What's the value of "Concurrent Players"?
How many "In Call objects" do you really allow?
Do you have Authentication enabled?
How large is the number of queued objects on a per time basis?
What's the per instance Object's call time (that is the time required to
execute a single call on a single instance).

Willy.