You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Ewen Cheslack-Postava <me...@ewencp.org> on 2015/02/26 00:27:43 UTC
Review Request 31447: Patch for KAFKA-1881
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/
-----------------------------------------------------------
Review request for kafka.
Bugs: KAFKA-1881
https://issues.apache.org/jira/browse/KAFKA-1881
Repository: kafka
Description
-------
KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
Diffs
-----
core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
Diff: https://reviews.apache.org/r/31447/diff/
Testing
-------
Thanks,
Ewen Cheslack-Postava
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Ewen Cheslack-Postava <me...@ewencp.org>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
>
> Gwen Shapira wrote:
> My gradle.properties has:
> org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
>
> I take it that yours doesn't?
>
> The builds in Apache's jenkins didn't seem to fail on that test either...
>
> Ewen Cheslack-Postava wrote:
> The one checked into the repo does, and I double checked that I'm not overriding that setting in my ~/.gradle/gradle.properties. But as far as I can tell that only applies to the gradle daemon process. It forks off another process to run the tests, which doesn't inherit those settings. If I add this to the build.gradle file next to the overrides for ScalaCompile tasks:
>
> tasks.withType(JavaForkOptions) {
> jvmArgs = ['-XX:MaxPermSize=512m', '-Xmx1024m']
> }
>
> then the forked process gets those settings and the test passes without this patch.
>
> Gwen Shapira wrote:
> huh. so I have no idea why the tests pass on my setup...
I checked my setup by grabbing info from visualvm while the tests were running. Maybe double check the processes running for you when you run the tests, and what settings those processes have had passed to them?
I don't think it's critical since the immediate issue is resolved by the patch, but it would be nice to know why our test environments are inconsistent.
- Ewen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Gwen Shapira <gs...@cloudera.com>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
>
> Gwen Shapira wrote:
> My gradle.properties has:
> org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
>
> I take it that yours doesn't?
>
> The builds in Apache's jenkins didn't seem to fail on that test either...
>
> Ewen Cheslack-Postava wrote:
> The one checked into the repo does, and I double checked that I'm not overriding that setting in my ~/.gradle/gradle.properties. But as far as I can tell that only applies to the gradle daemon process. It forks off another process to run the tests, which doesn't inherit those settings. If I add this to the build.gradle file next to the overrides for ScalaCompile tasks:
>
> tasks.withType(JavaForkOptions) {
> jvmArgs = ['-XX:MaxPermSize=512m', '-Xmx1024m']
> }
>
> then the forked process gets those settings and the test passes without this patch.
huh. so I have no idea why the tests pass on my setup...
- Gwen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Ewen Cheslack-Postava <me...@ewencp.org>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
>
> Gwen Shapira wrote:
> My gradle.properties has:
> org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
>
> I take it that yours doesn't?
>
> The builds in Apache's jenkins didn't seem to fail on that test either...
The one checked into the repo does, and I double checked that I'm not overriding that setting in my ~/.gradle/gradle.properties. But as far as I can tell that only applies to the gradle daemon process. It forks off another process to run the tests, which doesn't inherit those settings. If I add this to the build.gradle file next to the overrides for ScalaCompile tasks:
tasks.withType(JavaForkOptions) {
jvmArgs = ['-XX:MaxPermSize=512m', '-Xmx1024m']
}
then the forked process gets those settings and the test passes without this patch.
- Ewen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Gwen Shapira <gs...@cloudera.com>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
>
> Gwen Shapira wrote:
> My gradle.properties has:
> org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
>
> I take it that yours doesn't?
>
> The builds in Apache's jenkins didn't seem to fail on that test either...
>
> Ewen Cheslack-Postava wrote:
> The one checked into the repo does, and I double checked that I'm not overriding that setting in my ~/.gradle/gradle.properties. But as far as I can tell that only applies to the gradle daemon process. It forks off another process to run the tests, which doesn't inherit those settings. If I add this to the build.gradle file next to the overrides for ScalaCompile tasks:
>
> tasks.withType(JavaForkOptions) {
> jvmArgs = ['-XX:MaxPermSize=512m', '-Xmx1024m']
> }
>
> then the forked process gets those settings and the test passes without this patch.
>
> Gwen Shapira wrote:
> huh. so I have no idea why the tests pass on my setup...
>
> Ewen Cheslack-Postava wrote:
> I checked my setup by grabbing info from visualvm while the tests were running. Maybe double check the processes running for you when you run the tests, and what settings those processes have had passed to them?
>
> I don't think it's critical since the immediate issue is resolved by the patch, but it would be nice to know why our test environments are inconsistent.
>
> Gwen Shapira wrote:
> First, I didn't know about visualvm. Its very sweet :)
>
> Looking at it, the GradleDaemon had the flags I specified above and it had 500M RAM allocated throughout the test. Used mem for this process grew gradually to 250M during the test execution.
> GradleWorkerMain actually ran the tests. It had no memory-related JVM flags. It started with 250M allocated and jumped to 750M when testDeleteTopicWithCleaner started (with 522M used).
>
> With that info, I suspect that the default JVM settings on my Mac OS X Yosemite, JVM 1.7.0.67 were different.
>
> I looked at: java -XX:+PrintFlagsFinal -version
> and found:
> uintx MaxHeapSize := 4294967296 {product}
>
> Thats pretty large :)
>
> Ewen Cheslack-Postava wrote:
> Ok, so maybe this was a JDK6 -> JDK7 change. I'm on JDK6 since we're still supporting it. Same output for me:
>
> uintx MaxHeapSize = 132120576 {product}
>
> So mystery solved. These things would probably get caught more easily if we had decent test coverage across multiple JDK versions...
Once we have the pre-commit hook running tests for us and reporting in the JIRA, we can add multiple JDK versions.
- Gwen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Ewen Cheslack-Postava <me...@ewencp.org>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
>
> Gwen Shapira wrote:
> My gradle.properties has:
> org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
>
> I take it that yours doesn't?
>
> The builds in Apache's jenkins didn't seem to fail on that test either...
>
> Ewen Cheslack-Postava wrote:
> The one checked into the repo does, and I double checked that I'm not overriding that setting in my ~/.gradle/gradle.properties. But as far as I can tell that only applies to the gradle daemon process. It forks off another process to run the tests, which doesn't inherit those settings. If I add this to the build.gradle file next to the overrides for ScalaCompile tasks:
>
> tasks.withType(JavaForkOptions) {
> jvmArgs = ['-XX:MaxPermSize=512m', '-Xmx1024m']
> }
>
> then the forked process gets those settings and the test passes without this patch.
>
> Gwen Shapira wrote:
> huh. so I have no idea why the tests pass on my setup...
>
> Ewen Cheslack-Postava wrote:
> I checked my setup by grabbing info from visualvm while the tests were running. Maybe double check the processes running for you when you run the tests, and what settings those processes have had passed to them?
>
> I don't think it's critical since the immediate issue is resolved by the patch, but it would be nice to know why our test environments are inconsistent.
>
> Gwen Shapira wrote:
> First, I didn't know about visualvm. Its very sweet :)
>
> Looking at it, the GradleDaemon had the flags I specified above and it had 500M RAM allocated throughout the test. Used mem for this process grew gradually to 250M during the test execution.
> GradleWorkerMain actually ran the tests. It had no memory-related JVM flags. It started with 250M allocated and jumped to 750M when testDeleteTopicWithCleaner started (with 522M used).
>
> With that info, I suspect that the default JVM settings on my Mac OS X Yosemite, JVM 1.7.0.67 were different.
>
> I looked at: java -XX:+PrintFlagsFinal -version
> and found:
> uintx MaxHeapSize := 4294967296 {product}
>
> Thats pretty large :)
Ok, so maybe this was a JDK6 -> JDK7 change. I'm on JDK6 since we're still supporting it. Same output for me:
uintx MaxHeapSize = 132120576 {product}
So mystery solved. These things would probably get caught more easily if we had decent test coverage across multiple JDK versions...
- Ewen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Gwen Shapira <gs...@cloudera.com>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
>
> Gwen Shapira wrote:
> My gradle.properties has:
> org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
>
> I take it that yours doesn't?
>
> The builds in Apache's jenkins didn't seem to fail on that test either...
>
> Ewen Cheslack-Postava wrote:
> The one checked into the repo does, and I double checked that I'm not overriding that setting in my ~/.gradle/gradle.properties. But as far as I can tell that only applies to the gradle daemon process. It forks off another process to run the tests, which doesn't inherit those settings. If I add this to the build.gradle file next to the overrides for ScalaCompile tasks:
>
> tasks.withType(JavaForkOptions) {
> jvmArgs = ['-XX:MaxPermSize=512m', '-Xmx1024m']
> }
>
> then the forked process gets those settings and the test passes without this patch.
>
> Gwen Shapira wrote:
> huh. so I have no idea why the tests pass on my setup...
>
> Ewen Cheslack-Postava wrote:
> I checked my setup by grabbing info from visualvm while the tests were running. Maybe double check the processes running for you when you run the tests, and what settings those processes have had passed to them?
>
> I don't think it's critical since the immediate issue is resolved by the patch, but it would be nice to know why our test environments are inconsistent.
First, I didn't know about visualvm. Its very sweet :)
Looking at it, the GradleDaemon had the flags I specified above and it had 500M RAM allocated throughout the test. Used mem for this process grew gradually to 250M during the test execution.
GradleWorkerMain actually ran the tests. It had no memory-related JVM flags. It started with 250M allocated and jumped to 750M when testDeleteTopicWithCleaner started (with 522M used).
With that info, I suspect that the default JVM settings on my Mac OS X Yosemite, JVM 1.7.0.67 were different.
I looked at: java -XX:+PrintFlagsFinal -version
and found:
uintx MaxHeapSize := 4294967296 {product}
Thats pretty large :)
- Gwen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Gwen Shapira <gs...@cloudera.com>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
>
> Ewen Cheslack-Postava wrote:
> This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
My gradle.properties has:
org.gradle.jvmargs=-XX:MaxPermSize=512m -Xmx1024m
I take it that yours doesn't?
The builds in Apache's jenkins didn't seem to fail on that test either...
- Gwen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Ewen Cheslack-Postava <me...@ewencp.org>.
> On Feb. 26, 2015, 3:07 a.m., Gwen Shapira wrote:
> > Ah, now I get what "dedupe buffer" refers to :)
> >
> > I never managed to reproduce the oom, but this looks like the right fix.
This happened consistently for me, which provided good motivation to figure out how to fix it :) It looks like the tests use the default JVM settings (build.gradle has overrides for compile, but not for test), so the 500 MB allocation was always failing since it obviously exceeds the default 128 MB heap. Now I'm wondering if other people are running with different settings. Maybe if you have a gradle daemon running that was started with a bigger max heap size?
- Ewen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>
Re: Review Request 31447: Patch for KAFKA-1881
Posted by Gwen Shapira <gs...@cloudera.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/31447/#review74200
-----------------------------------------------------------
Ship it!
Ah, now I get what "dedupe buffer" refers to :)
I never managed to reproduce the oom, but this looks like the right fix.
- Gwen Shapira
On Feb. 25, 2015, 11:27 p.m., Ewen Cheslack-Postava wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31447/
> -----------------------------------------------------------
>
> (Updated Feb. 25, 2015, 11:27 p.m.)
>
>
> Review request for kafka.
>
>
> Bugs: KAFKA-1881
> https://issues.apache.org/jira/browse/KAFKA-1881
>
>
> Repository: kafka
>
>
> Description
> -------
>
> KAFKA-1881: Fix out of memory error in testDeleteTopicWithCleaner by making the dedupe buffer much smaller.
>
>
> Diffs
> -----
>
> core/src/test/scala/unit/kafka/admin/DeleteTopicTest.scala 0cbd72684a0cc6fe9f1fba2dc834de675b2eb994
>
> Diff: https://reviews.apache.org/r/31447/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Ewen Cheslack-Postava
>
>