synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ravi Undupitiya (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SYNAPSE-1003) Memory Leaks while using Anonymous Endpoints
Date Sat, 21 May 2016 04:25:12 GMT

     [ https://issues.apache.org/jira/browse/SYNAPSE-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ravi Undupitiya updated SYNAPSE-1003:
-------------------------------------
    Description: 
When using dynamic Load Balance endpoints in a send mediator and the endpoints have no name
in the xml configuration, they get given a unique name from the EndpointFactory..

* Every endpoint is registered over this name and an EndpointView as MBean is created. AdressEndpoints
in a LoadbalanceEndpoint never gets deregistered, causing a memory leak. 

* Every EndpointView registers a statistic runnable in a ScheduledExecutorService, but if
the endpoint gets destroyed, the runnable never gets canceled, causing another memory leak.


The first issue is reproducible by loading the following sequence: 
{code}
<sequence xmlns="http://ws.apache.org/ns/synapse" name="main">
	<in>
		<send>
			<endpoint>
				<loadbalance>
					<endpoint>
						<loadbalance>
							<endpoint>
								<address uri="http://localhost:8280/ServiceResponseDummy"/>
							</endpoint>
														<endpoint>
								<address uri="http://localhost:8280/ServiceResponseDummy"/>
							</endpoint>

						</loadbalance>
					</endpoint>
					<endpoint>
						<loadbalance>
							<endpoint>
								<address uri="http://msgdmem3:8280/ServiceResponseDummy"/>
							</endpoint>
														<endpoint>
								<address uri="http://msgdmem4:8280/ServiceResponseDummy"/>
							</endpoint>

						</loadbalance>
					</endpoint>
				</loadbalance>
			</endpoint>
		</send>
	</in>
	<out>
		<log level="custom">
			<property name="simple out sequence: " expression="get-property('From')"/>
		</log>
		<send/>
	</out>
</sequence>
{code}

The second is reproducible by dynamically loading sequence and engaging it (a case we've seen
where some people prefer to do this over statically configuring when they have over 1000's
of services to manage): 

{code}
public class TestCase extends AbstractMediator implements ManagedLifecycle {
	private static final Log log = LogFactory.getLog(ServiceConfigurationMediator.class);

	public boolean mediate(MessageContext messageContext) {
		try {
			InputStream in = getClass().getResourceAsStream("/test/sequence.xml");

			XMLStreamReader reader = XMLInputFactory.newInstance().createXMLStreamReader(in);
			StAXOMBuilder builder = new StAXOMBuilder(reader);
			OMElement xmlSequence = builder.getDocument().getOMDocumentElement();

			SequenceMediator mediatorInstance = new SequenceMediatorFactory().createAnonymousSequence(xmlSequence,
null);
			if (mediatorInstance instanceof ManagedLifecycle)
				((ManagedLifecycle) mediatorInstance).init(messageContext.getEnvironment());
			boolean result = mediatorInstance.mediate(messageContext);
			if (mediatorInstance instanceof ManagedLifecycle)
				((ManagedLifecycle) mediatorInstance).destroy();

			return result;
		} catch (Throwable e) {
			log.error("Fail: " + e, e);
			throw new SynapseException(e.getMessage(), e);
		}

	}

}
{code}

I would like to contribute the attached diff that addresses the above issues for your consideration
(it has been created over 2.1 branch). 

  was:
When using dynamic Load Balance endpoints in a send mediator and the endpoints have no name
in the xml configuration, they get given a unique name from the EndpointFactory..

* Every endpoint is registered over this name and an EndpointView as MBean is created. AdressEndpoints
in a LoadbalanceEndpoint never gets deregistered, causing a memory leak. 

* Every EndpointView registers a statistic runnable in a ScheduledExecutorService, but if
the endpoint gets destroyed, the runnable never gets canceled, causing another memory leak.


The first issue is reproducible by loading the following sequence: 
{code}
<sequence xmlns="http://ws.apache.org/ns/synapse" name="main">
	<in>
		<send>
			<endpoint>
				<loadbalance>
					<endpoint>
						<loadbalance>
							<endpoint>
								<address uri="http://localhost:8280/ServiceResponseDummy"/>
							</endpoint>
														<endpoint>
								<address uri="http://localhost:8280/ServiceResponseDummy"/>
							</endpoint>

						</loadbalance>
					</endpoint>
					<endpoint>
						<loadbalance algorithm="de.gad.bip.esb.esbext.transport.loadbalancealgorithm.RoundRobinRetryCheck">
							<endpoint>
								<address uri="http://msgdmem3:8280/ServiceResponseDummy"/>
							</endpoint>
														<endpoint>
								<address uri="http://msgdmem4:8280/ServiceResponseDummy"/>
							</endpoint>

						</loadbalance>
					</endpoint>
				</loadbalance>
			</endpoint>
		</send>
	</in>
	<out>
		<log level="custom">
			<property name="simple out sequence: " expression="get-property('From')"/>
		</log>
		<send/>
	</out>
</sequence>
{code}

The second is reproducible by dynamically loading sequence and engaging it (a case we've seen
where some people prefer to do this over statically configuring when they have over 1000's
of services to manage): 

{code}
public class TestCase extends AbstractMediator implements ManagedLifecycle {
	private static final Log log = LogFactory.getLog(ServiceConfigurationMediator.class);

	public boolean mediate(MessageContext messageContext) {
		try {
			InputStream in = getClass().getResourceAsStream("/test/sequence.xml");

			XMLStreamReader reader = XMLInputFactory.newInstance().createXMLStreamReader(in);
			StAXOMBuilder builder = new StAXOMBuilder(reader);
			OMElement xmlSequence = builder.getDocument().getOMDocumentElement();

			SequenceMediator mediatorInstance = new SequenceMediatorFactory().createAnonymousSequence(xmlSequence,
null);
			if (mediatorInstance instanceof ManagedLifecycle)
				((ManagedLifecycle) mediatorInstance).init(messageContext.getEnvironment());
			boolean result = mediatorInstance.mediate(messageContext);
			if (mediatorInstance instanceof ManagedLifecycle)
				((ManagedLifecycle) mediatorInstance).destroy();

			return result;
		} catch (Throwable e) {
			log.error("Fail: " + e, e);
			throw new SynapseException(e.getMessage(), e);
		}

	}

}
{code}

I would like to contribute the attached diff that addresses the above issues for your consideration
(it has been created over 2.1 branch). 


> Memory Leaks while using Anonymous Endpoints
> --------------------------------------------
>
>                 Key: SYNAPSE-1003
>                 URL: https://issues.apache.org/jira/browse/SYNAPSE-1003
>             Project: Synapse
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.0, 2.1
>            Reporter: Ravi Undupitiya
>            Assignee: Hiranya Jayathilaka
>              Labels: patch
>             Fix For: 2.1
>
>
> When using dynamic Load Balance endpoints in a send mediator and the endpoints have no
name in the xml configuration, they get given a unique name from the EndpointFactory..
> * Every endpoint is registered over this name and an EndpointView as MBean is created.
AdressEndpoints in a LoadbalanceEndpoint never gets deregistered, causing a memory leak. 
> * Every EndpointView registers a statistic runnable in a ScheduledExecutorService, but
if the endpoint gets destroyed, the runnable never gets canceled, causing another memory leak.

> The first issue is reproducible by loading the following sequence: 
> {code}
> <sequence xmlns="http://ws.apache.org/ns/synapse" name="main">
> 	<in>
> 		<send>
> 			<endpoint>
> 				<loadbalance>
> 					<endpoint>
> 						<loadbalance>
> 							<endpoint>
> 								<address uri="http://localhost:8280/ServiceResponseDummy"/>
> 							</endpoint>
> 														<endpoint>
> 								<address uri="http://localhost:8280/ServiceResponseDummy"/>
> 							</endpoint>
> 						</loadbalance>
> 					</endpoint>
> 					<endpoint>
> 						<loadbalance>
> 							<endpoint>
> 								<address uri="http://msgdmem3:8280/ServiceResponseDummy"/>
> 							</endpoint>
> 														<endpoint>
> 								<address uri="http://msgdmem4:8280/ServiceResponseDummy"/>
> 							</endpoint>
> 						</loadbalance>
> 					</endpoint>
> 				</loadbalance>
> 			</endpoint>
> 		</send>
> 	</in>
> 	<out>
> 		<log level="custom">
> 			<property name="simple out sequence: " expression="get-property('From')"/>
> 		</log>
> 		<send/>
> 	</out>
> </sequence>
> {code}
> The second is reproducible by dynamically loading sequence and engaging it (a case we've
seen where some people prefer to do this over statically configuring when they have over 1000's
of services to manage): 
> {code}
> public class TestCase extends AbstractMediator implements ManagedLifecycle {
> 	private static final Log log = LogFactory.getLog(ServiceConfigurationMediator.class);
> 	public boolean mediate(MessageContext messageContext) {
> 		try {
> 			InputStream in = getClass().getResourceAsStream("/test/sequence.xml");
> 			XMLStreamReader reader = XMLInputFactory.newInstance().createXMLStreamReader(in);
> 			StAXOMBuilder builder = new StAXOMBuilder(reader);
> 			OMElement xmlSequence = builder.getDocument().getOMDocumentElement();
> 			SequenceMediator mediatorInstance = new SequenceMediatorFactory().createAnonymousSequence(xmlSequence,
null);
> 			if (mediatorInstance instanceof ManagedLifecycle)
> 				((ManagedLifecycle) mediatorInstance).init(messageContext.getEnvironment());
> 			boolean result = mediatorInstance.mediate(messageContext);
> 			if (mediatorInstance instanceof ManagedLifecycle)
> 				((ManagedLifecycle) mediatorInstance).destroy();
> 			return result;
> 		} catch (Throwable e) {
> 			log.error("Fail: " + e, e);
> 			throw new SynapseException(e.getMessage(), e);
> 		}
> 	}
> }
> {code}
> I would like to contribute the attached diff that addresses the above issues for your
consideration (it has been created over 2.1 branch). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org


Mime
View raw message