[
https://issues.apache.org/jira/browse/CAMEL-19734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17795018#comment-17795018
]
Rhuan Rocha edited comment on CAMEL-19734 at 12/10/23 4:14 AM:
---------------------------------------------------------------
Hi [~davsclaus],
I've examined the StopWatch, and during my review, I came across this specific
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?
was (Author: JIRAUSER297305):
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)
