« Return to Thread: VM memory leak or expected functionality

Re: VM memory leak or expected functionality

by Rahul S :: Rate this Message:

We are also facing memory issues while using the MulticastingRouter.
The configuration is as follows

<model name="customer-information">
<mule-descriptor name="CustomerInfo" implementation="components.processor.CPProcessor" >
<inbound-router>
<endpoint address="cpService" transformers="ByteArrayToObject" />
</inbound-router>
<outbound-router>
<router className="org.mule.routing.outbound.MulticastingRouter">
<endpoint address="eSourceUpdateProfileService" connector="jmsConnector" synchronous="false" />
<endpoint address="bkUpdateProfileService" connector="jmsConnector" synchronous="false" />
</router>
</outbound-router>
</mule-descriptor>
</model>
<model name="esource-information">
<mule-descriptor name="eSrcInfo" implementation="components.processor.ESourceProcessor" >

<inbound-router>
<endpoint address="eSourceUpdateProfileService" />
</inbound-router>

</mule-descriptor>
</model>

<model name="bk-information">
<mule-descriptor name="BKInfo" implementation="components.processor.BKProcessor" >

<inbound-router>
<endpoint address="bkUpdateProfileService" />
</inbound-router>

</mule-descriptor>
</model>

Is this the root cause of the memory issue?
Any suggestions on how this can be modified so that the problem can be avoided.

Any help in this regard is highly appreciated

Andrew Perepelytsya wrote:

There's nothing for us to do, it's a misconfig in this case. I thought there
was a testcase issue currently.

On Dec 10, 2007 1:45 PM, Daniel Feist <dfeist@gmail.com> wrote:

> It would avoid the OutOfMemoryException if it were used
> yes but eventually you'll run out of disk space if you have an outbound vm
> endpoint with queuing and no consumer.
> So the root issue/question is still exists.. what to do if a user has such
> a queued endpoint with no consumer in their configuration, nothing? nothing
> but warn them somehow? or do something else?
>
> Dan
>
>
> On 10 Dec 2007, at 15:23, Andrew Perepelytsya wrote:
>
> Doesn't file persistent strategy help there?
>
> On Dec 10, 2007 1:19 PM, Daniel Feist <dfeist@gmail.com> wrote:
>
> > Hi,
> >
> > Just a quick heads up on an issue I had a quick look into this morning
> > and to see if anyone has any good ideas ...
> >
> > http://mule.mulesource.org/jira/browse/MULE-2158
> > (The issue is reported against 2.x but it's likely it also affects 1.4.x
> > .)
> >
> > This issue was initially reported as a memory leak which appeared when
> > performing stress testing as part of MulticastRouterMule2136TestCase
> > test case. After looking into this memory leak, I found that there is
> > no bug and this seems to be expected behaviour.
> >
> > The reason for this is that there are outbound vm endpoints with event
> > queuing enabled that have no vm receiver configured with the same uri,
> > and neither does any client code pull events from the queue via the
> > dispatcher (using recieve()/request()). The result of course is that
> > these message just pile up in the MessagePersistenceStrategy's hashmap
> > until we get a OutOfMemoryException.
> >
> > (MemoryPersistenceStrategy is used by default at least in 2.x)
> >
> > The question is what should be done about this:
> >
> > - nothing. it's expected
> > - nothing. it's expected, but document somewhere.
> > - it's expected, but we need better error/warn messages so user
> > doesn't get a OME or if they do then know why they are getting (how
> > would we do this?).
> > - set up a dummy receiver if none configured? ( not sure this would
> > work though because of the receive() usage)
> >
> > Dan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
>

« Return to Thread: VM memory leak or expected functionality