Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
3.5.0, 3.6.0
-
None
-
None
-
camel 3.5.0, filebeat 7.9.1, jdk 1.8.0_242, Debian 10, Linux 4.19.0-6-amd64
Description
I am new to camel. I use a filebeat source that delivers logfile data over the lumberjack v2 batch protocol. As a receiving server I use the camel lumberjack component to further process the data in a camel pipeline.
I realized that the LumberjackSessionHandler of camels lumberjack component is not stateless but is being used by camel for all parallel lumberjack connection requests. Thus, new incoming connections with their own batch windows mess up any ongoing process of the already existing window, e.g. window size settings and counting acknowledges.
Many different combinations of multicast().parallelProcessing().threads(...) with filebeats workers/pipelines showed the same result.
The states of the stateful LumberjackSessionHandler are mixed up and the handling of parallel windows is broken which results in unwanted/unfinished acknowledges. As a result it hangs up the whole communication process to the filebeat source.
The LumberjackSessionHandler is not able to handle multiple threads, but camel uses it as it would be able to.
How can I tell camel to use separate LumberjackSessionHandlers and processing pipelines for each lumberjack batch request? Or do I misunderstand the concept of how camel uses components?
Sorry, I wasn't able to find a more specific "camel-lumberjack" component in the list of issue proposals above so I selected camel-core...