[jira] [Created] (HADOOP-10465) Fix use of generic within SortedMapWritable
Bertrand Dechoux created HADOOP-10465: - Summary: Fix use of generic within SortedMapWritable Key: HADOOP-10465 URL: https://issues.apache.org/jira/browse/HADOOP-10465 Project: Hadoop Common Issue Type: Improvement Affects Versions: 2.3.0 Reporter: Bertrand Dechoux Priority: Minor SortedMapWritable could use Generics the right way so that there is no warning within the implementation and more important for the consumer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HADOOP-10466) Lower the log level in UserGroupInformation
Nicolas Liochon created HADOOP-10466: Summary: Lower the log level in UserGroupInformation Key: HADOOP-10466 URL: https://issues.apache.org/jira/browse/HADOOP-10466 Project: Hadoop Common Issue Type: Improvement Affects Versions: 2.3.0, 3.0.0 Reporter: Nicolas Liochon Assignee: Nicolas Liochon Fix For: 3.0.0, 2.5.0 That's more or less the continuation of HADOOP-10015... Some info should be debug if we apply the same policy. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release Apache Hadoop 2.4.0
Gera,
Apologies for the late response, I decided to take the weekend off! *smile*
Thanks for the feedback, I took a look at your list and here are some
observations:
On Apr 4, 2014, at 5:06 PM, Gera Shegalov g...@shegalov.com wrote:
I built the release from the rc tag, enabled timeline history service and
ran a sleep job on a pseudo-distributed cluster.
I encourage another rc, for 2.4.0 (non-binding)
1) Despite the discussion on YARN-1701, timeline AHS still sets
yarn.timeline-service.generic-application-history.fs-history-store.uri to a
location under ${hadoop.log.dir} that is meant for local file system, but
uses it on HDFS by default.
This is certainly unfortunate, but essentially it's just a bad default config
value. As such, there is a pretty simple clear workaround which I'll
release-doc.
2) Critical patch for WebHdfs/Hftp to fix the filesystem contract HDFS-6143
is not included
I had already commented on the jira around the time of RC as you may remember.
Also, this isn't a regression - this bug has existed for quite a while now.
Furthermore, there are some back-compatibility concerns we still need to
address.
3) Several patches that already proved themselves useful for diagnostics in
production and have been available for some months are still not included.
MAPREDUCE-5044/YARN-1515 is the most obvious example. Our users need to see
where the task container JVM got stuck when it was timed out by AM.
Please accept my personal apologies, this wasn't on my radar to review. In
future, pls drop me a note if you don't see any activity on a jira you care
about - I'm sure others like Vinod, Jason etc. would love to help too; it's
just something that got missed by the community collectively. Having said that,
as you can imagine, new features cannot be a blocker to a release; this sets up
a dynamic where it's impossible to please everyone and we cannot ship any
release… as you may have seen it's been quite an effort for the last 3-4 weeks
just to corral everyone into fixing/reviewing/committing blocker bugs itself.
*smile*
Overall, please feel free to share your feedback, but the above list doesn't
seem to have a critically bad release blocker.
Also, I plan to follow up with a 2.4.1 in a couple of weeks; I'll make sure to
include as much as your list as possible - and future ones.
thanks,
Arun
Thanks,
Gera
On Fri, Apr 4, 2014 at 3:51 PM, Azuryy azury...@gmail.com wrote:
Arun,
Do you mean you will cut another RC for 2.4?
Sent from my iPhone5s
On 2014年4月5日, at 3:50, Arun C. Murthy a...@hortonworks.com wrote:
Thanks for helping Tsuyoshi. Pls mark them as Blockers and set the
fix-version to 2.4.1.
Thanks again.
Arun
On Apr 3, 2014, at 11:38 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.com
wrote:
Hi,
Updated a test result log based on the result of 2.4.0-rc0:
https://gist.github.com/oza/9965197
IMO, there are some blockers to be fixed:
* MAPREDUCE-5815(TestMRAppMaster failure)
* YARN-1872(TestDistributedShell failure)
* HDFS: TestSymlinkLocalFSFileSystem failure on Linux (I cannot find
JIRA about this failure)
Now I'm checking the problem reported by Azuryy.
Thanks,
- Tsuyoshi
On Fri, Apr 4, 2014 at 8:55 AM, Tsuyoshi OZAWA
ozawa.tsuyo...@gmail.com wrote:
Hi,
Ran tests and confirmed that some tests(TestSymlinkLocalFSFileSystem)
fail.
The log of the test failure is as follows:
https://gist.github.com/oza/9965197
Should we fix or disable the feature?
Thanks,
- Tsuyoshi
On Mon, Mar 31, 2014 at 6:22 PM, Arun C Murthy a...@hortonworks.com
wrote:
Folks,
I've created a release candidate (rc0) for hadoop-2.4.0 that I would
like to get released.
The RC is available at:
http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0
The RC tag in svn is here:
https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc0
The maven artifacts are available via repository.apache.org.
Please try the release and vote; the vote will run for the usual 7
days.
thanks,
Arun
--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or
entity to
which it is addressed and may contain information that is
confidential,
privileged and exempt from disclosure under applicable law. If the
reader
of this message is not the intended recipient, you are hereby
notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender
immediately
and delete it from your system. Thank You.
--
- Tsuyoshi
--
- Tsuyoshi
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity
to
which it is addressed and may contain information that is confidential,
privileged and exempt
Re: [VOTE] Release Apache Hadoop 2.4.0
On Thu, Apr 3, 2014 at 4:55 PM, Tsuyoshi OZAWA ozawa.tsuyo...@gmail.comwrote: Hi, Ran tests and confirmed that some tests(TestSymlinkLocalFSFileSystem) fail. The log of the test failure is as follows: https://gist.github.com/oza/9965197 Should we fix or disable the feature? Symlinks is still not completed, hence disable. sanjay Thanks, - Tsuyoshi On Mon, Mar 31, 2014 at 6:22 PM, Arun C Murthy a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.4.0 that I would like to get released. The RC is available at: http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0 The RC tag in svn is here: https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc0 The maven artifacts are available via repository.apache.org. Please try the release and vote; the vote will run for the usual 7 days. thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- - Tsuyoshi -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [VOTE] Release Apache Hadoop 2.4.0
+1 (binding) Verified the signatures and hashes for both src and binary tars. Built from the source, the binary distribution and the documentation. Started a single node cluster and tested the following: # Started HDFS cluster, verified the hdfs CLI commands such ls, copying data back and forth, verified namenode webUI etc. # Ran some tests such as sleep job, TestDFSIO, NNBench etc. I agree with Arun's anaylysis. At this time, the bar for blockers should be quite high. We can do a dot release if people want some more bug fixes. On Mon, Mar 31, 2014 at 2:22 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.4.0 that I would like to get released. The RC is available at: http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0 The RC tag in svn is here: https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc0 The maven artifacts are available via repository.apache.org. Please try the release and vote; the vote will run for the usual 7 days. thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- http://hortonworks.com/download/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [VOTE] Release Apache Hadoop 2.4.0
+1 (Binding) On Mon, Apr 7, 2014 at 11:52 AM, Suresh Srinivas sur...@hortonworks.comwrote: +1 (binding) Verified the signatures and hashes for both src and binary tars. Built from the source, the binary distribution and the documentation. Started a single node cluster and tested the following: # Started HDFS cluster, verified the hdfs CLI commands such ls, copying data back and forth, verified namenode webUI etc. # Ran some tests such as sleep job, TestDFSIO, NNBench etc. I agree with Arun's anaylysis. At this time, the bar for blockers should be quite high. We can do a dot release if people want some more bug fixes. On Mon, Mar 31, 2014 at 2:22 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.4.0 that I would like to get released. The RC is available at: http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0 The RC tag in svn is here: https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc0 The maven artifacts are available via repository.apache.org. Please try the release and vote; the vote will run for the usual 7 days. thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- http://hortonworks.com/download/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
RE: [VOTE] Release Apache Hadoop 2.4.0
+1 (binding). Ran it with Apache Tez. I agree with Suresh about including only critical regressions/bugs at this point. The less code we change the less new bugs we bring in at the last moment. Bikas -Original Message- From: Jonathan Eagles [mailto:jeag...@gmail.com] Sent: Monday, April 07, 2014 9:55 AM To: hdfs-...@hadoop.apache.org Cc: common-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org; yarn-...@hadoop.apache.org Subject: Re: [VOTE] Release Apache Hadoop 2.4.0 +1 (Binding) On Mon, Apr 7, 2014 at 11:52 AM, Suresh Srinivas sur...@hortonworks.comwrote: +1 (binding) Verified the signatures and hashes for both src and binary tars. Built from the source, the binary distribution and the documentation. Started a single node cluster and tested the following: # Started HDFS cluster, verified the hdfs CLI commands such ls, copying data back and forth, verified namenode webUI etc. # Ran some tests such as sleep job, TestDFSIO, NNBench etc. I agree with Arun's anaylysis. At this time, the bar for blockers should be quite high. We can do a dot release if people want some more bug fixes. On Mon, Mar 31, 2014 at 2:22 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.4.0 that I would like to get released. The RC is available at: http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0 The RC tag in svn is here: https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc 0 The maven artifacts are available via repository.apache.org. Please try the release and vote; the vote will run for the usual 7 days. thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- http://hortonworks.com/download/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Plans of moving towards JDK7 in trunk
It looks to me that the majority of this thread welcomes JDK7. Just to reiterate, there are two separate questions here: 1. When should hadoop-trunk can be only built on top of JDK7? 2. When should hadoop-branch-2 can be only built on top of JDK7? The answers of the above questions directly imply when and how hadoop can break the compatibility for JDK6 runtime. It looks that there are quite a bit of compatibility concerns of question (2). Should we focus on question (1) and come up with a plan? Personally I'd love to see (1) to happen as soon as possible. ~Haohui On Sun, Apr 6, 2014 at 11:37 AM, Steve Loughran ste...@hortonworks.comwrote: On 5 April 2014 20:54, Raymie Stata rst...@altiscale.com wrote: To summarize the thread so far: a) Java7 is already a supported compile- and runtime environment for Hadoop branch2 and trunk b) Java6 must remain a supported compile- and runtime environment for Hadoop branch2 c) (b) implies that branch2 must stick to Java6 APIs I wonder if point (b) should be revised. We could immediately deprecate Java6 as a runtime (and thus compile-time) environment for Hadoop. We could end support for in some published time frame (perhaps 3Q2014). That is, we'd say that all future 2.x release past some date would not be guaranteed to run on Java6. This would set us up for using Java7 APIs into branch2. I'll let others deal with that question. An alternative might be to keep branch2 on Java6 APIs forever, and to start using Java7 APIs in trunk relatively soon. The concern here would be that trunk isn't getting the kind of production torture testing that branch2 is subjected to, and won't be for a while. If trunk and branch2 diverge too much too quickly, trunk could become a nest of bugs, endangering the timeline and quality of Hadoop 3. This would argue for keeping trunk and branch2 in closer sync (maybe until a branch3 is created and starts getting used by bleeding-edge users). However, as just suggested, keeping them in closer sync need _not_ imply that Java7 features be avoided indefinitely: again, with sufficient warning, Java6 support could be sunset within branch2. One thing we could do is have a policy towards new features where there's consensus that they won't go into branch-2, especially things in their own JARs. Here we could consider a policy of build set up to be Java 7 only, with Java7 APIs. That would be justified if there was some special java 7 feature -such as its infiniband support. Add a feature like that in its own module (under hadoop-tools, presumably), and use Java7 and Java 7 libraries. If someone really did want to use the feature in hadoop-2, they'd be able to, in a java7+ only backport. On a related note, Steve points out that we need to start thinking about Java8. YES!! Lambdas are a Really Big Deal! If we sunset Java6 in a few quarters, maybe we can add Java8 compile and runtime (but not API) support about the same time. This does NOT imply bringing Java8 APIs into branch2: Even if we do allow Java7 APIs into branch2 in the future, I doubt that bringing Java8 APIs into it will ever make sense. However, if Java8 is a supported runtime environment for Hadoop 2, that sets us up for using Java8 APIs for the eventual branch3 sometime in 2015. Testing Hadoop on Java 8 would let the rest of the stack move forward. In the meantime, can I point out that both Scala-on-Java7 and Groovy-on-Java 7 offer closures quite nicely, with performance by way of INVOKEDYNAMIC opcodes. -steve -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You. -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: Plans of moving towards JDK7 in trunk
On Sat, Apr 5, 2014 at 12:54 PM, Raymie Stata rst...@altiscale.com wrote: To summarize the thread so far: a) Java7 is already a supported compile- and runtime environment for Hadoop branch2 and trunk b) Java6 must remain a supported compile- and runtime environment for Hadoop branch2 c) (b) implies that branch2 must stick to Java6 APIs I wonder if point (b) should be revised. We could immediately deprecate Java6 as a runtime (and thus compile-time) environment for Hadoop. We could end support for in some published time frame (perhaps 3Q2014). That is, we'd say that all future 2.x release past some date would not be guaranteed to run on Java6. This would set us up for using Java7 APIs into branch2. IMO we should not drop support for Java 6 in a minor update of a stable release (v2). I don't think the larger Hadoop user base would find it acceptable that upgrading to a minor update caused their systems to stop working because they didn't upgrade Java. There are people still getting support for Java 6. For the same reason, the various distributions will not want to drop support in a minor update of their products also, and since distros are using the Apache v2.x update releases as the basis for their updates it would mean they have to stop shipping v2.x updates, which makes it harder to collaborate upstream. Your point with regard to testing and releasing trunk is valid, though we need to address that anyway, outside the context of Java versions. Thanks, Eli
[jira] [Created] (HADOOP-10467) Enable proxyuser specification to support list of users in addition to list of groups.
Benoy Antony created HADOOP-10467: - Summary: Enable proxyuser specification to support list of users in addition to list of groups. Key: HADOOP-10467 URL: https://issues.apache.org/jira/browse/HADOOP-10467 Project: Hadoop Common Issue Type: Improvement Components: security Reporter: Benoy Antony Assignee: Benoy Antony Today , the proxy user specification supports only list of groups. In some cases, it is useful to specify the list of users in addition to list of groups. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release Apache Hadoop 2.4.0
With 11 +1s (4 binding) and no -1s the vote passes. Thanks to everyone who tried out the release and passed their feedback along. I'll send a note out once I actually get the bits out and the site updated etc. thanks, Arun On Mar 31, 2014, at 2:22 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.4.0 that I would like to get released. The RC is available at: http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0 The RC tag in svn is here: https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc0 The maven artifacts are available via repository.apache.org. Please try the release and vote; the vote will run for the usual 7 days. thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
Re: [VOTE] Release Apache Hadoop 2.4.0
Here's my late +1, was just finishing up looking at the release. - Verified signatures and digests - Examined LICENSE file - Installed binary distribution, ran some sample MapReduce jobs and examined logs and job history - Built from source Jason On 04/07/2014 03:04 PM, Arun C Murthy wrote: With 11 +1s (4 binding) and no -1s the vote passes. Thanks to everyone who tried out the release and passed their feedback along. I'll send a note out once I actually get the bits out and the site updated etc. thanks, Arun On Mar 31, 2014, at 2:22 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, I've created a release candidate (rc0) for hadoop-2.4.0 that I would like to get released. The RC is available at: http://people.apache.org/~acmurthy/hadoop-2.4.0-rc0 The RC tag in svn is here: https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.4.0-rc0 The maven artifacts are available via repository.apache.org. Please try the release and vote; the vote will run for the usual 7 days. thanks, Arun -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
Re: Hadoop v1.8 data transfer protocol
Hi Harsh, I did mean 0.18 - sorry about the typo. I read through the BlockSender.sendChunks method once again and noticed that I wasn't reading the checksum byte array correctly in my code. Thanks for the help, Dhaivat Pandya On Sun, Apr 6, 2014 at 8:59 PM, Harsh J ha...@cloudera.com wrote: There's been no Apache Hadoop release versioned v1.8 historically, nor is one upcoming. Do you mean 0.18? Either way, can you point to the specific code lines in BlockSender which have you confused? The sendBlock and sendPacket methods would interest you I assume, but they appear to be well constructed/named internally and commented in a few important spots. On Mon, Apr 7, 2014 at 6:39 AM, Dhaivat Pandya dhaivatpan...@gmail.com wrote: Hi, I'm trying to figure out how data is transferred between client and DataNode in Hadoop v1.8. This is my understanding so far: The client first fires an OP_READ_BLOCK request. The DataNode responds with a status code, checksum header, chunk offset, packet length, sequence number, the last packet boolean, the length and the data (in that order). However, I'm running into an issue. First of all, which of these lengths describes the length of the data? I tried both PacketLength and Length it seems that they leave data on the stream (I tried to cat a file with the numbers 1-1000 in it). Also, how does the DataNode signal the start of another packet? After Length number of bytes have been read, I assumed that the header would be repeated, but this is not the case (I'm not getting sane values for any of the fields of the header). I've looked through the DataXceiver, BlockSender, DFSClient (RemoteBlockReader) classes but I still can't quite grasp how this data transfer is conducted. Any help would be appreciated, Dhaivat Pandya -- Harsh J
[jira] [Created] (HADOOP-10468) TestMetricsSystemImpl.testMultiThreadedPublish fails intermediately
Haohui Mai created HADOOP-10468:
---
Summary: TestMetricsSystemImpl.testMultiThreadedPublish fails
intermediately
Key: HADOOP-10468
URL: https://issues.apache.org/jira/browse/HADOOP-10468
Project: Hadoop Common
Issue Type: Improvement
Reporter: Haohui Mai
Assignee: Haohui Mai
{{TestMetricsSystemImpl.testMultiThreadedPublish}} can fail intermediately due
to the insufficient size of the sink queue:
{code}
2014-04-06 21:34:55,269 WARN impl.MetricsSinkAdapter
(MetricsSinkAdapter.java:putMetricsImmediate(107)) - Collector has a full queue
and can't consume the given metrics.
2014-04-06 21:34:55,270 WARN impl.MetricsSinkAdapter
(MetricsSinkAdapter.java:putMetricsImmediate(107)) - Collector has a full queue
and can't consume the given metrics.
2014-04-06 21:34:55,271 WARN impl.MetricsSinkAdapter
(MetricsSinkAdapter.java:putMetricsImmediate(107)) - Collector has a full queue
and can't consume the given metrics.
{code}
The unit test should increase the default queue size to avoid intermediate
failure.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
