[
https://issues.apache.org/jira/browse/CAMEL-19734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795018#comment-17795018
]
Rhuan Rocha commented on CAMEL-19734:
-------------------------------------
Hi [~davsclaus],
I have reviewed the StopWatch and I saw this line
[https://github.com/apache/camel/blob/main/core/camel-util/src/main/java/org/apache/camel/util/StopWatch.java#L40]
{code:java}
public StopWatch(long timeMillis) {
start = timeMillis;
} {code}
The taken method is considering the time as nanoTime
[https://github.com/apache/camel/blob/main/core/camel-util/src/main/java/org/apache/camel/util/StopWatch.java#L74]
{code:java}
public long taken() {
if (start > 0) {
long delta = System.nanoTime() - start;
return Duration.ofNanos(delta).toMillis();
}
return 0;
} {code}
I think we have two issues here. The first issue is the start property can have
a value in milliseconds. The second issue is the nanoTime method has this text
within the doc: _*This method can only be used to measure elapsed time and is
not related to any other notion of system or wall-clock time. The value
returned represents nanoseconds since some fixed but arbitrary origin time
(perhaps in the future, so values may be negative).*_
The constructor StopWatch(long timeMillis) can induce the _developer to use it
with the_ System.currentTimeMillis [Ex.: StopWatch(System.currentTimeMillis())]
and generate a side effect. I think the better approach is to redefine the
StopWatch to work just with nanoTime, and remove the timeMillis. What do you
think about it? Does it make sense for you?
> SEDA endpoint with multiple consumers produces strange message history from
> error handler
> -----------------------------------------------------------------------------------------
>
> Key: CAMEL-19734
> URL: https://issues.apache.org/jira/browse/CAMEL-19734
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 3.20.6
> Reporter: Rich T
> Assignee: Rhuan Rocha
> Priority: Minor
> Attachments: camel-seda-reproducer.zip
>
>
> I have a SEDA endpoint with multiple consumers enabled and three consumers
> configured and default error handler is in place.
> If one of the consumer queues becomes full then with the default error
> handler the message history is output but the first item is always one of the
> other consumers with a really large elapsed time (the system hasn't even been
> running this long) and then this is followed by the consumer route that
> actually threw the exception:
>
>
> {code:java}
> Message History (source location is disabled)
> ---------------------------------------------------------------------------------------------------------------------------------------
> Source ID
> Processor Elapsed (ms)
> ClientInbound-ReadSimulatorSta
> from[seda://ClientInboundQueue?concurrentConsumers 1201857883
> ClientInbound-EventProcessor/p
> Processor@0x713c4d95 0
> ClientInbound-EventProcessor/c
> choice[when[{body instanceof xxx 0
> ClientInbound-EventProcessor/t
> seda://AttributeEventQueue?waitForTaskToComplete=I 0
> Stacktrace
> ---------------------------------------------------------------------------------------------------------------------------------------
> java.lang.IllegalStateException: Queue full
> {code}
> So from the above `ClientInbound-ReadSimulatorState` is one of the multiple
> consumers that doesn't throw an exception.
> `ClientInbound-EventProcessor` is the route that has a full queue which
> results in the queue full exception.
> I would expect to only see the `ClientInbound-EventProcessor` in the message
> history here; the first route in the history log seems to alternate between
> the two consumers that didn't generate the exception on successive error logs
> but they always have this strange elapsed time, here's a log showing the
> third consumer listed first:
>
>
> {code:java}
> Message History (source location is disabled)
> ---------------------------------------------------------------------------------------------------------------------------------------
> Source ID
> Processor Elapsed (ms)
> ClientInbound-Query/ClientInbo
> from[seda://ClientInboundQueue?concurrentConsumers 1201857882
> ClientInbound-EventProcessor/p
> Processor@0x713c4d95 0
> ClientInbound-EventProcessor/c
> choice[when[{body instanceof xxx 0
> ClientInbound-EventProcessor/t
> seda://AttributeEventQueue?waitForTaskToComplete=I 0
> Stacktrace
> ---------------------------------------------------------------------------------------------------------------------------------------
> java.lang.IllegalStateException: Queue full
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
