Thanks for the response Ron.  I checked out the issue, but I believe there
may be a different issue which can also lead to orphaned Request objects in
the BeanEndpoint.requests map when multiple threads are sending requests
concurrently.

1) I believe the synchoronize block may need to be moved around the entire
onProviderExchange() method, otherwise the currentRequest variable can be
corrupted (one thread overwriting a previous threads value).  The current
synchronize block can also allow threads to enter the block before the
bean/beanInfo object have been initalized causing the methodInvocation to
fail.

2) Also in the onProviderExchange() method, I believe the calls at the end
of the method to:

            checkEndOfRequest(req);
            currentRequest.set(null);

need to be placed inside a finally block.  If not, when a consumer responds
with a DONE status or if an ERROR occurs, the method just returns without
cleaning up the requests map or the currentRequest.

An example where #2 will cause a memory leak is when an InOut exchange is
received, the initial request will be passed to the bean.  After the bean
returns, the consumer may have already received the "out" repsonse and set
the status to DONE (although the deliveryChannel has not yet invoked the
process() method yet), so the call to checkEndOfRequest(req) at the end of
onProviderExchange() will remove the Request object from the requests map. 
When then deliveryChannel does eventually invoke the process() method and
the process() method invokes the onProviderExchange(), a new Request object
will be created in getOrCreateCurrentRequest(exchange), but this new Request
will never be removed from the requests map since the method simply returns
when the exchange status == DONE.  Moving the calls above to a finally block
will make sure clean up is performed regardless of exchange status and or
errors.


I apologize for the lack of an example to reproduce the problem, I do not
have access to the internet from my office.



rgavlin wrote:
> 
> 
> I believe you may have encountered issue
> https://issues.apache.org/activemq/browse/SMXCOMP-20. This issue has
> already been fixed.
> 
> /Ron
> 
> 
> 
> ----- Original Message ----
> From: rmayo <[email protected]>
> To: [email protected]
> Sent: Tuesday, March 24, 2009 9:59:25 AM
> Subject: Re: Memory Leak in BeanEndpoint?
> 
> 
> I haven't seen any other postings or replies to this post.  I believe this
> problem still exists today.  
> 
> The only way I can prevent the memory leak from occurring is by casting
> the
> MessageExchange to a MessageExchangeImpl and setting the status of the
> packet to ExchangeStatus.DONE explictly before returning from my pojo, so
> that BeanEndpoint.checkEndOfRequest() will remove the Request object from
> the requests Map : 
> 
> channel.send(exchange);
> ((MessageExchangeImpl)
> exchange).getPacket().setStatus(ExchangeStatus.DONE);
> 
> Using channel.sendSync() would work also since my pojo would block until
> the
> consumer had responded after setting the status to DONE, but calling
> sendSync is not desired. 
> 
> 
> Am I missing something too?
> 
> 
> 
> KBerthelot wrote:
>> 
>> I'm getting a memory leak when using the BeanComponent that results from
>> Request objects never being removed from the requests map in
>> BeanEndpoint. 
>> In my case I've got a http consumer endpoint with the target service
>> implemented by a BeanEndpoint.  When onProviderExchange() executes on the
>> BeanEndpoint, onMessageExchange() is invoked on the pojo, which sends a
>> response back to the HttpEndpoint.  The problem is that
>> checkEndOfRequest() executes on the BeanEndpoint before the http
>> ConsumerProcessor has processed the response message from the pojo and
>> set
>> the exchange status to ExchangeStatus.DONE.  Therefore the Request object
>> doesn't get removed from the requests Map.  It would be a bit messy, but
>> it seems like there should be a way to expire Request objects since it
>> seems like it's fairly easy for them to get orphaned.  In fact, I'm not
>> sure how you could avoid orphans for InOut exchanges since I'm not aware
>> of a way to guarantee that the exchange is complete before
>> onProviderExchange() finishes execution.  Am I missing something?
>> 
> 
> -- 
> View this message in context:
> http://www.nabble.com/Memory-Leak-in-BeanEndpoint--tp10298559p22681014.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Memory-Leak-in-BeanEndpoint--tp10298559p22709191.html
Sent from the ServiceMix - User mailing list archive at Nabble.com.

Reply via email to