Dhairya-007 opened a new pull request, #29680:
URL: https://github.com/apache/camel/pull/29680
## Problem
`FileWatchConsumer` hands every matched event to the queue the polling
threads read from, and throws the result away:
```java
FileEvent fileEvent = new FileEvent(directoryChangeEvent);
if (matchFilters(fileEvent)) {
eventQueue.offer(fileEvent);
}
```
`eventQueue` is bounded whenever the `queueSize` option is set:
```java
if (getEndpoint().getQueueSize() <= 0) {
eventQueue = new LinkedBlockingQueue<>();
} else {
eventQueue = new LinkedBlockingQueue<>(getEndpoint().getQueueSize());
}
```
so `offer` returns `false` as soon as the consumer falls behind the watch
service, and the file event is lost with nothing to show for it: no exchange,
no log line, no hint that `queueSize` is too small for the rate of changes. The
user sees files that were created or modified simply not being picked up.
The branch immediately above warns about precisely this kind of loss for the
watch service's own `OVERFLOW` event, which is what makes the silence here look
unintended:
```java
LOG.warn("OVERFLOW occurred, some events may be lost. Consider increasing of
option 'pollThreads'");
```
## Fix
Move the enqueue into `offerEvent(FileEvent)`, which logs a warning naming
the event type, the path and the configured size when the queue rejects the
event, and returns whether it was queued. Behaviour when the queue has room,
and the default unbounded queue, are unchanged.
## Tests
New `FileWatchConsumerQueueTest`:
- `shouldReportAnEventDroppedByAFullQueue` — with `queueSize=1`, the first
event is queued and the second is reported as dropped.
- `shouldQueueEveryEventWhenUnbounded` — the default queue takes 1000 events.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
