<thinkfr33ly@hotmail.com> wrote in message
news:52ee1546-d3fd-4192-aca5-d8d9a54f2a4e@y5g2000hsf.googlegroups.com...
> I'm experiencing a very strange issue in a production environment
> under heavy load. It appears as though a COM+ package has object
> activations that are getting "stuck". There is no actual processing
> taking place (afaict), but the call time for the component just keeps
> increasing and the pooling object is never returned to the pool. It
> basically appears as though the component is not being freed to return
> to the pool.
>
> The basic structure of the application is a COM+ Component written in
> C#. This component is activated via an MSMQ Trigger in response to a
> message arriving in a message queue.
>
> This application works fine under normal load. Even under somewhat
> heavy load, as long as the queue length doesn't get to be more than
> the max number of simultaneously pooled objects (20, by default),
> things work great. The objects are released back to the pool as they
> should be.
>
> If the queue length gets too long, the objects don't seem to be
> released as they should. This results in the Call Time for the object
> steadily increasing. It does appear that if I leave it long enough, it
> fixes itself sometimes... but usually, I'm forced to recycle the COM+
> application by executing a "Shut Down" command on the package.
>
> Sometimes this works and things are back to normal, but if the queue
> has lots of waiting messages, more often that not things get stuck
> again as soon as the first 20 objects are done processing.
>
> Interestingly, it appears to be a degenerative issue. When the
> components are working as they should, I'm able to process 40+
> messages per second. Over time, as objects get stuck, it decreases to
> 30, 20, 10, 5, etc. How long this deterioration takes appears to vary.
>
> I am calling ServicedComponent.DisposeObject when I'm done processing
> the message, and it's in a finally block to make sure it gets called.
>
> Ideas?