[
https://issues.apache.org/jira/browse/CAMEL-10116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361695#comment-15361695
]
Arno Noordover edited comment on CAMEL-10116 at 7/4/16 7:32 PM:
----------------------------------------------------------------
Notes so far:
- The List of MessageHistory might be added to the exchange in a thread unsafe
manner;
- Sometimes a defensive copy is made of the List (e.g. line 152 in
DefaultExchange, line 916 in ExchangeHelper);
- I found one place where the existence of Exchange.MESSAGE_HISTORY property is
checked. If it isn't present it is created and added to the properties hashmap
(CamelInternalProcessor line 746);
Questions:
- Should there be a new class introduced e.g. MessageHistories which hides the
collection implementation for the message history functionality?
- Should there be a method in Exchange like putIfAbsent from the
ConcurrentHashMap which adds a new element to the hashmap if it isn't present
or returns the existing element in a thread-safe manner?
- Should the defensive copy functionality be thread-safe? I don't know yet what
would happen in a multi threaded solution.
- Do we need to make a defensive copy of the MESSAGE_HISTORY property when
making a safe-copy of the properties? Maybe we shouldn't make a defensive copy
and need to use the same instance. What happens when another thread adds a
MessageHistory to the old properties map?
- Are there other places where the MESSAGE_HISTORY is added to the properties
HashMap?
But the main question of course:
Could the CamelInternalProcessor be the cause of this problem?
was (Author: anoordover):
Notes so far:
- The List of MessageHistory might be added to the exchange in a thread unsafe
manner;
- Sometimes a defensive copy is made of the List (e.g. line 152 in
DefaultExchange, line 916 in ExchangeHelper);
- I found one place where the existence of Exchange.MESSAGE_HISTORY property is
checked. If it isn't present it is created and added to the properties hashmap
(CamelInternalProcessor line 746);
Questions:
- Should there be a new class introduced e.g. MessageHistories which hides the
collection implementation for the message history functionality?
- Should there be a method in Exchange like putIfAbsent from the
ConcurrentHashMap which adds a new element to the hashmap if it isn't present
or returns the existing element in a thread-safe manner?
- Should the defensive copy functionality be thread-safe? I don't know yet what
would happen in a multi threaded solution.
- Do we need to make a defensive copy of the MESSAGE_HISTORY property when
making a safe-copy of the properties? Maybe we shouldn't make a defensive copy
and need to use the same instance. What happens when another thread adds a
MessageHistory to the old properties map?
- Are there other places where the MESSAGE_HISTORY is added to the properties
HashMap?
> NullPointerException in DefaultAsyncProcessorAwaitManager
> ---------------------------------------------------------
>
> Key: CAMEL-10116
> URL: https://issues.apache.org/jira/browse/CAMEL-10116
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.17.1
> Reporter: Wolfgang Nagele
> Assignee: Arno Noordover
> Fix For: 2.17.3, 2.18.0
>
>
> The following statement can cause a NPE (line #256 in
> DefaultAsyncProcessorAwaitManager at version 2.17.1):
> {{MessageHistory history = list.get(list.size() - 1);}}
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.camel.impl.DefaultAsyncProcessorAwaitManager$AwaitThreadEntry.<init>(DefaultAsyncProcessorAwaitManager.java:257)
> ~[camel-core-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.impl.DefaultAsyncProcessorAwaitManager$AwaitThreadEntry.<init>(DefaultAsyncProcessorAwaitManager.java:238)
> ~[camel-core-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.impl.DefaultAsyncProcessorAwaitManager.await(DefaultAsyncProcessorAwaitManager.java:73)
> ~[camel-core-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:122)
> ~[camel-core-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87)
> ~[camel-core-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.component.stream.StreamConsumer.processLine(StreamConsumer.java:218)
> ~[camel-stream-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.component.stream.StreamConsumer.readFromStream(StreamConsumer.java:146)
> ~[camel-stream-2.17.1.jar!/:2.17.1]
> at
> org.apache.camel.component.stream.StreamConsumer.run(StreamConsumer.java:99)
> ~[camel-stream-2.17.1.jar!/:2.17.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_91]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_91]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
