470,631 Members | 1,640 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,631 developers. It's quick & easy.

Web Service calls Queued Component

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);
}
}

Nov 7 '07 #1
11 1668
"BillGatesFan" <kl******@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
>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.

Nov 8 '07 #2
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:eq**************@TK2MSFTNGP03.phx.gbl...
"BillGatesFan" <kl******@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
>>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.
Nov 8 '07 #3
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in messagenews:eq**************@TK2MSFTNGP03.phx.gbl. ..


"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
>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

Nov 8 '07 #4
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]
- mv*@spam.guard.caspershouse.com

"BillGatesFan" <kl******@hotmail.comwrote in message
news:11*********************@i38g2000prf.googlegro ups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
>"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
messagenews:eq**************@TK2MSFTNGP03.phx.gbl ...


"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@k79g2000hse.googleg roups.com...
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

Nov 8 '07 #5
On Nov 8, 2:42 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.comwrote:
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]
- m...@spam.guard.caspershouse.com

"BillGatesFan" <klj_m...@hotmail.comwrote in message

news:11*********************@i38g2000prf.googlegro ups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
messagenews:eq**************@TK2MSFTNGP03.phx.gbl. ..
"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
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

Nov 8 '07 #6
"BillGatesFan" <kl******@hotmail.comwrote in message
news:11*********************@i38g2000prf.googlegro ups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
>"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
messagenews:eq**************@TK2MSFTNGP03.phx.gbl ...


"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@k79g2000hse.googleg roups.com...
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.

Nov 8 '07 #7
On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message

news:11*********************@i38g2000prf.googlegro ups.com...


On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
messagenews:eq**************@TK2MSFTNGP03.phx.gbl. ..
"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
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?

Nov 9 '07 #8
On Nov 9, 10:41 am, BillGatesFan <klj_m...@hotmail.comwrote:
On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"

<willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11*********************@i38g2000prf.googlegro ups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
>"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
>messagenews:eq**************@TK2MSFTNGP03.phx.gbl ...
"BillGatesFan" <klj_m...@hotmail.comwrote in message
>news:11**********************@k79g2000hse.googleg roups.com...
>>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

Nov 9 '07 #9
"BillGatesFan" <kl******@hotmail.comwrote in message
news:11**********************@y27g2000pre.googlegr oups.com...
On Nov 9, 10:41 am, BillGatesFan <klj_m...@hotmail.comwrote:
>On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"

<willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message
>news:11*********************@i38g2000prf.googlegr oups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
messagenews:eq**************@TK2MSFTNGP03.phx.gbl ...
"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@k79g2000hse.googleg roups.com...
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.
Nov 10 '07 #10
On Nov 10, 11:42 am, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message

news:11**********************@y27g2000pre.googlegr oups.com...


On Nov 9, 10:41 am, BillGatesFan <klj_m...@hotmail.comwrote:
On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11*********************@i38g2000prf.googlegro ups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
>"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
>messagenews:eq**************@TK2MSFTNGP03.phx.gbl ...
"BillGatesFan" <klj_m...@hotmail.comwrote in message
>news:11**********************@k79g2000hse.googleg roups.com...
>>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.

Nov 12 '07 #11
On Nov 12, 12:56 pm, BillGatesFan <klj_m...@hotmail.comwrote:
On Nov 10, 11:42 am, "Willy Denoyette [MVP]"

<willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message
news:11**********************@y27g2000pre.googlegr oups.com...
On Nov 9, 10:41 am, BillGatesFan <klj_m...@hotmail.comwrote:
>On Nov 8, 6:03 pm, "Willy Denoyette [MVP]"
><willy.denoye...@telenet.bewrote:
"BillGatesFan" <klj_m...@hotmail.comwrote in message
>news:11*********************@i38g2000prf.googlegr oups.com...
On Nov 8, 12:39 pm, "Willy Denoyette [MVP]"
<willy.denoye...@telenet.bewrote:
>"Willy Denoyette [MVP]" <willy.denoye...@telenet.bewrote in
>messagenews:eq**************@TK2MSFTNGP03.phx.gbl ...
"BillGatesFan" <klj_m...@hotmail.comwrote in message
>news:11**********************@k79g2000hse.googleg roups.com...
>>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?

Nov 12 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.