[jira] [Updated] (FLUME-2053) TestExecSource.testMonitoredCounterGroup fails
[ https://issues.apache.org/jira/browse/FLUME-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2053: Affects Version/s: v1.5.1 TestExecSource.testMonitoredCounterGroup fails -- Key: FLUME-2053 URL: https://issues.apache.org/jira/browse/FLUME-2053 Project: Flume Issue Type: Bug Components: Build Affects Versions: v1.4.0, v1.5.1 Environment: Ubuntu 13.04 Java(TM) SE Runtime Environment (build 1.7.0_13-b20) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) Maven 3.0.5 Reporter: Hans Uhlig Assignee: Ashish Paliwal Failed tests: testMonitoredCounterGroup(org.apache.flume.source.TestExecSource): Expected Value: 5 expected:[5] but was:[0] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FLUME-2515) TestExecSource.testMonitoredCounterGroup sometimes fails, on some environments
[ https://issues.apache.org/jira/browse/FLUME-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola resolved FLUME-2515. - Resolution: Duplicate TestExecSource.testMonitoredCounterGroup sometimes fails, on some environments -- Key: FLUME-2515 URL: https://issues.apache.org/jira/browse/FLUME-2515 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Labels: test-fail Fix For: v1.6.0 I have seen this failing on Travis with Open JDK 7. It seems it passes on different runs. I haven't checked yet, but it's probably related to execution being slower. https://travis-ci.org/Stratio/flume/jobs/38708780#L7175 testMonitoredCounterGroup(org.apache.flume.source.TestExecSource) Time elapsed: 3997 sec FAILURE! org.junit.ComparisonFailure: Expected Value: 5 expected:[5] but was:[0] at org.junit.Assert.assertEquals(Assert.java:125) at org.apache.flume.source.TestExecSource.testMonitoredCounterGroup(TestExecSource.java:273) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2627) RpcClient implementations have inconsistent handling of unreachable hosts
Santiago M. Mola created FLUME-2627: --- Summary: RpcClient implementations have inconsistent handling of unreachable hosts Key: FLUME-2627 URL: https://issues.apache.org/jira/browse/FLUME-2627 Project: Flume Issue Type: Bug Reporter: Santiago M. Mola Priority: Minor NettyAvroRpcClient.configure will throw FlumeException if it cannot connect to host. ThriftRpcClient.configure will try to establish a connection but it will not throw if it cannot connect, it will set its internal connection state to DEAD and will return false for ThriftRpcClient.isActive(). LoadBalancingRpcClient.configure and FailoverRpcClient.configure will not try to connect at all. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2625) There are several unstable tests within FLUME
[ https://issues.apache.org/jira/browse/FLUME-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14327321#comment-14327321 ] Santiago M. Mola commented on FLUME-2625: - [~trex58] Could you provide specific errors (with stacktraces) for TestLoadBalancingRpcClient abd TestThriftClient? There are several unstable tests within FLUME - Key: FLUME-2625 URL: https://issues.apache.org/jira/browse/FLUME-2625 Project: Flume Issue Type: Bug Components: Test Affects Versions: v1.5.0.1 Environment: RHEL 7.1 / x86_64 / Open JDK 1.7 Reporter: Tony Reix Hi, I'm working on porting FLUME in a RHEL 7.1 / PPC64LE / IBM JVM 1.7 environment. As an example, I've found that the test .source.TestSyslogUdpSource fails, but not always, only 7 times out of 10 tries. Testing on RHEL 7.1 / x86_64 / IBM JVM, I've also had random failures. Running the same .source.TestSyslogUdpSource test in RHEL 7.1 / x86_64 / Open JDK 1.7 environment, I've found that this test fails only once out of 30 tries: it is an unstable test. In order to find which test issues are specific to PPC64 or IBMJVM environment, I've run 10 times all the FLUME tests in the RHEL 7.1 / x86_64 / Open JDK 1.7 environment, which I call my reference environment. Then, using a tool that compares all the results, I've found that there are 16 tests that are unstable in my reference (x86_64/OpenJDK) . By unstable, I mean to say that the results vary, though the environment is exactly the same. These tests are: .api.TestLoadBalancingRpcClient .api.TestThriftRpcClient .channel.file.TestFileChannelRestart .channel.TestSpillableMemoryChannel .instrumentation.http.TestHTTPMetricsServer .sink.TestAvroSink .sink.TestThriftSink .source.avroLegacy.TestLegacyAvroSource .source.http.TestHTTPSource .source.TestAvroSource .source.TestExecSource .source.TestMultiportSyslogTCPSource .source.TestSyslogTcpSource .source.TestSyslogUdpSource .source.TestThriftSource .source.thriftLegacy.TestThriftLegacySource About .source.TestSyslogUdpSource test, my analysis is that the test code is not reliable since the test checks that some data is correct without checking that all the messages have arrived (sometimes, a message has not arrived in time, and a reference is NULL). Adding sleep(1000) to the test with IBM JVM, the test then failed only 3 times out of 10. So, I think that several FLUME tests are coded in a way that is not 100% reliable. Or it could also be that some core code of FLUME is not 100% reliable. I mean to say that some code may have been written based on the specific behaviour of the OpenJDK Java Virtual Machine, which was used for testing. Some change about how the order of threads are launched, or about the time needed to send messages in the JVM/OS, may lead to issues that are not correctly handled by the code (mainly test code, but maybe core code too). And it seems that, though being perfectly correct, the IBM JVM does not work the same way compared to OpenJDK. So, this is a pain. Mainly in my PPC64LE/IBMJVM environment. I think that these 16 tests must be analysed and improved. Also, running tests with OpenJDK AND IBM JVM in your development and test/Jenkins environments would help to see these random issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2629) Improve RpcClient unit tests
[ https://issues.apache.org/jira/browse/FLUME-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14327506#comment-14327506 ] Santiago M. Mola commented on FLUME-2629: - Here's the review board: https://reviews.apache.org/r/31195/ I have fixed a few minor bugs that arised when writing new tests. Improve RpcClient unit tests Key: FLUME-2629 URL: https://issues.apache.org/jira/browse/FLUME-2629 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Assignee: Santiago M. Mola Attachments: FLUME-2629-0.patch There is some room for improvement in RpcClient-related tests: - Some of them use Avro and Thrift servers that are not needed (most of the time). This makes them unnecessarily slower and, in some cases, unstable. - There is a lot of reliance on Thread.sleep(arbitraryTime) hoping that *something* happens meanwhile. These tests are unstable in some environments where arbitraryTime is too low. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2629) Improve RpcClient unit tests
[ https://issues.apache.org/jira/browse/FLUME-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2629: Attachment: FLUME-2629-0.patch Improve RpcClient unit tests Key: FLUME-2629 URL: https://issues.apache.org/jira/browse/FLUME-2629 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Assignee: Santiago M. Mola Attachments: FLUME-2629-0.patch There is some room for improvement in RpcClient-related tests: - Some of them use Avro and Thrift servers that are not needed (most of the time). This makes them unnecessarily slower and, in some cases, unstable. - There is a lot of reliance on Thread.sleep(arbitraryTime) hoping that *something* happens meanwhile. These tests are unstable in some environments where arbitraryTime is too low. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2629) Improve RpcClient unit tests
Santiago M. Mola created FLUME-2629: --- Summary: Improve RpcClient unit tests Key: FLUME-2629 URL: https://issues.apache.org/jira/browse/FLUME-2629 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Assignee: Santiago M. Mola There is some room for improvement in RpcClient-related tests: - Some of them use Avro and Thrift servers that are not needed (most of the time). This makes them unnecessarily slower and, in some cases, unstable. - There is a lot of reliance on Thread.sleep(arbitraryTime) hoping that *something* happens meanwhile. These tests are unstable in some environments where arbitraryTime is too low. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2625) There are several unstable tests within FLUME
[ https://issues.apache.org/jira/browse/FLUME-2625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14324049#comment-14324049 ] Santiago M. Mola commented on FLUME-2625: - I've been working on a patch to avoid relying on Thread.sleep calls with arbitrary values and using Mockito to wait for certain method calls instead. That should help to solve most of these test failures. There are several unstable tests within FLUME - Key: FLUME-2625 URL: https://issues.apache.org/jira/browse/FLUME-2625 Project: Flume Issue Type: Bug Components: Test Affects Versions: v1.5.0.1 Environment: RHEL 7.1 / x86_64 / Open JDK 1.7 Reporter: Tony Reix Hi, I'm working on porting FLUME in a RHEL 7.1 / PPC64LE / IBM JVM 1.7 environment. As an example, I've found that the test .source.TestSyslogUdpSource fails, but not always, only 7 times out of 10 tries. Testing on RHEL 7.1 / x86_64 / IBM JVM, I've also had random failures. Running the same .source.TestSyslogUdpSource test in RHEL 7.1 / x86_64 / Open JDK 1.7 environment, I've found that this test fails only once out of 30 tries: it is an unstable test. In order to find which test issues are specific to PPC64 or IBMJVM environment, I've run 10 times all the FLUME tests in the RHEL 7.1 / x86_64 / Open JDK 1.7 environment, which I call my reference environment. Then, using a tool that compares all the results, I've found that there are 16 tests that are unstable in my reference (x86_64/OpenJDK) . By unstable, I mean to say that the results vary, though the environment is exactly the same. These tests are: .api.TestLoadBalancingRpcClient .api.TestThriftRpcClient .channel.file.TestFileChannelRestart .channel.TestSpillableMemoryChannel .instrumentation.http.TestHTTPMetricsServer .sink.TestAvroSink .sink.TestThriftSink .source.avroLegacy.TestLegacyAvroSource .source.http.TestHTTPSource .source.TestAvroSource .source.TestExecSource .source.TestMultiportSyslogTCPSource .source.TestSyslogTcpSource .source.TestSyslogUdpSource .source.TestThriftSource .source.thriftLegacy.TestThriftLegacySource About .source.TestSyslogUdpSource test, my analysis is that the test code is not reliable since the test checks that some data is correct without checking that all the messages have arrived (sometimes, a message has not arrived in time, and a reference is NULL). Adding sleep(1000) to the test with IBM JVM, the test then failed only 3 times out of 10. So, I think that several FLUME tests are coded in a way that is not 100% reliable. Or it could also be that some core code of FLUME is not 100% reliable. I mean to say that some code may have been written based on the specific behaviour of the OpenJDK Java Virtual Machine, which was used for testing. Some change about how the order of threads are launched, or about the time needed to send messages in the JVM/OS, may lead to issues that are not correctly handled by the code (mainly test code, but maybe core code too). And it seems that, though being perfectly correct, the IBM JVM does not work the same way compared to OpenJDK. So, this is a pain. Mainly in my PPC64LE/IBMJVM environment. I think that these 16 tests must be analysed and improved. Also, running tests with OpenJDK AND IBM JVM in your development and test/Jenkins environments would help to see these random issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2622) TestLifecycleSupervisor performs excessive sleeps and no assertions
[ https://issues.apache.org/jira/browse/FLUME-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2622: Attachment: FLUME-2622-0.patch TestLifecycleSupervisor performs excessive sleeps and no assertions --- Key: FLUME-2622 URL: https://issues.apache.org/jira/browse/FLUME-2622 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Attachments: FLUME-2622-0.patch TestLifecycleSupervisor has a bunch of Thread.sleep calls (which might be excesive for some systems or insufficient for others). This makes TestLifecycleSupervisor tests unnecessarily slow. Also, it contains too few assertion, so the actual behaviour is not tested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2622) TestLifecycleSupervisor performs excessive sleeps and no assertions
Santiago M. Mola created FLUME-2622: --- Summary: TestLifecycleSupervisor performs excessive sleeps and no assertions Key: FLUME-2622 URL: https://issues.apache.org/jira/browse/FLUME-2622 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor TestLifecycleSupervisor has a bunch of Thread.sleep calls (which might be excesive for some systems or insufficient for others). This makes TestLifecycleSupervisor tests unnecessarily slow. Also, it contains too few assertion, so the actual behaviour is not tested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2620) File channel throws NullPointerException if a header value is null
Santiago M. Mola created FLUME-2620:
---
Summary: File channel throws NullPointerException if a header
value is null
Key: FLUME-2620
URL: https://issues.apache.org/jira/browse/FLUME-2620
Project: Flume
Issue Type: Bug
Components: File Channel
Reporter: Santiago M. Mola
File channel throws NullPointerException if a header value is null.
If this is intended, it should be reported correctly in the logs.
Sample trace:
org.apache.flume.ChannelException: Unable to put batch on required channel:
FileChannel chan { dataDirs: [/var/lib/ingestion-csv/chan/data] }
at
org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:200)
at
org.apache.flume.source.SpoolDirectorySource$SpoolDirectoryRunnable.run(SpoolDirectorySource.java:236)
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)
Caused by: java.lang.NullPointerException
at
org.apache.flume.channel.file.proto.ProtosFactory$FlumeEventHeader$Builder.setValue(ProtosFactory.java:7415)
at org.apache.flume.channel.file.Put.writeProtos(Put.java:85)
at
org.apache.flume.channel.file.TransactionEventRecord.toByteBuffer(TransactionEventRecord.java:174)
at org.apache.flume.channel.file.Log.put(Log.java:622)
at
org.apache.flume.channel.file.FileChannel$FileBackedTransaction.doPut(FileChannel.java:469)
at
org.apache.flume.channel.BasicTransactionSemantics.put(BasicTransactionSemantics.java:93)
at
org.apache.flume.channel.BasicChannelSemantics.put(BasicChannelSemantics.java:80)
at
org.apache.flume.channel.ChannelProcessor.processEventBatch(ChannelProcessor.java:189)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2619) Spooldir source does not log channel exceptions
Santiago M. Mola created FLUME-2619: --- Summary: Spooldir source does not log channel exceptions Key: FLUME-2619 URL: https://issues.apache.org/jira/browse/FLUME-2619 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Spooldir assumes that any ChannelException means that the channel is full and it does not log the exception message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2215) ResettableFileInputStream can't support ucs-4 character
[
https://issues.apache.org/jira/browse/FLUME-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14312495#comment-14312495
]
Santiago M. Mola commented on FLUME-2215:
-
Can someone review the smaller patch? It's here:
https://reviews.apache.org/r/16516/
[~hshreedharan]?
ResettableFileInputStream can't support ucs-4 character
Key: FLUME-2215
URL: https://issues.apache.org/jira/browse/FLUME-2215
Project: Flume
Issue Type: Bug
Affects Versions: v1.5.0
Reporter: syntony liu
Assignee: Santiago M. Mola
Priority: Critical
Labels: patch
Attachments: FLUME-2215-0-README.txt, FLUME-2215-0.patch,
FLUME-2215-1-README.txt, FLUME-2215-1.patch
ResettableFileInputStream.java:readChar() not handle ucs-4 character. it need
2 charBuf. it cause an unexpected termination。
a temporary solution:
if (res.isOverflow() !charBuf.hasRemaining()){
logger.warn(decoder ucs-4 at postion: {} , buf.position());
tmpBuf.clear();
res = decoder.decode(buf, tmpBuf, isEndOfInput);
incrPosition( buf.position() - start, false);
return '?';
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2616) Add Cassandra sink
[ https://issues.apache.org/jira/browse/FLUME-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2616: Attachment: FLUME-2616-0.patch Add Cassandra sink -- Key: FLUME-2616 URL: https://issues.apache.org/jira/browse/FLUME-2616 Project: Flume Issue Type: New Feature Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Attachments: FLUME-2616-0.patch A Cassandra sink would be a useful addition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2616) Add Cassandra sink
Santiago M. Mola created FLUME-2616: --- Summary: Add Cassandra sink Key: FLUME-2616 URL: https://issues.apache.org/jira/browse/FLUME-2616 Project: Flume Issue Type: New Feature Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola A Cassandra sink would be a useful addition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2616) Add Cassandra sink
[ https://issues.apache.org/jira/browse/FLUME-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14307527#comment-14307527 ] Santiago M. Mola commented on FLUME-2616: - Here's a Cassadra sink for Flume: https://github.com/Stratio/flume/tree/feature/cassandra-sink/flume-ng-sinks/flume-cassandra-sink This is a cleaned up / refactored version of the Stratio Cassandra Sink: https://github.com/Stratio/flume-ingestion/tree/develop/stratio-sinks/stratio-cassandra-sink Should I add a review board? Add Cassandra sink -- Key: FLUME-2616 URL: https://issues.apache.org/jira/browse/FLUME-2616 Project: Flume Issue Type: New Feature Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola A Cassandra sink would be a useful addition. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2448) Building flume from trunk failing with dependency error
[ https://issues.apache.org/jira/browse/FLUME-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239121#comment-14239121 ] Santiago M. Mola commented on FLUME-2448: - I cannot reproduce this, but I have experimented occasional network errors with JBoss repository. As far as I know, neither JBoss or Cloudera repositories are needed for Flume, so removing them would prevent this errors too. See: https://issues.apache.org/jira/browse/FLUME-2567 Building flume from trunk failing with dependency error --- Key: FLUME-2448 URL: https://issues.apache.org/jira/browse/FLUME-2448 Project: Flume Issue Type: Bug Components: Build Affects Versions: v1.5.0.1 Reporter: Ankul Rastogi I am getting a error during building Flume from source As per documentation I just cloned from git (https://git-wip-us.apache.org/repos/asf/flume.git) and ran mvn clean install -DskipTests Failing module - Flume NG Morphline Solr Sink [ERROR] Failed to execute goal on project flume-ng-morphline-solr-sink: Could not resolve dependencies for project org.apache.flume.flume-ng-sinks:flume-ng-morphline-solr-sink:jar:1.6.0-SNAPSHOT: Failed to collect dependencies at org.kitesdk:kite-morphlines-solr-core:jar:tests:0.15.0 - org.apache.solr:solr-core:jar:4.6.1 - org.apache.hadoop:hadoop-common:jar:1.0.1: Failed to read artifact descriptor for org.apache.hadoop:hadoop-common:jar:1.0.1: Could not transfer artifact org.apache.hadoop:hadoop-common:pom:1.0.1 from/to cdh.repo (https://repository.cloudera.com/artifactory/cloudera-repos): repository.cloudera.com: Unknown host repository.cloudera.com - [Help 1] Seems that the hadoop-common entries are missing from the cloudera repo. I see that there is a upgrade of kite from 0.12 - 0.15 https://git-wip-us.apache.org/repos/asf?p=flume.git;a=commit;h=49db6f59173bb9e9ae7ce671034d6562551cedf0 Is their any help that I can get on this. PS - When I reverted the kite SDK version back to 0.12 the build completed successfully -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2571) Update Kite dependency to 0.17.0 (or 0.17.1)
Santiago M. Mola created FLUME-2571: --- Summary: Update Kite dependency to 0.17.0 (or 0.17.1) Key: FLUME-2571 URL: https://issues.apache.org/jira/browse/FLUME-2571 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Fix For: v1.6.0 Flume works without any change with Kite 0.17.0. Kite 0.17.1 should be out really soon (this week?), so maybe we can wait and upgrade directly to 0.17.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2567) Remove unneeded repository declarations in pom.xml
[ https://issues.apache.org/jira/browse/FLUME-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239777#comment-14239777 ] Santiago M. Mola commented on FLUME-2567: - [~fwiffo] Yes. I've tested it on a clean environment (https://travis-ci.org/Stratio/flume/builds/42887413). Local Maven repository shold be empty before every build. Remove unneeded repository declarations in pom.xml -- Key: FLUME-2567 URL: https://issues.apache.org/jira/browse/FLUME-2567 Project: Flume Issue Type: Bug Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2567-0.patch pom.xml contains multiple repository declarations that do not seem to be needed (jboss, maven central, cloudera). Actually, it seems to me that none of these is needed. Can we remove all repository declarations and let it use just the default (Maven Central)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FLUME-2567) Remove unneeded repository declarations in pom.xml
[ https://issues.apache.org/jira/browse/FLUME-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239777#comment-14239777 ] Santiago M. Mola edited comment on FLUME-2567 at 12/9/14 6:17 PM: -- [~fwiffo] Yes. I've tested it on a clean environment (https://travis-ci.org/Stratio/flume/builds/42887413). Local Maven repository should be empty before every build. was (Author: smolav): [~fwiffo] Yes. I've tested it on a clean environment (https://travis-ci.org/Stratio/flume/builds/42887413). Local Maven repository shold be empty before every build. Remove unneeded repository declarations in pom.xml -- Key: FLUME-2567 URL: https://issues.apache.org/jira/browse/FLUME-2567 Project: Flume Issue Type: Bug Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2567-0.patch pom.xml contains multiple repository declarations that do not seem to be needed (jboss, maven central, cloudera). Actually, it seems to me that none of these is needed. Can we remove all repository declarations and let it use just the default (Maven Central)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2256) Generic JDBC Sink
[
https://issues.apache.org/jira/browse/FLUME-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232779#comment-14232779
]
Santiago M. Mola commented on FLUME-2256:
-
I haven't got time recently to work on this, but there is a work in progress to
prepare de JDBC sink for submission. It should be already functional but it
still lacks a lot of testing. Anyone interested, here's the link to the exact
branch:
https://github.com/Stratio/flume/tree/features/jdbc-sink/flume-ng-sinks/flume-ng-jdbc-sink
Generic JDBC Sink
-
Key: FLUME-2256
URL: https://issues.apache.org/jira/browse/FLUME-2256
Project: Flume
Issue Type: New Feature
Reporter: Jeremy Karlson
Assignee: Jeremy Karlson
Attachments: FLUME-2256.diff
I've been working on a generic JDBC sink. It needs a bit more testing, but I
think it's ready for review and feedback. I have not yet updated the Flume
documentation, but I can / will if people are happy with this.
Since the config file is how you’d interact with it, here’s a working example
from my source tree:
{code}
a.sinks.k.type=jdbc
a.sinks.k.channel=c
a.sinks.k.driver=com.mysql.jdbc.Driver
a.sinks.k.url=jdbc:mysql://localhost:8889/flume
a.sinks.k.user=username
a.sinks.k.password=password
a.sinks.k.batchSize=100
a.sinks.k.sql=insert into twitter (body, timestamp) values (${body:string},
${header.timestamp:long})
{code}
The interesting part is the SQL statement. You can put anything you want in
there - it will get converted to a prepared statement on execution. The
Ant-ish tokens get parsed and replaced with parameters at startup.
The tokens are three part. For example, in:
{code}
${body:string(UTF-8)}
{code}
The first is a place in the event to get the value from (“body”,
“header.foo”, or “custom”). The second part (string) is a type identifier
that converts into an appropriate JDBC parameter. The third part (“UTF-8)
is a configuration string for that type, if needed. As for types, so far
I’ve defined:
body: string (with optional charset encoding), bytearray
header: string, long, int, float, double, date (with mandatory date format
and optional timezone)
Additionally, if none of those make you happy you can define you own
parameter converters:
{code}
${custom:com.company.foo.MyConverter(optionaltextconfig)}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FLUME-2256) Generic JDBC Sink
[
https://issues.apache.org/jira/browse/FLUME-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14232779#comment-14232779
]
Santiago M. Mola edited comment on FLUME-2256 at 12/3/14 8:41 AM:
--
I haven't got time recently to work on this, but there is a work in progress to
prepare the JDBC sink for submission. It should be already functional but it
still lacks a lot of testing. Anyone interested, here's the link to the exact
branch:
https://github.com/Stratio/flume/tree/features/jdbc-sink/flume-ng-sinks/flume-ng-jdbc-sink
was (Author: smolav):
I haven't got time recently to work on this, but there is a work in progress to
prepare de JDBC sink for submission. It should be already functional but it
still lacks a lot of testing. Anyone interested, here's the link to the exact
branch:
https://github.com/Stratio/flume/tree/features/jdbc-sink/flume-ng-sinks/flume-ng-jdbc-sink
Generic JDBC Sink
-
Key: FLUME-2256
URL: https://issues.apache.org/jira/browse/FLUME-2256
Project: Flume
Issue Type: New Feature
Reporter: Jeremy Karlson
Assignee: Jeremy Karlson
Attachments: FLUME-2256.diff
I've been working on a generic JDBC sink. It needs a bit more testing, but I
think it's ready for review and feedback. I have not yet updated the Flume
documentation, but I can / will if people are happy with this.
Since the config file is how you’d interact with it, here’s a working example
from my source tree:
{code}
a.sinks.k.type=jdbc
a.sinks.k.channel=c
a.sinks.k.driver=com.mysql.jdbc.Driver
a.sinks.k.url=jdbc:mysql://localhost:8889/flume
a.sinks.k.user=username
a.sinks.k.password=password
a.sinks.k.batchSize=100
a.sinks.k.sql=insert into twitter (body, timestamp) values (${body:string},
${header.timestamp:long})
{code}
The interesting part is the SQL statement. You can put anything you want in
there - it will get converted to a prepared statement on execution. The
Ant-ish tokens get parsed and replaced with parameters at startup.
The tokens are three part. For example, in:
{code}
${body:string(UTF-8)}
{code}
The first is a place in the event to get the value from (“body”,
“header.foo”, or “custom”). The second part (string) is a type identifier
that converts into an appropriate JDBC parameter. The third part (“UTF-8)
is a configuration string for that type, if needed. As for types, so far
I’ve defined:
body: string (with optional charset encoding), bytearray
header: string, long, int, float, double, date (with mandatory date format
and optional timezone)
Additionally, if none of those make you happy you can define you own
parameter converters:
{code}
${custom:com.company.foo.MyConverter(optionaltextconfig)}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2567) Remove unneeded repository declarations in pom.xml
Santiago M. Mola created FLUME-2567: --- Summary: Remove unneeded repository declarations in pom.xml Key: FLUME-2567 URL: https://issues.apache.org/jira/browse/FLUME-2567 Project: Flume Issue Type: Bug Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 pom.xml contains multiple repository declarations that do not seem to be needed (jboss, maven central, cloudera). Actually, it seems to me that none of these is needed. Can we remove all repository declarations and let it use just the default (Maven Central)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2567) Remove unneeded repository declarations in pom.xml
[ https://issues.apache.org/jira/browse/FLUME-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2567: Attachment: FLUME-2567-0.patch Remove unneeded repository declarations in pom.xml -- Key: FLUME-2567 URL: https://issues.apache.org/jira/browse/FLUME-2567 Project: Flume Issue Type: Bug Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2567-0.patch pom.xml contains multiple repository declarations that do not seem to be needed (jboss, maven central, cloudera). Actually, it seems to me that none of these is needed. Can we remove all repository declarations and let it use just the default (Maven Central)? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2488) TestElasticSearchRestClient fails on Oracle JDK 8
[
https://issues.apache.org/jira/browse/FLUME-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219154#comment-14219154
]
Santiago M. Mola commented on FLUME-2488:
-
[~jrufus] Feel free to upload yours!
TestElasticSearchRestClient fails on Oracle JDK 8
-
Key: FLUME-2488
URL: https://issues.apache.org/jira/browse/FLUME-2488
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: jdk8
Fix For: v1.6.0
Attachments: FLUME-2488-0.patch
The JSON comparison should be performed independently of the keys order:
https://travis-ci.org/Stratio/flume/jobs/36847693#L6735
shouldAddNewEventWithoutTTL(org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient)
Time elapsed: 493 sec FAILURE!
junit.framework.ComparisonFailure:
expected:{index:{_[type:bar_type,_index:foo_index]}}
{body:test}
but was:{index:{_[index:foo_index,_type:bar_type]}}
{body:test}
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at
org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient.shouldAddNewEventWithoutTTL(TestElasticSearchRestClient.java:105)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2227) Move BlobDeserializer from Morphline Sink to flume-ng-core
[ https://issues.apache.org/jira/browse/FLUME-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2227: Component/s: Sinks+Sources Fix Version/s: v1.6.0 Move BlobDeserializer from Morphline Sink to flume-ng-core -- Key: FLUME-2227 URL: https://issues.apache.org/jira/browse/FLUME-2227 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.4.0 Reporter: Roshan Naik Assignee: Roshan Naik Fix For: v1.6.0 Attachments: FLUME-2227.1.patch, FLUME-2227.v2.patch, FLUME-2227.v3.patch This deserializer is more applicable to SpoolDir source and has no dependencies on Morphline sink. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2227) Move BlobDeserializer from Morphline Sink to flume-ng-core
[ https://issues.apache.org/jira/browse/FLUME-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14207890#comment-14207890 ] Santiago M. Mola commented on FLUME-2227: - This sounds good. Any chance this gets pulled into 1.6.0? Move BlobDeserializer from Morphline Sink to flume-ng-core -- Key: FLUME-2227 URL: https://issues.apache.org/jira/browse/FLUME-2227 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.4.0 Reporter: Roshan Naik Assignee: Roshan Naik Fix For: v1.6.0 Attachments: FLUME-2227.1.patch, FLUME-2227.v2.patch, FLUME-2227.v3.patch This deserializer is more applicable to SpoolDir source and has no dependencies on Morphline sink. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14206507#comment-14206507
]
Santiago M. Mola commented on FLUME-2487:
-
[~ashishpaliwal] Given the non-deterministic nature of the test (dependent of
the time its run), chances are that you never get this error running the test.
But the bug is clearly visible in the code: floating point numbers are not
exact and they lead to rounding errors. This is a well-known fact. Just run
this yourself:
@Test
public void testXXX() {
for (long i = 100; i 999; i++) {
float frac = Float.parseFloat(String.format(.%d, i));
float multiplied = (frac * 1000f);
long milliseconds = (long) multiplied;
if (i != milliseconds) {
System.out.println(PRECISION ERROR: + i + | + milliseconds + |
+ frac + | + multiplied);
}
}
}
Output:
PRECISION ERROR: 251 | 250 | 0.251 | 250.8
PRECISION ERROR: 253 | 252 | 0.253 | 252.8
PRECISION ERROR: 502 | 501 | 0.502 | 501.7
PRECISION ERROR: 506 | 505 | 0.506 | 505.7
PRECISION ERROR: 511 | 510 | 0.511 | 510.7
This code needs to use integer arithmetic or BigDecimal. My patch uses just
integer arithmetic, but I can write one to use BigDecimal if that's preferred.
Timestamp mismatch in TestMultiportSyslogTCPSource
--
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
Attachments: FLUME-2487-0.patch
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola updated FLUME-2487:
Attachment: (was: FLUME-2487-0.patch)
Timestamp mismatch in TestMultiportSyslogTCPSource
--
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola updated FLUME-2487:
Attachment: FLUME-2487-0.patch
Patch updated with test case that may prove the bug.
Timestamp mismatch in TestMultiportSyslogTCPSource
--
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
Attachments: FLUME-2487-0.patch
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2487) SyslogParser has rounding errors in timestamp parsing
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola updated FLUME-2487:
Summary: SyslogParser has rounding errors in timestamp parsing (was:
Timestamp mismatch in TestMultiportSyslogTCPSource)
SyslogParser has rounding errors in timestamp parsing
-
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
Attachments: FLUME-2487-0.patch
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FLUME-2516) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH
[ https://issues.apache.org/jira/browse/FLUME-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2516: Labels: easyfix easytest (was: ) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH Key: FLUME-2516 URL: https://issues.apache.org/jira/browse/FLUME-2516 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Labels: easyfix, easytest Fix For: v1.6.0 Attachments: FLUME-2516-0.patch TestElasticSearchIndexRequestBuilderFactory fails when Locale != ENGLISH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-199) Unit tests should hunt for available ports if defaults are in use
[ https://issues.apache.org/jira/browse/FLUME-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-199: --- Affects Version/s: (was: v0.9.0) v1.5.0.1 Fix Version/s: (was: v0.9.5) v1.6.0 Unit tests should hunt for available ports if defaults are in use - Key: FLUME-199 URL: https://issues.apache.org/jira/browse/FLUME-199 Project: Flume Issue Type: Improvement Components: Test Affects Versions: v1.5.0.1 Reporter: E. Sammer Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Currently, some of the unit tests fail if flume is running while tests are running. This leads to false positives in failure detection and slows down the dev cycle as one has to remember not to run flume while tests are in progress. It would be an improvement to hunt for an open port if the default port(s) are already in use during testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (FLUME-199) Unit tests should hunt for available ports if defaults are in use
[ https://issues.apache.org/jira/browse/FLUME-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reopened FLUME-199: Assignee: Santiago M. Mola Unit tests should hunt for available ports if defaults are in use - Key: FLUME-199 URL: https://issues.apache.org/jira/browse/FLUME-199 Project: Flume Issue Type: Improvement Components: Test Affects Versions: v1.5.0.1 Reporter: E. Sammer Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Currently, some of the unit tests fail if flume is running while tests are running. This leads to false positives in failure detection and slows down the dev cycle as one has to remember not to run flume while tests are in progress. It would be an improvement to hunt for an open port if the default port(s) are already in use during testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-199) Unit tests should hunt for available ports if defaults are in use
[ https://issues.apache.org/jira/browse/FLUME-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197839#comment-14197839 ] Santiago M. Mola commented on FLUME-199: Reopening this issue. I started to work on this for 1.6.0 on a branch. Unit tests should hunt for available ports if defaults are in use - Key: FLUME-199 URL: https://issues.apache.org/jira/browse/FLUME-199 Project: Flume Issue Type: Improvement Components: Test Affects Versions: v1.5.0.1 Reporter: E. Sammer Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Currently, some of the unit tests fail if flume is running while tests are running. This leads to false positives in failure detection and slows down the dev cycle as one has to remember not to run flume while tests are in progress. It would be an improvement to hunt for an open port if the default port(s) are already in use during testing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-173) Create standard unit tests for Sinks
[ https://issues.apache.org/jira/browse/FLUME-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14197858#comment-14197858 ] Santiago M. Mola commented on FLUME-173: Reopening. This is still applicable and would be a great improvement for testing. Create standard unit tests for Sinks Key: FLUME-173 URL: https://issues.apache.org/jira/browse/FLUME-173 Project: Flume Issue Type: New Feature Components: Sinks+Sources Affects Versions: v1.5.0.1 Reporter: Jonathan Hsieh Fix For: v1.6.0 Create standard tests for sinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-173) Create standard unit tests for Sinks
[ https://issues.apache.org/jira/browse/FLUME-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-173: --- Affects Version/s: (was: v0.9.4) v1.5.0.1 Fix Version/s: (was: v0.9.5) v1.6.0 Create standard unit tests for Sinks Key: FLUME-173 URL: https://issues.apache.org/jira/browse/FLUME-173 Project: Flume Issue Type: New Feature Components: Sinks+Sources Affects Versions: v1.5.0.1 Reporter: Jonathan Hsieh Fix For: v1.6.0 Create standard tests for sinks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2215) ResettableFileInputStream can't support ucs-4 character
[
https://issues.apache.org/jira/browse/FLUME-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195360#comment-14195360
]
Santiago M. Mola commented on FLUME-2215:
-
[~hshreedharan] Yes. The patch rewrites a substantial amount of code.
Alternatively, we can go with the first patch proposed by [~adutra], which is
much more limited in scope.
ResettableFileInputStream can't support ucs-4 character
Key: FLUME-2215
URL: https://issues.apache.org/jira/browse/FLUME-2215
Project: Flume
Issue Type: Bug
Affects Versions: v1.5.0
Reporter: syntony liu
Assignee: Santiago M. Mola
Priority: Critical
Labels: patch
Attachments: FLUME-2215-0-README.txt, FLUME-2215-0.patch,
FLUME-2215-1-README.txt, FLUME-2215-1.patch
ResettableFileInputStream.java:readChar() not handle ucs-4 character. it need
2 charBuf. it cause an unexpected termination。
a temporary solution:
if (res.isOverflow() !charBuf.hasRemaining()){
logger.warn(decoder ucs-4 at postion: {} , buf.position());
tmpBuf.clear();
res = decoder.decode(buf, tmpBuf, isEndOfInput);
incrPosition( buf.position() - start, false);
return '?';
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FLUME-2215) ResettableFileInputStream can't support ucs-4 character
[
https://issues.apache.org/jira/browse/FLUME-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola reassigned FLUME-2215:
---
Assignee: Santiago M. Mola
ResettableFileInputStream can't support ucs-4 character
Key: FLUME-2215
URL: https://issues.apache.org/jira/browse/FLUME-2215
Project: Flume
Issue Type: Bug
Affects Versions: v1.5.0
Reporter: syntony liu
Assignee: Santiago M. Mola
Priority: Critical
Labels: patch
Attachments: FLUME-2215-0-README.txt, FLUME-2215-0.patch,
FLUME-2215-1-README.txt, FLUME-2215-1.patch
ResettableFileInputStream.java:readChar() not handle ucs-4 character. it need
2 charBuf. it cause an unexpected termination。
a temporary solution:
if (res.isOverflow() !charBuf.hasRemaining()){
logger.warn(decoder ucs-4 at postion: {} , buf.position());
tmpBuf.clear();
res = decoder.decode(buf, tmpBuf, isEndOfInput);
incrPosition( buf.position() - start, false);
return '?';
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2531) Upgrade Thrift to 0.9.1
Santiago M. Mola created FLUME-2531: --- Summary: Upgrade Thrift to 0.9.1 Key: FLUME-2531 URL: https://issues.apache.org/jira/browse/FLUME-2531 Project: Flume Issue Type: Improvement Reporter: Santiago M. Mola Thrift 0.9+ is needed for some sinks (e.g. Cassandra) but just upgrading the dependency version breaks compilation and backwards compatibility with the Hadoop 1 profile. It would be great to find a way to update it while preserving compatibility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2215) ResettableFileInputStream can't support ucs-4 character
[
https://issues.apache.org/jira/browse/FLUME-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189940#comment-14189940
]
Santiago M. Mola commented on FLUME-2215:
-
I have updated the patch by [~adutra] and opened a Review Board request for
others to review it. It has been working for me for a couple of months without
any problem so far.
ResettableFileInputStream can't support ucs-4 character
Key: FLUME-2215
URL: https://issues.apache.org/jira/browse/FLUME-2215
Project: Flume
Issue Type: Bug
Affects Versions: v1.5.0
Reporter: syntony liu
Assignee: Santiago M. Mola
Priority: Critical
Labels: patch
Attachments: FLUME-2215-0-README.txt, FLUME-2215-0.patch,
FLUME-2215-1-README.txt, FLUME-2215-1.patch
ResettableFileInputStream.java:readChar() not handle ucs-4 character. it need
2 charBuf. it cause an unexpected termination。
a temporary solution:
if (res.isOverflow() !charBuf.hasRemaining()){
logger.warn(decoder ucs-4 at postion: {} , buf.position());
tmpBuf.clear();
res = decoder.decode(buf, tmpBuf, isEndOfInput);
incrPosition( buf.position() - start, false);
return '?';
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2529) Kafka Source test fails: testBatchTime
Santiago M. Mola created FLUME-2529: --- Summary: Kafka Source test fails: testBatchTime Key: FLUME-2529 URL: https://issues.apache.org/jira/browse/FLUME-2529 Project: Flume Issue Type: Bug Affects Versions: v1.6.0 Environment: Jenkins CI environment Reporter: Santiago M. Mola Fix For: v1.6.0 Stacktrace: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.flume.source.kafka.TestKafkaSource.testBatchTime(TestKafkaSource.java:197) Relevant log section might be: 2014-10-29 11:24:23,190 (kafka-processor-6667-2) [ERROR - kafka.utils.Logging$class.error(Logging.scala:103)] Closing socket for /127.0.0.1 because of error java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) at kafka.utils.Utils$.read(Utils.scala:375) at kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54) at kafka.network.Processor.read(SocketServer.scala:347) at kafka.network.Processor.run(SocketServer.scala:245) at java.lang.Thread.run(Thread.java:745) (Attached you'll find the full log) Note that this is being executed in an Jenkins environment with lots of other Hadoop stuff being run, so conflicts on ports (Kafka, ZooKeeper) are likely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2529) Kafka Source test fails: testBatchTime
[ https://issues.apache.org/jira/browse/FLUME-2529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2529: Attachment: failure_stdout.log Kafka Source test fails: testBatchTime -- Key: FLUME-2529 URL: https://issues.apache.org/jira/browse/FLUME-2529 Project: Flume Issue Type: Bug Affects Versions: v1.6.0 Environment: Jenkins CI environment Reporter: Santiago M. Mola Fix For: v1.6.0 Attachments: failure_stdout.log Stacktrace: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.flume.source.kafka.TestKafkaSource.testBatchTime(TestKafkaSource.java:197) Relevant log section might be: 2014-10-29 11:24:23,190 (kafka-processor-6667-2) [ERROR - kafka.utils.Logging$class.error(Logging.scala:103)] Closing socket for /127.0.0.1 because of error java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) at kafka.utils.Utils$.read(Utils.scala:375) at kafka.network.BoundedByteBufferReceive.readFrom(BoundedByteBufferReceive.scala:54) at kafka.network.Processor.read(SocketServer.scala:347) at kafka.network.Processor.run(SocketServer.scala:245) at java.lang.Thread.run(Thread.java:745) (Attached you'll find the full log) Note that this is being executed in an Jenkins environment with lots of other Hadoop stuff being run, so conflicts on ports (Kafka, ZooKeeper) are likely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2528) MalformedInputException when parsing new log file
[
https://issues.apache.org/jira/browse/FLUME-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14188238#comment-14188238
]
Santiago M. Mola commented on FLUME-2528:
-
How did you put the log file into the directory? You might need to use mv
from another directory in the same device. Otherwise, Flume could start parsing
the logfile when it is partially written.
MalformedInputException when parsing new log file
-
Key: FLUME-2528
URL: https://issues.apache.org/jira/browse/FLUME-2528
Project: Flume
Issue Type: Bug
Affects Versions: v1.5.0.1
Environment: Red Hat Enterprise Linux Server release 6.4
java version 1.6.0_45
Reporter: kext
Labels: MalformedInputException
Below is my processing steps:
1. put the log file into /home/dev/logs(configure log path)
2. start flume, the result is normal.
but, if i reverse the steps to be liked below:
1. start flume
2. put the same log file into the configure log path
then get below exception.
Exception details:
2014-10-29 17:26:47,125 (pool-3-thread-1) [ERROR -
org.apache.flume.source.SpoolDirectorySource$SpoolDirectoryRunnable.run(SpoolDirectorySource.java:256)]
FATAL: Spool Directory source src: { spoolDir: /home/dev/logs/ }: Uncaught
exception in SpoolDirectorySource thread. Restart or reconfigure Flume to
continue processing.
java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException(CoderResult.java:260)
at
org.apache.flume.serialization.ResettableFileInputStream.readChar(ResettableFileInputStream.java:195)
at
org.apache.flume.serialization.LineDeserializer.readLine(LineDeserializer.java:134)
at
org.apache.flume.serialization.LineDeserializer.readEvent(LineDeserializer.java:72)
at
org.apache.flume.serialization.LineDeserializer.readEvents(LineDeserializer.java:91)
at
org.apache.flume.client.avro.ReliableSpoolingFileEventReader.readEvents(ReliableSpoolingFileEventReader.java:238)
at
org.apache.flume.source.SpoolDirectorySource$SpoolDirectoryRunnable.run(SpoolDirectorySource.java:227)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
I really don't know the reason because the testing log files are same, and i
found that #2052# is a little similar with my issue, but i don't think that
they are same, may i know if anyone can give me some help? thanks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FLUME-2513) testConsumeFileRandomlyNewFile fails
[ https://issues.apache.org/jira/browse/FLUME-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola resolved FLUME-2513. - Resolution: Duplicate testConsumeFileRandomlyNewFile fails Key: FLUME-2513 URL: https://issues.apache.org/jira/browse/FLUME-2513 Project: Flume Issue Type: Bug Affects Versions: v1.6.0 Reporter: Santiago M. Mola Priority: Blocker Labels: test-fail Fix For: v1.6.0 TestReliableSpoolingFileEventReader.testConsumeFileRandomlyNewFile fails. This test is producing different errors on different environments and codebase versions. Here's the test output running on vanilla latest trunk with Hadoop 1 profile: 2014-10-22 12:41:25,897 (main) [DEBUG - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.init(ReliableSpoolingFileEventReader.java:138)] Initializing ReliableSpoolingFileEventReader with directory=target/test/work/TestReliableSpoolingFileEventReader, metaDir=.flumespool, deserializer=LINE 2014-10-22 12:41:25,930 (main) [DEBUG - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.init(ReliableSpoolingFileEventReader.java:160)] Successfully created and deleted canary file: target/test/work/TestReliableSpoolingFileEventReader/flume-spooldir-perm-check-2042181446777183717.canary 2014-10-22 12:41:26,180 (pool-1-thread-1) [INFO - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:343)] Preparing to move file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file2 to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file2fileSuffix 2014-10-22 12:41:26,181 (pool-1-thread-1) [DEBUG - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:379)] Successfully rolled file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file2 to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file2fileSuffix 2014-10-22 12:41:26,183 (pool-1-thread-1) [INFO - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:343)] Preparing to move file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file0 to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file0fileSuffix 2014-10-22 12:41:26,184 (pool-1-thread-1) [DEBUG - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:379)] Successfully rolled file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file0 to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file0fileSuffix 2014-10-22 12:41:26,186 (pool-1-thread-1) [INFO - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:343)] Preparing to move file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/new-file to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/new-filefileSuffix 2014-10-22 12:41:26,187 (pool-1-thread-1) [DEBUG - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:379)] Successfully rolled file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/new-file to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/new-filefileSuffix 2014-10-22 12:41:26,189 (pool-1-thread-1) [INFO - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:343)] Preparing to move file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file1 to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file1fileSuffix 2014-10-22 12:41:26,189 (pool-1-thread-1) [DEBUG - org.apache.flume.client.avro.ReliableSpoolingFileEventReader.rollCurrentFile(ReliableSpoolingFileEventReader.java:379)] Successfully rolled file /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file1 to /home/smola/dev/repos/stratio-ingestion/target/test/work/TestReliableSpoolingFileEventReader/file1fileSuffix 2014-10-22 12:41:26,191 (pool-1-thread-1) [INFO -
[jira] [Commented] (FLUME-2484) NullPointerException in Kafka Sink test
[ https://issues.apache.org/jira/browse/FLUME-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181091#comment-14181091 ] Santiago M. Mola commented on FLUME-2484: - I'm still getting this error with latest code: https://travis-ci.org/Stratio/flume/jobs/38727640#L8030 NullPointerException in Kafka Sink test --- Key: FLUME-2484 URL: https://issues.apache.org/jira/browse/FLUME-2484 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.6.0 Reporter: Santiago M. Mola Priority: Blocker Fix For: v1.6.0 Kafka Sink test fails on Travis with NullPointerException: https://travis-ci.org/Stratio/flume/jobs/36814710#L6560 Running org.apache.flume.sink.kafka.TestKafkaSink Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 17.061 sec FAILURE! testStaticTopic(org.apache.flume.sink.kafka.TestKafkaSink) Time elapsed: 1823 sec ERROR! java.lang.NullPointerException at org.apache.flume.sink.kafka.TestKafkaSink.testStaticTopic(TestKafkaSink.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Results : Tests in error: testStaticTopic(org.apache.flume.sink.kafka.TestKafkaSink) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2464) Remove hadoop-2 profile
[ https://issues.apache.org/jira/browse/FLUME-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181327#comment-14181327 ] Santiago M. Mola commented on FLUME-2464: - What about making hadoop-2 the default profile (with hbase 98) and preserve the hadoop-1 profile with an explicit property? Remove hadoop-2 profile --- Key: FLUME-2464 URL: https://issues.apache.org/jira/browse/FLUME-2464 Project: Flume Issue Type: Bug Reporter: Hari Shreedharan This profile is quite painful to maintain since there is no hbase-0.94.2 artifact against hadoop-2. Let's get rid of this since hbase-98 profile takes care of hadoop 2 builds with hbase-98 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola updated FLUME-2487:
Attachment: FLUME-2487-0.patch
Timestamp mismatch in TestMultiportSyslogTCPSource
--
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
Attachments: FLUME-2487-0.patch
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola reassigned FLUME-2487:
---
Assignee: Santiago M. Mola
Timestamp mismatch in TestMultiportSyslogTCPSource
--
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
Attachments: FLUME-2487-0.patch
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
[
https://issues.apache.org/jira/browse/FLUME-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181374#comment-14181374
]
Santiago M. Mola commented on FLUME-2487:
-
This was a precision error produced by the use of floating point arithmetic
during parsing.
Timestamp mismatch in TestMultiportSyslogTCPSource
--
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: test-fail
Fix For: v1.6.0
Attachments: FLUME-2487-0.patch
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FLUME-2480) Typo in file channel exception: Usable space exhaused
[ https://issues.apache.org/jira/browse/FLUME-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reassigned FLUME-2480: --- Assignee: Santiago M. Mola Typo in file channel exception: Usable space exhaused --- Key: FLUME-2480 URL: https://issues.apache.org/jira/browse/FLUME-2480 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Trivial Labels: easyfix, easytest Fix For: v1.6.0 Attachments: FLUME-2480-0.patch File Channel throws an IOException with a typo: Usable space exhaused instead of Usable space exhausted. This leaks to test too, with the following snippet: Assert.assertTrue(e.getMessage(), e.getMessage() .startsWith(Usable space exhaused)); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2480) Typo in file channel exception: Usable space exhaused
[ https://issues.apache.org/jira/browse/FLUME-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2480: Attachment: FLUME-2480-0.patch Typo in file channel exception: Usable space exhaused --- Key: FLUME-2480 URL: https://issues.apache.org/jira/browse/FLUME-2480 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Trivial Labels: easyfix, easytest Fix For: v1.6.0 Attachments: FLUME-2480-0.patch File Channel throws an IOException with a typo: Usable space exhaused instead of Usable space exhausted. This leaks to test too, with the following snippet: Assert.assertTrue(e.getMessage(), e.getMessage() .startsWith(Usable space exhaused)); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2510) TestHDFSEventSink.testCloseRemovesFromSFWriters fails with Hadoop 2 profile
[ https://issues.apache.org/jira/browse/FLUME-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179677#comment-14179677 ] Santiago M. Mola commented on FLUME-2510: - I'll check that and investigate the issue. TestHDFSEventSink.testCloseRemovesFromSFWriters fails with Hadoop 2 profile --- Key: FLUME-2510 URL: https://issues.apache.org/jira/browse/FLUME-2510 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Labels: test-fail Fix For: v1.6.0 testCloseRemovesFromSFWriters(org.apache.flume.sink.hdfs.TestHDFSEventSink) Time elapsed: 3520 sec FAILURE! java.lang.AssertionError [...] at org.apache.flume.sink.hdfs.TestHDFSEventSink.testCloseRemovesFromSFWriters(TestHDFSEventSink.java:1075) Failure example: https://travis-ci.org/Stratio/flume/jobs/38577036#L6323 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2514) Some TestFileChannelRestart tests are extremely slow
Santiago M. Mola created FLUME-2514: --- Summary: Some TestFileChannelRestart tests are extremely slow Key: FLUME-2514 URL: https://issues.apache.org/jira/browse/FLUME-2514 Project: Flume Issue Type: Bug Components: File Channel Reporter: Santiago M. Mola Fix For: v1.6.0 TestFileChannelRestart tests are really slow. For example, testToggleCheckpointCompressionFromFalseToTrue and testToggleCheckpointCompressionFromTrueToFalse take ~4 minutes each. Some of them could be made faster by using channels with lower capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2514) Some TestFileChannelRestart tests are extremely slow
[ https://issues.apache.org/jira/browse/FLUME-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2514: Attachment: FLUME-2215-0.patch Some TestFileChannelRestart tests are extremely slow Key: FLUME-2514 URL: https://issues.apache.org/jira/browse/FLUME-2514 Project: Flume Issue Type: Bug Components: File Channel Reporter: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2215-0.patch TestFileChannelRestart tests are really slow. For example, testToggleCheckpointCompressionFromFalseToTrue and testToggleCheckpointCompressionFromTrueToFalse take ~4 minutes each. Some of them could be made faster by using channels with lower capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FLUME-2514) Some TestFileChannelRestart tests are extremely slow
[ https://issues.apache.org/jira/browse/FLUME-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reassigned FLUME-2514: --- Assignee: Santiago M. Mola Some TestFileChannelRestart tests are extremely slow Key: FLUME-2514 URL: https://issues.apache.org/jira/browse/FLUME-2514 Project: Flume Issue Type: Bug Components: File Channel Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2215-0.patch TestFileChannelRestart tests are really slow. For example, testToggleCheckpointCompressionFromFalseToTrue and testToggleCheckpointCompressionFromTrueToFalse take ~4 minutes each. Some of them could be made faster by using channels with lower capacity. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2515) TestExecSource.testMonitoredCounterGroup sometimes fails, on some environments
Santiago M. Mola created FLUME-2515: --- Summary: TestExecSource.testMonitoredCounterGroup sometimes fails, on some environments Key: FLUME-2515 URL: https://issues.apache.org/jira/browse/FLUME-2515 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Fix For: v1.6.0 I have seen this failing on Travis with Open JDK 7. It seems it passes on different runs. I haven't checked yet, but it's probably related to execution being slower. https://travis-ci.org/Stratio/flume/jobs/38708780#L7175 testMonitoredCounterGroup(org.apache.flume.source.TestExecSource) Time elapsed: 3997 sec FAILURE! org.junit.ComparisonFailure: Expected Value: 5 expected:[5] but was:[0] at org.junit.Assert.assertEquals(Assert.java:125) at org.apache.flume.source.TestExecSource.testMonitoredCounterGroup(TestExecSource.java:273) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2516) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH
Santiago M. Mola created FLUME-2516: --- Summary: TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH Key: FLUME-2516 URL: https://issues.apache.org/jira/browse/FLUME-2516 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 TestElasticSearchIndexRequestBuilderFactory fails when Locale != ENGLISH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2516) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH
[ https://issues.apache.org/jira/browse/FLUME-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2516: Attachment: FLUME-2516-0.patch TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH Key: FLUME-2516 URL: https://issues.apache.org/jira/browse/FLUME-2516 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2516-0.patch TestElasticSearchIndexRequestBuilderFactory fails when Locale != ENGLISH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2516) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH
[ https://issues.apache.org/jira/browse/FLUME-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2516: Attachment: FLUME-2516-0.patch TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH Key: FLUME-2516 URL: https://issues.apache.org/jira/browse/FLUME-2516 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2516-0.patch TestElasticSearchIndexRequestBuilderFactory fails when Locale != ENGLISH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2516) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH
[ https://issues.apache.org/jira/browse/FLUME-2516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2516: Attachment: (was: FLUME-2516-0.patch) TestElasticSearchIndexRequestBuilderFactory fails with Locale != ENGLISH Key: FLUME-2516 URL: https://issues.apache.org/jira/browse/FLUME-2516 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 TestElasticSearchIndexRequestBuilderFactory fails when Locale != ENGLISH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2488) TestElasticSearchRestClient fails on Oracle JDK 8
[
https://issues.apache.org/jira/browse/FLUME-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14180049#comment-14180049
]
Santiago M. Mola commented on FLUME-2488:
-
This patch should solve the problem and be backwards compatible.
TestElasticSearchRestClient fails on Oracle JDK 8
-
Key: FLUME-2488
URL: https://issues.apache.org/jira/browse/FLUME-2488
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Labels: jdk8
Fix For: v1.6.0
Attachments: FLUME-2488-0.patch
The JSON comparison should be performed independently of the keys order:
https://travis-ci.org/Stratio/flume/jobs/36847693#L6735
shouldAddNewEventWithoutTTL(org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient)
Time elapsed: 493 sec FAILURE!
junit.framework.ComparisonFailure:
expected:{index:{_[type:bar_type,_index:foo_index]}}
{body:test}
but was:{index:{_[index:foo_index,_type:bar_type]}}
{body:test}
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at
org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient.shouldAddNewEventWithoutTTL(TestElasticSearchRestClient.java:105)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (FLUME-2488) TestElasticSearchRestClient fails on Oracle JDK 8
[
https://issues.apache.org/jira/browse/FLUME-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola reassigned FLUME-2488:
---
Assignee: Santiago M. Mola
TestElasticSearchRestClient fails on Oracle JDK 8
-
Key: FLUME-2488
URL: https://issues.apache.org/jira/browse/FLUME-2488
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Assignee: Santiago M. Mola
Labels: jdk8
Fix For: v1.6.0
Attachments: FLUME-2488-0.patch
The JSON comparison should be performed independently of the keys order:
https://travis-ci.org/Stratio/flume/jobs/36847693#L6735
shouldAddNewEventWithoutTTL(org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient)
Time elapsed: 493 sec FAILURE!
junit.framework.ComparisonFailure:
expected:{index:{_[type:bar_type,_index:foo_index]}}
{body:test}
but was:{index:{_[index:foo_index,_type:bar_type]}}
{body:test}
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at
org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient.shouldAddNewEventWithoutTTL(TestElasticSearchRestClient.java:105)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2510) TestHDFSEventSink.testCloseRemovesFromSFWriters fails with Hadoop 2 profile
Santiago M. Mola created FLUME-2510: --- Summary: TestHDFSEventSink.testCloseRemovesFromSFWriters fails with Hadoop 2 profile Key: FLUME-2510 URL: https://issues.apache.org/jira/browse/FLUME-2510 Project: Flume Issue Type: Bug Components: Sinks+Sources Reporter: Santiago M. Mola Fix For: v1.6.0 testCloseRemovesFromSFWriters(org.apache.flume.sink.hdfs.TestHDFSEventSink) Time elapsed: 3520 sec FAILURE! java.lang.AssertionError [...] at org.apache.flume.sink.hdfs.TestHDFSEventSink.testCloseRemovesFromSFWriters(TestHDFSEventSink.java:1075) Failure example: https://travis-ci.org/Stratio/flume/jobs/38577036#L6323 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2475) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum
[ https://issues.apache.org/jira/browse/FLUME-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2475: Attachment: (was: FLUME-2475-0.patch) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum Key: FLUME-2475 URL: https://issues.apache.org/jira/browse/FLUME-2475 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 .toLowerCase() / .toUpperCase() is used intensively in Flume's code base without passing Locale.ENGLISH to it. This breaks Flume depending on the system locale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2475) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum
[ https://issues.apache.org/jira/browse/FLUME-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2475: Attachment: FLUME-2475-0.patch Sorry for the delay. Here's the updated patch. toLowerCase/toUpperCase used without Locale parameter to manipulate Enum Key: FLUME-2475 URL: https://issues.apache.org/jira/browse/FLUME-2475 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2475-0.patch .toLowerCase() / .toUpperCase() is used intensively in Flume's code base without passing Locale.ENGLISH to it. This breaks Flume depending on the system locale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2490) HBase tests hang up forever if hostname points to 127.0.1.1
[ https://issues.apache.org/jira/browse/FLUME-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166521#comment-14166521 ] Santiago M. Mola commented on FLUME-2490: - Ideally tests would be omitted instead of passed. Anyway, I'm working towards a more general solution with integration tests. It's still a work in progress in this branch: https://github.com/Stratio/flume/tree/feature/integration-test HBase tests hang up forever if hostname points to 127.0.1.1 --- Key: FLUME-2490 URL: https://issues.apache.org/jira/browse/FLUME-2490 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 HBase tests hang up forever if hostname points to 127.0.1.1 instead of 127.0.0.1. It would be nice if this circumstance was detected during tests set up and the affected tests were ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2483) TestLog.testMinimumRequiredSpaceTooSmallForPut failing
[ https://issues.apache.org/jira/browse/FLUME-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166526#comment-14166526 ] Santiago M. Mola commented on FLUME-2483: - I don't know. This patch works for my environmnet (local and Travis CI) but a definitive solution would involve some mocking/reflection to simulate a full filesystem reliably. I'll give it a try. TestLog.testMinimumRequiredSpaceTooSmallForPut failing -- Key: FLUME-2483 URL: https://issues.apache.org/jira/browse/FLUME-2483 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2483-0.patch This test is failing when it runs on Travis CI. I haven't been able to further debug it yet. https://travis-ci.org/Stratio/flume/jobs/36758319#L6178 testMinimumRequiredSpaceTooSmallForPut(org.apache.flume.channel.file.TestLog) Time elapsed: 792 sec ERROR! java.io.IOException: Usable space exhaused, only 225056866304 bytes remaining, required 225106210816 bytes at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:985) at org.apache.flume.channel.file.Log.replay(Log.java:488) at org.apache.flume.channel.file.TestLog.doTestMinimumRequiredSpaceTooSmallForPut(TestLog.java:202) at org.apache.flume.channel.file.TestLog.testMinimumRequiredSpaceTooSmallForPut(TestLog.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FLUME-2483) TestLog.testMinimumRequiredSpaceTooSmallForPut failing
[ https://issues.apache.org/jira/browse/FLUME-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reassigned FLUME-2483: --- Assignee: Santiago M. Mola TestLog.testMinimumRequiredSpaceTooSmallForPut failing -- Key: FLUME-2483 URL: https://issues.apache.org/jira/browse/FLUME-2483 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2483-0.patch This test is failing when it runs on Travis CI. I haven't been able to further debug it yet. https://travis-ci.org/Stratio/flume/jobs/36758319#L6178 testMinimumRequiredSpaceTooSmallForPut(org.apache.flume.channel.file.TestLog) Time elapsed: 792 sec ERROR! java.io.IOException: Usable space exhaused, only 225056866304 bytes remaining, required 225106210816 bytes at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:985) at org.apache.flume.channel.file.Log.replay(Log.java:488) at org.apache.flume.channel.file.TestLog.doTestMinimumRequiredSpaceTooSmallForPut(TestLog.java:202) at org.apache.flume.channel.file.TestLog.testMinimumRequiredSpaceTooSmallForPut(TestLog.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2474) TestHDFSEventSinkOnMiniCluster fails if user umask is not 0022
[ https://issues.apache.org/jira/browse/FLUME-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166528#comment-14166528 ] Santiago M. Mola commented on FLUME-2474: - I was building against hadoop-1 profile. I'm now building against all profiles. I'll try to come up with a general solution. TestHDFSEventSinkOnMiniCluster fails if user umask is not 0022 -- Key: FLUME-2474 URL: https://issues.apache.org/jira/browse/FLUME-2474 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1, v1.6.0 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Labels: patch Fix For: v1.6.0 Attachments: 0003-Ensure-proper-file-permissions-on-TestHDFSEventSinkO.patch MiniDFSCluster requires DFS_DIR to have rwxr-x-r-x permissions recursively. That is usually achieved by having umask set to 0022, but that's not convenient for tests. I'm attaching a patch to solve the problem using setfacl. Here's the error log: Running org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster Tests run: 4, Failures: 0, Errors: 3, Skipped: 1, Time elapsed: 10.23 sec FAILURE! simpleHDFSTest(org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster) Time elapsed: 9473 sec ERROR! java.lang.NullPointerException at org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:422) at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:280) at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:124) at org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster.simpleHDFSTest(TestHDFSEventSinkOnMiniCluster.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2483) TestLog.testMinimumRequiredSpaceTooSmallForPut failing
[ https://issues.apache.org/jira/browse/FLUME-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14167732#comment-14167732 ] Santiago M. Mola commented on FLUME-2483: - Sounds good. TestLog.testMinimumRequiredSpaceTooSmallForPut failing -- Key: FLUME-2483 URL: https://issues.apache.org/jira/browse/FLUME-2483 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2483-0.patch This test is failing when it runs on Travis CI. I haven't been able to further debug it yet. https://travis-ci.org/Stratio/flume/jobs/36758319#L6178 testMinimumRequiredSpaceTooSmallForPut(org.apache.flume.channel.file.TestLog) Time elapsed: 792 sec ERROR! java.io.IOException: Usable space exhaused, only 225056866304 bytes remaining, required 225106210816 bytes at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:985) at org.apache.flume.channel.file.Log.replay(Log.java:488) at org.apache.flume.channel.file.TestLog.doTestMinimumRequiredSpaceTooSmallForPut(TestLog.java:202) at org.apache.flume.channel.file.TestLog.testMinimumRequiredSpaceTooSmallForPut(TestLog.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2485) Thrift Source tests fail on Oracle JDK 8
[ https://issues.apache.org/jira/browse/FLUME-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2485: Labels: jdk8 (was: ) Thrift Source tests fail on Oracle JDK 8 Key: FLUME-2485 URL: https://issues.apache.org/jira/browse/FLUME-2485 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.6.0 Reporter: Santiago M. Mola Labels: jdk8 Fix For: v1.6.0 Thrift Source tests fail on Oracle JDK 8: https://travis-ci.org/Stratio/flume/jobs/36817396#L6245 testAppendBatch(org.apache.flume.source.TestThriftSource) Time elapsed: 6083 sec FAILURE! java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.flume.source.TestThriftSource.testAppendBatch(TestThriftSource.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2488) TestElasticSearchRestClient fails on Oracle JDK 8
[
https://issues.apache.org/jira/browse/FLUME-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santiago M. Mola updated FLUME-2488:
Labels: jdk8 (was: )
TestElasticSearchRestClient fails on Oracle JDK 8
-
Key: FLUME-2488
URL: https://issues.apache.org/jira/browse/FLUME-2488
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Labels: jdk8
Fix For: v1.6.0
The JSON comparison should be performed independently of the keys order:
https://travis-ci.org/Stratio/flume/jobs/36847693#L6735
shouldAddNewEventWithoutTTL(org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient)
Time elapsed: 493 sec FAILURE!
junit.framework.ComparisonFailure:
expected:{index:{_[type:bar_type,_index:foo_index]}}
{body:test}
but was:{index:{_[index:foo_index,_type:bar_type]}}
{body:test}
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at
org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient.shouldAddNewEventWithoutTTL(TestElasticSearchRestClient.java:105)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2490) HBase tests hang up forever if hostname points to 127.0.1.1
[ https://issues.apache.org/jira/browse/FLUME-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14157952#comment-14157952 ] Santiago M. Mola commented on FLUME-2490: - HBase server needs that hostname points to 127.0.0.1. So it's the embedded HBase server used in tests the one that is getting into an infinite loop during initialization. I don't think this can be solved on our side. We can mitigate the problem by ignoring the environment if it is not suited for running the test. As an alternative, I'm working on a integration-test branch where these test run with an external HBase server. HBase tests hang up forever if hostname points to 127.0.1.1 --- Key: FLUME-2490 URL: https://issues.apache.org/jira/browse/FLUME-2490 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 HBase tests hang up forever if hostname points to 127.0.1.1 instead of 127.0.0.1. It would be nice if this circumstance was detected during tests set up and the affected tests were ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2475) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum
[ https://issues.apache.org/jira/browse/FLUME-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2475: Assignee: Santiago M. Mola toLowerCase/toUpperCase used without Locale parameter to manipulate Enum Key: FLUME-2475 URL: https://issues.apache.org/jira/browse/FLUME-2475 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2475-0.patch .toLowerCase() / .toUpperCase() is used intensively in Flume's code base without passing Locale.ENGLISH to it. This breaks Flume depending on the system locale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FLUME-2474) TestHDFSEventSinkOnMiniCluster fails if user umask is not 0022
[ https://issues.apache.org/jira/browse/FLUME-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reassigned FLUME-2474: --- Assignee: Santiago M. Mola TestHDFSEventSinkOnMiniCluster fails if user umask is not 0022 -- Key: FLUME-2474 URL: https://issues.apache.org/jira/browse/FLUME-2474 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1, v1.6.0 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Labels: patch Fix For: v1.6.0 Attachments: 0003-Ensure-proper-file-permissions-on-TestHDFSEventSinkO.patch MiniDFSCluster requires DFS_DIR to have rwxr-x-r-x permissions recursively. That is usually achieved by having umask set to 0022, but that's not convenient for tests. I'm attaching a patch to solve the problem using setfacl. Here's the error log: Running org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster Tests run: 4, Failures: 0, Errors: 3, Skipped: 1, Time elapsed: 10.23 sec FAILURE! simpleHDFSTest(org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster) Time elapsed: 9473 sec ERROR! java.lang.NullPointerException at org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:422) at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:280) at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:124) at org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster.simpleHDFSTest(TestHDFSEventSinkOnMiniCluster.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FLUME-2472) SyslogUtils fails when system locale is not English
[ https://issues.apache.org/jira/browse/FLUME-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reassigned FLUME-2472: --- Assignee: Santiago M. Mola SyslogUtils fails when system locale is not English --- Key: FLUME-2472 URL: https://issues.apache.org/jira/browse/FLUME-2472 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1, v1.6.0 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Labels: patch Fix For: v1.6.0 Attachments: 0002-Force-English-Locale-on-SyslogUtils.patch SyslogUtils tests will fail if system locale is not English: TestHeader9(org.apache.flume.source.TestSyslogUtils) Time elapsed: 4 sec ERROR! java.text.ParseException: Unparseable date: 2014Apr 11 13:14:04 at java.text.DateFormat.parse(DateFormat.java:357) at org.apache.flume.source.TestSyslogUtils.checkHeader(TestSyslogUtils.java:188) at org.apache.flume.source.TestSyslogUtils.checkHeader(TestSyslogUtils.java:202) at org.apache.flume.source.TestSyslogUtils.TestHeader9(TestSyslogUtils.java:138) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) TestHeader10(org.apache.flume.source.TestSyslogUtils) Time elapsed: 2 sec ERROR! java.text.ParseException: Unparseable date: 2014Apr 1 13:14:04 at java.text.DateFormat.parse(DateFormat.java:357) at org.apache.flume.source.TestSyslogUtils.checkHeader(TestSyslogUtils.java:188) at org.apache.flume.source.TestSyslogUtils.checkHeader(TestSyslogUtils.java:202) at org.apache.flume.source.TestSyslogUtils.TestHeader10(TestSyslogUtils.java:150) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at
[jira] [Created] (FLUME-2486) TestExecSource fails on some environments
Santiago M. Mola created FLUME-2486: --- Summary: TestExecSource fails on some environments Key: FLUME-2486 URL: https://issues.apache.org/jira/browse/FLUME-2486 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Fix For: v1.6.0 This seems to occur on slow platforms (e.g. Travis). A workaround already existed for Windows. https://travis-ci.org/Stratio/flume/jobs/36817397#L6143 testShellCommandSimple(org.apache.flume.source.TestExecSource) Time elapsed: 1254 sec FAILURE! java.lang.AssertionError: array lengths differed, expected.length=5 actual.length=0 at org.junit.Assert.fail(Assert.java:93) at org.junit.internal.ComparisonCriteria.assertArraysAreSameLength(ComparisonCriteria.java:70) at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:34) at org.junit.Assert.internalArrayEquals(Assert.java:416) at org.junit.Assert.assertArrayEquals(Assert.java:168) at org.junit.Assert.assertArrayEquals(Assert.java:185) at org.apache.flume.source.TestExecSource.runTestShellCmdHelper(TestExecSource.java:360) at org.apache.flume.source.TestExecSource.testShellCommandSimple(TestExecSource.java:152) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2487) Timestamp mismatch in TestMultiportSyslogTCPSource
Santiago M. Mola created FLUME-2487:
---
Summary: Timestamp mismatch in TestMultiportSyslogTCPSource
Key: FLUME-2487
URL: https://issues.apache.org/jira/browse/FLUME-2487
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Fix For: v1.6.0
https://travis-ci.org/Stratio/flume/jobs/36847695#L6180
{noformat}
testMultiplePorts(org.apache.flume.source.TestMultiportSyslogTCPSource) Time
elapsed: 2465 sec FAILURE!
org.junit.ComparisonFailure: Timestamps must match expected:141223934050[2]
but was:141223934050[1]
at org.junit.Assert.assertEquals(Assert.java:125)
at
org.apache.flume.source.TestMultiportSyslogTCPSource.testMultiplePorts(TestMultiportSyslogTCPSource.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2488) TestElasticSearchRestClient fails on Oracle JDK 8
Santiago M. Mola created FLUME-2488:
---
Summary: TestElasticSearchRestClient fails on Oracle JDK 8
Key: FLUME-2488
URL: https://issues.apache.org/jira/browse/FLUME-2488
Project: Flume
Issue Type: Bug
Components: Sinks+Sources
Affects Versions: v1.5.0.1
Reporter: Santiago M. Mola
Fix For: v1.6.0
The JSON comparison should be performed independently of the keys order:
https://travis-ci.org/Stratio/flume/jobs/36847693#L6735
shouldAddNewEventWithoutTTL(org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient)
Time elapsed: 493 sec FAILURE!
junit.framework.ComparisonFailure:
expected:{index:{_[type:bar_type,_index:foo_index]}}
{body:test}
but was:{index:{_[index:foo_index,_type:bar_type]}}
{body:test}
at junit.framework.Assert.assertEquals(Assert.java:85)
at junit.framework.Assert.assertEquals(Assert.java:91)
at
org.apache.flume.sink.elasticsearch.client.TestElasticSearchRestClient.shouldAddNewEventWithoutTTL(TestElasticSearchRestClient.java:105)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FLUME-2474) TestHDFSEventSinkOnMiniCluster fails if user umask is not 0022
[ https://issues.apache.org/jira/browse/FLUME-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14156289#comment-14156289 ] Santiago M. Mola commented on FLUME-2474: - Note that this fix is not portable, so it's not ready to be included. TestHDFSEventSinkOnMiniCluster fails if user umask is not 0022 -- Key: FLUME-2474 URL: https://issues.apache.org/jira/browse/FLUME-2474 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1, v1.6.0 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Labels: patch Fix For: v1.6.0 Attachments: 0003-Ensure-proper-file-permissions-on-TestHDFSEventSinkO.patch MiniDFSCluster requires DFS_DIR to have rwxr-x-r-x permissions recursively. That is usually achieved by having umask set to 0022, but that's not convenient for tests. I'm attaching a patch to solve the problem using setfacl. Here's the error log: Running org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster Tests run: 4, Failures: 0, Errors: 3, Skipped: 1, Time elapsed: 10.23 sec FAILURE! simpleHDFSTest(org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster) Time elapsed: 9473 sec ERROR! java.lang.NullPointerException at org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:422) at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:280) at org.apache.hadoop.hdfs.MiniDFSCluster.init(MiniDFSCluster.java:124) at org.apache.flume.sink.hdfs.TestHDFSEventSinkOnMiniCluster.simpleHDFSTest(TestHDFSEventSinkOnMiniCluster.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2482) Race condition in File Channels' Log.removeOldLogs
[ https://issues.apache.org/jira/browse/FLUME-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14156294#comment-14156294 ] Santiago M. Mola commented on FLUME-2482: - I've got no patch yet. But yes, it seems a bug in the test: it is forcing a checkpoint while Log is already checkpointing in a different thread. Race condition in File Channels' Log.removeOldLogs -- Key: FLUME-2482 URL: https://issues.apache.org/jira/browse/FLUME-2482 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Labels: race-condition Fix For: v1.6.0 TestFileChannelRestart.testToggleCheckpointCompressionFromFalseToTrue sometimes produces a race condition at Log.removeOldLogs. https://travis-ci.org/Stratio/flume/jobs/36782318#L6193 testToggleCheckpointCompressionFromFalseToTrue(org.apache.flume.channel.file.TestFileChannelRestart) Time elapsed: 144362 sec ERROR! java.util.ConcurrentModificationException at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859) at java.util.ArrayList$Itr.next(ArrayList.java:831) at org.apache.flume.channel.file.Log.removeOldLogs(Log.java:1070) at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:1055) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.fest.reflect.method.Invoker.invoke(Invoker.java:110) at org.apache.flume.channel.file.TestUtils.forceCheckpoint(TestUtils.java:134) at org.apache.flume.channel.file.TestFileChannelRestart.restartToggleCompression(TestFileChannelRestart.java:930) at org.apache.flume.channel.file.TestFileChannelRestart.testToggleCheckpointCompressionFromFalseToTrue(TestFileChannelRestart.java:896) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2483) TestLog.testMinimumRequiredSpaceTooSmallForPut failing
[ https://issues.apache.org/jira/browse/FLUME-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2483: Attachment: FLUME-2483-0.patch TestLog.testMinimumRequiredSpaceTooSmallForPut failing -- Key: FLUME-2483 URL: https://issues.apache.org/jira/browse/FLUME-2483 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2483-0.patch This test is failing when it runs on Travis CI. I haven't been able to further debug it yet. https://travis-ci.org/Stratio/flume/jobs/36758319#L6178 testMinimumRequiredSpaceTooSmallForPut(org.apache.flume.channel.file.TestLog) Time elapsed: 792 sec ERROR! java.io.IOException: Usable space exhaused, only 225056866304 bytes remaining, required 225106210816 bytes at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:985) at org.apache.flume.channel.file.Log.replay(Log.java:488) at org.apache.flume.channel.file.TestLog.doTestMinimumRequiredSpaceTooSmallForPut(TestLog.java:202) at org.apache.flume.channel.file.TestLog.testMinimumRequiredSpaceTooSmallForPut(TestLog.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2483) TestLog.testMinimumRequiredSpaceTooSmallForPut failing
[ https://issues.apache.org/jira/browse/FLUME-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14156298#comment-14156298 ] Santiago M. Mola commented on FLUME-2483: - The attached patch avoided the problem so far in my builds. The problem could pop up again in some environments (if somethis is writing a lot data to the same partition where tests are run) but this has been enough for me. TestLog.testMinimumRequiredSpaceTooSmallForPut failing -- Key: FLUME-2483 URL: https://issues.apache.org/jira/browse/FLUME-2483 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Fix For: v1.6.0 Attachments: FLUME-2483-0.patch This test is failing when it runs on Travis CI. I haven't been able to further debug it yet. https://travis-ci.org/Stratio/flume/jobs/36758319#L6178 testMinimumRequiredSpaceTooSmallForPut(org.apache.flume.channel.file.TestLog) Time elapsed: 792 sec ERROR! java.io.IOException: Usable space exhaused, only 225056866304 bytes remaining, required 225106210816 bytes at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:985) at org.apache.flume.channel.file.Log.replay(Log.java:488) at org.apache.flume.channel.file.TestLog.doTestMinimumRequiredSpaceTooSmallForPut(TestLog.java:202) at org.apache.flume.channel.file.TestLog.testMinimumRequiredSpaceTooSmallForPut(TestLog.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2286) Upgrade Guava version to 14.0.1
[
https://issues.apache.org/jira/browse/FLUME-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14156363#comment-14156363
]
Santiago M. Mola commented on FLUME-2286:
-
I'm currently testing Guava 17.0. It requires upgrading some other dependencies
but it should be good.
Upgrade Guava version to 14.0.1
---
Key: FLUME-2286
URL: https://issues.apache.org/jira/browse/FLUME-2286
Project: Flume
Issue Type: Wish
Affects Versions: v1.5.0
Reporter: Joshua Hyde
Priority: Minor
Labels: patch
Attachments: FLUME-2286.patch
I wrote a custom Sink as a Flume plugin that uses code that leverages the
{{CacheBuilder}} class provided by Guava. The problem was that my code uses
Guava 14.0.1, and I ended up with this error:
{noformat}
31 Dec 2013 11:11:45,071 ERROR
[SinkRunner-PollingRunner-DefaultSinkProcessor]
(my.package.CustomSink.process:104) - Failed to process events.
java.lang.NoSuchMethodError:
com.google.common.cache.CacheBuilder.maximumSize(J)Lcom/google/common/cache/CacheBuilder;
at my.package.CustomSink.process(CustomSink.java:90)
at
org.apache.flume.sink.DefaultSinkProcessor.process(DefaultSinkProcessor.java:68)
at org.apache.flume.SinkRunner$PollingRunner.run(SinkRunner.java:147)
at java.lang.Thread.run(Thread.java:744)
{noformat}
Thankfully, I have direct control over the code that uses Guava 14.0.1 and
can download it to the version used by Flume (10.0.1 at time of writing
this), but it'd be nice if I didn't have to downgrade my code base for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2489) Upgrade Apache Curator to 2.6.0
Santiago M. Mola created FLUME-2489: --- Summary: Upgrade Apache Curator to 2.6.0 Key: FLUME-2489 URL: https://issues.apache.org/jira/browse/FLUME-2489 Project: Flume Issue Type: Bug Components: Node Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 This is required in order to upgrade Guava. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FLUME-2489) Upgrade Apache Curator to 2.6.0
[ https://issues.apache.org/jira/browse/FLUME-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola reassigned FLUME-2489: --- Assignee: Santiago M. Mola Upgrade Apache Curator to 2.6.0 --- Key: FLUME-2489 URL: https://issues.apache.org/jira/browse/FLUME-2489 Project: Flume Issue Type: Bug Components: Node Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 This is required in order to upgrade Guava. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2489) Upgrade Apache Curator to 2.6.0
[ https://issues.apache.org/jira/browse/FLUME-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2489: Attachment: FLUME-2489-0.patch Upgrade Apache Curator to 2.6.0 --- Key: FLUME-2489 URL: https://issues.apache.org/jira/browse/FLUME-2489 Project: Flume Issue Type: Bug Components: Node Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Assignee: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2489-0.patch This is required in order to upgrade Guava. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2286) Upgrade Guava version to 14.0.1
[
https://issues.apache.org/jira/browse/FLUME-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14156583#comment-14156583
]
Santiago M. Mola commented on FLUME-2286:
-
It seems there are major stoppers for Guava 11.0.1.
hadoop-minicluster depends on guava 11.0.1 and it is used in
flume-ng-hbase-sink tests. Testing with the hbase-98 profile will fail:
{noformat}
org.apache.flume.sink.hbase.TestAsyncHBaseSink Time elapsed: 1839 sec
ERROR!
java.lang.NoClassDefFoundError: com/google/common/io/LimitInputStream
at
org.apache.hadoop.hdfs.server.namenode.FSImageFormat$LoaderDelegator.load(FSImageFormat.java:118)
{noformat}
Upgrade Guava version to 14.0.1
---
Key: FLUME-2286
URL: https://issues.apache.org/jira/browse/FLUME-2286
Project: Flume
Issue Type: Wish
Affects Versions: v1.5.0
Reporter: Joshua Hyde
Priority: Minor
Labels: patch
Attachments: FLUME-2286.patch
I wrote a custom Sink as a Flume plugin that uses code that leverages the
{{CacheBuilder}} class provided by Guava. The problem was that my code uses
Guava 14.0.1, and I ended up with this error:
{noformat}
31 Dec 2013 11:11:45,071 ERROR
[SinkRunner-PollingRunner-DefaultSinkProcessor]
(my.package.CustomSink.process:104) - Failed to process events.
java.lang.NoSuchMethodError:
com.google.common.cache.CacheBuilder.maximumSize(J)Lcom/google/common/cache/CacheBuilder;
at my.package.CustomSink.process(CustomSink.java:90)
at
org.apache.flume.sink.DefaultSinkProcessor.process(DefaultSinkProcessor.java:68)
at org.apache.flume.SinkRunner$PollingRunner.run(SinkRunner.java:147)
at java.lang.Thread.run(Thread.java:744)
{noformat}
Thankfully, I have direct control over the code that uses Guava 14.0.1 and
can download it to the version used by Flume (10.0.1 at time of writing
this), but it'd be nice if I didn't have to downgrade my code base for this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FLUME-2490) HBase tests hang up forever if hostname points to 127.0.1.1
Santiago M. Mola created FLUME-2490: --- Summary: HBase tests hang up forever if hostname points to 127.0.1.1 Key: FLUME-2490 URL: https://issues.apache.org/jira/browse/FLUME-2490 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 HBase tests hang up forever if hostname points to 127.0.1.1 instead of 127.0.0.1. It would be nice if this circumstance was detected during tests set up and the affected tests were ignored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2480) Typo in file channel exception: Usable space exhaused
Santiago M. Mola created FLUME-2480: --- Summary: Typo in file channel exception: Usable space exhaused Key: FLUME-2480 URL: https://issues.apache.org/jira/browse/FLUME-2480 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Trivial Fix For: v1.6.0 File Channel throws an IOException with a typo: Usable space exhaused instead of Usable space exhausted. This leaks to test too, with the following snippet: Assert.assertTrue(e.getMessage(), e.getMessage() .startsWith(Usable space exhaused)); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2481) TestFileChannelEncryption fails with System locale other than en_US
Santiago M. Mola created FLUME-2481: --- Summary: TestFileChannelEncryption fails with System locale other than en_US Key: FLUME-2481 URL: https://issues.apache.org/jira/browse/FLUME-2481 Project: Flume Issue Type: Bug Reporter: Santiago M. Mola Priority: Minor Tests check for exception messages that are locale-dependent, so they fail when system locale is not en_US. Relevant code: Assert.assertEquals(java.io.FileNotFoundException: /path/does/not/exist + (No such file or directory), ex.getMessage().startsWith()); Exception: testMissingKeyStorePasswordFile(org.apache.flume.channel.file.encryption.TestFileChannelEncryption) Time elapsed: 2 sec FAILURE! org.junit.ComparisonFailure: expected:.../does/not/exist (No [such file or directory]) but was:.../does/not/exist (No [existe el archivo o el directorio]) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.flume.channel.file.encryption.TestFileChannelEncryption.testMissingKeyStorePasswordFile(TestFileChannelEncryption.java:325) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2481) TestFileChannelEncryption fails with System locale other than en_US
[ https://issues.apache.org/jira/browse/FLUME-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2481: Attachment: FLUME-2481-0.patch TestFileChannelEncryption fails with System locale other than en_US --- Key: FLUME-2481 URL: https://issues.apache.org/jira/browse/FLUME-2481 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2481-0.patch Tests check for exception messages that are locale-dependent, so they fail when system locale is not en_US. Relevant code: Assert.assertEquals(java.io.FileNotFoundException: /path/does/not/exist + (No such file or directory), ex.getMessage().startsWith()); Exception: testMissingKeyStorePasswordFile(org.apache.flume.channel.file.encryption.TestFileChannelEncryption) Time elapsed: 2 sec FAILURE! org.junit.ComparisonFailure: expected:.../does/not/exist (No [such file or directory]) but was:.../does/not/exist (No [existe el archivo o el directorio]) at org.junit.Assert.assertEquals(Assert.java:125) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.flume.channel.file.encryption.TestFileChannelEncryption.testMissingKeyStorePasswordFile(TestFileChannelEncryption.java:325) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2482) Race condition in File Channels' Log.removeOldLogs
Santiago M. Mola created FLUME-2482: --- Summary: Race condition in File Channels' Log.removeOldLogs Key: FLUME-2482 URL: https://issues.apache.org/jira/browse/FLUME-2482 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Fix For: v1.6.0 TestFileChannelRestart.testToggleCheckpointCompressionFromFalseToTrue sometimes produces a race condition at Log.removeOldLogs. https://travis-ci.org/Stratio/flume/jobs/36782318#L6193 testToggleCheckpointCompressionFromFalseToTrue(org.apache.flume.channel.file.TestFileChannelRestart) Time elapsed: 144362 sec ERROR! java.util.ConcurrentModificationException at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859) at java.util.ArrayList$Itr.next(ArrayList.java:831) at org.apache.flume.channel.file.Log.removeOldLogs(Log.java:1070) at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:1055) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.fest.reflect.method.Invoker.invoke(Invoker.java:110) at org.apache.flume.channel.file.TestUtils.forceCheckpoint(TestUtils.java:134) at org.apache.flume.channel.file.TestFileChannelRestart.restartToggleCompression(TestFileChannelRestart.java:930) at org.apache.flume.channel.file.TestFileChannelRestart.testToggleCheckpointCompressionFromFalseToTrue(TestFileChannelRestart.java:896) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2483) TestLog.testMinimumRequiredSpaceTooSmallForPut failing
Santiago M. Mola created FLUME-2483: --- Summary: TestLog.testMinimumRequiredSpaceTooSmallForPut failing Key: FLUME-2483 URL: https://issues.apache.org/jira/browse/FLUME-2483 Project: Flume Issue Type: Bug Components: File Channel Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Fix For: v1.6.0 This test is failing when it runs on Travis CI. I haven't been able to further debug it yet. https://travis-ci.org/Stratio/flume/jobs/36758319#L6178 testMinimumRequiredSpaceTooSmallForPut(org.apache.flume.channel.file.TestLog) Time elapsed: 792 sec ERROR! java.io.IOException: Usable space exhaused, only 225056866304 bytes remaining, required 225106210816 bytes at org.apache.flume.channel.file.Log.writeCheckpoint(Log.java:985) at org.apache.flume.channel.file.Log.replay(Log.java:488) at org.apache.flume.channel.file.TestLog.doTestMinimumRequiredSpaceTooSmallForPut(TestLog.java:202) at org.apache.flume.channel.file.TestLog.testMinimumRequiredSpaceTooSmallForPut(TestLog.java:184) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2484) NullPointerException in Kafka Sink test
Santiago M. Mola created FLUME-2484: --- Summary: NullPointerException in Kafka Sink test Key: FLUME-2484 URL: https://issues.apache.org/jira/browse/FLUME-2484 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.6.0 Reporter: Santiago M. Mola Priority: Blocker Fix For: v1.6.0 Kafka Sink test fails on Travis with NullPointerException: https://travis-ci.org/Stratio/flume/jobs/36814710#L6560 Running org.apache.flume.sink.kafka.TestKafkaSink Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 17.061 sec FAILURE! testStaticTopic(org.apache.flume.sink.kafka.TestKafkaSink) Time elapsed: 1823 sec ERROR! java.lang.NullPointerException at org.apache.flume.sink.kafka.TestKafkaSink.testStaticTopic(TestKafkaSink.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Results : Tests in error: testStaticTopic(org.apache.flume.sink.kafka.TestKafkaSink) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FLUME-2484) NullPointerException in Kafka Sink test
[ https://issues.apache.org/jira/browse/FLUME-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14155652#comment-14155652 ] Santiago M. Mola commented on FLUME-2484: - [~gwenshap] Maybe you have some hint for a fix? NullPointerException in Kafka Sink test --- Key: FLUME-2484 URL: https://issues.apache.org/jira/browse/FLUME-2484 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.6.0 Reporter: Santiago M. Mola Priority: Blocker Fix For: v1.6.0 Kafka Sink test fails on Travis with NullPointerException: https://travis-ci.org/Stratio/flume/jobs/36814710#L6560 Running org.apache.flume.sink.kafka.TestKafkaSink Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 17.061 sec FAILURE! testStaticTopic(org.apache.flume.sink.kafka.TestKafkaSink) Time elapsed: 1823 sec ERROR! java.lang.NullPointerException at org.apache.flume.sink.kafka.TestKafkaSink.testStaticTopic(TestKafkaSink.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Results : Tests in error: testStaticTopic(org.apache.flume.sink.kafka.TestKafkaSink) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FLUME-2485) Thrift Source tests fail on Oracle JDK 8
Santiago M. Mola created FLUME-2485: --- Summary: Thrift Source tests fail on Oracle JDK 8 Key: FLUME-2485 URL: https://issues.apache.org/jira/browse/FLUME-2485 Project: Flume Issue Type: Bug Components: Sinks+Sources Affects Versions: v1.6.0 Reporter: Santiago M. Mola Fix For: v1.6.0 Thrift Source tests fail on Oracle JDK 8: https://travis-ci.org/Stratio/flume/jobs/36817396#L6245 testAppendBatch(org.apache.flume.source.TestThriftSource) Time elapsed: 6083 sec FAILURE! java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.flume.source.TestThriftSource.testAppendBatch(TestThriftSource.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2475) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum
[ https://issues.apache.org/jira/browse/FLUME-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2475: Attachment: FLUME-2475-0.patch toLowerCase/toUpperCase used without Locale parameter to manipulate Enum Key: FLUME-2475 URL: https://issues.apache.org/jira/browse/FLUME-2475 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2475-0.patch, FLUME-2475-0.patch .toLowerCase() / .toUpperCase() is used intensively in Flume's code base without passing Locale.ENGLISH to it. This breaks Flume depending on the system locale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FLUME-2475) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum
[ https://issues.apache.org/jira/browse/FLUME-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santiago M. Mola updated FLUME-2475: Attachment: (was: FLUME-2475-0.patch) toLowerCase/toUpperCase used without Locale parameter to manipulate Enum Key: FLUME-2475 URL: https://issues.apache.org/jira/browse/FLUME-2475 Project: Flume Issue Type: Bug Affects Versions: v1.5.0.1 Reporter: Santiago M. Mola Priority: Minor Fix For: v1.6.0 Attachments: FLUME-2475-0.patch .toLowerCase() / .toUpperCase() is used intensively in Flume's code base without passing Locale.ENGLISH to it. This breaks Flume depending on the system locale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
