Arseniy Tashoyan created CAMEL-10048:
----------------------------------------
Summary: Memory leak in RoutingSlip
Key: CAMEL-10048
URL: https://issues.apache.org/jira/browse/CAMEL-10048
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.17.1, 2.17.0, 2.16.3, 2.16.2
Environment: java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
Reporter: Arseniy Tashoyan
RoutingSlip has a cache of error handlers implemented as a ConcurrentHashMap.
This map stores error handlers as values, and uses some synthetic objects as
keys. For some kind of destinations provided in routing slip, map lookup
operation does not work. Hence, new error handlers are always added to the map
and existing error handlers never reused. Finally, the program runs out of
memory.
The synthetic keys are actually instances of class
RoutingSlip.PreparedErrorHandler. Such key is based on two objects:
RouteContext and destination Processor. Neither RouteContext nor Processor do
not require their implementations to provide equals() and hashCode() methods.
Strictly speaking, caching implementation in RoutingSlip is incorrect, because
it uses hash map in the discouraged way. However, for some cases it works.
The problem occurs when routing slip contains a 'sync' destination, in other
words - destination is a Processor that does not implement AsyncProcessor
interface. RoutingSlip determines destination producer via
ProducerCache.doInAsyncProducer(), and the latter uses
AsyncProcessorConverterHelper.convert() method. This method creates new
instance of Processor for every processor that is not an instance of
AsyncProcessor. This is where problem hides: new object has different hash code
(defined by Object.hashCode()) and new object isn't equal to the object used as
a key in the hash map (well, Object.equals()). Finally, new key for the hash
map is calculated, lookup operation cannot find this key in the hash map, new
key-value pair is put into the hash map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)