[
https://issues.apache.org/jira/browse/ZOOKEEPER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696907#action_12696907
]
Hadoop QA commented on ZOOKEEPER-337:
-
+1 overall. Here are the results of testing
[
https://issues.apache.org/jira/browse/ZOOKEEPER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12696925#action_12696925
]
Hadoop QA commented on ZOOKEEPER-347:
-
-1 overall. Here are the results of testing
[
https://issues.apache.org/jira/browse/ZOOKEEPER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-370:
-
Status: Open (was: Patch Available)
There is no hudson report after
[
https://issues.apache.org/jira/browse/ZOOKEEPER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-370:
-
Status: Patch Available (was: Open)
Fix critical problems reported
to implement jdiff
---
Key: ZOOKEEPER-371
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371
Project: Zookeeper
Issue Type: Improvement
Components: build
Affects Versions: 3.2.0
Environment: to
[
https://issues.apache.org/jira/browse/ZOOKEEPER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697080#action_12697080
]
Patrick Hunt commented on ZOOKEEPER-347:
this fixes a C code gcc compiler
[
https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-29:
Attachment: ZOOKEEPER-29.patch
This new patch is partially functional.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697112#action_12697112
]
Mahadev konar commented on ZOOKEEPER-29:
flavio,
i just took a cursory look at
[
https://issues.apache.org/jira/browse/ZOOKEEPER-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697162#action_12697162
]
Hadoop QA commented on ZOOKEEPER-370:
-
-1 overall. Here are the results of testing
Also, I should mention that some of the errors Andrew was seeing are related
to ZOOKEEPER-344:
I see this kind of stuff:
2009-04-07 17:58:13,344 - WARN [NIOServerCxn.Factory:2181:
nioserverc...@417] - Exception
causing close of session 0x2208296c38e due to
java.io.IOException: Read error
What are you running for a session timeout on your clients?
Can you run with something like jvisualvm or jconsole, and watch the gc
activity when the session timeouts occur? Might give you some insight.
Have you tried one of the alternative GC's available in the VM?
This is good to know. It will allow us to try an replicate the
situation, which we haven't been able to do.
I'm hoping we can come up with something that we can proactively do to
address this...
Patrick
Nitay wrote:
Also, I should mention that some of the errors Andrew was seeing are
[
https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697182#action_12697182
]
Flavio Paiva Junqueira commented on ZOOKEEPER-29:
-
Mahadev, I'm ok with
The default session timeout in HBase is currently 10 seconds. Bumping it up
to 30 and 60 reduced SessionExpired exceptions, according to Andrew. I
believe Andrew did run it under jconsole. He was also tuning GC parameters.
He mentioned running using incremental garbage collector
Nitay,
Thanks for sending us the info.
We have experienced such gc problem in our HDFS (hadoop file system) setups.
The gc had been quite a problem for us with the Namenode (hadoop hdfs)
process. We have seen the namenode just stalling for minutes doing garbage
collection. We currently run the
Nitay is correct about the native threads. Using the pure Java API,
the garbage collector will occasionally pause other Java threads to do
a full mark and sweep. Even switching to the concurrent collector only
delays the problem. The issues is mixing a high throughput application
(HBase) with a
[
https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697220#action_12697220
]
Stu Hood commented on ZOOKEEPER-29:
---
Two comments:
This ticket seems to overlap
[
https://issues.apache.org/jira/browse/ZOOKEEPER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-347:
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch
I'm curious about your session scenario. If your servers can hang for X seconds
without a problem and Y is your session timeout, why would you set Y X? In
your case if you set your session timeout to 5 secs for example, but your
server can hang for 20 seconds doing GC, your clients cannot
[
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697277#action_12697277
]
Patrick Hunt commented on ZOOKEEPER-78:
---
These comments are relative to the java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12697294#action_12697294
]
Patrick Hunt commented on ZOOKEEPER-369:
It would be great if we could ping the
21 matches
Mail list logo
