Re: Review Request 34200: Review request for FLUME-2689, reloading conf file leads syslogTcpSource not receives any event
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34200/ --- (Updated 八月 4, 2016, 4:56 a.m.) Review request for Flume. Changes --- Use approach suggested by Balázs Donát Bessenyei to avoid long pause. Bugs: FLUME-2689 https://issues.apache.org/jira/browse/FLUME-2689 Repository: flume-git Description --- Reloading conf file will stop old syslog source and start new syslog source. Stopping syslog tcp source only closes the NioServerSocketChannel, resulting in the client sends data through the old channel. In that case, the new source never receives data. The tcpdump shows the events have received but the new source doesn't and ss shows the client connection stays same with old one. The right way to stop syslog source is close both the NioSocketChannel and NioServerSocketChannel, and shutdown the executor. Diffs (updated) - flume-ng-core/src/main/java/org/apache/flume/source/SyslogTcpSource.java 185c00c flume-ng-core/src/test/java/org/apache/flume/source/TestSyslogTcpSource.java 10ef8d8 Diff: https://reviews.apache.org/r/34200/diff/ Testing --- Thanks, wei yang
Review Request 50778: patch: race condition in SpillableMemoryChannel log print, please review
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50778/ --- Review request for Flume. Repository: flume-git Description --- race condition in SpillableMemoryChannel log print Diffs - flume-ng-channels/flume-spillable-memory-channel/src/main/java/org/apache/flume/channel/SpillableMemoryChannel.java b46d646 Diff: https://reviews.apache.org/r/50778/diff/ Testing --- Tested in our production environment. With this change, concurrent problem not occured. Thanks, lee qiaoping
[jira] [Comment Edited] (FLUME-2965) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407049#comment-15407049
]
liqiaoping edited comment on FLUME-2965 at 8/4/16 3:26 AM:
---
Hi Denes and Roshan, Sorry that I am glad to submit the patch to review but I
just don't know how to do it...
It seems that I can't assign this bug to myself, and when I click 'Submit
patch', there 's no box to put the patch file in.
Is there some link or tutorial for this ?
was (Author: lqp276):
Hi Denes and Roshan, Sorry that I am glad to submit the patch to review but I
just don't know how to do it...
Is there some link or tutorial for this ?
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2965
> URL: https://issues.apache.org/jira/browse/FLUME-2965
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
> Attachments: SpillableMemoryChannel.java
>
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2965) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15407049#comment-15407049
]
liqiaoping commented on FLUME-2965:
---
Hi Denes and Roshan, Sorry that I am glad to submit the patch to review but I
just don't know how to do it...
Is there some link or tutorial for this ?
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2965
> URL: https://issues.apache.org/jira/browse/FLUME-2965
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
> Attachments: SpillableMemoryChannel.java
>
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2965) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406832#comment-15406832
]
Roshan Naik commented on FLUME-2965:
Thanks [~lqp276]
Took a quick look... and in general it looks like the right fix. Would be
easier to idenitify all the changes in this fix if just the diff/patch was
uploaded. Also please create a code review as suggested by Denes.
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2965
> URL: https://issues.apache.org/jira/browse/FLUME-2965
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
> Attachments: SpillableMemoryChannel.java
>
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2857) Kafka Channel does not restore default values when live update config
[
https://issues.apache.org/jira/browse/FLUME-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1540#comment-1540
]
Bessenyei Balázs Donát commented on FLUME-2857:
---
[~tmgstev]: thank you for the bug report
Would you like to provide a patch for it or would you like me to assign the
ticket to myself and start working on it?
> Kafka Channel does not restore default values when live update config
> -
>
> Key: FLUME-2857
> URL: https://issues.apache.org/jira/browse/FLUME-2857
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Reporter: Tristan Stevens
>
> Been using the following config:
> {noformat}
> tier1.channels.channel1.type = org.apache.flume.channel.kafka.KafkaChannel
> tier1.channels.channel1.capacity = 1
> tier1.channels.channel1.transactionCapacity = 1
> tier1.channels.channel1.brokerList =
> 10.0.0.64:9092,10.0.0.65:9092,10.0.0.66:9092
> tier1.channels.channel1.topic = flume.aggregator.channel
> tier1.channels.channel1.zookeeperConnect = 10.0.0.64:2181
> tier1.channels.channel1.kafka.producer.type=async
> tier1.channels.channel1.kafka.batch.num.messages=200
> {noformat}
> If I remove the producer.type and batch.num.messages (i.e. restore them to
> default values) when doing a live update config the new values do not take
> effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2961) Make TaildirSource work with multiline
[
https://issues.apache.org/jira/browse/FLUME-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406647#comment-15406647
]
Bessenyei Balázs Donát commented on FLUME-2961:
---
[~wenqiao]: I'm suggesting linking FLUME-2800 as a duplicate of this issue.
(And maybe even marking it as resolved-duplicate.)
Are there any objections?
> Make TaildirSource work with multiline
> --
>
> Key: FLUME-2961
> URL: https://issues.apache.org/jira/browse/FLUME-2961
> Project: Flume
> Issue Type: Improvement
> Components: Sinks+Sources
>Affects Versions: v1.7.0
>Reporter: tinawenqiao
>Assignee: tinawenqiao
> Fix For: v1.7.0
>
> Attachments: FLUME-2961_1.patch
>
>
> TaidirSource defaults to LINE, this has issue when multiline log events like
> stack traces and have request/responses. Following part is Java traceback
> logs. We expect to have log line start regex Key to aggregate all the log
> lines till the next regex key is found.
> 2016-07-16 14:59:43,956 ERROR lifecycleSupervisor-1-7 LifecycleSupervisor.run
> - Unable to start EventDrivenSourceRunner: {
> source:cn.yottabyte.flume.source.http.HTTPSource{name:sourceHttp,state:IDLE}
> } - Exception follows.
> java.lang.IllegalStateException: Running HTTP Server found in source:
> sourceHttp before I started one. Will not attempt to start.
> at com.google.common.base.Preconditions.checkState(Preconditions.java:145)
> at
> cn.yottabyte.flume.source.http.HTTPSource.startHttpSourceServer(HTTPSource.java:170)
> at cn.yottabyte.flume.source.http.HTTPSource.start(HTTPSource.java:166)
> at
> org.apache.flume.source.EventDrivenSourceRunner.start(EventDrivenSourceRunner.java:44)
> at
> org.apache.flume.lifecycle.LifecycleSupervisor$MonitorRunnable.run(LifecycleSupervisor.java:251)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2857) Kafka Channel does not restore default values when live update config
[
https://issues.apache.org/jira/browse/FLUME-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406642#comment-15406642
]
Tristan Stevens commented on FLUME-2857:
I actually believe this isn't specific to the Kafka Channel and applies to all
live config updates in Flume when removing values and therefore expecting them
to go back to defaults.
> Kafka Channel does not restore default values when live update config
> -
>
> Key: FLUME-2857
> URL: https://issues.apache.org/jira/browse/FLUME-2857
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Reporter: Tristan Stevens
>
> Been using the following config:
> {noformat}
> tier1.channels.channel1.type = org.apache.flume.channel.kafka.KafkaChannel
> tier1.channels.channel1.capacity = 1
> tier1.channels.channel1.transactionCapacity = 1
> tier1.channels.channel1.brokerList =
> 10.0.0.64:9092,10.0.0.65:9092,10.0.0.66:9092
> tier1.channels.channel1.topic = flume.aggregator.channel
> tier1.channels.channel1.zookeeperConnect = 10.0.0.64:2181
> tier1.channels.channel1.kafka.producer.type=async
> tier1.channels.channel1.kafka.batch.num.messages=200
> {noformat}
> If I remove the producer.type and batch.num.messages (i.e. restore them to
> default values) when doing a live update config the new values do not take
> effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2857) Kafka Channel does not restore default values when live update config
[
https://issues.apache.org/jira/browse/FLUME-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406634#comment-15406634
]
Tristan Stevens commented on FLUME-2857:
cc [~bessbd]
> Kafka Channel does not restore default values when live update config
> -
>
> Key: FLUME-2857
> URL: https://issues.apache.org/jira/browse/FLUME-2857
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Reporter: Tristan Stevens
>
> Been using the following config:
> {noformat}
> tier1.channels.channel1.type = org.apache.flume.channel.kafka.KafkaChannel
> tier1.channels.channel1.capacity = 1
> tier1.channels.channel1.transactionCapacity = 1
> tier1.channels.channel1.brokerList =
> 10.0.0.64:9092,10.0.0.65:9092,10.0.0.66:9092
> tier1.channels.channel1.topic = flume.aggregator.channel
> tier1.channels.channel1.zookeeperConnect = 10.0.0.64:2181
> tier1.channels.channel1.kafka.producer.type=async
> tier1.channels.channel1.kafka.batch.num.messages=200
> {noformat}
> If I remove the producer.type and batch.num.messages (i.e. restore them to
> default values) when doing a live update config the new values do not take
> effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2573) flume-ng --conf parameter is not used when starting a flume agent
[
https://issues.apache.org/jira/browse/FLUME-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406627#comment-15406627
]
Bessenyei Balázs Donát commented on FLUME-2573:
---
There has been no action on this ticket in the last few weeks, I suggest
marking this ticket as resolved ("Not a bug").
(Reason: this ticket blocks release of Flume 1.7.0 and it doesn't seem to be a
bug.)
Are there any objections to marking the ticket as resolved?
> flume-ng --conf parameter is not used when starting a flume agent
> -
>
> Key: FLUME-2573
> URL: https://issues.apache.org/jira/browse/FLUME-2573
> Project: Flume
> Issue Type: Bug
> Components: Node
>Affects Versions: v1.4.0
> Environment: ubuntu 12 & Flume 1.4.0
>Reporter: Biju Nair
> Labels: flume-ng
> Fix For: v1.7.0
>
> Attachments: FLUME-2573-0.patch
>
>
> flume-ng script accepts the parameter
> [conf|https://github.com/apache/flume/blob/trunk/bin/flume-ng#L183] to pass
> the directory which stores the configuration files and adds it to the
> FLUME_CLASSPATH. But
> [org.apache.flume.node.Application|https://github.com/apache/flume/blob/trunk/flume-ng-node/src/main/java/org/apache/flume/node/Application.java#L302]
> expects configuration files passed to have an absolute path. So even if user
> passes `conf` and `conf-file` option, `application` looks for the
> configuration file in the directory from which it is executed. It would be
> good to take the `conf` value into consideration so that users can place the
> config files anywhere.
> Currently big-top init.d script joins the [`conf` and `conf-file`
> values|(https://github.com/apache/flume/blob/trunk/bin/flume-ng#L183] when
> calling flume-ng. The same can be done in the ` flume-ng ` script.
> Alternatively the `conf ` parameter can be read in ` application ` and
> concatenated in the code. The latter is a cleaner approach but will have
> impact on ` big-top `.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2964) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406597#comment-15406597
]
Bessenyei Balázs Donát commented on FLUME-2964:
---
Hi [~lqp276],
I guess, this ticket is a duplicate of FLUME-2965. I'll mark it as such, so
when someone later looks at this ticket, they will find the solution to this
problem.
Please tell if I'm mistaken.
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2964
> URL: https://issues.apache.org/jira/browse/FLUME-2964
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2966) NULL text in a TextMessage from a JMS source in Flume can lead to NPE
[
https://issues.apache.org/jira/browse/FLUME-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406548#comment-15406548
]
Bessenyei Balázs Donát commented on FLUME-2966:
---
Hi [~sahuja],
Would you like to provide a patch for this issue or would you like me to work
with you on this one?
> NULL text in a TextMessage from a JMS source in Flume can lead to NPE
> -
>
> Key: FLUME-2966
> URL: https://issues.apache.org/jira/browse/FLUME-2966
> Project: Flume
> Issue Type: Bug
>Reporter: Siddharth Ahuja
>
> Code at
> https://github.com/apache/flume/blob/trunk/flume-ng-sources/flume-jms-source/src/main/java/org/apache/flume/source/jms/DefaultJMSMessageConverter.java#L103
> does not check for a NULL text in a TextMessage from a Flume JMS source.
> This can lead to a NullPointerException here:
> {code}textMessage.getText().getBytes(charset){code} while trying to
> de-reference a null text from the textmessage.
> We should probably skip these like the NULL Objects in the ObjectMessage just
> below at:
> https://github.com/apache/flume/blob/trunk/flume-ng-sources/flume-jms-source/src/main/java/org/apache/flume/source/jms/DefaultJMSMessageConverter.java#L107.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2966) NULL text in a TextMessage from a JMS source in Flume can lead to NPE
Siddharth Ahuja created FLUME-2966:
--
Summary: NULL text in a TextMessage from a JMS source in Flume can
lead to NPE
Key: FLUME-2966
URL: https://issues.apache.org/jira/browse/FLUME-2966
Project: Flume
Issue Type: Bug
Reporter: Siddharth Ahuja
Code at
https://github.com/apache/flume/blob/trunk/flume-ng-sources/flume-jms-source/src/main/java/org/apache/flume/source/jms/DefaultJMSMessageConverter.java#L103
does not check for a NULL text in a TextMessage from a Flume JMS source. This
can lead to a NullPointerException here:
{code}textMessage.getText().getBytes(charset){code} while trying to
de-reference a null text from the textmessage.
We should probably skip these like the NULL Objects in the ObjectMessage just
below at:
https://github.com/apache/flume/blob/trunk/flume-ng-sources/flume-jms-source/src/main/java/org/apache/flume/source/jms/DefaultJMSMessageConverter.java#L107.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2965) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15406313#comment-15406313
]
Denes Arvay commented on FLUME-2965:
Hi [~lqp276], thank you for your bug report and fix. Could you please submit it
to the Review board at https://reviews.apache.org? If you need any assistance
on this, let me know.
Please also add some unit tests for your fix, if it's possible. Thanks.
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2965
> URL: https://issues.apache.org/jira/browse/FLUME-2965
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
> Attachments: SpillableMemoryChannel.java
>
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Review Request 50232: FLUME-2619: Spooldir source does not log channel exceptions
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50232/ --- (Updated Aug. 3, 2016, 3:54 p.m.) Review request for Flume, Denes Arvay and Attila Simon. Repository: flume-git Description --- Spooldir assumes that any ChannelException means that the channel is full and it does not log the exception message. Diffs (updated) - flume-ng-core/src/main/java/org/apache/flume/source/SpoolDirectorySource.java d88cc1d flume-ng-core/src/test/java/org/apache/flume/source/TestSpoolDirectorySource.java 82c5351 Diff: https://reviews.apache.org/r/50232/diff/ Testing --- [INFO] Flume NG Core .. SUCCESS [08:04 min] Thanks, Balázs Donát Bessenyei
[jira] [Updated] (FLUME-2965) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
liqiaoping updated FLUME-2965:
--
Flags: Patch
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2965
> URL: https://issues.apache.org/jira/browse/FLUME-2965
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
> Attachments: SpillableMemoryChannel.java
>
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2965) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
liqiaoping updated FLUME-2965:
--
Attachment: SpillableMemoryChannel.java
try to fix
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2965
> URL: https://issues.apache.org/jira/browse/FLUME-2965
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
> Attachments: SpillableMemoryChannel.java
>
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FLUME-2964) race condition in SpillableMemoryChannel log print
[
https://issues.apache.org/jira/browse/FLUME-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
liqiaoping resolved FLUME-2964.
---
Resolution: Duplicate
> race condition in SpillableMemoryChannel log print
> --
>
> Key: FLUME-2964
> URL: https://issues.apache.org/jira/browse/FLUME-2964
> Project: Flume
> Issue Type: Bug
> Components: Channel
>Affects Versions: v1.7.0
>Reporter: liqiaoping
>Priority: Minor
>
> use SpillableMemoryChannel with http blob handler, and send many request
> concurrently, As the jetty has a threadpool to handle incoming request, the
> commit to SpillableMemoryChannel will be concurrent.
> the Following code :
> @Override
> protected void doCommit() throws InterruptedException {
> if (putCalled) {
> putCommit();
> if (LOGGER.isDebugEnabled()) {
> LOGGER.debug("Put Committed. Drain Order Queue state : "
> + drainOrder.dump());
> }
> in method - >drainOrder.dump() will iterate its internal queue, in the
> meantime, has changed by other thread, thus throw a concurrent modification
> exception. thus will result the channel processor try to rollback, but
> actually the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2964) race condition in SpillableMemoryChannel log print
liqiaoping created FLUME-2964:
-
Summary: race condition in SpillableMemoryChannel log print
Key: FLUME-2964
URL: https://issues.apache.org/jira/browse/FLUME-2964
Project: Flume
Issue Type: Bug
Components: Channel
Affects Versions: v1.7.0
Reporter: liqiaoping
Priority: Minor
use SpillableMemoryChannel with http blob handler, and send many request
concurrently, As the jetty has a threadpool to handle incoming request, the
commit to SpillableMemoryChannel will be concurrent.
the Following code :
@Override
protected void doCommit() throws InterruptedException {
if (putCalled) {
putCommit();
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Put Committed. Drain Order Queue state : "
+ drainOrder.dump());
}
in method - >drainOrder.dump() will iterate its internal queue, in the
meantime, has changed by other thread, thus throw a concurrent modification
exception. thus will result the channel processor try to rollback, but actually
the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2965) race condition in SpillableMemoryChannel log print
liqiaoping created FLUME-2965:
-
Summary: race condition in SpillableMemoryChannel log print
Key: FLUME-2965
URL: https://issues.apache.org/jira/browse/FLUME-2965
Project: Flume
Issue Type: Bug
Components: Channel
Affects Versions: v1.7.0
Reporter: liqiaoping
Priority: Minor
use SpillableMemoryChannel with http blob handler, and send many request
concurrently, As the jetty has a threadpool to handle incoming request, the
commit to SpillableMemoryChannel will be concurrent.
the Following code :
@Override
protected void doCommit() throws InterruptedException {
if (putCalled) {
putCommit();
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Put Committed. Drain Order Queue state : "
+ drainOrder.dump());
}
in method - >drainOrder.dump() will iterate its internal queue, in the
meantime, has changed by other thread, thus throw a concurrent modification
exception. thus will result the channel processor try to rollback, but actually
the transaction has commit succefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2765) ThriftSource spaws too many threads
[
https://issues.apache.org/jira/browse/FLUME-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15405400#comment-15405400
]
Qu Peng commented on FLUME-2765:
[~hshreedharan]，have you submit the patch? I'm using flume 1.6.0 now, and I
have same problem, too. Please help me, thanks!
> ThriftSource spaws too many threads
> ---
>
> Key: FLUME-2765
> URL: https://issues.apache.org/jira/browse/FLUME-2765
> Project: Flume
> Issue Type: Bug
> Components: Sinks+Sources
>Affects Versions: v1.6.0
>Reporter: Tobias Heintz
> Attachments: thread-dump-flume-1.6.txt
>
>
> We are in the process of migrating from the old Flume to version 1.6. We are
> using the ThriftSource with the new KafkaSink. Here's what our config looks
> like:
> {code}
> agent1.channels = ch1
> agent1.sources = thriftSrc
> agent1.sinks = kafka
> agent1.channels.ch1.type = memory
> agent1.channels.ch1.capacity = 1
> agent1.channels.ch1.transactionCapacity = 500
> # THRIFT
> agent1.sources.thriftSrc.type = thrift
> agent1.sources.thriftSrc.channels = ch1
> agent1.sources.thriftSrc.bind = 0.0.0.0
> agent1.sources.thriftSrc.port = 4042
> agent1.sources.thriftSrc.threads = 150 # if we don't set this option, the
> source keeps creating more and more threads until all heap memory is used up
> and then it crashes
> # KAFKA
> agent1.sinks.kafka.channel = ch1
> agent1.sinks.kafka.type = org.apache.flume.sink.kafka.KafkaSink
> agent1.sinks.kafka.batchSize = 50
> agent1.sinks.kafka.brokerList = broker.example.com:9092
> agent1.sinks.kafka.requiredAcks = 1
> agent1.sinks.kafka.topic = topic1
> {code}
> We have been noticing some bad behavior by the Thrift source/Thrift server
> using the JMX connection. If we don't restrict the number of threads, it
> spawns thousands of new threads, apparently one for every message it
> receives. These threads all have the name "Flume Thrift IPC Thread [number]"
> and according to the jvisualvm console they are always idle. At some point
> all of the JVM memory is used up through creating new threads and flume
> crashes with the following exception:
> {code}
> 12 Aug 2015 16:56:11,721 ERROR [Thread-1]
> (org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run:544) -
> run() exiting due to uncaught error
> java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method)
> at java.lang.Thread.start(Thread.java:714)
> at
> java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360)
> at
> org.apache.thrift.server.TThreadedSelectorServer.requestInvoke(TThreadedSelectorServer.java:310)
> at
> org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:209)
> at
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:576)
> at
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:536)
> {code}
> When we set the option to restrict the number of threads, the server sticks
> to that number and runs smoothly, however it drops messages occasionally (may
> have a different cause).
> I am wondering whether this is a bug or in some way expected behavior? What
> are the best practices for using a ThriftSource? Are there further parameters
> to possibly tune (like channel.capacity)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
