[
https://issues.apache.org/jira/browse/NIFI-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15185562#comment-15185562
]
ASF GitHub Bot commented on NIFI-1599:
--------------------------------------
Github user bbende commented on the pull request:
https://github.com/apache/nifi/pull/262#issuecomment-193929305
@olegz I didn't want to get into a complete refactoring of the different
handlers/dispatchers, as there are some complicated subtleties there, but I
took another shot and tried to at least ensure that the queuing logic is shared
across them with a class that wraps the blocking queue.
I supposed it could have been a static utility method, but I'm not usually
a fan of static methods that need to take a lot of parameters.
> ListenSyslog/ListenRELP should report when internal queue is full
> -----------------------------------------------------------------
>
> Key: NIFI-1599
> URL: https://issues.apache.org/jira/browse/NIFI-1599
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Bryan Bende
> Assignee: Bryan Bende
> Priority: Minor
> Fix For: 0.6.0
>
>
> In a recent ticket we exposed a property for choosing the maximum capacity of
> the internal queue used to transfer messages from the threading reading from
> the channel to the processor.
> Currently there is really no way to know if the queue is filling up and the
> size should be increased. We do an indefinite blocking put() when adding to
> the queue, but it would be nice if we tried with some amount of timeout and
> then logged an error so the user was aware that data was being dropped.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
